"Generate Then Verify" Moved Your Work. It Didn't Remove It.

Let the model write the code, then you check it. That is the advice, and four out of five teams who took it now spend more time in review than they did before.

Somebody measured where the hours went #

Harness surveyed 700 engineering practitioners and managers at large enterprises across five countries this April, through Sapio Research:

81% say developers spend more time in code review since adopting AI coding tools, with 28% reporting a significant increase of more than 30%.

The step everyone assumed was the light one is where the time landed. It is vendor-commissioned and self-reported, and enterprise teams are not your four-person startup - discount it as you see fit, and the number still points this direction rather than the other one.

Reading is not the cheap half, and never was #

Writing a function means holding one intention in your head and making the machine agree with it. Reading a function means reconstructing somebody else’s intention from the residue, without being sure there was one.

AI output fails this way too. It is plausible. It compiles, it follows a pattern, it looks like something a competent person wrote, and none of those properties tell you whether it is right for your system.

GitClear has been measuring the residue across 623 million analyzed changes from 2023 to 2026. Moved code - their proxy for the reorganising work that keeps a codebase coherent - was 21% of changed lines in 2022. It fell to 13% in 2023. It is 3.8% so far in 2026.

Duplication you can find later. The habit of going back and tidying is harder to restart once a team stops doing it, and generation does not encourage it: the model is very good at adding a thing and has no opinion about whether the thing should have been added next to the four like it.

The obvious fix is the one that does not work #

If verification is now the expensive step, automate verification. Everyone arrives here, and the tooling exists, and some of it is genuinely good.

It is also the one place where handing the work back to a machine fails in a specific and quiet way. I went through the evidence separately in what to ask when your dev shop says the code was reviewed, so I will not re-run it here. The short version is that making an automated reviewer quiet enough for developers to tolerate is the same operation as making it miss things, and it misses them worst in the categories you would least like.

So the expensive half of this workflow has no automation path, which is why “generate then verify” is a description of where the work went rather than a plan for handling it.

What we do instead #

None of this is an argument against using the tools. We use them daily. It is an argument against the sentence, and the first thing it changes is what we hand to a model in the first place.

The question we ask is not “can it write this” but “how fast can I tell whether it did”:

The left column is not the easy work. It is the work where a wrong answer announces itself quickly and cannot reach far when it does.

Two habits carry the rest of it. The first is saying the review number out loud during planning, which in practice means estimating like this:

Task: add rate limiting to the public API

  write it yourself        ~2h, and I understand it afterwards
  generate + verify        ~20m generating
                           ~90m reading it properly
                           = 1h50m, and I understand it less

Decision: generate. The check is fast here - there is a test
that fails when the limit is wrong. Would not generate the
billing reconciliation on the same trade.

Quoting the twenty minutes and discovering the ninety is how teams end up feeling slower while shipping more. The second habit is keeping the tidying in the same pull request rather than in a someday ticket, since a someday ticket is where that 3.8% went.

Then somebody owns the merge by name - a person who read it and would be embarrassed by it later, rather than a bot’s approval. That rule predates any of this. It just got much easier to skip.

What I actually think #

I have watched a lot of code get produced very quickly and then get read very slowly, including in this repository. The generating is not the part that takes the day.

If your team has adopted AI tooling and velocity has not moved the way you expected, you are not doing it wrong and the tools are not broken. The work moved somewhere nobody was measuring.

So measure there. Put the review estimate in the ticket next to the build estimate, for two weeks, and see which one you keep getting wrong.

Sources #

• Harness, State of Engineering Excellence 2026 - 700 practitioners and managers across the US, UK, India, France and Germany, fielded by Sapio Research, April 2026.
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research - 623 million analyzed changes, 2023-2026.