June 27, 2026
The Drill We're Not Running
This post is part of my Medium blog.
In June, I wrote about knowledge decay — the HBR piece about AI slop embedded at every step of a process, each step stopping checking the last one. Job descriptions AI-written, résumés AI-optimized, screening AI-ranked, interviews AI-conducted. Nobody's reading anything. They're generating and evaluating AI output about other AI output.
That was about processes. Here's what's coming for the code.
New Relic's 2026 State of AI Coding report surveyed 200 technology leaders at enterprise companies. The headline finding: 67% report that AI generates or significantly refactors between 51% and 75% of their weekly code output. The median enterprise is now operating in a codebase predominantly written by machine intelligence. And here's the contradiction at the center of it: 94% of leaders rate AI-generated code as higher quality than human-authored code at review time. But once that same code ships, 78% report more incidents. 86% report an increase in senior engineer time spent fixing code. 74% say at least 25% of AI code needs significant rework. 82% report production failures in the past six months.
New Relic's Chief Technical Strategist Nic Benders called it "agent debt": "the rapid accumulation of unvetted architectural logic that triggers production incidents down the line." The code looks good in review. It passes the checks. It ships. Then it breaks, and nobody can explain why, because nobody wrote it.
Two to three years from now, this gets worse in a way the report doesn't capture. It's not just that AI-generated code produces more incidents. It's that the knowledge of how the system works — the mental model that an engineer builds by writing code, debugging it, living with it — doesn't exist. The code was generated, not written. The person who prompted it into existence doesn't understand the architecture. The person who reviewed it rated it high quality because it looked clean, not because they traced the logic. And the person who'll be asked to fix it at 3 AM during an outage has never seen it before.
You can't hire your way out of this. The METR study found that experienced developers were 19% slower with AI tools but believed they were 24% faster. The developers who would normally build deep familiarity with a codebase are using tools that let them skip that process. They're optimizing for shipping, not for understanding. In two to three years, the senior engineer who can walk into an unfamiliar codebase and reason about it from first principles is going to be rare — not because the skill disappeared, but because fewer people are developing it. The pipeline that produced engineers who understood systems from the metal up is being replaced by a pipeline that produces engineers who understand prompts.
Now think about incident response.
When something breaks at 3 AM, the on-call engineer pulls up the dashboard, reads the logs, traces the failure path, and starts remediating. That process assumes the engineer can read the code. Not just the diff — the architecture. Why this service calls that one. What happens when this queue backs up. What the failure mode looks like when this cache invalidates at the wrong time. That knowledge comes from having written or maintained similar systems. It doesn't come from having prompted a tool that generated something that compiled.
The industry is responding to this by making incident response agentic too. Datadog announced its Bits AI SRE agent — it reads telemetry, understands architecture, follows runbooks. PagerDuty launched an SRE Agent that runs diagnostics, surfaces context, suggests remediation, and can execute approved actions automatically. New Relic has its own SRE Agent in preview. The pitch is the same across all of them: let the AI do the first pass. Let it correlate the telemetry. Let it suggest the fix.
Here's the problem nobody's asking about. What happens when the AI service is the incident?
If your SRE tools are agentic — if your incident response depends on an AI service reading your telemetry and suggesting remediation — then an outage at that AI service is a simultaneous failure of your response infrastructure. The thing that's broken is also the thing you use to figure out what's broken. You've coupled your incident response to a third-party service that you don't control and can't guarantee.
This isn't hypothetical. Model providers have outages. OpenAI had a major API outage in January 2025 that lasted hours. Anthropic has had multiple degraded-performance incidents. When your SRE agent can't reach the model, it's not an SRE agent. It's a dead process.
And the codebase it was supposed to help you navigate? You didn't write it. Your team didn't write it. An agent wrote it, and the person who reviewed it checked the box that said "looks good" because the diff was clean and the tests passed. Now it's 3 AM, the service is down, the SRE agent can't reach the model, and the on-call engineer is staring at code that nobody in the building has ever read.
Are any of you running drills for this? When was the last time your team simulated an outage where the AI tools went down at the same time as the system? If the answer is "we haven't," that's the answer. It's time to start.
Run a game day where the model provider is unreachable. Turn off the SRE agent. Hand your on-call engineer a terminal and the codebase and see what happens. If they can't trace the failure path without the AI — if they can't read the code, find the bug, and write the fix — then you've found the gap. And the gap isn't in the tools. It's in the knowledge.
The HBR piece was about knowledge decay in processes. This is knowledge decay in code. The process decays when nobody checks the output. The code decays when nobody understands the input. And in two to three years, the people who could have understood it won't be available — not because they're gone, but because they never developed the skill. They shipped faster than anyone in history. They just can't explain what they shipped.
Run the drill. Before you need it.
In Redundant, the first book in The Condition Set trilogy, Rob Coleman runs the FinOps review that names the waste nobody wants to hear about. The numbers don't change. The question is who they get used against.