We've Never Shipped Code This Fast. Understanding It Hasn't Kept Up.

Ask anyone where dev ends and ops begins and they'll struggle to draw the line. That's the point of the last decade of DevOps: the two disciplines merged so completely that the boundary stopped mattering. But ask where building ends and understanding begins, and everyone answers instantly. Right after deploy.

That boundary isn't new. What's new is the speed mismatch across it. AI-assisted coding has made the build side of software faster than at any point in its history. Nobody has made the understand side move at anything close to the same pace. The seam was always there and it was always a bit fragile. Now, with one side of it accelerating even more and the other standing still, this brittle seam can break more easily than ever.

Most teams still follow the old pattern. Someone spots a business problem, engineers scope it and ship it, and only once it's live do the real questions start: is it fast, is it holding, is it doing what the business actually needed. Observability shows up at the end, wired on after the decision has already been made. That was tolerable when software moved slowly enough that the lag didn't cost much. It doesn't work when code arrives in hours and the watching still takes days to organize.

A gap we've closed once already

This isn't a new kind of problem, even if it feels like one. A decade ago, dev and ops were entirely separate disciplines, with separate tools, separate incentives, and little communication between them. DevOps didn't fix that by inventing clever new software first. It fixed it by deciding, as an industry, that the two were one job wearing two hats, and then building tools that assumed that from the start.

That's roughly what needs to happen now to the boundary between building something and watching it run. Understand the problem. Build with visibility already switched on, not added later. Deploy it. See what actually happens. Feed that straight back into the next decision. Then do it again.

It sounds simple written out like that. It very much isn't, in practice, which is exactly why so few teams have managed it.

Why the gap is starting to cost real money

The cost of this gap isn't hypothetical, and it isn't small. Grafana Labs' own Observability Survey has practitioners describing it in plain dollar terms: one SRE manager at a small IoT company put a single four-hour outage at two million dollars, and estimated that faster correlation analysis would have recovered all but two hundred thousand of it by cutting resolution from four hours to fifteen minutes. Others report mean time to resolution cut by a third or more once telemetry is centralized, translating into tens of thousands of dollars a quarter in recovered engineer time alone. This is what "reliability debt" actually means: not a line item, but money leaving the business in real time every minute an incident runs undiagnosed.

Most organizations aren't short on symptoms. Alert fatigue, complexity, overhead: these are the visible costs of large, decentralized services nowadays where observability is bolted onto systems shipping faster than the instrumentation around them can keep up.

Here's the part that should worry people more than it currently does: only 14% of organizations are observing their LLM-powered systems in production at all. That gap shows up twice, in two different places. Inside engineering orgs, coding agents are shipping PRs faster than anyone's watching what they actually changed. And for the growing number of companies now shipping agentic features to their own customers, that same blind spot moves downstream. An agent making decisions in production, with no one watching it run, isn't a productivity tool anymore, it's a live dependency. Either way, that's not a risk sitting somewhere in the future. Every agent in production right now without eyes on it is reliability debt already accruing, just waiting for the invoice.

Not another phase, just the same loop, properly closed

I don't think the answer is bolting an "observability phase" onto the front of the pipeline. That just moves the seam somewhere else in the diagram; it doesn't get rid of it. The fix is duller and harder than that: the same information, what the business needed, what got built, how it's performing, what it's costing, where it's breaking, needs to stay visible to the same people at every single stage, rather than getting rewritten into a different format each time it changes hands.

None of this requires waiting for a five-year DevOps-style culture shift to play out again. It starts smaller: the next time your team builds with a coding agent they should have the telemetry conversation at the same time they are planning the changes, not filed as a follow-up ticket. Going even further, production telemetry made available early can also influence engineering decisions, making plans better and implementations more tuned to the day-to-day realities of your systems. Telemetry and why certain decisions were made become part of the definition of done. If your agents are already shipping into production faster than anyone's watching them, that's the one thing worth fixing this quarter before an outage forces you to.

Here's what it looks like in practice: someone starts with a real business problem and a reason it's worth solving, not a ticket, an actual reason. They can ask an agent to help scope that problem against what's already known: how similar things have performed, where past versions of this broke, what "normal" looks like for something like it. They build it with observability switched on from the first commit, because the agent treats instrumentation as a default rather than an afterthought. It ships. Once it's running, AI agents are on hand to monitor the rollout, watch for unexpected side effects, and report on the progress and usage out in the wild. No more searching through dashboards, or writing advanced queries to get answers. What gets learned from that feeds straight back into the next problem someone scopes, instead of dying in a postmortem doc two people ever open.

Then you do it again. That's the whole loop: problem, build with sight turned on, ship, watch, learn, repeat. The point isn't that AI touches every step. It's that it's the same thread of context running through all of them, so nobody has to re-explain the system to a new tool every time they move from one stage to the next. This is essentially the next step of loop engineering: Context Looping. You make sure that during the agent loops you build, the agents are incentivized to get the right context on their own.

I don't think this is a new category so much as it's DevOps finishing the job it started. A decade ago the industry closed the gap between building and shipping by refusing to treat them as separate jobs. The gap left over is between building and actually understanding, and AI is the first thing capable of closing it at the same speed it's currently opening it. Same technology, both directions. The only question is whether your team decides that on purpose, or finds out the hard way during the next incident.

KubeCon + CloudNativeCon is taking place in Salt Lake City from November 9 to 12. Register Now!

Author Bio:

Mat Ryer is the Senior Director of AI at Grafana Labs. He has been coding since he was six years old, when he would copy code out of computer magazines with his father before hacking away at the programs to see what might happen. That same spirit led him to start programming in Go before its v1 release (when os.Error was still a thing) after falling in love with its simplicity and elegance. He's a regular contributor to open-source projects. He can often be seen and heard speaking at conferences around the world, making jokes where, out of sheer politeness and respect, the audience remains absolutely silent.