When the build takes a night, the thinking is the work.
Agile was a response to waterfall: projects took so long to show results that teams learned to build in small slices and check often. AI agents change the economics again. Building is becoming fast and cheap. Knowing exactly what to build, and proving that what was built is right, is not. The AI-DLC is a way of working for that world. It belongs to no product, and you can run it with the tools you already have.
The bottleneck has moved upstream, and downstream.
For twenty-five years, the expensive part of software was writing it. Agile, sprints and the backlog were all ways of managing that cost: build a little, show it, learn, repeat.
Agents can now write large parts of a product overnight, and models and token prices are both moving in one direction. It is reasonable to expect agents, in time, to build exactly what they are asked for. At that point the main source of defects is no longer the builder. It is the ask.
So human effort moves to the two ends of the lifecycle. Upstream, people must be precise about intent, and design must be challenged before anything is committed. Downstream, verification must be strong enough to trust work no person typed. Agile's values about people, customers and change still hold. What has changed is where the scarce effort sits.
Building software with agents, we have come to value:
- Precise intentoverdetailed task plans
- Challenged designsovercorrected builds
- Trusted, ranked contextovermore context
- Verified outcomesoverdelivered output
- Recorded reasonsoverremembered ones
In the spirit of the Agile Manifesto: there is value in the items on the right, but we value the items on the left more.
The V-model comes back, at agent speed.
When large pieces of a product are built in one pass, you can't rely on catching problems sprint by sprint. Each level of intent needs its matching check, agreed before the build starts. The V was right about that. What was wrong was the months it took to travel. Agents shrink the bottom of the V to hours, so the whole loop can run in days.
-
01 · Intent
Say what outcome you want, and why
A named person states the outcome, who it is for, the constraints, and how anyone will know it worked. One Intent may change code, documents, training or anything else the organisation produces.
Owner: a person -
02 · Shape
Let AI find the gaps
AI interrogates the Intent: missing cases, conflicts with earlier decisions, unstated assumptions, scope that should be split. People answer and decide. The result is precise enough to be built literally.
AI proposes · people decide -
03 · Challenge
Challenge the design before committing
The design faces structured challenge from AI and from specialists such as security, data protection, architecture and regulation. Each challenge gets an answer or a reason for dismissing it, and both are recorded.
Challengers: AI and specialists -
04 · Specify
Write the checks before the code
For each level of intent, agree how it will be proven: acceptance criteria, system and integration tests, component tests, and the test data they need. Ideally these are written by someone, or something, other than the builder.
People and test agents -
05 · Build
Let agents build, often overnight
Agents build against the specification and generate the documentation and trace links as they go. Throwaway prototypes are welcome at any earlier stage. They sharpen the spec, and the spec is what you keep.
Agents, with people on call -
06–07 · Verify and validate
Prove it, continuously
Automated checks run at every level on production-representative data. Verify asks "was it built as specified?" Validate asks "does the design hold up as a whole: performance, resilience, security?"
Automated, independent -
08 · Accept
A person accepts against the Intent
A named person reviews the evidence against what was asked for and signs off. Agents can recommend, but they never approve their own work.
Accountable: a person -
09 · Learn
Release in steps, then measure the outcome
A one-pass build is not a big-bang release. Ship progressively behind flags or canaries, measure whether the outcome happened, and feed what production teaches back into the next Intent and into the test data.
Evidence closes the loop
Twelve principles behind the AI-DLC.
-
Human effort moves to the front
When building takes hours, the time people spend getting the Intent right is the best investment in the lifecycle. A day of clear thinking now saves a night of precise, wasted building.
-
Write as if it will be built literally
Expect agents to do exactly what is asked, and increasingly to do it without mistakes. Ambiguity becomes the main source of defects, so treat vague language in an Intent as a defect in its own right.
-
AI shapes intent, people own it
AI is excellent at asking the questions people forget: edge cases, conflicts, missing acceptance criteria. Use it to sharpen every Intent, but keep a named person accountable for what it says.
-
Challenge before you commit
Every significant design is challenged before the build, by AI and by the specialists who would otherwise find the problem later. Challenges that are dismissed need a reason, and the reason is kept.
-
Context has an order of authority
AI can read everything, so what it reads must be trusted. Rank sources, mark where each one came from, and treat stale or unverified material as a risk rather than more input. See the ranking.
-
Newer, informed decisions win
A recent decision overrides an older one only if it was made knowing about the older one. Decisions are superseded explicitly, never silently edited, so anyone can follow the chain.
-
Code is the truth, so the repository explains itself
People are poor at maintaining code documentation, and AI is good at it. Agents generate and update architecture notes, module docs and decision records in the repository with every change. Documentation that drifts from the code fails the build.
-
Every change carries its why
Each commit and merge links to the Intent and decisions behind it, using plain text in the commit itself. Git history then answers "why was this changed?" without needing any particular tool. See an example.
-
Verification is designed with the intent
Each level of intent has a matching check, agreed before the build. The checks should be independent of the builder: a different agent, a different model, or a person.
-
Test data is a product
Generate synthetic test data from the data model before anything is built. Keep it honest with a feedback loop from production: shapes, volumes, distributions and edge cases, never raw customer data. Drift between test and production data is a defect.
-
The MVP becomes the minimum verified product
The "minimum" in MVP was about the cost of building. When building is cheap, build several variants to learn, keep the best specification, and throw the code away. What you ship is still small, but it is fully verified and carries its controls from day one.
-
Tool-agnostic by design
The AI-DLC is a way of working, not a product. Keep its records in open formats that live with the work: markdown in the repository, links in commits, tests in the pipeline. Your evidence should outlast any vendor, including us.
Not all knowledge is equal.
Agents can take in every document, chat and wiki page an organisation has ever written. Most of it is out of date, and some of it contradicts the rest. Feeding all of it to an agent with equal weight is how confident, wrong work gets built.
A starting order of authority, highest first. Each organisation should set its own, write it down, and give it to every agent it uses.
- Running code and passing tests
What the system actually does today. - The latest informed decision
Recorded, attributed, and made with knowledge of what it replaces. - The approved Intent and its specification
What was agreed for this change. - Documentation kept in the repository
Trusted to the extent that checks keep it in step with the code. - Conversations and transcripts
Useful evidence, but not a decision until someone confirms it. - External and generated material
Use with care, cite the source, and verify before relying on it.
Put the why in the history.
The simplest way to make every change traceable is to write the links into the commit itself. Git trailers are plain text, every tool can read them, and they stay with the code wherever it moves.
The identifiers can point at anything: a markdown file in the repository, a page in a wiki, or a record in a work management tool. The AI-DLC only asks that they exist and that they resolve.
Raise daily payment limit for business accounts Applies the new limit to the business tier only and adds limit checks to the payment validation service. Intent: INT-142 Raise business payment limits Decision: DEC-311 Limit set at £250k (risk review) Decision: DEC-298 superseded by DEC-311 Verified-by: tests/payments/limits_spec Agent: coding-agent, approved model, skill v1.4 Reviewed-by: A. Person <a.person@example.com> # Illustrative example
What changes, and what doesn't.
Agile got the important things right: people over process, working software, close collaboration with customers, and responding to change. The AI-DLC keeps those values and changes the practices built around the cost of writing code.
| In agile practice | In the AI-DLC |
|---|---|
| Sprint | Intent: work moves when it is clear and verified, not when the calendar says so |
| Backlog grooming and story points | Shaping and challenge: effort goes into precision, not estimation |
| User story | Intent with acceptance checks agreed before the build |
| Definition of done | Verified against the Intent and accepted by a named person |
| Daily stand-up | Live status from the work itself; people meet to decide, not to report |
| Velocity | Time from Intent to verified outcome, and rework caused by ambiguity |
| Minimum viable product | Minimum verified product, informed by cheap throwaway variants |
| Wiki pages and tribal knowledge | A repository that explains itself, with decisions linked to every change |
AI-DLC, ADLC, and AWS's AI-DLC are not the same thing.
Several lifecycles for the AI era have names that sound alike, and one shares our acronym. They solve different problems.
Agent Development Lifecycle
A lifecycle, used by several vendors, for building AI agents as products: scoping an agent, evaluating its behaviour, and monitoring it in production. Its subject is the agent itself. Ours is about the work that people and agents do together.
AI-Driven Development Life Cycle
AWS's method for building software with AI as a central collaborator. It runs in three phases (Inception, Construction and Operations), replaces sprints with short "bolts", and elaborates requirements with the whole team in the room. We share its view that intent comes first, and we cite it below.
AI Development Lifecycle
A way of working for building any software, document or change with agents, owned by no vendor and tied to no tool. It adds a challenge stage before commitment, a ranked order of trusted context, verification agreed before the build, and evidence that a regulator can follow.
What we built on, and where we differ.
Plenty of people are rethinking the lifecycle for AI. Spec-driven development, AWS's own AI-DLC and recent agile manifestos for AI all agree that intent and verification matter more than ever. We have learned from all of them.
Where our AI-DLC differs: it is not tied to any tool or vendor; it treats the trustworthiness of context as a first-class problem; it adds an explicit challenge stage before commitment; and it is written for organisations that must prove how every change was made.
- Manifesto for Agile Software Development (2001)The original four values and twelve principles. Our format borrows from it.
- AWS: AI-Driven Development Life Cycle (AI-DLC)AI as a central collaborator, with "bolts" of hours or days in place of sprints and team "mob elaboration" of requirements.
- GitHub Spec KitSpec-driven development: the specification, not the code, is the main thing people write and review.
- InfoQ: the AI and agile manifesto debate (2026)Whether agentic delivery is too fast for agile, with responses including Kent Beck's "augmented coding".
- The AI-Native Large-Scale Agile Software Development Manifesto (2026)Britto et al. propose intent-driven teams, living knowledge and verification-first assurance.
- DORA: State of AI-assisted Software Development (2025)AI amplifies the strengths and weaknesses an organisation already has, which makes the surrounding practices matter more.
You don't need Tolvane to work this way.
A repository, markdown, commit trailers and a good pipeline will take you a long way. Tolvane is being built for teams that want the AI-DLC to run at enterprise scale, with people and agents working on Intents together, challengers your specialists configure, a decision record for every change, and evidence a regulator can follow.
This is a draft, and we'd welcome challenge on it. Tell us what we've got wrong.
- Intents as the unit of work, not tickets
- AI challengers configured by your own specialists
- Decisions superseded, never silently edited
- Links from every change back to its Intent, in your own Git history
- Works alongside the tools you already use