The sprint that shipped twice as much and understood half as much

An engineering manager at a logistics company described two consecutive sprints that told a story together. In the first, with AI tools running hot, the team shipped roughly twice their usual volume of features. It was their best sprint on paper by a wide margin. In the second sprint, something strange happened. The team spent most of their time not building new things but trying to understand what they had built in the first sprint, because when they went to extend it, debug it, and connect it to the next round of work, they discovered they did not really understand their own recent code. The record output of the first sprint had come partly at the expense of their comprehension of it, and the second sprint was where they paid that back.

Output can outrun understanding

There is an assumption baked into how teams think about shipping, that when a feature is shipped, the team understands it. This was reliably true when people wrote the code by hand, because writing code is itself an act of understanding it. You cannot write a function without, in the process, coming to understand it. Shipping and understanding rose together, so measuring output was a decent proxy for the team’s grasp of the system.

AI tools decouple the two. When an agent writes the code, the team can ship it without ever developing the understanding that hand-writing would have forced. The output rises, the comprehension does not follow, and a gap opens between how much the team has shipped and how much it actually understands. That gap is invisible in the sprint where the code ships, because the code works and the tickets close. It becomes visible in the next sprint, when the team has to build on, debug, or change the code, and discovers it is working with a codebase it does not know as well as it should. The velocity of the first sprint was borrowed from the comprehension the team would need in the second, and the loan comes due the moment they have to touch what they shipped.

The worst version of this compounds. If each sprint ships more than it understands, the deficit grows, and the codebase becomes progressively less known to the people responsible for it. Eventually a large amount of production code is understood by no one, which is a fragile place to be, and the team got there one high-output sprint at a time, each one looking like a win.

Keep understanding close to output

The lesson is that shipping and understanding have to stay close together, and when AI tools let output outrun comprehension, the team has to deliberately close the gap that hand-writing used to close for free. Understanding is no longer a byproduct of shipping. It has to be its own act.

What teams do to keep comprehension up with output.

Require the author to understand what they ship, in their own words, so shipping still implies grasping.
Keep changes small enough to actually understand, rather than shipping large generated diffs nobody fully holds.
Treat understanding as part of done, so a feature is not done until someone could debug and extend it.
Watch for the comprehension gap directly, since output metrics will not show it until it surfaces as rework.
Resist the record sprint that borrows against next sprint, when the output came at the cost of knowing the code.

The point is not to ship less. It is to make sure that what you ship, you also understand, so the next sprint is building on knowledge instead of paying off a deficit.

How we think about it at Density Labs

The high-output sprint followed by the low-output understanding sprint is a pattern we see when teams first lean hard on AI tools. The first sprint feels like a breakthrough, and it partly is, but some of that output was borrowed from the team’s comprehension of its own code, and the next sprint is where the debt shows up as time spent understanding what should already be understood.

When we help a team adopt AI tools sustainably, we keep understanding tied to output, so the velocity is real rather than borrowed. The goal is a team that ships more and knows what it shipped, not one that ships more and spends the following sprint catching up to its own codebase.

Shipping used to mean understanding, because you wrote it. Now you can ship what you do not understand, and next sprint you find out what that cost.