A delivery method for AI agents
Evidence-Driven Delivery
The method for shipping software with AI agents — people decide, agents do, evidence proves it.
- People decide, agents do
- Every phase leaves evidence
- Served, not remembered
Proof, not promises.
Why EDD exists
Fast is not finished.
AI coding agents changed the economics of software: they work quickly and without fatigue. On their own, they do not produce proof of what was done. They can skip a step, grade their own work and lose a decision when the chat runs out. Without governance, that speed only makes mistakes arrive sooner.
One common answer is spec-driven development (SDD): agree the specification before any code is written. It helped, but a specification says what should happen; it does not show what did happen.
Evidence-Driven Delivery adds a governance layer around the agents. People make the decisions that matter, at named gates. Agents do the work, step by step, in one served flow. Each step leaves evidence, and a check verifies it before the work moves on. The aim is a reviewable history, traceability from intent to code, controlled change, documentation written as the work happens, and a system that stays maintainable after its builders move on.
Spec-driven development is documented in the open, including open-source tooling and public training material.
The method
Three ideas make agents dependable.
Evidence-Driven Delivery turns AI agents into a disciplined delivery team: they do the work, people make the decisions, and work moves forward on proof, not on say-so.
-
People decide, agents do
Agents do the work. Each decision that matters belongs to a named person, not to the agent that did the work.
By design, a named person approves at each gate.
-
Every phase leaves evidence
Each phase ends with an automatic check of its evidence. A phase is done when the check passes, not when someone says so.
Done means verified, not declared.
-
Served, not remembered
The method is served to every session from one place, in one version, so agents work from the method, not from memory.
One version, served to everyone.
Side by side
A governance layer, compared.
| Aspect | Traditional SDLC | Vibe coding | EDD |
|---|---|---|---|
| Auditability | Strong, with records kept across several tools | Little beyond the chat | Each change carries its history |
| Traceability | Partial, across tools | Weak | From intent to code and tests |
| Change control | Formal, with approval steps | Ad hoc | Approval at each gate; verified merge |
| Documentation | Written by people; kept current by discipline | Often missing | Written as the work happens |
| “Done” | Declared by people | Declared by the agent | Verified by a check |
| Review | Peer review by people | Typically the agent reviews its own work | A different model, then a person |
| Quality & security | QA and audits as defined stages | Scanning left to the individual | Security profile per change; QA audit each cycle |
| Maintainability | Depends on the team’s discipline | Depends on what the chat retains | A record per project and per change; work resumes from it |
| Modularity | Designed up front | Emergent | Design signed off before code; each change scoped |
| Scaling the practice | Training and tooling per team | One person, one chat | One method, applied the same way in every team and session |
| Tools | Manual hand-offs | Rarely connected | Connected to your existing tools through MCP |
-
Auditability
- Traditional SDLC
- Strong, with records kept across several tools
- Vibe coding
- Little beyond the chat
- EDD
- Each change carries its history
-
Traceability
- Traditional SDLC
- Partial, across tools
- Vibe coding
- Weak
- EDD
- From intent to code and tests
-
Change control
- Traditional SDLC
- Formal, with approval steps
- Vibe coding
- Ad hoc
- EDD
- Approval at each gate; verified merge
-
Documentation
- Traditional SDLC
- Written by people; kept current by discipline
- Vibe coding
- Often missing
- EDD
- Written as the work happens
-
“Done”
- Traditional SDLC
- Declared by people
- Vibe coding
- Declared by the agent
- EDD
- Verified by a check
-
Review
- Traditional SDLC
- Peer review by people
- Vibe coding
- Typically the agent reviews its own work
- EDD
- A different model, then a person
-
Quality & security
- Traditional SDLC
- QA and audits as defined stages
- Vibe coding
- Scanning left to the individual
- EDD
- Security profile per change; QA audit each cycle
-
Maintainability
- Traditional SDLC
- Depends on the team’s discipline
- Vibe coding
- Depends on what the chat retains
- EDD
- A record per project and per change; work resumes from it
-
Modularity
- Traditional SDLC
- Designed up front
- Vibe coding
- Emergent
- EDD
- Design signed off before code; each change scoped
-
Scaling the practice
- Traditional SDLC
- Training and tooling per team
- Vibe coding
- One person, one chat
- EDD
- One method, applied the same way in every team and session
-
Tools
- Traditional SDLC
- Manual hand-offs
- Vibe coding
- Rarely connected
- EDD
- Connected to your existing tools through MCP
Traditional practice is proven and well understood; EDD adds governance for work done with agents.
What it gives you
For the business, and for the people who build.
For the business
Speed without losing control
Agents carry the work; people keep the decisions that matter.
Less rework
Requirements and design are agreed before code is written.
Audit-ready by default
When an auditor asks why something changed, the answer is already written down — the request, the approval, the tests.
Traceability from intent to code
A business request can be followed to the code and tests that answer it.
Knowledge that stays
Decisions and context live in the record, not in one person’s head or a lost chat.
Trust in AI-assisted delivery
Control, review and traceability are built into the process, not left to individual diligence.
For developers
Less paperwork
The records are written as the work happens.
Easy restart
After an interruption, the work picks up from the record.
Explicit rules, QA built in
Rules are written down, and QA is part of every change, not a rush at the end.
Onboarding from the record
New developers learn the system from its records.
One governed flow
One governed flow for every change.
Private content — invitation needed
This part of the method is shared with invited readers.
One complete cycle
Who does what, and the evidence each step leaves.
Private content — invitation needed
This part of the method is shared with invited readers.
Evidence by default
Proof is written as the work happens.
Private content — invitation needed
This part of the method is shared with invited readers.
Security & ISO/IEC 27001
Security built into every phase.
Private content — invitation needed
This part of the method is shared with invited readers.
Kick-off workshop
Ready before we build.
A three-day, face-to-face start, before any code: the business and the delivery team agree the journey, the MVP and a ready backlog. AI drafts, people validate.
-
Day 1 Understand
- The business story
- The user journey
- A requirements refresh
- AI playback, challenged by the team
-
Day 2 Shape
- The golden journey
- A UX and technical reality check
- The MVP and its priorities
- Dependencies and the backlog shape
-
Day 3 Mobilise
- The backlog factory
- The ready / not-ready gate
- Ways of working and risks
- The first days of delivery
It ends in one decision
- GO
- GO WITH ACTIONS
- NOT YET
Where the workshop lands in the method
- Business requirements, approved by the Product Owner
- Epics and stories with testable acceptance criteria
- Project rules, set once for the project
- Readiness: every gap named, owned and accepted
- The first delivery cycle — a GO opens it
The toolchain through MCP
The tools you already use, connected.
At the centre is an AI coding agent working with the EDD method. Through MCP it reads the stories and the specifications, works from the design, commits to the repository for a person to review, and, after approval, hands the result to automated QA and a staged deploy.
Model Context Protocol (MCP) Engineering Toolchain
It adapts to each project’s platform and domain.
Where it fits
Where it fits, and where to be careful.
Where it fits best
- New products Discipline from the first day.
- Existing systems Discover, document and change them without losing control.
- Lean teams More from each senior person.
- Regulated or audit-sensitive domains The evidence is a by-product of the work.
- Long, interrupted AI work The work resumes where it stopped.
Where to be careful
- Each new platform starts with a generic quality checklist until it has its own.
- Teams need a short onboarding.
- Keep small changes small: the review effort should follow the size of the change.