The page arrives at 3 a.m. A service is failing under real load, the graphs are ugly, and the engineer on call opens the code to find out what it does. Nobody on the bridge wrote it. For most of my career, that sentence meant the author had left the company. Now it can mean the author was never a person.
That scene is not from our incident log, and my job is to keep it that way. I no longer believe the gates alone will. I left this question open at the end of The Golden Path Needs an Intent Interface. This is the answer I owe it.
The new constraint is not whether generated software can clear the gate. It is whether an organization can preserve enough operational understanding to restore that software when production violates the model the spec described. If intent compiles into implementation, operability has to become part of the intent.
The diagram ends too early
Most of the agentic SDLC argument, mine included, is about getting a change safely to production. The spec defines the work, the standards constrain it, the specialist agents produce it, and the gates verify it. Two Gates and a Night Shift put human judgment at the two points where it is cheapest and most consequential. The pipeline carries the change through deployment and live verification, and I stand by every step of it.
Then the diagram ends. The service does not.
I also went back through my own archive. I have written often about how work gets specified, generated, reviewed, and merged, and barely at all about what happens after that. The run side of my own argument is mostly unwritten, which is a strange gap for someone who carries operational responsibility for a Fortune 100 production estate.
Nobody pages the agent. Every production service still needs a human owner, and ownership without comprehension is only a name in a catalog.
The failure hides somewhere else
Bad code in the obvious sense already leaves evidence. Syntax errors, type mismatches, and missed null checks show up for a compiler, a test, a linter, or a reviewer. The dangerous change is the one that looks reasonable everywhere we know to inspect and is wrong only when it meets the system we failed to describe.
Agents did not invent that class of failure. They changed its economics. They can produce plausible implementations from an incomplete model faster than a team can discover what the model omitted. If the spec describes success and the tests model success, the output can be coherent and confidently incomplete.
In Part III of the second edition of the book, I gave this failure a name: the confident defect. A confident defect is a failure that ships fluently. The diff looks right, the tests pass, and the wrong thing reaches production. A gate catches only what its standards and evaluation actually exercise. The defect lives in the link the system skipped.
The shape is easy to recognize. A retry policy looks reasonable in review and passes every test built around returned errors. Under production concurrency, a slow dependency triggers retries, the retries amplify load, and degradation becomes a thundering herd problem. The implementation did exactly what the spec described.
The system as described is not the system that gets paged.
Comprehension debt
Recovery time has many inputs. Comprehension is one of them, and it is the one this essay is about. A responder who carries a working mental model can use the failure to test a suspicion. A responder who does not starts from symptoms, at night, under pressure, with no map. When nobody wrote it, nobody remembers it.
Nobody should have to memorize generated code to hold a pager. That would rebuild the syllabus the intent interface exists to retire. The human needs a smaller model: what normal looks like, how the service fails, which signal separates one failure from another, and how to return it to safety.
The gap between what a team's system does and what the team can explain well enough to maintain it has a name. Addy Osmani calls it comprehension debt. It is related to technical debt, but it does not live in the code alone. Clean code can carry it. Ugly code can be well understood. It lives in the distance between the system and the people responsible for restoring it.
Technical debt usually leaks into normal work through slow features, fragile changes, and familiar grumbling. Comprehension debt can remain silent until an incident calls it due, all at once, with interest. Agents do not create that debt. They let us acquire it at merge speed.
What agents actually changed
Engineers have always operated systems they did not write. That is the strongest objection to this argument, and it is true. Human authorship never guaranteed shared understanding. It did create repeated chances to build it: the implementation struggle, the design argument, the review comment, and the teammate who remembered why the retry count is four.
Agent-produced changes can compress or remove those encounters. They can arrive faster and with less human contact. A transcript can preserve provenance, but provenance is not a mental model. It records what the agent attempted and what the human accepted. It does not guarantee that anyone can explain the system when the symptoms break the script.
An agent can join the bridge too, and it should. It can read the runbook, correlate the signals, and propose a first action. The accountable owner is still a person, and the mental model that person needs most is the one that lets them recognize when the agent's suggestion is wrong.
The risk is the ratio. Agent-mediated change can outpace the humans who need to reason about it under pressure. Most delivery metrics do not watch that ratio.
If code nobody remembers is arriving at merge speed, we have to create and verify operability at the same speed.
Operability is spec-shaped
The fix is convenient for me, because it is the fix I keep proposing: put it in the spec. Operability is a requirement like any other. SLOs, expected failure modes, ownership, the rollback path, and the runbook belong in the specification and travel with the change. A gate that blocks a missing test can block a missing rollback path.
An agent that can write the service can draft the runbook for the service. That is useful, and it is not proof, because a generated runbook is still generated confidence. The artifact says what should happen. An exercise tells you whether it does. Execute the rollback, restore the backup, fire the alert, and inject a failed dependency. Then put enough load through the canary to observe the behavior the spec promised.
Chaos engineering already runs experiments like these against a steady-state hypothesis. Here the hypothesis comes from the operability spec, and the experiment runs at the gate, before the change merges. Not every change reruns every exercise. The service carries the baseline, and a risky change refreshes the evidence it can invalidate.
Return to the retry policy. The useful test is not only whether it retries four times after an error. The operability spec says what happens when the dependency is slow under representative concurrency. The gate injects the latency and verifies that outbound calls remain bounded. It exercises the rollback. The runbook points to the signal that separates dependency latency from local saturation and names the first mitigating action. Now the spec, the gate, and the person holding the pager share the same model.
Here is the minimum service contract I would require before changes merge:
- Name an SLI tied to user impact, the SLO target and measurement window, and the error budget implied by them.
- Name the accountable owner and the escalation path.
- Name the critical dependencies and describe what the service does when each one is slow or unavailable. That is a different question from what it does when each one returns an error.
- Carry a rollback path somebody has executed rather than described.
- Ship a runbook for the highest-likelihood and highest-impact failures, the signal that separates them, and the first safe action for each.
- Define whether the service degrades, rejects work, or fails closed under representative and above-forecast load, because saturation is where plausible defaults become production incidents.
Most estates carry hundreds of services that predate any contract like this. The gate applies to their next change, and service owners backfill the baseline by risk tier, starting with the services whose failure would hurt the most.
None of that is new reliability practice. In many organizations, pieces already exist on a wiki page written once and opened too rarely. What changed is the cost. An agent can draft the operability package alongside the change, while the task context and evidence are still available. Automation can make the exercises repeatable. Neither makes judgment free, and that is fine. The expensive part should be proving the service can fail safely, not typing the runbook.
The operability package is now cheap enough that its absence should be indefensible. The evidence still has to be earned.
The Spec Is the Product argued that the spec is the durable asset and the code is regeneratable output. This essay is what durable has to mean. A spec that stops at the happy path is a build artifact. A spec that carries the evidence needed to restore the service is an operational asset.
That creates a control loop. Specify operability in the service contract, prove it with exercises, measure what production teaches you, and throttle change to the reliability the service has demonstrated.
Tag agent involvement in the incident review
One form field costs almost nothing. Reliable provenance behind it is harder. Incident reviews should record the degree of agent involvement in every suspected contributing change, not only the apparent trigger.
Start with agent involvement: human-written, agent-assisted, or agent-primary. Record supervision separately. Preserve the originating spec, retained session or build provenance, verification path, and named human owner. Keep the trigger, contributing conditions, and authorship separate. Agent involvement is telemetry about the operating model, not a verdict on the tool. The classification will be imperfect at first. Imperfect provenance is still better than none.
The field exists so the questions become answerable. Do changes with heavy agent involvement fail in different ways? Do they take longer to recover? Did the runbook shorten the night? Which missing requirement should become the next gate? Until that field exists, every confident claim about how agent-involved changes behave in your production system is still a story.
Error budgets are the throttle
When agents can produce changes faster than humans can absorb them, something has to set the pace. Error budgets already connect a service's reliability to its release velocity. Do not invent a separate morality for machine-written code. Trust the gate, not the actor, and apply the service's existing policy regardless of who, or what, produced the change.
Burn rate is established too, as an alerting signal. I would wire the release policy to it, the same way the alerts already are. A service with budget remaining can still be burning it fast enough to justify tighter release rules before it runs out. While the service remains within its SLO and below the agreed burn-rate thresholds, changes follow the normal release policy. When it begins consuming budget too quickly, tighten the policy. When it exhausts the budget for a cause the service can control, freeze non-remediation changes to that service. Rollbacks, urgent security fixes, and recovery work keep moving.
This is still policy. The difference is that it is tied to observed service behavior rather than confidence in the actor. Agree on the thresholds, owners, exceptions, and resume conditions before the incident, then encode the parts the pipeline can enforce.
That policy needs a mechanism behind it. Cap non-remediation changes per service per change window, require service-owner review, use smaller canaries for necessary changes, and hold net-new work while recovery proceeds. Encode the rule once, where it applies without a debate about whether this particular agent is trustworthy.
The system earns throughput by demonstrating that it can absorb and recover from what it ships. That rule also answers the uncomfortable executive question of how fast the agents should be allowed to go.
As fast as the service can absorb without missing its SLO, and not one merge faster.
The gate proves a standard ran. The pager proves you can live with what it let through.
