What we mean by the Agentic Development Life Cycle
The SDLC rested on two quiet assumptions. Agents break both, and most of the pain teams are feeling right now is the sound of that breaking.
A team I spoke to recently shipped forty-one pull requests in a week with six engineers. Their board said they had completed nine tickets. Nobody was lying. Nobody was even being careless. The board was simply the slowest-moving artefact in a system that had quietly gotten ten times faster everywhere else.
That gap, between what a team has actually done and what its system of record believes, is not new. What is new is the rate at which it opens. It used to widen over a sprint. Now it widens over an afternoon.
This is the first piece in a series about what we have started calling the Agentic Development Life Cycle. Before defining it, it is worth being precise about what broke, because the interesting part is not “AI writes code now.” That part is obvious and largely settled. The interesting part is what the code-writing was holding up.
The two assumptions
The software development life cycle, in every flavour it has taken since the seventies, rests on two assumptions so basic that they are almost never stated.
The first: a human writes the change. Not just types it, but holds the intent behind it. When a developer opened a pull request, a great deal of context travelled with them: why this approach, what was considered and rejected, which edge case worried them, what they would do next. That context was expensive to produce, which meant it was scarce, which meant the process could afford to treat each change as a meaningful unit worth reviewing carefully.
The second: a human updates the plan. Someone moves the ticket. Someone writes the standup note. Someone tells the project manager the estimate slipped. The plan is a hand-maintained copy of reality, and the whole apparatus of agile ceremony exists to keep that copy roughly in sync with the original.
Both assumptions held for fifty years. Both are now false, and they became false at the same time, which is why the failure feels disorienting rather than merely inconvenient.
What happens when both break at once
If only the first assumption broke, you would have a code review problem. More changes, less context per change, reviewers under strain. Uncomfortable, but tractable.
If only the second broke, you would have a project management problem. Familiar territory. Every organisation has lived through a period where the board drifted and someone was assigned to fix it.
Breaking both at once produces something different in kind. The system generating work has accelerated by an order of magnitude, and the system recording work has not accelerated at all, because it runs on human attention and human attention did not get faster. The result is not a slower board. It is a board that becomes actively misleading, fast enough that decisions get made on it before anyone notices.
You can watch this happen in a specific, mundane way. An agent implements a ticket. The pull request merges. The ticket stays in progress because moving it was a separate act that nobody performed. Three days later a status report is generated from the board. The report says the feature is not done. Someone reprioritises based on that. The feature was done on Tuesday.
Multiply that by forty-one pull requests a week.
SDLC assumed
- A human writes the change
- A human updates the plan
- Context travels with the author
- "Done" is a judgement call
ADLC requires
- Agents write most of the change
- The record maintains itself
- Context must be written down
- "Done" is machine-evaluable
So what is the ADLC
The Agentic Development Life Cycle is what you get when you stop assuming a human writes the change or maintains the plan, and design the life cycle around what is actually true instead.
That reduces to three requirements. They are not exotic. They are just different from what the SDLC needed.
A definition of done that a machine can evaluate. This is the big one, and it is where most teams underestimate the work. An agent builds precisely what the criteria describe. If your acceptance criteria say “the checkout works correctly,” you have not given an instruction, you have given a vibe. A human developer would have filled the gap from context and taste. An agent fills it from the literal text, which means vague criteria now produce confidently wrong software at speed. The definition of done stops being documentation and becomes an executable interface.
A record that maintains itself from ground truth. If nobody is going to update the ticket, the ticket has to update itself from something that cannot drift: the branches, the pull requests, the reviews, the merges. Source control is the only artefact in the system that is definitionally true, because it is the work rather than a description of the work. Every other record is a copy, and copies drift.
Proof for every automated action. Once software is moving your tickets and gating your merges, the obvious question is what happens when it is wrong. If the answer is “we would not know,” you have replaced a slow honest system with a fast dishonest one, which is worse. Every automated change needs to be attributable, inspectable and reversible, or you should not automate it.
Notice that none of these three are about generating code faster. That problem is solved. These are all about the layer that has to exist around fast code generation for the output to be trustworthy.
What this is not
A few things the ADLC is explicitly not, because the term is new enough that it will attract whatever meaning people project onto it.
It is not a claim that developers are going away. The work moves toward specification, judgement and review, and the ratio of thinking to typing goes up sharply. That is a change in the job, not a deletion of it.
It is not a methodology you adopt on a Monday. There is no ceremony to install, no certification, no two-day workshop. It is a description of what your life cycle has to look like once the two assumptions fail, whether you plan for it or not.
And it is not automatic improvement. Speed without a definition of done gets you to the wrong place faster, and I have now seen enough teams prove that empirically to be confident it is the default outcome rather than the pathological one.
Where this breaks down
I should be honest about the limits of the framing.
The clean version of this argument assumes agents are producing a large share of your changes. If they are writing ten percent of your code, the two assumptions are bruised rather than broken, and ordinary discipline will carry you further than any new machinery. Do not rebuild your life cycle for a problem you do not yet have.
The second limit is that machine-verifiable criteria are genuinely harder to write than prose, and some work resists them. Exploratory work, research spikes, design-heavy changes and anything where the goal is to learn rather than to deliver do not decompose into checkable outcomes without becoming absurd. A life cycle that insists everything be verifiable will quietly push teams away from the work that most needs human judgement.
The third is that everything above assumes you can read ground truth. If your team’s real work happens outside source control, in a low-code platform, in a data pipeline configured through a console, in infrastructure changed by hand, then the ground-truth layer has much less to read and the guarantees get correspondingly weaker. Be suspicious of anyone who tells you otherwise, including us.
The takeaway
The SDLC assumed a human wrote the change and a human kept the plan honest. Agents broke both, at the same time, and most of the friction teams are feeling right now is that break rather than any specific tool being bad.
The response is not more ceremony and not less automation. It is a definition of done a machine can check, a record that reconciles itself against source control, and proof for every automated action.
The next piece in this series takes the two assumptions apart one at a time, starting with what actually travelled inside a human-authored pull request, and what we lost when that stopped being the unit of work.