The software industry is still generating more code with AI, but a new survey suggests the harder problem is no longer writing that code. It is proving that the code survives contact with production.
In a new report from Lightrun, featured by VentureBeat, 200 senior SRE and DevOps leaders describe a workflow that is moving faster at the keyboard and slower everywhere else. The headline finding is blunt: 43% of AI-generated code changes still require manual debugging in production, even after they pass QA and staging.
That is not a small edge case. It is evidence that the center of gravity in AI-assisted development has shifted. Teams are getting more output from copilots, agents, and code-generation tools, but they are also paying more for verification, rollback, and incident response. In other words, the bottleneck has moved from typing code to trusting it.
What the survey says about the gap between generation and reliability
The report frames the problem as a trust wall. Only 0% of the leaders surveyed said they were very confident that AI-generated code would behave correctly once deployed. Most organizations are still stuck in multi-step validation loops: 88% said they need two or three redeploy cycles to publish a single AI-generated change, and 11% need four to six.
That matters because every extra cycle slows down the promise that made AI coding attractive in the first place. If a team can draft a feature in minutes but needs several passes to make it safe enough to release, the apparent productivity win gets partially eaten by downstream toil. The report also says 44% of AI SRE or APM tool failures happen because the tools never captured execution-level data such as variable state, memory usage, or request flow.
Why runtime visibility is becoming the missing layer
The most useful part of the report is not the frustration metric; it is the diagnosis. Lightrun argues that AI tools and conventional monitoring are often blind to what matters most once code is live. A prompt can produce a plausible change, but a runtime system is where hidden assumptions show up: race conditions, schema mismatches, unexpected request paths, and a long tail of integration problems that no static review can fully eliminate.
That is why runtime visibility is becoming the missing layer in AI-assisted development. The report says 97% of engineering leaders believe their AI SRE agents operate without significant visibility into production behavior, and nearly half said their agents have only limited visibility into live execution states. If that is true, then the industry is asking AI to both create and diagnose software while denying it the data it needs to do either job well.
This is also where the economics start to break. The same report says 54% of high-severity incident resolutions still rely on tribal knowledge rather than diagnostic evidence from AI SRE or APM systems. In practice, that means organizations are leaning on senior engineers, tacit memory, and human improvisation to patch over gaps that automation has not yet closed.
What teams should take from this
The right response is not to abandon AI coding. The report does not suggest that. It suggests that AI coding now needs a more serious operating model.
- Instrument production, not just the editor. If the runtime cannot explain itself, AI-generated changes will keep turning into debugging work later.
- Measure the full cost of a change. Time to first draft is useful, but time to verified production matters more.
- Treat validation as a first-class product feature. Testing, observability, canaries, and rollback are now part of the AI coding stack, not optional add-ons.
- Track whether the AI is helping or just shifting work downstream. A faster draft that creates more incident noise is not a net win.
The survey lands at a useful moment because it captures the next phase of the AI coding debate. The first wave was about whether AI could write code at all. The second wave is about whether organizations can trust, validate, and operate that code at scale. The answer, at least for now, is that many teams are not there yet.
That does not make AI coding a failure. It makes it incomplete. The winners in this phase will not be the teams that generate the most code. They will be the teams that can prove the code works, catch failures early, and make production behavior visible enough for humans and machines to act on it together.
