Idea · Organisation
AI-DLC
AI-DLC (AI Development Lifecycle) is a software lifecycle in which agents do a large share of the writing, testing and operating, and humans own the definition of done, the review of intent, and the decision to release.
AI-DLC is the name I use for the way software gets built when agents do a large part of the building. It is not a methodology with certificates. It is a description of what changes in a team once an agent can take a ticket, write the code, run the tests and open the pull request, and what has to change in the process so that the result is still something you would put in production.
What moves, and what stays
Three things move from people to agents: first drafts of code, first drafts of tests, and the mechanical parts of operations such as rollouts, log triage and dependency updates. Three things stay with people and get more important: deciding what “done” means, reviewing whether the work does what was intended, and deciding to release.
- Review of intent
- A code review that checks whether the change does what the ticket asked for and nothing else, rather than whether the code is well written; in AI-DLC it replaces line-by-line review as the primary human gate.
What changes in each stage
Definition. The ticket becomes the specification, because the agent will take it literally. Acceptance criteria are written as tests where possible. A vague ticket that a senior engineer would have interpreted well produces a confident, wrong pull request.
Build. Agents produce the first version. Engineers spend their time on the parts that need judgement: data models, security boundaries, the interfaces between systems, and anything the agent got confidently wrong.
Review. Line-by-line review of generated code does not scale and does not catch the important failures. Review of intent does. Reviewers read the ticket, the tests and the diff summary, and ask one question: does this do what was asked and nothing more?
Test. Evaluation sets become a first-class artefact, for the software and for any model inside it. A change that passes unit tests but drops the evaluation score does not merge.
Release. The decision to release is a human one, made with a trace of what the agents did. Rollouts are staged by default because reverting is cheap and the failure modes are new.
Operate. Agents watch the system and propose fixes. People approve them. Every proposal comes with the evidence the agent used.
Why write it down at all
Because teams drift into this without noticing, and the drift is where the risk is. An agent that started as an autocomplete ends up merging its own pull requests, and nobody decided that. AI-DLC is the act of deciding it: which steps agents own, which steps people own, and what evidence crosses the boundary. At Ailoitte this is how we run our own delivery pods, under ISO 27001 and ISO 9001, which is the practical test of whether a process is real: an auditor can follow it.
Related
- SDLC vs AI-DLC: why technology leaders are switching, the playbook: what changes at each of the eight stages, the return, the failure modes, and a seven-step adoption path.
- AI Velocity Pods, the delivery model that uses this lifecycle.
- Agentic in Production, the standard the output has to meet.
- For a public benchmark of how well agents do the “build” step on real repositories, see SWE-bench. For the operations side, the DORA research on delivery performance remains the best baseline to measure against.
Questions people ask
- Is AI-DLC just "use Copilot"?
- No. Code completion changes how fast a person types. AI-DLC changes who does which step. When an agent opens the pull request, runs the tests and proposes the rollout, the human's job moves from writing to specifying and reviewing, and the process has to change to match.
- Does AI-DLC reduce headcount?
- It changes the shape of a team more than its size. At Ailoitte the change has been visible in three places. Pods got smaller and more senior, because the junior work of first drafts moved to agents and the senior work of specification and review grew. Review time moved from lines of code to intent: a reviewer now spends most of an hour on whether the change does what the ticket asked and almost none on style. And every pod gained a role that did not exist before, the person who owns what the agents are allowed to do, from the refusal list to the tools they can call. Headcount per outcome went down; the seniority of that headcount went up.