On the last Thursday of May, a client asked me to explain why her engineering team was delivering at roughly half the pace of the one it had replaced. The new team was smaller, better tooled, and cost less to run. The previous team had been larger and more senior. Delivery had not followed the direction of the investment.
The restructuring had its own logic. The firm had acquired licences for AI coding assistants across the preceding year and watched junior engineers produce, on a good morning, what had previously required a senior engineer's afternoon. On that basis, the ratio looked unfavourable: a senior engineering headcount drawing senior salaries in an environment where the productivity gap appeared to be closing. The decision to release two of the three senior engineers and redistribute the budget looked defensible.
#02What the sprint data showed
The team had entered a review bottleneck that was not named in any retrospective. Code moved from development to review quickly. It moved from review to merge slowly. The remaining tech lead was processing a queue of diffs she had not designed, written by engineers who were producing faster than she could evaluate them. She was competent enough to catch what needed catching. The catching was consuming most of the deployment window, and deployment frequency had declined to a degree that was visible in the sprint cadence data.
The missing resource was not a coding resource. It was a reviewing one. The junior engineers with AI tools had increased the rate at which code entered the review queue. Nothing in the restructuring had increased the rate at which code could leave it.
What AI coding tools change is the input side of a review process, not the process itself. A junior engineer with a capable assistant can produce a syntactically coherent diff in the time it would previously have taken to write the simplest function. What reviewing that diff requires is produced by something else entirely: judgment about production behaviour, familiarity with the failure modes that do not surface until a change is live, architectural awareness of what a decision will interact with at runtime. That capacity accumulates through years of shipping and breaking things. It is not a feature of the tool.
The team had removed that capacity in the same decision that introduced the tools, on the logic that the two were substitutes. They were not substitutes. They addressed different steps in the same pipeline, and increasing the throughput of one step without addressing the other creates a queue.
I gave the client the honest version of this on the call and she was not pleased with it, which was reasonable. She had not made the original decision carelessly. She had made a rational resourcing call on a plausible theory of where the productivity constraint lived. The theory was right about code production. It was not right about review. Those are different constraints, and a restructuring plan that treats them as one will encounter the difference in the sprint data before it encounters it in the incident record.
The firm brought in a senior engineer on a part-time engagement the following month. Delivery frequency recovered within six weeks. The sprint data from that period is the clearest account I have of what the original restructuring had actually changed. Not what the people making the decision had thought they were changing.
“That capacity accumulates through years of shipping and breaking things. It is not a feature of the tool.”