Blast radius gets scored per pull request and the bugs are not

Gergely Orosz asked around and published a survey on September 8 of how teams are handling the review pile now that agents write most of the code. The GitHub data he cites has pull requests opened rising fivefold across three years, with the sharpest jump after the end of 2025. The answers sort into a few shapes. Humans review the AI review instead of the code. Triage by blast radius, which he confirmed with both Anthropic and OpenAI. Review the plan, or the tests, or the database schema, but not the implementation. Produce smaller changes. Or read everything by hand, which WeTravel still does after deciding the AI reviewers were too noisy to justify.

The receipts are specific. Duckbill Group, five people, woke up to sixty open pull requests, moved to a risk label enforced by a shell script, turned on nearly every lint rule and pushed unit coverage to a floor of 85 percent, and went from 353 merged to 684. Median merge time was one hour for changes no human read and twenty six hours for the ones a human did.

Here is where I would push back. Every one of these schemes scores a single change. The vault’s coding workflow page carries a failure that no per-change score would have caught: a source-field decision and a gate threshold, each defensible on its own, incompatible together, with test fixtures built in a way that made the gate incapable of detecting the resulting production failure. That is a composition bug. It has no blast radius until two green diffs meet.

Concede that triage is still the right first move, because reading everything is not a plan at five times the volume.

Still, a low-risk label is a claim about one diff, and the thing that breaks is the branch. The teams reviewing schemas and plans are closer to right than the ones grading patches, and I suspect they got there by accident.