When coding is not the bottleneck

The problem

Ask a software organisation why a feature took three months and the answer is rarely “typing”. It is the week spent working out what the customer meant, the fortnight waiting for the one person who understands the pricing module, the rework after a test nobody ran, and the release held back because nobody could say what had changed. Writing the code was a few days somewhere in the middle.

AI coding agents compress those few days. Unless something else changes, the other eleven weeks remain.

The consequence

Faster code generation pushes more work into the slow parts of the system. Review queues lengthen. Requirements that were vague stay vague, but now there is more code built on them. Knowledge that lived in one person’s head is consulted more often and becomes a harder bottleneck. DORA’s 2025 research on AI-assisted development describes this pattern at industry scale: AI amplifies what an organisation already is, strengths and weaknesses alike.

The approach

The useful question is not “how do we write code faster?” but “where does work wait, and why?” In the organisation described on this site, the answers pointed at four places, and each became a design decision:

• Requirements that could not be tested. Every piece of work now starts from requirements precise enough that a test can name them, and cannot progress until one does.
• Knowledge in people’s heads. The data model, business rules and past decisions are written into catalogues and a shared memory that every agent session reads before acting.
• Checks that depended on someone remembering. The rules that matter are enforced where the agent acts, not recalled at review time.
• Releases nobody could reconstruct. Each phase leaves evidence, so what was checked is a record rather than a recollection.

None of these is an AI technique. They are ordinary delivery disciplines that became affordable once an agent did the typing.

The evidence

The internal records show the checks doing their job: more recorded phase-exit attempts fail than pass. Work is held at the point it falls short, rather than discovered short later.

The boundary

No productivity comparison has been made against a team without these disciplines, so this article does not claim one. It argues from where work waits, which any organisation can observe for itself.

What to do next

Map one recent piece of work from request to release, and mark where it waited. If most of the waiting is outside coding, faster coding will not help much until those points change. The operating model describes one way to change them.