Most teams treat specs as overhead, a document you write to satisfy someone else and then forget. We treat them as the fastest way to ship. Here is how OpenSpec fits into the way we build at Make It Digital, and why writing a spec first makes an AI-native studio faster rather than slower.
What OpenSpec is
OpenSpec is a lightweight, structured way to describe a change before you build it. Each change lives as a short spec in the repository: the problem, the proposed behaviour, the acceptance criteria, and what is explicitly out of scope. Specs sit next to the code, get reviewed like code, and stay as a living record once the work ships.
Nothing about it is heavy. A spec is often a single page. The point is not documentation for its own sake. The point is a shared source of truth that both people and AI agents can act on with confidence.
Why it speeds things up
Software gets slow when the loop between idea, code, and feedback is slow. Most of that slowness is not typing. It is ambiguity: half understood requirements, decisions made in the middle of implementation, and rework when the result is not what someone pictured in their head.
A spec moves that thinking to the front, where it is cheap to change. When we agree on behaviour and acceptance criteria first, three things happen:
- The expensive work, building, starts from a clear target instead of a guess.
- AI agents produce far better code, because a spec gives them the context, the constraints, and a definition of done that a one line prompt never could.
- Review gets simpler, because we are checking a change against an agreed spec instead of debating intent after the code already exists.
How we work with it
Our loop is simple, and it runs on every change, large or small.
- Frame. We write a short spec: the problem, the proposal, the acceptance criteria, and what is out of scope. This takes minutes, not days.
- Review the spec. It is far cheaper to change a sentence than a pull request. Disagreements surface here, before a single line of code exists.
- Build with AI. We hand the spec to an AI agent as its brief. It drafts the implementation and the tests against the acceptance criteria, while our engineers steer, correct, and hold the line on architecture and taste.
- Iterate. When reality pushes back, and it always does, we update the spec, not just the code. The spec and the codebase never drift apart.
- Archive. Once the work ships, the spec stays as a record of what changed and why. New teammates and future agents read it instead of asking around.
The advantages we see
- Faster starts. A clear spec removes the blank page problem for both people and agents.
- Less rework. We catch misunderstandings in a one page document, not in a finished feature.
- Better AI output. A spec is the highest leverage input you can give a coding agent. Precise in, precise out.
- Tighter reviews. Reviewers check against agreed criteria instead of reverse engineering someone's intent from a diff.
- Living documentation. The spec is written anyway, so the docs are a by product of the work, not a separate chore nobody wants.
- Parallel work. Independent specs can be built at the same time without teams stepping on each other.
The short version
OpenSpec is not extra process. It is the thing that lets us move fast without breaking the parts that matter. We spend a little time up front turning a fuzzy idea into a clear one, then let AI do the heavy lifting against a target everyone already agreed on. That is how we ship in weeks instead of quarters, and how the second version usually comes out better than the first.