01
Faster pieces, same old seams
Software is built in pieces. Someone works out what the business needs. Someone else designs the architecture. Another team defines the APIs, another the user experience, and finally someone writes the code. Each piece has its own tools, its own documents and its own way of describing the same things.
Between every two pieces sits a seam, and every seam is crossed by hand. A requirement becomes a diagram; a diagram becomes an API; an API becomes code. Each crossing is a translation, and each translation loses a little meaning, adds a little duplication, and lets the delivered software drift a little further from what the business meant.
The problem isn’t that we lack capable AI tools. It’s that there is no continuous, machine-readable thread from business intent to running code — so every AI tool works on one fragment.
Three waves of AI in software
It helps to see AI adoption as three waves, moving at very different speeds:
- Mainstream1 · AI-assisted coding
Copilots that complete code on a developer’s desktop. Settled and everywhere.
- Crossing the chasm2 · Agents at scale
Coding agents doing multi-file features and refactors across many teams. Still hard to operate.
- Emerging3 · The AI-native lifecycle
The whole delivery process rebuilt around one persistent, connected model of intent that guides people and agents alike.
The first wave is a success story on its own terms. In Google’s DORA research, 90% of technology professionals use AI at work and more than 80% feel more productive. But DORA also gives the warning that explains everything that follows: AI is “an amplifier of whatever system already exists, for better or worse.”
Engineering leaders · McKinsey
Enterprises · McKinsey, Deloitte
So the results split. A quarter of leaders see real acceleration; almost a third see things get worse. McKinsey also finds that nearly two-thirds of enterprises haven’t scaled AI beyond isolated pockets, leaving enterprise-level returns out of reach for most. The difference isn’t the model. Teams that redesigned their process and their in-between artifacts before adding agents were twice as likely to see gains above 20%. Teams that layered AI onto the old process mostly made the old process faster — including its mistakes.
When one step gets faster in isolation, the bottleneck simply moves: to coordination, to alignment between teams, to checking whether the architecture still holds, to shared understanding. Faster output from a misaligned pipeline is just misaligned code, sooner.
02
Four answers to the same problem
The market has noticed the friction, and four kinds of tools have grown up around it. Each one fixes something real. None of them, on its own, connects the whole path.
Spec-driven coding frameworks
GitHub Spec Kit · BMAD-METHOD · OpenSpec · Kiro
The idea: replace throwaway chat prompts with durable written specifications that guide coding agents.
What works: intent is captured in structured files instead of disappearing in chat history, and agents get clear task structure.
Where it stops: the spec lives at the coding-agent layer, usually as a feature or project document. It isn’t a domain model that carries forward, so the next release starts with a new spec.
Agent orchestration & context platforms
Augment
The idea: index the whole codebase and keep deep memory across sessions, so you don’t keep re-teaching agents.
What works: agents can navigate large, existing codebases and stay consistent over time.
Where it stops: the existing code is the ground truth. Working forward from code, it can’t tell whether that code still reflects what the business wants.
Architecture & modelling tools
C4 tooling · enterprise-architecture platforms
The idea: model and visualise systems, boundaries and interactions.
What works: architects and managers get a clear picture of the system and its dependencies.
Where it stops: the models are documentation for people. Agents can’t query them, and they describe how the system should look without governing how the code changes.
Standards & convention tools
Agent OS
The idea: learn a team’s conventions from the codebase and feed them into the agent’s context.
What works: agents stop breaking local style and patterns.
Where it stops: it deliberately does without a standing specification, betting that frontier models can handle architecture on the fly. Convention matching works locally; system-wide governance is left open.
03
Side by side
| Approach | Source of truth | What it gives you | What it leaves open |
|---|---|---|---|
| Spec-driven frameworks | A project PRD or user story | Durable specs instead of throwaway prompts | Scoped to one agent and one project; no compounding domain model |
| Context platforms | The existing codebase | Persistent agent memory and deep code context | Anchored to code; no governing model of business intent |
| Architecture tools | Diagrams and design documents | Clear system structure for people | Not connected to delivery; not queryable by agents |
| Convention tools | Conventions extracted from code | Consistent local patterns | No standing model of intent; architecture left to the model |
| A connected toolchain | A persistent domain and architecture model | A continuous, machine-readable path from intent to code | Needs a redesigned workflow that the disciplines adopt together |
All four treat symptoms of the same condition: structured task specs, deeper code memory, clearer diagrams, enforced conventions. Each in isolation leaves the chain between intent and code broken — which is exactly why so many organisations see local speed turn into system-level friction.
04
What a connected toolchain needs
Connecting the chain means moving from isolated prompting to a continuous, machine-readable representation of intent — one that grows richer with every feature instead of being thrown away after each project. Five things make that possible.
- A ubiquitous domain language. One vocabulary shared by business analysis, domain modelling, architecture, UX and code. When “Customer”, “Order” or “Policy” means exactly the same thing in a requirement, a model and a class, the translation step disappears.
- An integrated lifecycle. Analysis, architecture and implementation stop being separate stages that hand documents downstream, and become one connected process where requirements, constraints and code evolve together.
- Model-driven development over prompting. A persistent domain model replaces one-off prompts as the source of truth for people and agents. Every feature adds to the model instead of starting a fresh document. The model persists; the prompts don’t need to.
- Domain storytelling and event modelling. Requirements are captured in a machine-readable shape from day one — stories, events and the interactions between them — so they flow into architecture and code without being retyped.
- Standard building blocks and a living system model. Structural code — endpoints, DTOs, event listeners, test scaffolding — is generated deterministically, for example with Nx generators, which saves expensive model reasoning for the domain logic. And the architecture, such as a queryable C4 model, becomes something agents consult to see the impact of a change, check boundaries and find where new code belongs.
| Element | Where it lives in M1Spec |
|---|---|
| Ubiquitous language | Domain languages per bounded context; a rename follows through stories, schemas and systems. |
| Integrated lifecycle | Discovery, Architecture and Implementation workspaces working on one model. |
| Model over prompts | Event model, API contract, backlog, test plans and implementation plans all derived from the stored model, with your decisions kept alongside. |
| Storytelling & event modelling | Domain stories turned into an AI-generated event model, with correctness rules checked on every save. |
| Building blocks & living model | Your patterns as Nx generators the agent runs; the C4 model, technologies and patterns served to the agent, which reports back what it changed. |
05
Before you choose
Judging AI development tools by typing speed misses the point. The real question is whether a tool reduces friction across the organisation and builds knowledge that lasts. Five questions help:
- Compounding model or reset artifacts? Does the tool grow a domain and architecture model with every release, or do teams write new specs, prompts and context files every time?
- Business intent or code only? Does the AI work against a model of what should be built and why, or only forward from the code that exists?
- Actionable architecture or static documentation? Can agents read, check and act on the architecture, or is it pictures for people?
- Deterministic scaffolding or model guesswork? Are structural patterns produced by generators, keeping model reasoning for business logic?
- One language end to end? Does one domain vocabulary run through requirements, event models, architecture and generated code?
Answer them for your own setup
Where a connected toolchain pays off most
Not every organisation feels this pain equally. It is sharpest where three kinds of complexity meet:
Established products with deep domain rules, inherited architecture and many dependent services.
Several teams, with product, architecture, design and engineering handing work to one another.
A constant stream of changes driven by the market, customers and strategy.
Where the domain lives on and keeps evolving, an investment in a shared model compounds instead of depreciating. In those organisations, keeping everyone in sync can cost as much as building the features — so typing faster doesn’t help, but connecting the thread does.
Point solutions make the pieces faster. A connected toolchain makes the delivery faster.
