Speccing is 80% of the work (code is the easy part)
2026-06-15
An uncomfortable ratio from years of shipping: roughly 80% of the time that produces a good feature is spent before and around the code — understanding, specifying, prototyping, revising. Code is increasingly the cheap part. Some of mine is AI-generated. The spec never is.
Here's the loop I trust.
First, get to the real problem: clients describe solutions, not problems, so I ask why until the actual constraint shows up — the "seven whys" survive because they work.
Second, prototype embarrassingly early: user flows and rough mockups, because feedback on something people can see is far richer than feedback on a paragraph.
Third, expect total loss: zero of my initial designs have made it to the end intact, so the goal of a first design isn't to be right — it's to be wrong quickly and informatively.
Fourth, estimate with humility: I pad 20–30%, not for laziness but because the spec will change, and pretending otherwise helps no one.
None of this is anti-code. When generation is nearly free, judgment becomes the whole job: knowing what to build, what to cut, and what "done" actually means for the person on the other side of the screen. The engineers I want to work with — and the one I try to be — treat specification as the craft and code as its consequence.
