The stall
Why throughput plateaus after the tools go on, and what the plateau is actually telling you.
You turned the agents on. For a few weeks it felt fast. Then the gains flattened, and nobody could say exactly why.
The stall is not a failure. It is a signal. It usually means the team sped up one stage of the lifecycle and moved the bottleneck somewhere else, or that usage is uneven and the average hides it. You do not fix that by pushing harder on the tools. You fix it by finding where the work actually slows down.
The bottleneck just moved
A team gets good at generating code with an agent. The coding stage, which used to take days, now takes hours. Everyone feels the speed, because coding is the part you watch happen.
But the work did not get faster end to end. It got faster at one stage, and all that extra output now piles up at the next one. Review. Test. Whatever was already the tightest part of your pipeline is now tighter, because more is arriving at it.
The feeling of speed is real. The throughput gain is not. Those are different things, and the gap between them is exactly where the stall lives.
Read it in the numbers, not the vibe
The signal that catches this is cycle time, measured per stage, not end to end. When we baseline a stalled team, we look at how long a unit of work sits in each stage, and at the variance between engineers. Two patterns show up almost every time.
| What the team feels | What the per-stage numbers show |
|---|---|
| ”We got faster, then it settled.” | One stage now soaks up the extra output. Work queues there for days. |
| ”The team is modestly quicker on average.” | Two engineers compounding hard, five who switched the tool on and kept working the old way. The average hides both. |
The first is a constraint that moved. The second is a habit gap the mean is papering over. Neither is visible from commit counts, and neither gets fixed by prompting harder.
A plateau is information, not a verdict on the tools. It is telling you where the constraint actually is, which is almost never the place you were optimising. The teams that get past it read the plateau, find the real constraint, and make the one or two habits that relieve it consistent across everyone, not just the two who figured it out alone.
You do not design your way out of a stall. You measure your way out of it.