2026-07-23 · 5 min read

Engineering leaders should check AI-generated code more than ever

Checksum published its State of AI Code 2026 report this week, a survey of 105 engineering leaders, and two numbers in it deserve to sit next to each other on a slide until someone explains how both can be true at the same time. 78% of those leaders say they trust AI-generated code more than they did a year ago, and 61% of them shipped a production incident caused by AI-generated code within the last 90 days. Not "at some point in their career." In the last quarter. So confidence is climbing while the things that should inform confidence are not improving, and the distance between those two lines is probably the most honest single picture of where software teams are sitting in mid-2026.

The numbers that should have moved and didn't

If trust were actually tracking quality, you'd expect the rest of the survey to look like a success story. It doesn't. 74% of the same leaders say they rolled back AI-generated code because it failed in a way their unit tests did not catch, which is a polite way of saying three quarters of them watched a green CI badge sail through review and then had to revert the change by hand after something broke in production. 65% say AI code needs more review time than human-written code, not less, which makes sense once you've sat with a 400-line diff where every function is formatted perfectly and the bug is hiding in the one assumption the model made about which field is nullable. And 29% report that their senior engineers now spend more time reviewing code than writing it, which is the kind of stat that sounds like a punchline until you realize it describes your own Tuesday. Checksum's founder Gal Vered summarized it without hedging: "AI has dramatically accelerated how software gets written, but verification hasn't kept pace."

And this isn't one survey being weird. LeadDev's reporting on the same problem in June cited data showing AI-generated pull requests carry 1.7 times more issues than human-written ones, and that a full third of teams hold AI code back from shipping because they can't figure out how to build enough confidence in it to let it through. Kris Kang, who runs agent products at JetBrains, described the mechanics in that piece with the sentence that should probably be the epigraph on every AI-coding deck this year: code generation now runs at machine speed "while the downstream verification and organizational processes are still dragging along at human speed."

Where the trust actually leaks in

So if the evidence is screaming "verify harder" and teams are verifying less carefully, what's happening in the gap? The best clue sits in LinearB's 2026 engineering benchmarks, drawn from about 8 million pull requests, and the story it tells is one of those sequences where every step makes perfect sense and the outcome is a disaster. In teams with high AI adoption, total review time is up 91%, because there's more code to look at. AI-authored PRs sit unclaimed in the queue 4.6 times longer than human ones, because nobody is excited to open a 600-line generated diff between two meetings. And then the strange part: once somebody finally clicks into one, they review it twice as fast as they review a human PR.

Think about that for a second. The PRs that carry 1.7 times more defects get less reading time per line, not more. That's not efficiency. That's skimming. The reviewer procrastinated because the diff looked long and tedious, and now they're behind on their queue, and the code in front of them is clean and idiomatic and CI is green, and the path of least resistance is a thumbs-up and a two-word "looks good." Every individual approval feels completely reasonable in the moment. In aggregate, this is how 61% of teams shipped an AI-caused incident in one quarter while simultaneously telling a surveyor that their trust in AI code went up.

Aviation and medicine have a name for this: automation complacency. When an automated system is right most of the time, humans stop checking it precisely at the moments where checking would have mattered most. The bot's silence starts reading as "verified, nothing to see here." It only ever meant "generated, nobody looked."

The green tests problem, or: checking the code's homework against its own answer key

The single most uncomfortable number in the Checksum report is the 74% who rolled back AI code that passed its unit tests, because passing tests is the exact signal that teams lean on hardest when review attention runs thin. "Did the tests pass? Great, merge it." But here's the thing about AI-written code: it usually arrives with AI-written tests, and those tests assert what the code does, not what the requirements meant. The model writes a function, then writes a test that calls the function and checks that the output matches what the function returns, which is a bit like asking a student to grade their own exam by checking whether their answers agree with their answers. A test suite that faithfully pins down the wrong behavior will stay green through code review, through CI, through deploy, all the way to the incident channel at 2am, because nobody along the way compared the green checkmark against the original spec. The only moment where "the tests pass" and "the code is wrong" can be seen at the same time is when a human reads the diff against what was actually asked for, and that moment is the one that's getting shorter.

What this actually changes about how you review

You can't fix an industry-wide verification gap from your own keyboard, and the surveys make it clear that this is an industry-wide problem, not a team-level one. But there's a version of these numbers that translates directly into what you do on the next PR that lands in your queue. The 61% incident rate means that "I generally trust AI code" is a statement about averages, and the diff in front of you is not an average. The specific PR you're about to approve is either fine or it isn't, and averages tell you nothing about which one this is, so the trust question has to be asked fresh every time. And the LinearB data about reviews going faster, not slower, means the instinct to watch for is the one where the code looks clean and your thumb drifts toward approve: AI bugs don't look like human bugs, they're well-formatted and confidently named and locally idiomatic, and polish is not evidence of correctness. It's the house style of the generator.

The most concrete habit the 74% stat argues for is reading the requirements before you read the tests. If you check the diff against the test file, you're auditing the code's self-portrait, the one it painted itself. Check the diff against what was actually asked for instead, and then treat the test file as one more piece of code under review, because that's what it is.

And there's one more thing, less comfortable than the rest: find out what you actually catch. Almost nobody knows their own miss rate, because in a real repo nothing ever tells you what you failed to see. The PR merges, everyone moves on, and the feedback loop that would have let you improve simply doesn't exist. That's the gap DiffDojo is built on: you review realistic AI-written PRs with known planted bugs, leave comments, give a verdict, and get graded against a canonical review that shows you exactly what you caught and what you walked past. "I'm a careful reviewer" stops being a belief and becomes a measured number, and given what these surveys are saying about the difference between confidence and evidence, that measurement is probably worth having.