Refactoring says "the third time you do something similar, refactor". I lowered it to two for a reason that probably only holds for solo Claude Code dev: there is no PR review, so the second occurrence is the last moment where I am still lucid about the abstraction I am about to commit to. By the third, Claude proposes the abstraction spontaneously and I sign without looking, because session pressure has worn me down.
Never the first. The never is deliberate and probably excessive. But a default formulated with an exception becomes an exception searched for. Never shuts down the internal negotiation. When the genuinely exceptional case arrives — and it does — I must argue against the rule explicitly, which is exactly the friction I want.
What I have seen so far
Three sessions, three subjects, three modules. Claude proposed one premature abstraction that I caught and that he retracted in one exchange, against three or four per session the week before. Not a study. One observer, confirmation bias, sample ridiculous. But the line loads with CLAUDE.md on every start, and the baseline pressure now points against the trained default. A proper A/B test is the subject of a later post.
Coda
The doctrine in CLAUDE.md is not a list of best practices. It is the material accumulation of lessons I refused to repeat a fourth time. The rule of three (Fowler, abstractions) applied to the rule of three (mine, oral reframings in session). The third time I find myself saying the same thing to Claude, it goes into CLAUDE.md as a line. Otherwise I will say it again in the next session, and the lesson will leave with the context.
Sequel to [CANONICAL URL #52: to complete after push of over-engineering-3-recadrages]. A/B test of the CLAUDE.md effect on Claude Code output: subject of a later post in this series.