Swizec Teller runs a team shipping 2,900 pull requests per quarter. The bottleneck isn’t writing code — it’s validating it. AI code-review bots (Cursor’s BugBot, custom Claude review skills) helped once but grew into a cost and attention problem: slow, pedantic, expensive, and paradoxically adding review burden by requiring humans to review both the code and the AI’s commentary.

Swizec’s solution: custom linters generated from design docs and style guides, using an LLM once to write the rule rather than running it on every PR.

  • Slow vs fast: LLM review takes 10–30 minutes per PR batch, long enough that the original author has wandered off. Linters run in seconds — the slowest takes 27 seconds for a full sweep.
  • Noisy vs deterministic: LLM bots flag generic edge cases and invented security concerns, adding verbose essays. Linters produce the same short message for the same issue every time — predictable and skim-able.
  • Shift left: Linters run in-editor (squiggly lines) and in pre-commit hooks, catching problems before code reaches GitHub. Agents self-correct mid-commit.
  • Generated from docs: Pointing an LLM at DESIGN.md produced rules like no-raw-color, no-hardcoded-mono, descriptive-test-names, no-swallowed-errors, check_import_direction (service layer doesn’t import from presentation), and a vale-de-blab linter that catches passive voice, AI tells, and navel-gazing in prose.

The principle is elegant: use an LLM once to codify team-specific norms into deterministic rules, then enforce those rules cheaply on every change forever. The insight applies to any team with strong opinions about code structure — which is most teams, whether they have documented them or not.