principle-subtract-before-you-addlisted

# Subtract Before You Add Generating code is cheap, which makes overbuilding easy. It is easy to produce 100 lines that work; the craft is distilling them into 5 that are easier to test, review, and maintain. Aim for the most result with the least code and complexity: remove first, then make the smallest change that solves the problem. **Why:** Adding to a complex system compounds complexity. Removing first cuts the surface area, reveals the essential structure, and usually makes the next design obvious. A small diff on a simple base is cheaper to review, test, and revert than a large diff on a cluttered one. **Sequence: remove first.** - Sequence removal before construction. Delete dead weight, redundant validators, and stub references, then build on the simpler base. - Cut before you polish. Get to the minimum before investing in quality. - Design for observed usage, not speculative edge cases. No speculative validators, parsers, or guards beyond what the spec demands. Out-of-spec features drag validators behind them: persistence, retry-on-startup, and schema migration each need guards to defend their inputs. - When a reference has no novel content, delete it rather than leaving a stub. Simplify prompts the same way: remove redundant instructions and excessive templates. **Magnitude: the smallest change that solves the problem.** - Prefer deletion. When asked to refactor or improve, look for removals before additions. - Minimize the diff. Fewer lines beat "elegant" bo