I have a personal AI coding system built on cell biology. Germline for code, epigenome for memory, metabolon for runtime. It runs on a Fly app, a Mac, and a remote box. The public repo is the organism’s DNA; my private repos hold its state.
Yesterday I started cleaning it up. I had two private repos that could have been one. I had a Latin misfit in an otherwise bio-themed stack. Easy rename job. Then Claude and I got ambitious.
What if vivesca was not just my personal setup but a real framework? Brew install vivesca. An init command scaffolds your own private phenotype. Updates via brew upgrade. Each user gets their own instance; the public repo is the genotype; everyone’s epigenome accumulates separately. Cell biology all the way down. We had the architecture diagrams. We had the CLI surface. We had the biological metaphor map. Three rounds of “that is great, let us keep going” later, I stopped and asked the question you should always ask: is this actually a good idea?
I made myself list the hard problems honestly. The code is Python, Rust, Go, Bash, and Markdown — “one install” across languages means shipping a binary plus virtual environments plus hooks, which is not an install but a distribution. Every shell hook references absolute paths; install location determines everything, and upgrades move paths. The init command would have to create a GitHub repo under someone else’s account via OAuth, or assume they did it manually. If a user edits a skill file and I ship a new version, who wins — that is a package manager’s hardest feature for a package nobody has installed. My code knows about my hostnames by name, reads my password manager, assumes my VPN. Generalizing them is a secrets abstraction subsystem, a compute manifest, and a provisioning flow, each its own project. An empty starting memory means the organism cannot bootstrap. My starting memory means new users inherit my biases, my contacts, my schedule. There is no neutral state. The biology metaphor is a twenty-term glossary for anyone who is not me. And not one person has asked to run their own vivesca. I would be building for an imagined audience, and imagined audiences produce wrong abstractions.
Nine real problems appeared immediately. None of them were trivia. All of them would have eaten months.
What I shipped instead was a cleanup. Renamed the misfit. Planned the repo merge. Committed both specs with status frontmatter. Updated my state tracker: parked until week two of the next job, because migration risk during deadline week is not worth the elegance gain. The cleanup ships. The framework does not.
The moment that mattered was when I asked whether the architecture was perfect and ideal. The honest answer was no. The honest answer is almost always no for any architecture that has been iterated on for ten minutes without hitting code. Hard problems compound invisibly in the design phase. You cannot see them until you try to implement, and the cost of trying and failing at scale is much higher than the cost of listing them up front. The move that saved me was asking the question and making the agent list the problems instead of defending the proposal.
YAGNI applies to architecture, not just features. You already know not to add features nobody has asked for. The same logic applies to abstractions, frameworks, and generalisations. If you are designing for imagined users, you are building on fiction. When real users show up, they will need different things than you predicted, because you predicted them from your own specifics.
Ship the smallest thing that solves your actual problem. Document the elegant version for later. Let it sit until someone asks. If no one asks, you saved months. If someone asks, the spec is ready and now you have a real second user to design with. Framework-first is a trap that looks like ambition. The best frameworks are extracted from working systems, not designed before them.