Not one team could verify an AI fix in a single deploy.

Lightrun polled 200 SRE and DevOps leaders for its 2026 State of AI-Powered Engineering report and asked a plain operational question: how many manual redeploy cycles does it take to confirm that an AI-suggested fix actually works in production.

88% said two to three. 11% said four to six. The share who said one was zero.

Sit with that for a second. Redeploying to find out whether a fix worked is the oldest loop in the job. It is also precisely the loop everybody assumed AI would shorten. Writing got faster. Checking did not move, and by this measurement it got worse, because there is now far more to check.

The gap, measured twice from different rooms#

Sonar surveyed over 1,100 developers for its 2026 State of Code report and found that AI now accounts for 42% of committed code, with respondents expecting 65% by next year. In the same survey, 96% said they do not fully trust that AI-generated code is functionally correct. Only 48% said they always check it before committing.

Read those two numbers next to each other. Nearly everyone distrusts the output. Fewer than half always verify it. The remainder are shipping code they have told a survey they do not believe in.

38% said reviewing AI-generated code takes more effort than reviewing a colleague's, which is the mechanism behind the gap rather than a separate complaint. Verification got more expensive at the exact moment it became more necessary, so people quietly do less of it.

Sonar names this the verification gap. Lightrun measures the same thing further downstream and calls it redeploy cycles. Stack Overflow's 2026 developer survey has the blunt version of it, with AI usage at 84% and the share expressing high trust at 3%.

Three surveys, three methodologies, one shape.

Note: None of these numbers say AI writes bad code. They say the checking step has no tooling proportional to the volume, which is a different and more fixable problem.

Why checking a fix is harder than writing one#

Three reasons, ranked by how much of the pain they own.

1. The evidence was never captured#

43% of AI-generated code changes require manual debugging in production even after passing QA or staging, per the same Lightrun report. The sharper finding sits a page later: in 44% of cases where an AI SRE or APM investigation failed, it failed because the execution-level data had never been recorded.

Not analyzed incorrectly. Absent.

That is the whole story of runtime debugging compressed into one statistic. You cannot verify a fix against evidence you do not have, and no amount of model quality substitutes for a variable's value at the moment it was wrong. 60% of the surveyed leaders named lack of runtime visibility as their primary bottleneck in resolving incidents, which is the same finding stated as an opinion instead of a measurement.

2. Almost-right is the expensive kind of wrong#

Broken code announces itself. It throws, it names a file, it points at a line, and the loop closes in minutes.

Code that almost works does none of that. It passes review because it looks like what you would have written, passes tests because the tests encode the same assumption, and fails four systems away from where the assumption was made. The reported frustration ranks this above outright failure, and the economics are obvious once stated: the cost of a wrong answer scales with how long it takes to notice.

3. The fix arrives confident and without provenance#

This is the one I think tooling owes you, because it is the one tooling created.

A model returns a fix and a confidence number. The number is generated by the same process that generated the fix, from the same context, with the same blind spots. If the model never saw the file, its confidence is a statement about its prose, not about your code. We have written up what happened when we actually graphed ours, and inverted is not a typo.

So the reader gets a number that looks like evidence and is not, at exactly the moment they are deciding whether to skip the redeploy.

Three fields a proposed fix has to carry#

These are stated so they are useful against whatever tool you use, not only against ours.

Whether it was checked, in three states rather than two. Checked and passed. Checked and failed. Not checked. The third state is the one that gets collapsed, and collapsing it is the entire lie: a fix nobody examined renders identically to a fix that survived examination. Our engine returns verified: true | false | null and treats null as a first-class answer with its own reason string, because "we did not check this" is a real finding and a silent absence is not.

What the check proves, in words, narrower than you would like. Our import check proves that a named import resolves against the files DebugAI already retrieved for that request. It does not prove the package is installed. We cannot see your dependency graph, so we cannot make that claim, and shipping a bare verified: true would be read as the stronger one. The reason string is mandatory in the type. A verdict with no reason is not a verdict.

What a failure does to the confidence number. In our engine a verified: false caps reported confidence at 15 regardless of what the model said, and a verified: true leaves the model's number alone rather than inflating it, because passing a syntax check is not evidence of being right. An honest label that does not move the number it contradicts is decoration.

Warning: An honest upstream does not protect you on its own. If a component can report "I had nothing to work with," every consumer downstream has to read that field and change behaviour. We shipped a version that reported it correctly and then offered to write the fix to disk anyway.

Here is the part that costs us something to say. Our v1 covers exactly two deterministic classes, parse and import. Everything else comes back as not checked. That is a small covered surface next to the number of ways code fails, and we would rather publish the narrow label that is true than the broad one that is convenient. A verification badge that appears on everything is a badge that means nothing.

The browser is where the evidence goes missing#

Most of that 44% has a specific shape, and if you write frontend code you have already met it.

The error fired in someone else's browser. The stack frames read at li and at App, with no path and no line, because the source maps live in a bundle and the exception happened three layers into a render. Nothing reached your terminal. Nothing reached your logs. The only artifact is a message from a user saying it is broken on their end, and your reproduction attempt works fine.

The ecosystem has noticed. Chrome DevTools shipped an MCP server so agents can read the console, and framework-specific tools like next-browser expose the React tree and browser logs to a terminal agent. The premise underneath all of it is the admission that coding agents have been blind to the runtime the entire time. They can read your repository and cannot see your application run.

We have been building the DebugAI version of this, which captures those browser errors and hands them to the engine with the context they arrived with, so the trace that named no file still resolves to one. It is in closed beta right now, deliberately small, because a feature whose whole claim is "the evidence is real" cannot be validated by us alone.

If you want a seat, say so on the beta page and say what you would point it at. We turn Pro on while you test.

Sixty seconds against whatever you already use#

Do not take a vendor's word for any of this, including ours. This runs against any assistant, agent, or internal script pointed at your repo.

# 1. Take an error whose stack names no file you can write to.
#    A React key warning works. So does any exception raised
#    inside a dependency.
# 2. Ask your tool for a fix and go to the apply step.
# 3. Ask it one question: was this checked, and against what.

Three outcomes, in descending order of how much I would trust the tool:

1. It says it could not verify the fix and tells you what it did check. Good, and rarer than it should be.
2. It gives a confidence number and no provenance. Now you know the number is a self-report. Useful to know before it matters.
3. It applies the fix without showing you a diff. Worth discovering on a scratch repo rather than on your work branch. We wrote up how a tool ends up writing to the wrong file entirely, including ours.

The test costs a minute and tells you something about your tooling that no changelog will.

FAQ#

Is the verification gap just people being lazy about review?#

The Sonar data argues against it. 38% report that reviewing AI code takes more effort than reviewing a human colleague's, which means the same review budget buys less coverage than it did two years ago while the volume of code needing review roughly doubled. That is a throughput problem wearing the costume of a discipline problem.

Why not have the model verify its own fix?#

Because the check has to fail independently of the thing being checked. A model asked to grade its own output is running the same inference over the same context that produced the error, and it will agree with itself. Our checks run in a subprocess with resource limits and no network, and they either produce a mechanical result or return not checked. Neither outcome consults the model.

Does "not checked" make the tool look worse?#

Yes, on the surface, and it is still the right label. The alternative is a badge that appears on every fix, which trains you to stop reading it inside a week. A signal that is always present carries no information. We would rather own a smaller checked surface and grow it than claim a broad one nobody can audit.

Do these numbers mean AI coding tools are a bad deal?#

No, and the surveys do not claim it. Sonar's respondents expect AI to write 65% of committed code by next year, which is not the behaviour of people who regret it. The finding is narrower and more actionable: generation scaled, verification did not, and the gap between those two curves is where the week goes. Lightrun puts developer time spent on debugging, verification, and troubleshooting at 38% of the week. Two days out of five.

DebugAI reads the stack trace, pulls the files that actually matter, and hands you a fix you can apply in one click. It also tells you what it checked, what it could not, and refuses to dress up the difference.