Turning agent slop into gold: lint rules and verification at Grokbot

In a conference talk posted to YouTube, an engineer who goes by Potato says they personally shipped 3,000 pull requests to production last month and that the team behind Grokbot, an Electron desktop app for working with AI agents, shipped 11,000. Potato's explanation for how that volume stays usable starts with one habit: whenever you correct an agent, turn the correction into something a machine checks, such as a lint rule, a type, a test or a change in how the code is structured, instead of adding another line to an instructions file like AGENTS.md. The reasoning is that agents write code based on what they read, and the largest thing they read is the codebase. A workaround or deprecated pattern left in place looks like the house style, so the next agent copies it.

Most of the examples remove a decision from the agent entirely. The team built a client framework called Dune, which Potato compares to Next.js for Electron apps, and encoded lessons from building desktop software into its lint rules. React's useEffect hook, which the talk says takes a lot of nuance to use well and which agents tend to misuse, is banned in product code and allowed only inside Dune's own APIs. At Cursor, another Electron app, the talk says agents often imported code meant for the main thread into the renderer thread, causing long tasks and jank, so in Grokbot the two sit in separate top-level directories and imports between them are blocked by a dependency analyzer and lint rules. The team bans about 99% of code comments as well. In a second example from Cursor, agents used timers such as setTimeout as quick fixes and wrote comments defending them, until the timers spread and performance suffered. Instead of relying on comments, Grokbot's lint errors tell the agent to fix the root cause.

The second layer is verification, and according to the talk, code review on the team has largely shrunk to inspecting what verification produces: videos, screenshots, diagrams and formal verification results. The basic form gives the agent a way to run the app itself with the debugging tools human developers use, such as the Chrome DevTools Protocol, along with a feature map, a list of the app's features from the user's point of view that gives people and agents the same names for parts of the interface. The team has also started using TLA+ to model-check major user flows, such as notifications across devices, using Lean to check that a custom virtualization library it wrote does not cause flickering or jittering, and running property-based UI tests with a library called Bombadil. Potato calls the formal methods experimental and "not a silver bullet", while saying they have already found bugs.

The evidence offered on quality is the team's own reporting. Besides the 11,000 pull requests, the talk says the team cuts a stable release about once a day, about 227 people contributed at least one pull request in October, and the share of pull requests that get reverted has fallen and holds steady at about half a percent. Potato also says startup, typing, opening chats and switching chats have all become faster since launch. The talk gives no earlier revert rate to compare against, and a revert catches only changes bad enough to roll back, so these figures show that the faster pace has not visibly broken the product. They do not measure code quality directly. This account is based on the caption transcript only. The slides and demo videos shown in the talk were not seen.

The advice is mostly about order. Fix the codebase and make verification strong before automating, Potato says, because an inner loop that produces slop will produce more of it once automated. Only then does the talk describe the outer loop, in which each new release triggers an automated project that uses the whole app like a real user, opens pull requests fixing the bugs it finds, and merges them, which Potato says works because most product code no longer needs deep human review. Steve Yegge reached a related caution in his own recap of talks on software factories, writing that factories need a large amount of curation or they turn into what he calls "garbage mountains".