Observability Without Feedback Is Just Watching

A version of this essay went out first to subscribers of Observability Next, my LinkedIn newsletter, where the next issue takes on sentiment: what your systems are saying when nothing trips a threshold. Subscribe here to get it first.

Here’s what I hear from engineering teams, almost word for word, whether they’re four people or four hundred:

“I need fast, accurate feedback about what’s breaking in production, and I need it to reach the engineer who can fix it. That isn’t happening today. And I’m not going to hire ops people to make it happen, either because I can’t or because I shouldn’t have to.”

That’s a description of a broken feedback loop. The ops feedback loop, the path from what happened at runtime back to whoever is about to make the next change, is broken and getting worse. This issue is about why, and what it takes to close it.

Observability Has a Structural Problem

It’s tempting to blame the telemetry. Logs, metrics, and traces are fine. It’s tempting to blame the people. They’re doing exactly what the tools ask of them. The problem is the structure of observability itself.

Observability was designed around two assumptions that are no longer true:

• Humans reading dashboards
• Human-generated code

The architecture collects everything, ships it somewhere central, indexes it, and waits for a person to open a panel, form a hypothesis, and write an alert rule so they don’t have to look next time. Every step assumes a human is the consumer, and that code changes slowly enough for a human to keep up.

AI didn’t break that structure. It exposed it. AI didn’t make code worse; it made more of it, faster, and those two compound. A team that shipped weekly ships several times a day. An engineer who owned two services owns two services and an agent that touches nine more. Volume went up, velocity went up, and the number of humans available to watch stayed flat or shrank. Monitoring was configured for the system you had last year. That system is long gone.

Fifty Developers, One Pager

Here’s the broken loop on the ground. A regulated lender is moving a twenty-year-old legacy platform onto Kubernetes. Four people run DevOps; one of them is the Kubernetes engineer. Fifty developers are on coding agents, and both that number and their output keep climbing. The ops team doesn’t, and there’s no plan for it to. The code lands faster than it can be absorbed.

PagerDuty catches the up/down infrastructure alerts. Nothing at the application level reaches a developer at all. So the way an incident gets found is that a human notices first. Something feels off, and someone goes digging through Elasticsearch or Loki by hand until they find it. Nothing connects the alert to the cause. The team is too small to hand-build the dashboards and rules that would, and even if they did, the rules would describe yesterday’s system.

Every tool in that story is good. Just none of them feed back.

A Dashboard Isn’t a Feedback Loop

Observability tells you what happened. It’s a record, and a good one. But the thing that needs to act on runtime information now isn’t a person at a dashboard at 9 AM. It’s a coding agent in the middle of a task, or an engineer with an agent open, deciding whether what they shipped ten minutes ago is fine. Neither wants a dashboard. They want an answer: what broke, why, and what to change.

A dashboard doesn’t give you that. A loop does: signal comes out of runtime, gets reduced to what matters, and goes back into development while the code is still moving. Observability without feedback is just watching. A feedback loop tells the agent what to do next.

Regular readers know I’ve argued for a while that collect-everything is broken. That’s the input side. The feedback side is the payoff, and it’s the half teams are actually asking about.

Isn’t this AI SRE?

Dstl8 is going to show up on AI SRE lists, and it should. I love that the interest is there, because it means the market has noticed the same gap. Most AI SRE tools automate the SRE function as it stands today. But AI-speed engineering is absorbing that function into development, so they’re aiming at a target that’s shrinking under them. The new AI development lifecycle needs more than a closed infrastructure incident loop: something pages, an agent investigates, ops gets an answer faster. That’s real, but it’s not enough.

Look at how most AI SRE agents are built. The AI is bolted onto an existing observability platform. It sits on top of the same collect-everything, ship-it-central, index-it, wait-for-a-question structure, reading what a human would have read, just faster. You can’t bolt a feedback loop onto the old structure, and an AI SRE bolted on inherits every limit of the thing it’s bolted to: it sees only what was collected, it starts when something pages rather than when something ships, and it hands its answer to ops, not to the engineer or agent about to make the next change.

Now look at the lender again. The cause could be in the cluster or in the code, and nobody gets to pick which. A bolt-on hands off at exactly the point where the answer lives. As development absorbs more of ops, the incident loop and the development loop are collapsing into one. The AI SRE has to be built into the feedback loop natively, not attached to the record after the fact.

Feedback-Native, Not Bolted On

Native means starting where the data lives. A loop can’t run on a data lake. By the time telemetry has been shipped, indexed, and stored, the deploy that caused the problem is three deploys back, and the cost of asking about it is the reason nobody does.

So it has to start at the source, and it has to run continuously. That’s Telemetry Distillation, and it drives a four-step loop.

• Distill. Read the actual content of every line of telemetry where it lives, not just its status code, and pull out sentiment, patterns, anomalies, and severity. Sentiment is the one nobody else produces; it gets its own issue next time.
• Correlate. Connect what was found to the deploy that caused it, whether the cause is infrastructure, configuration, or application code. One investigation, wherever it lands.
• Reason. Deliver a cited diagnosis and the change it points to, whether that’s a line of code or a config value, into Claude Code, Cursor, or Codex, where your agent applies it.
• Remember. Every investigation feeds a knowledge graph, so the next one starts where the last one ended.

That’s the loop the teams I talk to are describing. Two years ago we started building it, and last week we shipped it. Dstl8 is the runtime feedback loop for AI-speed engineering.

Since going live, Dstl8 has surfaced 51 incidents for the lender, with no dashboard or alert rule built by anyone. At the other end of the scale, an enterprise fintech running 13 Kubernetes clusters surfaced 336 and resolved 328. Zero alert rules in both cases. Not because alert rules are bad, but because nobody had time to write them, and the thing that needed the alert was an agent anyway.

“A Fundamental Capability, Not a Nice-to-Have.”

ECI Research covered the Dstl8 launch and described where they think the market is moving:

As agentic coding systems move from co-pilots to autonomous deployment actors, the ability to route runtime intelligence back to the agent that shipped the code becomes a fundamental capability, not a nice-to-have.

The SDLC Changed. Monitoring Didn’t.

Every stage of the software lifecycle got an AI accelerant: planning, writing, review, test, deploy. Runtime got a faster firehose but has been stuck with the same old data lakes and dashboards. If we don’t fix runtime feedback, the new lifecycle breaks.

Next issue: what your systems are saying when nothing trips a threshold, and why nobody was listening.

Dstl8 is available at dstl8.ai. We’ll be at KubeCon in Salt Lake City in November.