What the SDLC got right that we should keep
Nine pieces arguing that the old life cycle rested on broken assumptions. This one argues the other side: which practices were load-bearing for reasons that have nothing to do with who writes the code.
There is a particular kind of engineering organisation that shows up every technology cycle, and it is always run by intelligent people. They have correctly identified that an existing practice rests on an assumption that no longer holds. They remove the practice. They are right about the assumption and wrong about the consequences, because the practice was also quietly doing three other things that nobody had written down, and those three things do not fail immediately. They fail in about seven months, in a way that is attributed to something else.
I have spent nine pieces in this series making the case that the software development life cycle rested on two assumptions (a human writes the change, a human maintains the plan) that agents have broken, and that a great deal of process built on those assumptions is now measuring the wrong things. I believe that case. I also think it is one-sided by construction, and that the larger practical risk for most teams in 2026 is not that they will cling too long to the old life cycle. It is that they will delete the parts that were never about the assumptions at all.
So this piece argues the other way. Not as a hedge, but because I think several of these are genuinely more important now than they were.
Small batches were never about human capacity
The single most durable finding in modern software delivery is that small, frequent, independently deployable changes outperform large batched ones on speed and stability simultaneously. That finding has survived a decade of research and every attempt to explain it away as a correlation.
The reason it is durable is that it is not really a fact about people. It is a fact about the relationship between change size and diagnostic difficulty. When something breaks after a small change, the search space for the cause is small. When something breaks after fifty bundled changes, the search space is combinatorial. That property is indifferent to who or what composed the changes.
Which means agents do not weaken the argument for small batches, they strengthen it. Agents can produce enormous diffs effortlessly, with no fatigue signal to say “this has become too much for one change.” The natural size limit that existed because a human got tired is gone. If you were relying on that limit, and most teams were without knowing it, you have to replace it with an explicit one.
Worse, agent-authored large changes are harder to diagnose than human-authored ones of the same size, because there is no author to interrogate about what they were thinking. A 4,000-line human diff has one person who can walk you through it. A 4,000-line generated diff has a work item and a hope.
Keep small batches. Enforce them mechanically. This is more important than it was, not less.
A large human-authored change
- Cost real effort, so it was rare
- Fatigue was a natural brake on size
- An author who can be interrogated
- Reasoning recoverable, if slowly
A large agent-authored change
- Effortless, so nothing limits it
- No fatigue signal at all
- No author holding the reasoning
- Harder to diagnose at the same size
Trunk-based development and integration frequency
Adjacent and for the same underlying reason. Long-lived branches accumulate divergence, and divergence is where semantic conflicts hide. The pain of integration scales worse than linearly with time apart.
Agentic development pushes hard in the wrong direction here, because parallel agent work is easy to start and the branches multiply. It is trivially simple to have nine branches open, each individually sensible, each drifting from the others and from trunk. The old discipline of integrating at least daily was invented for a world with far less parallelism than that, and it applies with more force rather than less.
I would go further: the ability to hold many changes in flight simultaneously is the single most dangerous new capability, because it is the one with no natural brake and the failure it produces (semantic conflict between independently correct changes) is the hardest class of defect to find.
Nine branches open, each individually reasonable, is trivially easy to arrange now and was practically impossible before.
It is the single most dangerous new capability, because it is the one with no natural brake, and the failure it produces surfaces at integration rather than at authoring time.
Definition of done as a shared, explicit contract
The agile canon insisted that “done” be defined and shared rather than assumed. Most teams treated this as bureaucratic and produced a checklist nobody read.
It turns out to have been one of the most important ideas in the whole methodology, and the teams that took it seriously are the ones having the easiest time now. Everything in this series about machine-verifiable acceptance criteria is a restatement of definition of done with the ambiguity removed. The concept was right the first time. What has changed is the price of ignoring it, which used to be modest (a human filled the gap with judgement) and is now high (a machine fills it plausibly and at volume).
Nobody needs to invent a new idea here. The old one needs to be taken literally.
Retrospectives and the practice of examining the process
The most consistently undervalued ceremony in the entire canon, and the first one cut when a team gets busy.
The case for keeping it is straightforward: the process is changing faster than it has changed in twenty years. Every team is running an unproven configuration of tools, practices and boundaries that did not exist eighteen months ago. In that environment, a protected recurring session for asking “what is this actually doing to us” is not overhead, it is the primary mechanism by which the team improves at all.
The teams that will come out of this period well are not the ones that picked the right tools. Tools change every quarter. They are the ones that built a reliable habit of noticing what was working.
Cross-functional teams and end-to-end ownership
The argument for you-build-it-you-run-it was that separating the people who create a system from the people who operate it produces bad incentives and slow feedback. That argument had nothing to do with who typed the code. It was about accountability and about the loop between a decision and its consequences.
If anything, ownership matters more now. When a large share of code is generated, the question “who is responsible for this behaviour in production” gets harder to answer and more important to answer. Diffuse accountability plus high change volume is a genuinely bad combination, and the temptation to treat generated code as unowned (“the agent wrote it”) is real and needs to be shut down explicitly. Somebody specified it, somebody approved it, somebody owns the consequence.
Version control discipline
Almost too obvious to state, except that the argument has strengthened dramatically and I have not seen many people say so.
Meaningful commits. Linked work items. Clear history. Signed changes. These were always good hygiene and were treated as such: nice, not essential. In an agentic life cycle they are load-bearing, because source control is the only artefact that is definitionally true, and everything else (status, plans, documentation, audit evidence, decision provenance) is now being derived from it. A repository with rich, linked, honest history is a functioning nervous system. One with a thousand commits saying “fix” and no ticket links is a system that cannot see itself.
The teams that maintained this discipline for aesthetic reasons are about to discover they were building infrastructure.
Post-incident review without blame
A practice with fifty years of history in aviation and about fifteen in software, and one that becomes strange and important in an agentic context.
Strange because the blame question gets genuinely confused. When an automated change causes an outage, the reflex is to blame the automation, which is both easy and useless, because the automation has no capacity to learn from being blamed. The useful questions are all upstream: why did the specification permit this, why did the checks not catch it, why did the review sampling not select this class of change, why did nobody consider this failure mode.
That is exactly what a good blameless review has always done. It was already about systems rather than individuals. The discipline transfers intact and the tendency to abandon it (because “the AI did it” feels like an answer) is a trap.
The bigger risk right now is over-correction
Here is the part I actually want to argue, and it is a claim about the current moment rather than about any specific practice.
There is a mode of thinking that goes: agents changed everything, therefore all prior practice is suspect, therefore we should rebuild from first principles. It is intoxicating and it is how a lot of very expensive quarters get spent. It gets the logic backwards. The correct question is not “what still applies” (which puts the burden of proof on established practice) but “what specifically broke, and what is the minimum change that addresses it.”
The two assumptions broke. That has clear, traceable consequences: definition of done has to become machine-checkable, status has to be derived rather than asserted, review has to become deliberate sampling rather than universal gatekeeping, and automated actions need proof and reversibility. Those follow directly.
Small batches did not break. Ownership did not break. Reflection did not break. Integration discipline did not break. Blameless review did not break. Nothing about agents touches the reasoning behind any of them, and a team that removes them because they came from the same era as the things that did break is making a category error that will cost real money.
There is also a timing argument. Most organisations are not yet in the state that justifies the aggressive version of this. If agents are producing fifteen percent of your changes, the two assumptions are strained rather than broken, ordinary discipline still works, and rebuilding your life cycle is solving a problem you do not have. The right move at fifteen percent is to fix your acceptance criteria and your ticket-to-change linkage, which are cheap, useful immediately, and are the prerequisites for everything else whenever you do get there.
Where this breaks down
This piece argues for conservatism, so the honest counter-arguments run the other way, and some of them land.
“Keep what worked” is exactly what every incumbent says while being disrupted. Every technology transition has had thoughtful people arguing that the fundamentals are unchanged, and they have sometimes been right and sometimes been comprehensively wrong. My list of durable practices is a judgement call, and I have no privileged access to which items on it are genuinely structural versus which merely feel structural because I am used to them. Someone reading this in three years may find the section on small batches quaint.
Practices persist by inertia, and inertia is a poor filter. I have justified several practices by noting that the reasoning behind them does not mention who writes the code. But a lot of process survives for reasons that have nothing to do with its reasoning: it is embedded in tools, in job titles, in how people are evaluated, in what the training course taught. A practice can be genuinely obsolete and still feel load-bearing because so much is bolted to it. I cannot fully distinguish “this is durable” from “this is deeply entangled,” and neither can anyone else right now.
Incrementalism has a specific failure mode. The minimum-change approach is right when the required change is decomposable. It is wrong when the pieces only work together, and there is a plausible reading of the ADLC where that is the case: derived status is not much use without criteria, criteria are not much use without enforcement, enforcement is not acceptable without proof and reversibility. If it is a system rather than a menu, then adopting it a piece at a time gets you most of the cost and little of the benefit, and the teams that rebuilt aggressively will look prescient. I do not think that is the case. I hold it at maybe thirty percent.
And my defence of retrospectives and cohesion may be nostalgia wearing a suit. I have argued in several pieces that ceremonies carried social functions worth preserving. It is entirely possible that a generation of engineers who learn to work primarily with agents will develop different and perfectly adequate ways of building shared understanding, and that my concern about lost apprenticeship channels is the same concern every generation has about the next one’s methods. I notice I cannot construct a version of that argument that would have been wrong in 1995 about pair programming, and that is not a comfortable observation to end on.
The takeaway
Two assumptions broke, and the consequences are specific: machine-checkable done, derived status, sampled review, proof for automated action. That is the actual scope of what has to change, and this series has spent nine pieces on it.
What did not break is everything whose justification never referenced who writes the code. Small batches, because diagnosis scales with change size. Frequent integration, because divergence hides semantic conflict. Explicit definition of done, which was always right and is now unavoidable. End-to-end ownership, because accountability got harder to locate rather than less necessary. Version control discipline, which was hygiene and is now infrastructure. Blameless review, because the useful questions were always upstream of the actor. And reflection, because the process is changing under everyone’s feet and noticing is the only defence.
That is the whole of this series. The next thing worth reading is not another argument about what changed, but the practical version: how a team that is currently at fifteen percent agent-authored code gets to a life cycle that will still work at seventy, without rebuilding anything it does not have to. Start with the linkage between changes and work items, and with acceptance criteria a machine could evaluate. Everything else in this series depends on those two, and both are cheap enough to start this week.