Zero Percent Confident

This piece first ran in my LinkedIn newsletter, Observability Next: Subscribe on LinkedIn

The Debate Is Over.

A few months back I wrote that stability has to match velocity. The 2026 numbers just put a price on what happens when it doesn’t.

Start with adoption, because that part is settled. Microsoft and Google have both said roughly a quarter of their code is AI-generated. Karpathy gave the practice a name this year, agentic engineering, and it stuck because it describes what teams actually do now: agents take the issue, write the patch, open the PR. The interesting question is no longer whether AI writes production code. It does.

The interesting question is whether anyone trusts it. And on that, the 2026 data is brutal:

• Lightrun surveyed 200 senior SRE and DevOps leaders. The share who said they were “very confident” AI-generated code behaves correctly once deployed: zero percent. Not low. Zero. Their CBO called it a trust wall, and the phrase fits.
• Same study: 43% of AI-generated code changes require manual debugging in production, after passing QA and staging.
• And 88% of teams need two to three redeploy cycles to verify an AI-suggested fix. Nobody could do it in one.
• Flux found 35% of teams write code with AI but won’t ship it, because they can’t do it safely.
• CloudBees found 81% of enterprise leaders report more production issues tied to AI code.

Read those together and notice what they don’t say. They don’t say AI writes bad code. They say teams have no reliable way to verify what the code does once it runs. The 43% number is the tell: that code passed every gate those organizations had. Review approved it. Tests passed. Staging looked fine. Production disagreed anyway.

Your Gates Are on the Wrong Side.

If your gates all pass and production still fails, you don’t need better gates. Your gates are on the wrong side of the deploy.

Built for a World That Changed.

Here’s the part I find most interesting, and it’s why this newsletter is called what it’s called. Everything we built in observability over the past decade was designed by humans, for humans, to watch code written by humans. Dashboards encode what someone anticipated might break. Alert thresholds encode known failure modes. Runbooks encode incidents you’ve already had. The entire model assumes failure modes are knowable in advance. For human-written code, they mostly were, because the person who wrote the code could also imagine how it would fail.

AI-generated code breaks that assumption. Same prompt, different implementation, different dependencies, different failure surface, every run. Its failures are unknown unknowns: modes nobody anticipated because nobody made the decisions. There is no dashboard for them. No threshold. No runbook. A monitoring model built on “watch for what we know can go wrong” cannot keep up with a code supply that invents new ways of going wrong daily.

The Author Never Sees Production.

And there’s one more break, new to the agentic workflow. A human who ships a bug eventually feels it: the incident channel, the postmortem, the fix. An agent writes the patch, the PR merges, and its context ends. Whatever production revealed never flows back to the thing that wrote the code. Every session starts from zero runtime knowledge. That’s the 88% number explained: agents guessing at production behavior they have never been shown.

Make it concrete. A Stripe webhook handler, agent-generated, reads a field that exists on test events and on most production events, but not on the one subscription type that matters. Local tests pass. It deploys. It fails silently for eleven days before a customer complains about a missed renewal. Nobody made a mistake you could point to: the model generated what it had seen, the tests passed on the data available, the code shipped looking correct. The failure lived in the gap between the model’s assumption and production reality, and the agent that wrote it was never going to find out. Nothing was watching that gap, and nothing carried it back.

That’s the runtime feedback gap. It isn’t a code quality problem. It’s a feedback problem, and closing it is what “observability next” means to me: not more storage, not better search, but a runtime feedback loop that carries production evidence back to the developer and the agent that shipped the change.

Over the next several issues I’m going to work through that argument one piece at a time: why your runtime platforms can’t answer the question the AI SDLC actually asks, why pointing an LLM at raw logs makes things worse, what architecture closes the loop, and what any of this looks like from inside Claude Code or Cursor.

If you’d rather not wait, we published the whole argument as a free guide, no gate, no form: How to Trust What Your Agents Ship. The data above, the architecture, and a four-question test for whether your team can actually answer “what changed” after a deploy.

Bob Quillin is founder and CEO of ControlTheory, makers of Dstl8, runtime feedback for AI-generated code.

Sources for this issue: Lightrun, 2026 State of AI-Powered Engineering Report (via VentureBeat, April 2026). Flux study of 309 engineering leaders (via LeadDev, June 2026). CloudBees, 2026 State of Code Abundance Report (May 2026).