Gary Bernhardt says he cuts agent diffs to 25% of their size
Three engineers describe the same week from different angles, and all of it lands on the review step.
Gary Bernhardt says the agent output he actually reviews looks nothing like the agent output people describe on X. In his post he puts a number on it. On everyday changes, his reviews often cut the diff to a quarter of its original size, and he names what he is cutting. Useless tests, paranoia, inverted logic.
In everyday changes, my reviews often cut the diff to 25% of its original size. Tons of useless tests; paranoia; inverted logic.
That is one engineer's experience on his own work, not a benchmark. It is also a specific, falsifiable claim about what survives review, which is more than most of the genre offers.
The bugs that pass review
David K 馃幑 described a different failure mode in a post the same week. His framing is that code quality is not the problem. Agents fill gaps with assumptions when information is missing and then commit to them, and he calls that the worst kind of bug because the agent does not register it as a bug at all.
They make *assumptions* when missing info and bake them in. This is (IMO) the worst kind of bug: the kind agents don't even recognize as bugs.
His point about code review agents is the sharp one. They are good at judging code on its own terms, and bad at noticing that correct looking code does not do what you wanted. He notes that grilling the agent with 200 questions up front does not fix it either, since some things are not knowable until implementation. His prescription is unglamorous. Read the code, or at least skim the tests and the core logic.
Four passes, one terrible interface
ThePrimeagen supplied the week's worked example of automated review not saving anyone. He described three hours building a feature with Fable, a thorough review from Sol, a simplicity pass from Grok that stripped superfluous code and unnecessary guardrails, and then another Sol pass to check the simplification had not broken any contracts. The output was, in his words, one of the worst interfaces he has ever seen.
and all of this to produce one of the worst interfaces I have ever seen.
Thariq replied with "I'm sorry Prime but I need to call Skill Issue here", which is where the disagreement actually sits. Nobody in this exchange is arguing the models cannot write code. The argument is about how much of the remaining mess is the tool and how much is the operator.
For working engineers, the common thread across all three is that none of these problems announce themselves. Bernhardt's excess tests pass. David K's baked in assumptions compile. Primeagen's interface survived four separate review passes from three different models. The generation step is cheap and the judging step is not, and stacking more models onto the judging step did not close the gap in the one example anybody posted this week.