AI Writes 42% of the Code. Only 48% of Us Always Check It.

The pipeline was green. Fourteen checks, every one of them passing, and the merge button sitting there in that confident blue it gets when absolutely nothing is standing in your way. Somebody had asked an assistant for a retry wrapper around a payment callback, read the top of it, skimmed the rest, and shipped it, because it looked exactly like the wrapper a competent engineer would have written by hand on a Tuesday afternoon. It was. Almost. The duplicate charges surfaced nineteen days later, and the two days spent chasing them ended at a sentence nobody in the repository could produce: what this code was supposed to do when a network timeout and a possibly-already-applied authorization arrive together.

Nobody skipped review. That is the part worth sitting with, because the reflex when this happens is to go shopping for another scanner. Sonar's State of Code Developer Survey, published January 8, 2026 from more than 1,100 developers globally, puts AI at 42% of all committed code, and the developers surveyed expect that to reach 65% by 2027. In that same survey, 96% report they do not fully trust that AI-generated code is functionally correct. Only 48% say they always check it before committing.

Line those three up and they stop being a story about lazy engineers. Distrust is near total. Verification is a coin flip. Across 25 years in enterprise software delivery I have never watched a group of professionals distrust something this thoroughly and act on it this inconsistently, and the easy explanation, that everyone is cutting corners under delivery pressure, covers maybe half of it. The other half is quieter, and it is the one nobody puts on a slide. Verify against what?

Why does so much AI code go unverified?

Because verification has a denominator nobody states out loud. To check something you need a standard to check it against, and for a typical change that standard lives in three places: the compiler, the test suite, and a person's memory of what the feature is supposed to do. Two of those are written down and machine-enforced. The third is not. AI pushed code volume past the point where an unwritten standard in one person's head can keep pace, and the failure mode is almost invisible, because it does not look like a failure at all. It looks like a passing build.

Notice what happens to a reviewer in that setting. Reading a human colleague's pull request, you get intent for free: the commit message, the ticket, the fact that Priya sat two desks over and mentioned on Wednesday that the reconciliation job was flaky. Context arrives with the code. AI code arrives without any of that, fluent and confident and structurally perfect, and the reviewer is left inferring what it was meant to do from what it does. That is not review. That is reverse-engineering, performed at speed, on a Friday, by someone with four other pull requests open.

Volume compounds it. The 42% figure is not spread evenly across throwaway scripts either, which is the detail that changed how I read this survey. Sonar found 88% of developers reaching for AI on prototypes and 83% on internal non-critical software, both unsurprising, but 73% on customer-facing applications and 58% on business-critical services. The code going in fastest is landing closest to the money.

Is the verification gap a tooling problem or a requirements problem?

Both, but not in equal measure, and I want to be straight about the tooling half rather than sell a false choice. Static analysis genuinely catches things a tired human at 5:40pm will not: the null dereference, the unclosed resource, the injection path threading through four call frames. The newer AI review layers are legitimately good at recognizing the shape of a defect. We wrote about what that review load costs a team in the hidden cost of the AI coding stack, and the answer was not nothing. Buy the tools. They pay for themselves.

Then notice the question every one of them is answering. Is this code wrong in a way I recognize? Not one of them answers the other question: is this code wrong in a way only your business knows about? A scanner has never once flagged a flawless implementation of the wrong rule. It cannot. The rule was never given to it, and a clean report on an undefined standard means only that the tool found nothing it knows how to look for, which teams read as safety and is in fact silence.

This is the same defect wearing different clothes across three of our recent pieces. When developers say AI output is almost right but not quite, almost right against what is doing the work in that sentence. When AI-assisted commits leak secrets at roughly twice the baseline rate (GitGuardian, State of Secrets Sprawl 2026), as we covered in AI security debt, the missing artifact is a stated rule about what may touch a credential. Different symptoms. One cause. The acceptance criterion was never written, so nothing downstream could enforce it.

What does a verifiable standard actually look like?

Concrete enough that a machine or a stranger can disagree with the code. "Retry on failure" is not a standard; it is a wish, and an assistant will happily satisfy it in a dozen mutually incompatible ways. "Retry at most twice on a connection timeout, never on a response that may already have been applied, and emit a reconciliation event when the outcome is unknown" is a standard. Same feature. One of them can be tested, prompted against, and argued with. The other one cannot, and that difference is the whole article.

Most teams have the order backwards. They generate first, then go looking for a way to check what came out, which is how you end up buying a scanner in month four and still shipping the payment bug in month five. Google inverted it. The rules went in the prompt, the validation ran automatically, and the human review had something specific to review against instead of a vague feeling that the diff looked fine. None of that required a frontier capability. It required somebody to sit down and write what correct meant.

Where does a team start on Monday?

Not with a policy. Pick the three services where a wrong answer costs actual money, and leave the other forty alone for now, because a standard nobody has time to write is worth exactly as much as no standard at all. A week of work, maybe two. Four steps, in this order:

1. Scope it to the blast radius. Rank services by what a wrong answer costs, not by how much AI touches them. Take the top three.
2. Write the rules, the forbidden states, and the edges. For each service: what the code must respect, what states it must never reach, and what should happen at the boundaries people keep arguing about in Slack and never resolve. The edges are the part everyone skips, and the part that produces duplicate charges.
3. Put the criteria in the prompt. Feed them to the assistant before it generates, the way Google wrote per-migration rules into the prompt before a single line was produced.
4. Put the same criteria in the review. The reviewer stops guessing at intent and starts checking against something. That is the whole difference between review and reverse-engineering.

Then the word "verify" finally has something behind it. Not discipline. The 48% is a measure of how many teams ever got as far as step two, and if that sounds like a small thing to be missing, consider that every scanner, every test and every audit downstream inherits whatever you wrote there.

Nicolas Payette

CEO and Founder, Specira AI

Nicolas Payette has spent 25 years in enterprise software delivery, leading digital transformations at companies like Technology Evaluation Centers and Optimal Solutions. He founded Specira AI to solve the root cause of project failure: unclear requirements, not slow code.