Your Coding Agent Is Creating Review Debt
Speaking session at AI Engineer World's Fair 2026
AI Engineer World's Fair 2026 talk: your coding agent is creating review debt, the accumulating gap between the code an agent produces and the code humans have actually reviewed, trusted, and understood. Five signal families and ten deterministic checks turn that gap into a single defensible score, validated across 524 real pull requests.
Your coding agent is not the problem. The debt it quietly creates is. Every AI-authored pull request that ships faster than a human can genuinely review it widens a gap, between code produced and code actually reviewed, trusted, and understood. This talk gives that gap a name, review debt, and a way to measure it as a single defensible number.
A short note on the talk
This was my session at the AI Engineer World's Fair 2026, one of the largest industry AI engineering conferences. The room is full of people shipping agents into production, so I did not pitch it as an anti-AI talk. Coding agents make teams faster, and that is real. The argument is narrower, and I think more useful: that speed creates a specific, compounding cost nobody is measuring, and that you can measure it deterministically, without a language model in the loop. The recording is above, the slides are below it, and what follows is the written version.
The gap nobody is measuring
Start with two public numbers that move in opposite directions. GitHub's 2025 Octoverse report, which covers every public pull request, shows commits up about 25 percent year over year while comments on commits, the closest proxy for review activity, fell about 27 percent. Production went up; review attention went down, in the same year. And on the teams furthest along the AI-adoption curve, Faros AI's 2026 benchmark reports median PR review time up more than fourfold, and roughly a third more pull requests merged with no review at all. Agents produce pull requests quickly; humans cannot responsibly review them at that pace. That gap is review debt, and it accrues quietly.
Why the usual metrics hide it
The numbers most teams celebrate, PRs per developer up, cycle time down, are real, but they are vanity metrics. PR count rises when one change splits into seven. A bigger median PR is bloat, not benefit. Cycle time falls when reviewers stop pushing back. They measure the speed of production, not the speed of trust. The costs that actually matter, reviewer fatigue, late-night rubber-stamp merges, tests that assert what the code does rather than what it should do, architectural drift, and incident lag, show up on no dashboard.
Review debt, defined
Review debt is the accumulating gap between code your agent produced and code humans have actually reviewed, trusted, and understood. It behaves like financial debt: it compounds, and the interest is paid in human attention. It compounds through three feedback loops. Agents learn from your codebase, so lightly-reviewed code grounds tomorrow's suggestions and the debt becomes generative. Reviewers cede the architectural call, because when most of a PR was generated, attention contracts to syntax and obvious bugs. And velocity expectations reset, so you never get to hire reviewers in proportion to the new throughput. Each loop is survivable on its own; together they run away.
Measuring it: five signals, ten deterministic checks
The heart of the talk is a way to score any pull request from 0 to 100, using five signal families implemented as ten deterministic checks: diff size and coupling, test evidence gap, directory and ownership spread, AI-authorship indicators, and evidence and rationale gaps. The most important word is deterministic. Every check is computable from a pull request and its repository, with no language model in the loop, because an LLM judge makes the score a moving target and something you cannot defend in an engineering review. The AI-authorship check is an amplifier only: it never fires a penalty on its own, and it never adds to the score when tests pass and CI is green. The framework punishes review burden, not AI authorship.
What the scans showed
I scored three pull requests side by side: a clean one (score 0, an almost ceremonial "looks good"); a large agent-assisted refactor with suspect claims and no tests (score 60, where the AI-indicator contributed only about 8 percent and the rest came from diff size, claim mismatch, and missing tests); and a well-shaped AI-authored PR with tests and a clear description (score 7). Then a 90-day scan across three public open-source repositories and 524 merged pull requests: about 228 cumulative senior-reviewer-hours, one outlier a 1,163-file SDK migration that scored 73 and should have shipped as a dozen smaller PRs, and AI-authorship firing on a steady 5 to 20 percent of PRs every week. The finding that matters: volume, not authorship, drives the burden. The amplifier-only design held up against real codebases.
From measurement to governance
The payoff is a conversation. Without a number, "reviewers seem tired" is easy to dismiss. With one, you can say the rollout added some percent of throughput and some points of review debt over a number of weeks, at a slope of so many senior-engineer-hours per week, and put a cost on changing that slope, or not. 2026 was the year teams decided whether to adopt coding agents; 2027 is when that shifts to governance: can we trust what we ship, who is accountable when an AI-authored change causes an incident, and where is the audit trail. Review debt is the first number that lets you have that conversation without giving up the speed.
If you take one thing away, score your last twenty pull requests by hand against the five signals this week. If the number matches your gut about which ones were painful to review, you have your framework. It is the same theme I keep coming back to in my work: the model can produce anything, so the interesting engineering is in the layer that decides what you actually trust and ship.
