AI Writes Code That Passes Review and Fails in Production

Two findings from the State of AI Coding 2026, a survey of 200 US technology decision makers run by Hanover Research for New Relic, sit awkwardly next to each other.

The first: 94% of technology leaders rate AI generated code as better quality than human written code when they review it.

The second: 78% report more production incidents tied to AI code, 82% have had at least one major production failure caused by it in the past six months, and 86% say senior engineers are firefighting more.

Both can be true at the same time. The reason they are is worth understanding, because it tells you where to spend your effort.

Review measures the wrong thing

AI code reviews well because it has the qualities reviewers look for. Consistent naming. Sensible structure. Docstrings. Error branches handled. Idiomatic framework use. It reads like code written by someone careful.

What review does not check is whether the code is right about your system.

Does this retry loop know the downstream service is not idempotent? Does this query know the table has 400 million rows and no index on that column? Does this cache invalidation know about the other three services reading the same key?

A model writes sensible code for a generic system. Your system is not generic. The failure is not messy code. It is clean code built on a wrong picture of the place it is about to run.

That is exactly the kind of defect review is worst at catching and production is very good at finding.

Rework is the number to watch

74% of respondents said at least a quarter of all AI generated code needs significant rework after deployment, because of poor context, incomplete data, or wrong assumptions about the system.

Rework after deployment is the expensive kind. It comes with an incident attached, it interrupts whatever the team was doing, and it eats senior engineers. That is the same group the 86% firefighting number is about.

If you are tracking what AI does to delivery speed but not what it does to rework and incidents, you are reading half the ledger.

What to change

Review for context, not style. The model already handles style. Point people at the questions it cannot answer. What else touches this data. What happens under concurrency. What the real production volumes are. What this assumes about services it cannot see.

Make your environment readable to the tool. A lot of these failures come from missing context rather than weak reasoning. Put schemas, real data volumes, service contracts, and known constraints in the repo, where the assistant and the next engineer both read them. That removes whole categories of wrong assumption.

Tag AI written changes and measure them separately. You cannot manage what you cannot see. Change failure rate and rework rate, split by who wrote it, turns an argument into a measurement. Some teams find no real difference. Others find it concentrated in one service or one type of change. Both are useful to know.

Protect the blast radius instead of slowing the review. If more code is arriving faster and some fixed share of it carries wrong assumptions, the leverage is in progressive delivery, feature flags, quick rollback, and alerts on business signals rather than in longer reviews. Assume some of it gets through, and make what gets through cheap to undo.

The honest read

None of this is an argument against AI assisted development. The volume is real. 67% of respondents said AI writes or heavily refactors between half and three quarters of their weekly code output. That is not going backwards.

It is an argument that the safeguards most teams rely on were designed for a different bottleneck. Review was the constraint when writing code was slow. Writing code is not slow any more, so the constraint moved downstream, to context, to verification, and to how fast you can undo a bad assumption once it is live.

If your incident rate has climbed alongside your AI adoption and nobody has put the two together, that is a good place to start.