Developers Are Shipping Twice as Fast. The Code Is Half as Understood. This Is Going to Hurt.

The GitHub data is real. Developers using AI coding assistants ship more code, faster, with fewer context switches.

Nobody is arguing with the velocity numbers anymore.

The argument happening now, quietly, inside engineering teams that have been running with AI assistance for twelve to eighteen months, is about a different number entirely.

Not how fast the code ships. How well anyone understands it after it ships.

And that number, in a lot of teams, is going in the wrong direction fast.

The metric that vanished

There used to be an implicit quality gate in software development that nobody called a quality gate.

It was called writing the code.

The act of writing something yourself, debugging why it did not work, reading the error message, changing the approach, writing it again, was also the act of building a mental model of what you built. By the time the code worked, you understood it.

Not perfectly. Not completely. But well enough to debug it at 3am. Well enough to know where to look when something broke. Well enough to explain it to the next person.

That gate is gone for a significant fraction of production code being shipped right now.

The code was generated. It was reviewed at a surface level. It passed tests. It shipped. The developer who shipped it could not, if pressed, explain why it works. They could explain what it does. That is a different thing.

The two types of not understanding

There is a version of not fully understanding your code that is completely fine.

You are using a library. You do not know every line of its implementation. You know its interface, its behaviour, its failure modes. You trust it because it has a track record, documentation, a community that has stress-tested it. You have appropriate confidence in something you did not write.

This is normal. This is how software has always been built.

There is another version that is not fine at all.

You are using code you wrote. Or code written in your name by an AI assistant running in your editor. It is in your repository. You own it. You are accountable for it. And you cannot fully explain why it does what it does.

Not because it is a battle-tested library someone else maintains. Because it was generated in thirty seconds by a tool optimised for plausibility, and plausible is not the same as correct, and you approved it because it looked right and the tests passed.

This is the version that is filling production codebases right now.

What “the tests passed” actually guarantees

Tests passing means the code behaves correctly in the scenarios the tests cover.

It does not mean the code is correct. It means it is correct for those inputs, under those conditions, in that test environment.

The scenarios the tests cover are the scenarios the developer thought to test. Which are the scenarios the developer understood well enough to write tests for. Which, when the code was generated rather than understood, are the obvious scenarios. The happy path. The cases the AI suggested tests for, which are the cases the AI was confident about.

The cases nobody thought to test are the cases where the AI made an assumption that seemed reasonable and was wrong. They are the cases that only appear under specific load conditions. The cases involving data the developer did not have in their test fixtures because they did not know to expect it.

These cases exist in every non-trivial piece of code. In AI-generated code they are more numerous, because the developer who reviewed the code did not spend enough time with it to have the intuitions that would suggest adversarial test cases.

They will appear in production. That is the only question: when.

The incident that nobody connects

Here is what the new version of this incident looks like.

Something breaks in production. The on-call engineer opens the relevant file. They read the code. It does not immediately make sense to them, not because it is unusually complex, but because they have no memory of writing it. They were not the one who wrote it. Or they did write it, assisted, six weeks ago, and the understanding that should have accompanied writing it was never built.

They spend forty minutes understanding code they should be able to debug in ten. The incident takes longer than it should.

The postmortem identifies the bug. It does not identify the underlying condition: that the team is operating production code they do not fully understand, and that condition applies to a growing proportion of the codebase, and that the next incident will have the same shape.

The postmortem closes. The condition remains.

The velocity paradox

Here is the part that makes this hard to address.

The teams shipping most aggressively with AI assistance are, by most measurements, the highest performing teams. They are shipping more features. Their sprint velocity is higher. Their time-to-market is faster.

These are real advantages. They are also creating a specific kind of fragility that does not show up in any of those metrics.

The codebase is growing faster than understanding of it.

In traditional development, understanding scales roughly with the codebase because the people building the codebase are also the people understanding it. You write it, you understand it. The ratio stays roughly constant.

With AI-assisted development at high velocity, the codebase grows at the rate AI can generate it. Understanding grows at the rate humans can absorb it. Those are not the same rate.

The gap between the two is the new technical debt. It does not look like old technical debt. There are no obviously bad patterns. The code is often cleaner than what a rushed human would have written. But it is foreign in a way that matters: the team that owns it does not have a deep mental model of it, and mental models are what make debugging fast, changes safe, and systems maintainable.

The teams that are getting this right

The best teams using AI coding assistants are not using them less. They are using them differently.

They use AI to generate a starting point and then they interrogate it. Not just review it. Interrogate it. Why did you structure it this way? What happens if this value is null? What is the failure mode if this service is unavailable? What does this function do when the list is empty?

They treat AI-generated code the way a senior engineer treats code from a junior: useful, needs verification, cannot be trusted without understanding.

They write the tests themselves, not because tests cannot be generated, but because the act of writing tests is the act of building the mental model. Generating tests and generating code are both fast. Understanding is not fast. The test-writing is the understanding.

They measure understanding explicitly. Before code ships, someone on the team who did not write it has to be able to explain it to someone who has never seen it. Not read it and confirm it looks right. Explain it. Teach it. If nobody can do that, the code is not ready to ship regardless of what the tests show.

The number that actually matters

GitHub can tell you how many lines of code your team shipped this month. Your project management tool can tell you how many story points were completed. Your deployment pipeline can tell you how many releases went out.

None of these tools can tell you what percentage of your production codebase your team could confidently debug at 3am.

That number is not tracked anywhere. It is not measured. It has no dashboard.

But it determines, more than any of the tracked metrics, whether the velocity you are building is compounding into a real advantage or accumulating into a liability that will arrive all at once when the system that nobody fully understands breaks in a way nobody anticipated.

The teams winning with AI coding tools in the long run will not be the ones that generated the most code.

They will be the ones that understood what they shipped.

Those are increasingly different teams.

And the gap between them is widening every sprint.