2026-07-23 · 5 min read

Engineering leaders should check AI-generated code more than ever

This week Checksum published its State of AI Code 2026 report, a survey of 105 engineering leaders. Two numbers from it belong side by side. 78% of those leaders 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. Confidence is rising. The failure rate isn't falling to meet it. That gap is the most honest description of where software teams are in mid-2026.

Confidence and evidence are moving in opposite directions

If trust were tracking quality, you'd expect the other numbers in the survey to be improving. They aren't. 74% of the same leaders rolled back AI-generated code because it failed in a way their unit tests did not catch. 65% say AI code needs more review time than human-written code, not less. And 29% report that their senior engineers now spend more time reviewing code than building anything. Checksum's founder Gal Vered put the diagnosis plainly: "AI has dramatically accelerated how software gets written, but verification hasn't kept pace."

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 third of teams hold AI code back from shipping because they can't build confidence in it. Kris Kang, who runs agent products at JetBrains, described the mechanics in that piece: 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 says "verify harder" and teams are verifying less carefully, what's happening in between? The best clue is in LinearB's 2026 engineering benchmarks, drawn from about 8 million pull requests. In teams with high AI adoption, review time is up 91%. AI-authored PRs sit unclaimed 4.6 times longer than human ones. And then the strange part: once somebody finally opens one, it gets reviewed twice as fast as a human PR.

Read that again. The PRs with 1.7 times more defects get less reading, not more. That's not efficiency, that's skimming. Reviewers procrastinate on the AI-generated diff because they expect it to be long and tedious, and when they finally open it they're behind on their queue, the code looks clean and idiomatic, CI is green, and the path of least resistance is approve. Every individual approval feels reasonable. In aggregate it's how 61% of teams shipped an AI-caused incident in one quarter while telling a surveyor their trust went up.

There's a name for this from aviation and medicine: automation complacency. When an automated system is right most of the time, humans stop checking it precisely where checking matters most. The bot's silence reads as "verified". It only ever meant "generated".

Green tests are not a verdict

The single scariest number in the Checksum report is the 74% rolling back AI code that passed its unit tests. It's scary because passing tests is exactly the signal teams lean on when review attention runs out. But AI-written code usually arrives with AI-written tests, and those tests assert what the code does, not what the requirements meant. 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. The only place where "the tests pass" and "the code is wrong" can be seen at the same time is a human reading the diff against the spec.

What a reviewer can do with this

You can't fix an industry-wide verification gap from your own keyboard, but the numbers above translate into three concrete habits:

• Make trust a per-diff decision, not a vibe. "I trust AI code more than last year" is a statement about averages. The diff in front of you is not an average, and the 61% incident rate says the tail is fat.
• Slow down exactly when the code looks clean. AI bugs don't look like human bugs. They're well-formatted, confidently named, and locally idiomatic. Polish is not evidence of correctness, it's the house style of the generator.
• Read the requirements before the tests. If you check the diff against the tests, you're auditing the code's self-portrait. Check it against what was actually asked for, then treat the tests as one more piece of code under review.

And one more, less comfortable: find out what you actually catch. Almost nobody knows their own miss rate, because a real repo can't tell you what you failed to see. That's the gap DiffDojo exists for. You review realistic AI-written PRs with known planted bugs, leave comments, give a verdict, and get graded against a canonical review, so "I'm a careful reviewer" becomes a measured number instead of a belief. Given what the surveys say about the difference between confidence and evidence, that measurement is worth having.

Read next: How to review AI-generated code: a guide for the human in the loop