Kent C. Dodds says he averages 77 merged PRs a day
His argument is that slop is an old engineering problem with old engineering fixes.
Kent C. Dodds says his own average over the last five days is 77 merged PRs a day. That follows his claim, covered earlier, of 110 PRs merged in a single day from his phone.
Swap "agent" with "software developer" and you have a process that actually has always been a good idea.
The number is attached to an argument about the word slop. Dodds says he does not love the term because it frames the problem as new, and it is not. His process has three steps. One, make sure agents create high quality PRs in the first place. Two, have good agent PR reviewers catch problems before they reach production. Three, use feature flags and keep a regularly tested disaster recovery process for anything that does reach production. Swap agent for software developer, he writes, and you have a process that has always been a good idea.
Step four is the one that produces the count. Once the first three are in place, he says, you can connect the input pipes so agentic work kicks off without your attention, which is how people end up shipping thousands of PRs a month. He names @poteto as an example of that volume.
Where the idea comes from
@poteto had made the related case a day earlier, in a post aimed at engineers who treat slop as something happening to them rather than something they can engineer away. Her two rules are that the agent needs a way to verify its own work, and that your codebase is memory. Agents love extending what already exists, so every bad pattern you let stand gets repeated.
The prescription is to convert each observed mistake into a constraint, then keep repeating that loop until the codebase is locked down enough that an agent with little context can one shot a high quality PR. She explicitly deprioritises prompt engineering for this, saying to forget rules and skills and add them later. The stronger version is to refactor so that agent anti-patterns become categorically impossible, using type systems, frameworks that reduce the architectural search space, or a purpose built framework like the one her team made for grok bot.
Matt Pocock, separately, posted a list of mistakes in the same spirit, including automated checks that are too lax, not enough automated review, too much human review, and an agent that cannot verify its own work.
For working engineers, none of the three people here are describing a model capability. They are describing lint rules, compilers with good diagnostics, strong type systems, review and rollback, applied harder because the code is arriving faster. Dodds says the video explaining how he does it publishes the day after his post.
every nit and every annoyance you've ever seen, every mistake and bad pattern you observe from agents, needs to turn into a constraint
Have the good opinion, not the loud one
One email a day. Under three minutes. What working engineers found out about coding with AI.