Where code quality goes when nobody has time to read the diff

Osmani's argument is that code review does not scale to agent-generated volume, so quality has to move into the constraints placed around the agent: tests, mutation testing, complexity and line-length limits, and whatever else gates a change before it reaches production. He lays out a three-lever model for what to do when verification capacity is outstripped by agent output: scale the verification system, throttle how fast agents generate changes, or lower the quality bar, and argues teams should expect to use all three at different times rather than pick one permanently. "Quality is in the constraints that we place around our agents," he writes, closing on the idea that the design question is no longer what a human catches on review, but what the harness is built to catch before a human ever sees it. The essay also circulated as a long-form X post that had drawn over 360,000 views by the morning of the 13th, an unusually wide reach for this kind of piece.

Why it matters: This is a framing piece more than a new technique, but it names a decision every team running agents at volume is already making by default, whether deliberately or not: which checks are load-bearing enough to gate a merge, and which are just process.