Continuous Specification
The practice of treating your specification like code: decisions are proposed, reviewed, superseded, and kept current as the product evolves, rather than frozen at the start of a project and abandoned.
Every spec is accurate exactly once.
The traditional spec is written before the work, argued over, approved, and then left behind. From the first day of building, the system starts to drift away from it. Decisions get made in pull requests, in chat threads, in review comments, and in quiet conversations that never reach the document. Within months the spec describes a system that no longer exists.
Coding agents have made this an order of magnitude worse. Code now outruns intent. A team with agents ships in an afternoon what used to take a sprint, and every shortcut taken in the prompt is a decision nobody wrote down. The faster you ship, the faster your stated intent and your actual system diverge.
The industry answer to drift in code was not to write better release plans. It was to make integration and delivery continuous. Specification needs the same move.
Specify the way you integrate: continuously.
Continuous Specification inverts the traditional order. The spec is not a prelude to building; it is an output of building, maintained with the same discipline as the code it describes. When a decision is made anywhere, it is pulled back into the model. When the model changes, the change is reviewed. When a decision is replaced, it is superseded, not erased, so the reasoning survives.
Done properly, the spec becomes the most trustworthy artefact a team owns: a living model of what the system is and why, current enough that people plan from it and agents build from it without checking over their shoulder.
Five principles.
Specification is continuous, not upfront.
A spec is not a phase that ends when building starts. It runs alongside the system for as long as the system runs, and it is finished only when the product is.
The spec is a model, not a document.
Features, domain language, boundaries, and behaviours, held as structure rather than prose. Structure is what makes a spec navigable, queryable, and checkable.
Decisions are the unit of change.
Specs change because someone decided something. Decisions are proposed, reviewed, and superseded in the open. A spec that changes silently is a spec you cannot trust.
Intent is versioned with the code.
The current specification is pushed back to the repo alongside the code it describes. Engineers, reviewers, and agents read product intent the same way they read source.
Agents are first-class consumers.
Coding agents ship most of the code now. They succeed when requirements are clear, intent is agreed, and design is sound. The spec is written once and read by humans and machines alike.
A workbench for the practice.
Specbench is the tool we built to work this way: a structured, queryable model of your system that your team shapes together, exposed to any MCP-compatible agent, and pushed back to your repo as versioned output. It is open source, because a practice worth adopting should not be locked to a vendor.