01
A feature’s journey
Follow one feature through a typical company.
It starts as a conversation. Someone in the business explains what customers need, and an analyst writes it down as a page of prose. An architect reads that page and draws a diagram. Someone turns the diagram into an API specification. A product owner slices it into tickets. A developer reads the tickets and writes the code. A tester reads the tickets again and writes the tests.
Six people, six documents, six translations. Each one is done by hand, and each one loses a little of what was meant. By the time the code ships, it does something close to what the business asked for — but not quite. And the diagram, the API spec and the tickets have already started to drift away from the code and from each other.
Software delivery doesn’t have a typing problem. It has a translation problem.
02
So we added AI to every step
The obvious move was to speed up each step: a chatbot for the requirements, a copilot for the code, an AI plugin for the tickets, a generator for the diagrams. Adoption has been enormous — 90% of technology professionals now use AI at work (DORA). It came in waves:
- AI-assisted coding. Copilots in every editor. Mainstream and settled.
- Coding agents at scale. Agents that change many files across many teams. Crossing the chasm now.
- The AI-native delivery lifecycle. The whole process redesigned around one connected representation of intent. Only just beginning.
The first two waves made each step faster. They didn’t make the delivery faster, because the translations between the steps are still done by hand — and now there is more output to translate.
What engineering leaders report
What enterprises report
The teams that did see real gains had one thing in common: they redesigned the process first, turning their in-between documents into something machines can work with, before adding agents. They were twice as likely to gain more than 20%. As DORA puts it, AI is “an amplifier of whatever system already exists, for better or worse.”
03
Four ways the market tried — and the piece each one misses
Tool makers saw the problem too. Each of the four main approaches fixes a real part of it:
GitHub Spec Kit, BMAD-METHOD, OpenSpec, Kiro. Durable written specs instead of throwaway chat prompts. But the spec lives at one project and one agent; it isn’t carried forward as a model that grows with every release.
Augment. Deep memory of a large codebase across sessions. But the existing code is the source of truth, so it can’t tell whether that code still matches what the business wants.
C4 tooling and enterprise-architecture platforms. Clear pictures of systems and boundaries. But the diagrams are for people; agents can’t query them, and they don’t govern how the code changes.
Agent OS. Learns a team’s conventions from the code and feeds them to agents. But it deliberately does without a standing model of intent, so the architecture is left for the model to guess.
Each one fixes a fragment. None of them connects the business intent at one end to the running code at the other. That connection is the missing thread. See the full comparison.
04
The thread, made real
Connecting the steps takes five things working together. Here is each one, and where it lives in M1Spec.
05
What changes
| AI on fragments | One connected thread | |
|---|---|---|
| What people hand over | Prose requirements, static diagrams, separate code files. | Domain stories, an event model, a living architecture. |
| Source of truth | Spread across teams and chat histories. | One persistent model that people and agents share. |
| What the AI sees | One file, one folder, one prompt. | The domain, the architecture, the patterns, the decisions. |
| How intent travels | Re-interpreted by hand at every step. | Derived from the step before it. |
| Drift | Found late, in production or in review. | Reported with every change and reviewed before it lands. |
| Next release | Starts with a fresh spec and a fresh prompt. | Starts from everything the model already knows. |
Five questions to ask any AI delivery tool
- Does it build a model that grows with every release, or do you write new specs and prompts every time?
- Does it work from what the business intends, or only from the code that already exists?
- Can agents read and act on the architecture, or is it a picture for people only?
- Are structural patterns run as code, or left for a language model to interpret?
- Is there one vocabulary from the requirement to the class name?
Answer them for your own setup
M1Spec was built so the answer to all five is yes.
