Methods
Specifications before code
Phase-by-phase specifications with acceptance criteria before writing code.
1 min read
The project rule
There is one rule that is not up for discussion: a phase is not implemented until its specification has been reviewed and closed. Before writing code, there is a document that says what is done, how it is done, and how you know it is right. Look before you touch, as I told in Audit before touching anything.
How it's organized
The project has nine phases, from 0 to 8: server foundations, data model, public frontend, content migration, LaIA, management panels, advertising, newsletter, and going to production. Each phase has its specification, with the data model field by field, the acceptance criteria, and the runbooks (the emergency manual).
In addition, some global rules apply to everything: don't make up data, security by default, analytics without cookies, small and clear commits.
Why it's worth it (especially with agents)
Specifications are also what enables working with AI agents (software that works on its own). There is a package in English designed for them, with each task numbered and its criteria. The agent doesn't improvise: it executes the task and the result is checked against the spec.
A real example: the design system spec asked for 14 concrete primitives (the basic pieces: a button, a field). When they were done, they were counted. And when any didn't closely resemble the validated HTML —as I told in From prototype to validated design—, it was redone.
More work before starting, much less work after.