The pager went off, and nobody recognized the code
This quarter, background coding agents crossed the line from demo to default. GitHub's autonomous PRs, Cursor's background agents, and Anthropic's Claude Code all shipped features in Q2 and Q3 that let an agent pick up an issue, write the fix, open the pull request, and, in a growing number of shops, merge it after a green CI run. The pitch is intoxicating: your backlog drains itself overnight.
Here is what the launch posts left out. Talk to anyone carrying a pager in a team that turned this on three months ago and you hear the same thing: incident volume is up, and the incidents take longer to resolve. Not because the code is worse, necessarily. Because when the alert fires at 3 a.m., the engineer staring at the stack trace has never seen this code, has no memory of writing it, and cannot ping the author, because there isn't one.
That is the part of the AI coding story the industry is not pricing in yet.
Everyone is measuring the wrong number
The entire discourse around AI coding tools is denominated in throughput. PRs merged per week. Lines shipped. Issues closed. Vendors put these numbers on slides because they go up and to the right, and because generation is the easy thing to measure.
But generation was never the bottleneck. Most teams could already write code faster than they could safely operate it. The constraint on shipping has always been the back half of the lifecycle: review, deploy, observe, and, when something breaks, understand. Agents crank the generation dial to eleven and leave the rest of the pipeline exactly where it was. You have not removed the bottleneck; you have shoved a firehose into it.
The metric that actually predicts your on-call pain is not lines shipped. It is Mean Time To Understand (MTTU): how long it takes a human to comprehend what a piece of code is doing, why it exists, and what it touched, starting from a cold page at the worst possible hour. MTTR (time to resolve) gets all the attention, but resolution is downstream of comprehension. You cannot fix what you do not yet understand.
Agents sever author intuition
For twenty years, on-call has quietly run on a resource nobody put on a dashboard: author intuition. When a service pages you, there was a decent chance you or a teammate wrote the offending code, remembered the tradeoff, recalled the TODO you left, or at minimum could read the commit and infer the mental model behind it. Blame in git was a social graph. git blame pointed at a person, and that person had context.
Machine-authored code snaps that thread. The commit message is generated. The PR description is generated. The reasoning that produced the change lived in a model's context window that was garbage-collected the moment the task finished. There is no one to Slack. The author intuition that made 3 a.m. survivable has been quietly deleted from your incident response, and no throughput metric will show you that loss.
This is the operational counterpoint to the productivity story. It is also the natural sequel to a question we raised earlier this year in Is AI-Generated Code Creating Unmonitorable Production Failures?. Back then the concern was hypothetical for most teams. Now the agents are merging on their own, and the concern has a pager attached.
The bottleneck moved to observability. Instrument for it.
The teams that win the next year will not be the ones running the most agents. They will be the ones who cut MTTU for code no human wrote. That is an instrumentation problem, not a generation problem. Concretely:
- Force agents to emit context, not just code. If an agent opens a PR, it should also write structured logs, meaningful span names, and error messages that explain intent, not just fire a generic exception. Make rich telemetry part of the definition of done in the agent's prompt and your review gate. Code without observability should fail CI the same way code without tests does.
- Map ownership to services, not authors. When the author is a model,
git blameis dead weight. You need a routing layer that answers "who is responsible for this surface" from service ownership and dependency graphs, so the page lands on someone who can act instead of bouncing around a channel. - Correlate across the noise. Agents ship more, smaller changes, more often. That means more deploys, more alerts, and more chances for one root cause to light up five dashboards. Correlation across noisy signals, tying an alert back to the specific deploy and diff that caused it, is what collapses the diagnosis window.
- Keep a provenance trail. Record which agent, which prompt, and which run produced a change, and link it from the alert. It is a partial replacement for the author you no longer have. When the page fires, the responder should reach the reasoning in one click, not reconstruct it from scratch.
None of this slows the agents down. It makes their output operable, which is the only way the throughput gain survives contact with production. A team that instruments for machine-authored code will out-ship a team that just floors the throughput pedal, because the first team is not spending its velocity gains back on longer, more frequent incidents.
The budget conversation you should have this quarter
Q3 is when the first full quarter of incident data from these tools lands, right as H2 tooling budgets get set. Leadership will be looking at the productivity upside. Your job is to bring the other half of the ledger and to bring it in language that lands: not "we need more monitoring," but "we have driven MTTU up by adopting agents, and here is what it is costing us in on-call hours and customer-facing minutes." That framing reads as an operating cost, not an engineering luxury.
This is the same discipline we argued for in Rethinking Infrastructure for the Open AI Ecosystem: the interesting question is never the shiny capability, it is whether your systems can absorb it. Agents are just the newest capability outrunning the infrastructure meant to hold it.
Tink was built around exactly this gap: watching production, correlating noisy alerts, and explaining a failure in plain English to whoever is on call, even when nobody on the team wrote the code that broke. If your agents are shipping faster than your humans can understand, that is the number to fix first.
Before you approve another agent seat this quarter, ask one question in the meeting: what is our Mean Time To Understand, and who owns bringing it down?
Try Tink on your server
One command to install. Watches your server, explains problems, guides fixes.