A Lint Rule for Every Bug
When review finds a bug, ask the agent for the check that would have caught it. That fixes the whole class of bug once.
The prompt
"asked bot to make a lint rule against it" (Lauren Tan, on every issue found)
Lauren Tan built a browser game in four days and about 1,150 agent PRs this way. Other rules from the same project are in Lint-Enforced Agent Guardrails: context in file names (.hot.ts bans allocation in the frame loop), comments banned by lint, and TLA+ specs for the game's state machines.
Why it works
Agents copy what exists and take the shortest path. A fix in one file teaches nothing to the next session, because the next session does not remember it. A lint rule does: it fires on every future change, costs few tokens, and tells the agent what is wrong at the moment it writes the code.
The companion post orders the tools for trusting agent work as an inverse pyramid, most effort at the top:
- Codebase improvements: better architecture, stronger types and invariants, clear boundaries, so the easy path is the right path.
- Static analysis: lint, tests, CI and formal checks such as TLA+.
- Prose: comments, rules,
AGENTS.md, skills. Use it for what cannot be enforced, and use it sparingly. - Human review: the hardest to scale, so spend it on designing an environment where agents do the right thing by default.
That post ends with a prompt that applies the pyramid to a codebase: read the user's past review comments and agent transcripts, find the pitfalls agents fall into most, and propose a plan to rearchitect the code so agents avoid them, answering open questions by prototyping and confirming the plan before starting.
When to use it
- Every time a review, a test failure or a user report finds a bug a rule could have caught.
- When the same correction appears in two sessions.
- When
AGENTS.mdgrows a rule that could be a lint rule instead.
If a rule cannot be written as a check, write it down in prose and move on; not everything can be enforced.
Which skill runs it
codebase-design holds the top of the pyramid (deep modules, removing special cases and fallbacks). doctor-enforcement runs the checks after edits. Kevin's own rule in less-is-more, "fix a problem's class once", is the same idea.
A standards file the reviewer reads
When a rule cannot be lint, put it where review will check it. Matt Pocock's fix for pointless generated tests is one line appended to a standards file that the /code-review skill reads: "Tautological tests considered harmful." The advice is to keep it there rather than in CLAUDE.md. Source: X/@mattpocockuk, 2026-08-27
Lauren Tan's "organic architecture" makes the same point at the scale of a codebase: when any number of agents can write code, review-enforced style guides stop holding, so the codebase needs hard constraints. A strong type system and compiler diagnostics do more than AGENTS.md or skill tweaks. "The best rules are in your code." Source: X/@poteto, 2026-07-18
Timeline
- 2026-11-03 | Page created from Lauren Tan's game build and inverse-pyramid posts. Source: X/@poteto, 2026-10-16 and 2026-11-01