`references/seed-automation-doctrine.md`

100 lines
# Seed post — the Automation Doctrine (2026-07-15)

Source: https://x.com/bcherny/status/2077460395279692197
Author: Boris Cherny (@bcherny), creator of Claude Code
Engagement at capture (2026-07-22): ~9,939 likes, 388 replies
Full text captured verbatim below (3,034 chars, via hydrate-tweet.js).

## Verbatim text

> Something I have been thinking about: in the past, the best engineers I knew
> spent a lot of time automating their work in various ways. Better vim/emacs
> automations, writing lint rules to catch repeat code issues, building up a
> suite of e2e tests so they don't need to smoke test the app manually. These
> kinds of things were the highest leverage activities an engineer could do,
> because it multiplied their own output, which in turn meant they could build
> more things.
>
> I think many of these automations have become even more important now. This
> is true for a number of reasons.
>
> First, infra and DevX automation speeds you up. And if you are running an
> army of agents, each of those agents will be sped up also. More automation ==
> more output per unit of time.
>
> Second, moving things to code improves efficiency. Your agent could fix an
> issue every time it sees that issue happen, but that uses tokens and might
> miss cases. If Claude instead writes a lint rule, CI step, or routine, that
> class of issue can be fully automated forever. This is really what people are
> talking about when they talk about loops -- it's about automating entire
> types of busywork rather than solving them one off. This isn't a new idea at
> all. Engineers have been doing this for a long time!
>
> Third and most importantly, automation makes it possible for others to
> contribute to the codebase more easily. Increasingly what I am seeing is
> engineers are contributing to codebases on day one because Claude can
> navigate the codebase for them, and that non-engineers are able to contribute
> to a codebase as effectively as engineers can. What gets in the way of both
> of these is domain knowledge that lives in peoples' heads rather than in
> automation -- the stuff you used to have to learn when ramping up. What has
> changed thanks to agents is the domain knowledge that can be encoded as
> infrastructure is no longer limited to what is expressible in lint rules and
> types and tests; it can now capture nearly all domain knowledge, encoded as
> code comments and skills and CLAUDE.md rules and memories. If I put up a PR
> for an iOS codebase I don't know and a code reviewer rejects it because it
> doesn't use the right framework, or if a designer builds a new feature and it
> gets rejected because it doesn't follow the right architectural patterns,
> these are failures of automation.
>
> Every team should be writing the CLAUDE.md's, REVIEW.md's, skills, and docs
> that enable agents to productively work in their codebase with zero
> additional context from the prompter. This sounds crazy, and at the same time
> is a natural extension of the stuff engineers have always done: automate, and
> encode domain knowledge as infrastructure. As the model gets smarter and as
> the harness matures, this task becomes easier. In the meantime, it is on
> every team to look for ways to convert their domain knowledge to infra so
> that Claude can write code better, so that code review catches issues
> automatically, and so the next person working on your codebase can
> contribute more easily.

## Distilled doctrine (the operational rules)

1. **Second-fix rule.** The first time an agent fixes an issue, it is a fix.
   The second time it fixes the *same class* of issue, that is a failure of
   automation — convert the class into a lint rule, CI step, canary, hook, or
   routine so it can never recur silently. Token-spend on repeat fixes is
   waste; code is free forever.
2. **Rejection = missing infra.** Any time work is rejected in review for a
   rule the author "should have known" (wrong framework, wrong pattern, house
   convention), the fix is not "tell the author" — it is to encode that rule
   where the agent reads it (CLAUDE.md, REVIEW.md, a skill, a memory).
3. **Zero-additional-context test.** The bar for a codebase's automation:
   an agent (or a day-one human) should be able to contribute productively
   with *zero* extra context from the prompter. If a task needs tribal
   knowledge delivered in the prompt, that knowledge belongs in infra.
4. **Automation multiplies fleets.** A DevX speedup is no longer ×1 engineer;
   it is ×N agents. Prioritize automation work accordingly — it compounds
   across every parallel session.
5. **The encoding surface is now everything.** Pre-agents, encodable domain
   knowledge was limited to lint rules, types, and tests. Now nearly all of it
   is encodable: code comments, skills, CLAUDE.md rules, memories, review
   docs. "It can't be automated" is rarely true anymore.

## How this maps onto Steve's stack (verification notes, 2026-07-22)

Steve's setup already practices much of this — the doctrine mostly *names*
what exists and sharpens the second-fix reflex:

- Already-encoded examples: the canary fleet (dw-five-field-canary et al. are
  literally "class-of-issue automated forever"), the MEMORY.md gotcha entries,
  CLAUDE.md standing rules (sort+density, admin created-date chips, MAP
  pricing), /best-practices pre-flight, /compound-engineering's
  Plan→Work→Review→Compound loop, /dreaming (session mistakes → memory).
- The sharpened habit this post adds: when a fix lands **twice** for the same
  class, stop and ask "lint rule / canary / hook / skill / CLAUDE.md — which
  one kills this class?" and draft that codification in the same session,
  instead of a third fix later.
- REVIEW.md is the one named artifact Steve's repos generally lack: a
  per-repo file of what code review rejects, readable by /code-review and
  /claude-codex panels. Candidate adoption, per-project, gated.