Three numbers from Sonar’s 2026 State of Code developer survey deserve to be read as one sentence: 42% of the code developers commit is now AI-generated or assisted, 96% say they do not fully trust that AI code is functionally correct, and only 48% always check it before committing. Almost everyone is suspicious; barely half act on the suspicion. Sonar calls it a verification gap, which is polite. I would call it signing documents you did not read.
I write from inside this, not above it. A meaningful share of the code and content in my own projects is agent-generated these days, including parts of this site’s publishing pipeline, and I wrote in Version Upgrades Are a Performance Feature that a benchmark you did not run is a rumor. This article is the same discipline pointed at a new source of claims: generated code is a claim about behavior, and merging it unverified is repeating a rumor with your name attached.
How we got a gap this wide#
The uncomfortable explanation is that nothing new broke; an old weakness got amplified. Reading code carefully was always the least budgeted activity in software: reviews rubber-stamped, tests written after the fact, diffs approved on trust in the author. That worked, barely, when the author was a colleague whose judgment you knew. Generation changes two variables at once: the volume of plausible code explodes, and the author is no longer someone whose blind spots you have learned. The 42% is not the problem. The 48% meeting it is.
Trust is not a feeling; it is a budget#
The teams that handle this well do not verify everything equally, because nobody can. They spend attention the way you spend any scarce resource: against risk. A generated helper that formats dates gets its tests run and a skim. A generated change to the payment path, the auth middleware, or a data migration gets read line by line, by a human whose name goes on it, exactly because the failure is expensive and quiet. The skill that becomes senior in this era is not prompting; it is triage: knowing which diffs deserve your full reading budget.
| Layer | What it catches | What it cannot catch |
|---|---|---|
| Types and compilation | Shape errors, obvious misuse | Plausible logic that is confidently wrong |
| Tests you already had | Regressions on covered paths | Behavior nobody thought to cover |
| Tests the AI wrote | The code agreeing with itself | Requirements the prompt never contained |
| Human reading, triaged by blast radius | Wrong assumptions, missing context, quiet failure modes | Nothing, if you actually read it |
The leadership half#
Tooling is the easy 20%. The rest is a norm a tech lead has to set and model: every merged line has a human owner, and owner means read it, not generated it. In practice that changes small things. Review comments ask "what did you check?", not just "does it work?". Pull requests say which parts are generated and what verification they got, so reviewers spend attention where it is thin. And the lead goes first: when I merge agent-written code, I say what I read closely and what I trusted to the tests, out loud, because the norm you want is the one juniors watch you practice. On my own projects, agent output ships through a gate that has caught real bugs in work I would have sworn was fine; the gate earns its keep precisely on the days I am most confident.
What I actually do#
- Triage by blast radius: payment, auth, data migrations, and anything concurrent gets read line by line; low-stakes glue gets tests plus a skim.
- Keep human-authored assertions for every requirement that matters; generated tests are a supplement, never the spec.
- State in the PR what was generated and what verification it got.
- Run generated changes through the same gates as human ones: types, tests, review; no fast lane for confident output.
- As the senior in the room, narrate your own verification; the norm spreads by imitation, not by policy doc.
A diff you did not read is a rumor, and merging it makes the rumor your signature.