Keep the Spec Alive
The spec isn't a monument you build once and admire. It's a living document, and the most common mistake is treating it as fixed. As you build, you'll learn things the planning stage couldn't tell you: a feature is harder than expected, a non-goal turns out to be essential, a user story was secretly two stories. When that happens, edit the spec first, then tell the AI to follow the new version. The spec leads; the code follows.
A few habits keep it honest:
- Update it the moment a decision changes. A spec that says one thing while your code does another is worse than no spec — it actively misleads the next AI .
- Cross tasks off as you finish them. The task list doubles as a progress tracker. Seeing six of eight items checked is its own kind of momentum.
- Move surprises into non-goals or a "later" list instead of just doing them. If a tempting feature shows up mid-build, write it down and keep going. You can decide later whether it earns a place in v1.
This is the discipline that separates "I built a thing" from "I built the thing I meant to." The spec is how you stay the author of your project instead of a passenger in it.