3,000 Pull Requests a Month, and the Codebase That Made It Possible
One engineer shipped 3,000 PRs last month. Her talk is about bans, lint rules and verification budgets, not a better model.
Guide7 min read
Lauren Tan shipped about 3,000 pull requests to production last month. Her team shipped 11,000. The number is not the interesting part. The interesting part is that the revert rate stayed around half a percent while roughly 227 people contributed at least one pull request in October, and that most of that code was never read by a human before it merged.
Her talk at AI Engineer is called "All Code Is Slop (Except Mine)", which is a joke about how every engineer judges generated code by a different standard than their own. The argument underneath the joke is narrower and more useful than the title suggests: the thing that let a team ship at that rate was not a smarter agent. It was a codebase with most of its doors bricked up.
The number that needs explaining
Velocity claims about AI coding are cheap, so start with the checks that make this one expensive to fake.
The team cut a new stable version of the client about once a day. Reverts held at about 0.5% of pull requests, lower on a relative basis than before the agents arrived. Performance, measured on startup, typing latency, opening a new chat and switching between chats, improved rather than decayed. All of this on an Electron app, which Tan points out has a ceiling, and which she does not pretend is free.
The scale change is easiest to see in review. In 2024 she would walk into work and review the three pull requests her colleagues had written that day. That number is now closer to 300. Nobody reviews 300 diffs with the same attention as three, which is the actual problem the rest of the talk solves: if review cannot scale, review has to become something else.
Trust is an environment, not a model
Tan's framing is an inverted pyramid, and the order matters more than the diagram.
At the base, the deterministic layers: API design, architecture, refactoring, lint rules, type systems, compilers, tests. Above them, verification, both runtime and formal. At the narrow top, prose: rules files, skills, AGENTS.md — anything that depends on the agent exercising judgment.
The reasoning for that order is that agents generate output from input, and the codebase is the largest input they get. A codebase full of workarounds teaches the next agent that workarounds are the house style. She uses a gardening analogy: constraints are the concrete foundations, new code grows around them, and weeds spread because nothing stops them.
The practical rule that follows is blunt. Every time you correct an agent, ask whether the correction can become a deterministic check instead of one more line in a rules file. Code is reproducible; prose is a suggestion.
What they banned
The concrete examples are where the talk earns its keep.
In Dune, the client framework the team built for Grok Bot and describes as roughly "Next.js for Electron apps", useEffect is banned in product code. It is allowed only inside specific Dune APIs. The reason given is not that the hook is bad but that it needs nuance to use well, agents handle nuance badly, and a lint rule eliminates the whole category of mistake. "We never need to catch that during code review again."
Import direction is enforced the same way. Two top-level directories, ElectronRenderer and ElectronMain, and imports between them are blocked by a dependency graph analyzer and lint rules. That came from watching agents pull main-process code into the renderer and produce long tasks and jank.
The third ban is the one that will annoy people. Grok Bot banned 99% of code comments. Tan's case: comments go stale, humans stop reading them, and an agent will happily use a comment to justify a shortcut instead of fixing the cause. The example she gives is from Cursor, where agents leaned on imperative timers — setTimeout, requestAnimationFrame, requestIdleCallback — as quick patches over a clash between VS Code's imperative style and React's declarative style. The timers multiplied, garbage collection climbed, the app stuttered, and the agents had written comments explaining why each patch was justified. The comments made the mess look intentional.
The replacement is lint rules that fail with a message telling the agent to fix the root cause. Do that enough times and the review queue empties itself, which is how agents end up merging their own pull requests.
Review moves from diffs to artifacts
If the code is constrained enough, the question stops being "is this diff correct" and becomes "did the thing work". Tan's team reviews artifacts: videos, screenshots, diagrams, formal verification output.
Runtime verification here means giving the agent a way to run the app and use the same debugging tools a person would, such as the Chrome DevTools protocol. Their skills include a "feature map", a sitemap of the product from the user's point of view, so that "the thingy in the left sidebar" resolves to something specific. They also wrap the driver in small custom CLIs, which cuts token usage and makes the check testable.
Formal verification is the newest layer and Tan is careful about it. They use TLA+ to model-check flows like notifications across multiple devices and platforms, and Lean to prove properties of a virtualization library they wrote, specifically to rule out flicker and jitter. Property-based testing for the UI runs on a library called Bombadil. She says formal verification has already found real bugs and is not a silver bullet; it is one more layer, still experimental.
The budget shift is the part worth stealing even if you never write a TLA+ spec. Tan cites another engineer who said that six months ago she could not trust her agents because of subtle bugs slipping through, and that today about 70% of her daily tokens go into verification. Tan says that matches her own usage. Most of the spend is not generation. It is checking.
Her read is that none of these techniques are new. They were simply too expensive to maintain before, and agents cut the cost of writing and maintaining them, which is why she calls this a good time to be doing software testing.
The bill comes first
The part of the talk that will be quoted least is the part about sequence.
It took Tan six months to reach the point where she could ship thousands of pull requests, many of them while asleep. The advice is to resist building the factory first: when you correct an agent, improve the codebase, start with a lint rule that stops new occurrences, then clean up the old ones. "If your inner coding loop produces slop, then automating that loop just produces more slop." The cost shows up as tokens, and tokens are not free.
Only after that foundation does the outer loop make sense. On each release, the team now spins up an agent project that fuzzes the whole application, uses it the way a real user would, files a fix for each bug it finds, and auto-merges. That last step is only defensible because the pull requests tend to be good by default, which is a statement about the codebase, not about the model. It is also, fairly, a demonstration of Grok Bot, the product Tan works on, and worth reading as such.
The uncomfortable question
The talk's real claim is that the bottleneck in AI-assisted engineering is not model quality but how much of your codebase you are willing to make illegal.
That is a harder sell than a better model, because it requires knowing what your code should look like, and most teams have never had to write that down. A lint rule is an opinion about the right way to build something, expressed precisely enough that a machine can enforce it. Banning useEffect is not a technical decision. It is a taste decision with a compiler attached.
So the question is not whether your agents are good enough. It is which of your current habits you would be willing to forbid, and what breaks the first week after you do.
More podcast deep dives from Podwise.
