# Abstract Only After Two Real Implementations Exist ## Claim An abstraction should be introduced once a second real implementation is in play, not in anticipation of one. <!-- atomicity: 1 idea ✓ --> ## Evidence **Source**: [[3. Resources/Readwise/Articles/Your AI Roadmap Is Already Out of Date|Your AI roadmap is already out of date]] — LeadDev, on setting technical direction when the ground keeps moving > [!quote] > The rough rule I use: abstract when you have two real implementations in play, not before. The rule earns its place because of what it *counterbalances*. The surrounding argument is that decisions should be sorted by reversal cost, with interfaces treated as commitments and orchestration as experiments — advice that reliably produces over-abstraction in teams that take it seriously. The author names that failure mode directly: *"Building a fully model-agnostic layer before you've shipped anything is its own form of waste."* Most treatments of reversibility omit this half, which is why the rule is the more portable half. Keeping options open has a cost, and the cost is paid up front in an abstraction nobody has yet needed and nobody can validate. Two implementations is the threshold because that is the first moment the abstraction can be *checked*. One implementation gives you a guess about what varies; two give you evidence. ## Scope & conditions - Holds as a **default**, not an absolute. Where a second implementation is genuinely certain and near — a scheduled migration, a regulatory requirement — building the seam early can be cheaper than retrofitting it. - Assumes retrofitting is possible. In systems where the boundary is expensive to introduce later (published APIs, on-disk formats, anything with external consumers), the calculus shifts toward earlier commitment. - Distinct from "commit to the contract, not the component" — that says *which* things to treat as durable; this says *when* to build the seam that makes them durable. - The tell for premature abstraction: an interface whose only implementation is the one you already had, with parameters nothing varies. ## Links - [[AI & the Future of Knowledge Work MOC]] — the counterweight to reversibility advice in a field where the right approach shifts quarterly - [[3. Resources/Permanent Notes/The Model Is a Thin Swappable Layer Over a Thick Infrastructure Codebase]] — the architecture this rule produces when followed, described from the far side - [[3. Resources/Permanent Notes/Canonical Sources Reduce Interface Drift]] — the maintenance argument for a single seam once you do build one - [[3. Resources/Permanent Notes/A Standardized Harness Turns Model Access Into a Second-Sourceable Supply Decision]] — the case where the second implementation is foreseeable enough to justify building early - [[3. Resources/Permanent Notes/Implementation Is Cheap So Taste Becomes the Bottleneck]] — why the judgment call matters more now: the cost of building the wrong abstraction fell, the cost of living with it did not - [[3. Resources/Permanent Notes/Instruction Files Are the Last Rung Not the First]] — because extends: the same restraint applied to instruction files, where writing the general rule is the cheap move that feels like a fix and holds least. - [[3. Resources/Permanent Notes/A Release Lead's Output Is Mostly Subtraction]] — because extends: the same restraint as a timing rule, where waiting is the decision and shipping early is the failure mode.