From SDLC to ADLC: the software lifecycle when AI writes the code.

The bottleneck moved

The SDLC was organized around one constraint. Producing working code was slow and expensive. Requirements, design, testing and deployment all existed to protect the costly middle, where people typed the system into existence.

That constraint is fading, though the record of what happens next is messy in a telling way. The latest DORA report finds AI adoption near universal and linked to higher delivery throughput, with instability elevated at the same time. METR’s attempts to measure the speedup tell their own story. A 2025 randomized trial found experienced developers 19 percent slower with AI while believing they were faster, and by early 2026 METR concluded the effect had likely improved but could no longer be measured reliably with that design. In Stack Overflow’s latest survey, two thirds of developers name answers that are almost right, but not quite, as their biggest frustration with AI. Output is up, trust is down, and the difference between help and rework tracks one variable, how well the system behind the change is understood.

Where adoption works, the work does not shrink, it moves. Review queues grow. Fewer people can say with confidence which rules the system actually enforces, so designing the next change starts to take longer than building it, and an AI-drafted design or impact analysis inherits the same stale picture. The gap between what the team believes the system does and what it really does widens with every change nobody has fully absorbed.

Code is an asset, but its value rides on the shared picture of the system. What it does today, why, and what it should do next. Design decisions, estimates, onboarding and every conversation between business and delivery run on that picture, and a codebase nobody understands trades more like a liability than an asset. The picture lived partly in the heads of whoever wrote the code, partly in the documents analysts maintained. When agents do the writing, the heads drop out of the loop, and the hand-updated documents fall further behind every week.

Writing code is no longer the constraint. The shared picture of the system is.

Where the SDLC breaks

The classic lifecycle rests on three assumptions that stop holding once agents do most of the writing.

• Specifications are documents. Many enterprises write them properly and keep them current, and that discipline is real work done well. The weakness is the format, not the analysts. A document is connected to the code only by human effort, and nothing in it can tell you whether the code still matches. That effort was sized for human writing speed. At agent speed, keeping documents honest by hand stops scaling.
• Review means reading code. Human review capacity was matched to human writing speed. When agents produce most of the changes, reading every diff stops working as a control, and the diffs themselves are drifting. GitClear’s 2026 analysis of 623 million code changes puts copy-pasted code at almost 16 percent of new lines in the first half of 2026, with refactoring and long-term maintenance falling at the same time. A diff also only shows what changed, not whether the system still does what was agreed.
• Governance happens at gates. Release boards and stage gates assume changes arrive in batches, on a schedule people can meet about. Agent-driven delivery is continuous. A quarterly review of a system that has changed hundreds of times since the last one verifies very little.

None of this argues against using agents. The throughput gain is real. It argues that the process around them has to change.

The three shifts of the ADLC

A note on the name before we start. Some vendors use ADLC for the agent development lifecycle, the process of building and operating AI agents themselves. This series means something else. Our subject is the life cycle of software when agents do the building.

1. The specification becomes a model, not a document

In the ADLC, the specification is a structured model of the system. Requirements, rules, screens and interfaces as nodes, typed relationships between them, and links into the code that implements each one. When code and model disagree, the disagreement shows up as a signal someone can act on, instead of accumulating silently. The spec stops being a phase you pass through and becomes the place where design happens. The next change is drafted against the current state of the model, not against a snapshot from the last release or a guess about what the code does.

2. Humans review intent, machines check evidence

Nobody can read code as fast as agents write it, so the human role has to change. The useful question is no longer “is this code correct?” but “is this the change we approved?” Answering it takes two things the SDLC could not keep current at change time. An impact map before the change, showing which rules, screens, integrations and owners it touches, and a comparison after it, matching what was approved against what was delivered, with links into the code as proof. Business stakeholders review prototypes and specifications in their own language. The machinery checks that delivery matches.

3. Context becomes infrastructure

Agents are only as good as the context they get. Point one at a whole repository and it can make confident changes for reasons it invents along the way. This is a documented pattern, not an anecdote. A 2026 review of the accumulated evidence concludes that specification discipline, not model capability, is the binding constraint on how dependable AI-assisted development gets. A long-context benchmark adds the other half. Even million-token context windows are read unevenly, so the answer is not a bigger window, it is better selection. Give the agent the relevant slice of the model, the affected requirements, the neighboring rules, the constraints that must hold, and it stays inside the agreed scope. The same slice serves everyone. The business stakeholder shaping the change, the developer reviewing it, the agent implementing it and the architect keeping the structure sound read one picture instead of four private ones. Every decision, human or machine, leaves a record.

What changes in practice

An organization running the ADLC works differently in a few visible ways.

1. A change request starts with an impact map, not an estimate. Before anyone commits to a date or a price, the model answers what the change touches and whose sign-off that implies.
2. Agents receive scoped briefs, not a repo and a prompt. Each brief is generated from the model. What to change, what must stay untouched, what evidence to return.
3. Acceptance is a comparison, not a demo. Approved scope is checked against delivered behavior, with the evidence links resolving into actual code.
4. Legacy systems are not exempt. A system built long before any of this can be analyzed into the same kind of model, so its rewrite, or its next decade of maintenance, starts from a map instead of guesswork.

Each of these steps costs something up front. What they buy is agent-speed delivery that does not end in a system nobody dares to change.

Two starting points, one destination

Organizations arrive at this transition from two very different places.

Regulated and heavily governed organizations have real spec discipline. Traceability matrices, review boards, analysts maintaining documents. But those documents record what was approved, not what runs. Keeping them true is people’s work, a conversation in most companies, a formal analyst gate in the best ones. Agents break both. They multiply the changes, they never raise a hand, and no gate staffed by humans clears agent volume. For these organizations, the ADLC starts by connecting the documents they already paid for to the code, with evidence, and keeping that connection checked automatically.

Mid-market companies mostly run with low spec hygiene. A backlog, some tickets, the real knowledge in a few heads. They move fast partly because they skipped the paperwork, and agents make them faster still, right up to the first key person leaving or the first change nobody can explain. For them, the ADLC rarely starts from documents. The most reliable record of what the system does is the code itself, so the picture has to be recovered from the code first, and only then governed.

Different starting points, same destination. One model that people design against and agents work from. The next articles in this series take each path in turn. The enterprise path, where existing documents have to be reconciled with reality, and the mid-market path, where the picture has to be rebuilt from the code itself.

The part that is a choice

Most organizations will get the first half of this transition by default. Agents arrive whether the process is ready or not. The second half, keeping one accurate and governed picture that the whole delivery runs on, only happens on purpose, and it is cheapest to start while the gap between what you run and what you know is still small.

The SDLC managed scarce code. The ADLC manages what is scarce now, a shared, current picture of the system that people design against and agents work from. That is what we are building POLYREQ for.