here you goThings I’ve made, read and saved — shared here.

All Code is slop except mine

Lauren Tan (Potato / poteto) · Principal Engineer, SpaceXSI · Grok Bot

Web pageShared 5 min read

#slop#vibecoding

On this page
  1. TL;DR
  2. Thesis
  3. The inverse pyramid and the garden
  4. Concrete mechanisms
  5. Verification
  6. Results and a warning
  7. Quotes
  8. Takeaways
  9. Tools

All Code Is Slop (Except Mine)

TL;DR

Lauren Tan argues that the job of a software engineer in the age of agents is to maintain or even improve code quality while massively increasing throughput, and that the path there is trust in the agent's environment, not more lines in AGENTS.md. She presents an inverse "trust pyramid": put the strongest constraints in the codebase and in deterministic checks, layer on runtime and formal verification, and only then use written rules for things that require judgment. On the Grok Bot team at SpaceXSI, that approach coincided with 11,000 production pull requests in a month, a roughly daily stable release, about 227 October contributors, a revert rate around half a percent, and a faster Electron app. Her closing advice is to harden the inner loop first, because automating a sloppy loop only produces more slop.

Thesis

Tan shipped 3,000 production pull requests last month (0:42), after six months of work, a lot of them in her sleep. Before agents, volume barely mattered except for outliers once called "coding machines"; now anyone can work at that pace. Her thesis: a software engineer's job is to maintain or even improve code quality while massively increasing productivity (0:54). Some call this a software factory. She calls it trust: investing in the agent's environment so you can trust the agent to do the right thing (1:32).

The inverse pyramid and the garden

  • At 2:02, an inverse pyramid: first, deterministic layers in the code (API design, architecture, refactoring, lint rules, type systems, compilers, tests) that constrain agents and force the right thing by default; then runtime and formal verification, to find bugs, check invariants, and show whether the agent understood your goals; only then prose: rules, skills, AGENTS.md.
  • The codebase is one of the agent's largest inputs, so turn a correction into a deterministic check instead of another line in AGENTS.md (2:58).
  • Garden (3:26): in 2024 she reviewed the three PRs her colleagues wrote; today more like 300. Every engineer is now a team of hundreds or thousands of agents, and code arrives as a continuous stream. Guardrails are the concrete that new agent code grows around. Workarounds, anti-patterns, deprecated code, and tech debt spread like weeds because agents copy established patterns, so keep the garden pristine.

Concrete mechanisms

  • Dune (4:58): a Grok Bot client framework, kind of like Next.js for Electron apps, with constraints and lint rules from desktop-app lessons.
  • useEffect (5:25): anything that requires nuance to use well often leads to slop. Banned in product code, allowed only in some Dune APIs, because it is often misused and agents are not good at it; she says this categorically removed it from review.
  • Directories (6:27): agents, including in Cursor (also an Electron app), imported main-thread code into the renderer, causing long tasks and jank. Grok Bot and Dune use top-level electron-renderer and electron-main; lint and a dependency graph analyzer forbid cross-imports.
  • Comments (6:55, 7:22, 8:19): agents use comments, markdown, rules, and skills to justify not doing the right thing, or over-rotate on a small correction. Imperative timers (setTimeout, requestAnimationFrame, requestIdleCallback) were quick fixes for a VS Code / React clash and caused garbage collection, lag, and jank; comments helped them spread. The team banned 99% of comments (stale, unread "comment slop," unenforceable) and uses lint to force a root-cause fix.
  • Principle (9:09): every correction becomes a deterministic check, or the problem is eliminated in the API or architecture. Do that enough, and agents can merge most of their own pull requests.

Verification

  • Review has shrunk toward verification artifacts: videos, screenshots, diagrams, and formal verification (9:39).
  • Runtime verification (10:01): let the agent run the code and use human tools, including the Chrome DevTools Protocol. A "feature map" is a user-facing sitemap so the agent need not guess at "the thingy in the left sidebar." Custom CLIs reuse the same driver, which cuts token usage and is testable.
  • Formal methods are newer and not a silver bullet (10:49). TLA+ model-checks major flows such as notifications across devices and platforms; Lean proves algorithm properties, including a custom virtualization library (flicker or jitter). This has already found quite a few bugs; Bombadil property-based UI testing has already caught a few UI bugs (11:34).
  • Cindy could not trust her agents six months earlier because subtle bugs were getting merged; now 70% of her daily tokens go into verification (11:51). Ordinary tools that used to be too expensive; agents cut that cost, and she calls this a golden age of testing and verification (12:30).
  • She built a statechart skill in pstack (potato stack) to visualize user-facing state machines (12:54).

Results and a warning

  • Last month the Grok Bot team shipped a "ridiculous" 11,000 production pull requests, cut a new stable client about once a day, and in October had about 227 people land at least one PR (13:31). Revert share down on a relative basis, steady at about half a percent (14:14). Faster startup, typing, opening new chats, and switching chats; still Electron, so there is a ceiling, but she says it is already much faster than many other agent UIs (14:29).
  • Before building a software factory, start with the codebase: a lint rule to stop new anti-patterns, clean up old ones, and strong verification (15:10). If the inner loop produces slop, automating it just produces more slop (15:32).
  • Outer loop (16:06, 16:18): Grok Bot connectors and routines kick off Cursor cloud agents and projects and can orchestrate hundreds or even thousands of agents. After each release, a Cursor project fuzzes the app, opens fix PRs, and auto-merges them, "as crazy as that sounds," because PRs tend to be good by default and most product code no longer needs deep human review.

Quotes

So whenever you're correcting your agent, think about how you can make that a deterministic check instead of adding another line to your rules or your AGENTS.md (2:58)

And if your inner coding loop produces slop, then automating that loop just produces more slop, and you need to throw more and more and more tokens at the problem, which we all know is very expensive. (15:32)

So when you have solid foundations and good organic architecture, you can turn slop into gold and you can ship with high quality, high velocity, without compromising on quality. (16:55)

Takeaways

  • Prefer lint rules, types, tests, or API changes over more lines in AGENTS.md.
  • Tightly scope APIs that take too much nuance (useEffect in product code).
  • Shift review to verification artifacts, and give agents a way to run the product.
  • Do not automate a sloppy inner loop.

Tools

Open the page