AI Writes the Code, Your Team Pays the Debt: What Agent-Generated Code Does to Maintainability

Coding agents are now writing production code in a large share of enterprise teams, and the pull request looks clean: it compiles, types check, CI is green. The uncomfortable question is what that green tick actually certifies. Two September 2026 papers argue it certifies almost nothing about maintainability.

The first, AI Writes Code, Humans Pay the Debt, sets out to measure how agent-generated code affects software quality over time — issue localisation accuracy, the introduction of technical debt, and how that debt evolves across subsequent commits. The second, A Governance Methodology Layer for AI-Assisted Software Development, makes the sharper structural point: autonomous coding agents produce output that passes syntactic checks — compilation, type safety, CI — at high velocity, but syntactic correctness does not imply semantic correctness. Design boundaries, security invariants, and maintainability contracts remain structurally invisible to automated pipelines.

For a CTO, that is the whole problem in one sentence. Your velocity dashboard is measuring the thing the agent is good at, and staying silent about the thing that costs you for the next three years.

Finding 1: CI green is a floor, not a bar

The governance paper draws a line between two classes of defect. One class — null dereferences, type mismatches, obvious injection patterns — is structurally detectable by static analysis and gets caught by the pipeline. The other class is not: a change that quietly widens a module's public surface, couples two components that were deliberately kept apart, or violates an invariant the code never encoded explicitly. An agent optimises for passing the checks it can see. The defects that survive are precisely the ones your automated pipeline cannot express.

This matters more with agent-generated code than with human code, because a human author usually carries the design intent in their head while they write. The agent does not. It produces something locally plausible that satisfies the visible constraints, and the design erosion accumulates commit by commit.

Action: Separate your quality signals. Track "passes CI" and "passes review against design intent" as two distinct gates, and stop treating a green pipeline as evidence of mergeable quality. This week, pull ten recently merged agent-assisted PRs and ask a senior engineer one question per PR: *does this respect the module boundaries we intended?* The hit rate will tell you how much your CI is actually certifying.

Finding 2: The debt compounds where localisation fails

The empirical study focuses on issue localisation accuracy — how well a change can later be traced back to the right place when something breaks. This is the unglamorous heart of maintainability. Debt extends beyond messy code; it represents code whose failure modes are hard to locate. When agent-generated changes spread logic across boundaries or introduce implicit coupling, the cost does not show up in the PR. It shows up six months later when an incident takes twice as long to diagnose because the responsible code is nowhere near where the symptom appears.

This is the mechanism behind "humans pay the debt". The productivity benefit is booked immediately and visibly. The cost is deferred, diffuse, and lands on a different team than the one that captured the gain — usually the on-call rotation and the next feature squad.

Action: Instrument the cost side. If you are adopting coding agents, start tracking mean time to locate for incidents in agent-heavy areas of the codebase versus human-authored areas. If localisation time is climbing where agent contribution is highest, you have quantified your debt accrual before it becomes a crisis — and you have the number you need to justify a stronger review gate.

Finding 3: Process beats capability

The governance paper's most useful contribution for engineering leaders is its "process-over-capability" evidence: the defects that survive are addressed more reliably by changing the *process* around the agent than by waiting for a more capable model. You do not fix invisible-invariant defects by upgrading to a smarter agent, because a smarter agent still cannot see contracts the code never encoded. You fix them by putting a review step in the path that can.

That review step has to be adversarial and design-aware. It is not a linter and it is not a rubber-stamp approval. It is a senior engineer — or a structured review protocol — asking the questions the pipeline structurally cannot: what boundary did this cross, what invariant did this assume, what will this cost to change later. Cloudflare's recent work on context-aware vulnerability remediation, where production traffic and security signals prioritise findings before proposing patches, is a useful proof point in an adjacent domain: even for security, the value comes from *context and prioritisation around* the automated output, not from the raw generation. The same logic holds for maintainability.

Action: Make the review gate structural, not optional. Require that any agent-assisted change above a size threshold gets a design-level review from someone senior enough to hold the intended architecture in their head — and give that reviewer explicit permission to reject on maintainability grounds alongside correctness. Measure the gate: track what it catches, so the value is evidenced with measured data.

What this looks like in delivery

The temptation, when velocity is up and CI is green, is to declare victory and let the debt compound quietly. The teams that get durable value from coding agents are the ones that keep a strong senior review gate in the path and measure what it catches — treating the agent as a fast drafter whose output must clear a human-defined bar before it counts as done.

This is exactly how the Anystack pod works. The pod uses AI in its own delivery — retrieval over a client's documentation, drafting stories and first-pass implementations — but nothing reaches production on the strength of a green pipeline alone. Every change clears test-effectiveness measurement and adversarial review against the client's own bar, so what merges is evidenced for maintainability with verified records. For an engineering leader adopting coding agents at scale, the lesson from both September papers is the same: keep the velocity, but put a design-aware review gate in front of it, and measure it. The debt you avoid is paid by the team you have not hired yet.