AI coding copilots changed our code review, not our typing speed

I gave AI coding copilots to 30+ engineers inside a UAE federal government entity. The expectation, stated openly in the business case, was that engineers would write code faster. That part happened. What nobody budgeted for was the second-order effect: everything that code has to pass through before it is allowed near production.

Typing got faster. Delivery did not, at first.

The bottleneck moved, it did not disappear

Within a few sprints the pattern was clear. More code was arriving at review, and it was arriving sooner. Pull requests grew. The author's confidence in a change rose faster than the reviewer's confidence did, because generated code reads cleanly even when it is wrong in a way that only shows up at integration.

So the queue simply relocated. It moved from waiting to be written to waiting to be trusted.

It is like adding a second oven to a restaurant that still has one food inspector. The kitchen is busier. The plates still leave at the same rate.

That is not a tooling problem. It is an ownership problem, and it is the same problem I have watched sink AI pilots that had nothing to do with code. The model was never the weak point. The operating model around it was.

Why generated code is harder to review, not easier

It is plausible before it is correct

Hand-written code carries the author's hesitation in it. You can see where someone was unsure. Generated code is uniformly confident. A reviewer has to actively look for the seams instead of being shown them.

Volume compounds

A reviewer who could give real attention to three hundred lines a day does not suddenly give real attention to a thousand. Beyond a certain size, review stops being review and becomes skimming with a rubber stamp. In a regulated environment that rubber stamp is a documented control, and a control that is not really being exercised is worse than no control at all.

The audit trail has to name a human

In national-scale government delivery, the review record is an audit artefact. It is looked at by internal audit, by external auditors and by the PMO. "The assistant suggested it" is not an answer any of them accept.

What we changed, using Definition of Done as the backbone

We did not write a new AI policy document. We took the framework the teams already lived inside, the Scrum Definition of Done, and we amended it. That choice mattered. A rule that lives in the Definition of Done gets enforced by the board every day. A rule that lives in a governance deck gets read once.

1. Smaller pull requests, enforced

We put a size threshold on pull requests and treated breaching it as a Definition of Done failure, not a style comment. A thousand line generated change does not get reviewed, it gets skimmed. Splitting the work is friction for the author and a large gain for the reviewer, and the reviewer is now the constraint, so the reviewer wins.

2. Named authorship

The engineer who submits generated code owns it in production. The copilot does not co-sign. This sounds obvious until you sit in a defect review and watch a team describe a fault as something the tool produced. Once ownership is explicit, the quality of what gets submitted changes before it ever reaches a reviewer.

3. Standards the model can actually read

Our architecture rules, naming conventions, logging requirements and integration patterns moved into the repository and into the prompt context. Not a PDF on a portal. If the assistant cannot see the standard, the standard does not exist at the moment the code is written, and you end up enforcing it manually at review, which is exactly the stage you are trying to protect.

Only after those three changes did review time come down, and only then did the copilots show benefit at the delivery level rather than the keystroke level.

The caveats I owe you

This is a field report, not a study

I went looking for external research to support the claim that copilots shift effort from writing to verifying. I did not find it. The batch that came back was not about software engineering at all. One paper was about inference efficiency in reasoning models, opening with the observation that "Reasoning models often generate very long reasoning traces, making inference computationally expensive". A real question, and completely unrelated to code review.

The others were further away still. One was condensed matter physics:

"Skyrmions experience a sideways gyroscopic force when they move. Bound molecules can cancel this force, we call them gyroscopically neutral."

So I will say plainly: I have no benchmark, no DORA figure and no third-party study behind this. What I have is one team of 30+ engineers inside a federal entity, and the sequence of things that had to change before the tooling paid back. Treat it as evidence of one shape, not proof of a trend. If your team measured something different, I would rather hear it than have it agree with me.

Typing speed is not nothing

The fair pushback is that faster authoring does matter at scale. It does. Boilerplate, scaffolding, test fixtures and repetitive integration code genuinely get faster, and in ESB and API work that is a meaningful share of the effort. I would not dismiss it. It just was not where our bottleneck lived, and buying more seats would not have moved it.

The takeaway

My honest estimate, from the delivery I have led rather than from a paper: in regulated engineering teams, roughly 60% of the delay after copilots arrive sits in verification, not authoring. If that is even directionally right, the spending decision follows from it.

For the rest of 2026, budget for review capacity, standards in the repo and clear authorship before you buy more licences. The licences are the cheap part.

AI moves the constraint. It rarely removes it. The teams that get value are the ones that go looking for where it moved to.

Where did your bottleneck move after copilots landed?