The best decision in Symbiote v1 was a feature I refused to ship.
Clients asked for docstring generation. It was technically feasible, obviously sellable, and I'd already built most of it. Then I tested it against large, well-documented codebases and watched full-file rewrites occasionally compress prose that some careful human had written years ago. Not often. Occasionally. Which is worse, because rare corruption is the kind you find months later. So v1 ships type annotations only — additive, verifiable, boring — and docstrings wait for an architecture that splices at the AST node level instead of rewriting files.
Cutting that feature hurt for about a day. It has paid for itself every week since, in support requests that never arrived and trust that never had to be repaired.
I keep relearning the same lesson at every scale. The strongest guarantee Symbiote makes isn't anything it does; it's the list of things it will not do. It will not touch execution logic. It will not reword a comment. It will not push to main. Every item on that refusal list is a sentence I don't have to say defensively in a sales conversation, because the architecture says it for me. Constraints you can't violate beat promises you intend to keep.
The same rule shaped this site. Monochrome, one typeface, no decoration competing with the work. When a page felt weak, my instinct — everyone's instinct — was to add something. A graphic, a section, another claim. Almost every time, the actual fix was removal. The remaining elements got louder. I don't fully understand why subtraction works this way, but I've stopped arguing with it: emptiness is load-bearing. Every element you cut transfers its weight to what stays.
It applies to scope, too. The physics engine I'm building points, eventually, at open problems — the kind of ambition that usually produces a decade of slideware. The only reason I trust the project is the subtraction built into its roadmap: it isn't allowed to attempt anything novel until it has re-derived Hooke's law, then Kepler, from raw data, with machine-checked proofs at each gate. Strip away the right to skip steps and what's left is either a working system or an honest failure. Both are useful. Slideware is neither.
There's a line I wrote into my own design notes and try to obey even when it stings: when in doubt, remove. Not because minimalism is tasteful — taste is a side effect — but because every removed element is one less thing that can be wrong. In systems whose whole value is trustworthiness, that arithmetic decides everything.
Subtraction is a strange discipline to sell. You're asking to be judged on invisible restraint, on failure modes that never fired, on features that don't exist because they shouldn't. But the longer I do this work, the more convinced I am that what you refuse to build is the most durable part of what you build.