From SDLC to ADLC: what actually changes when agents start building software

For fifty years the software lifecycle assumed the machine would do exactly what we told it. Agents broke that assumption. Here’s what’s taking its place, and what it means if you build with AI for a living.

A while back I watched a team ship an agent that passed every test we had. Unit tests, green. Integration, green. Security review, signed off. By the standards we’d used our whole careers, it was done. Two weeks after it went live, it started quietly making things up. Confident, well-formatted, wrong. Nothing in the code had changed. The model behind it had nudged, the data it leaned on had gone slightly stale, and that was enough.

That gap, between “passes all the checks” and “actually works in the world,” is the whole story of what people now call the Agentic Development Lifecycle, or ADLC. And the more agents I help put into production, the more I think the old playbook isn’t just strained. It’s measuring the wrong things.

This is about what’s shifting underneath us, and what I’d watch if you work in generative or agentic AI.

The lifecycle that ran the world

The Software Development Life Cycle is the thing most of us absorbed without ever being formally taught. Plan, gather requirements, design, build, test, deploy, maintain. Some shops run it as eight tidy phases, some fold it into two-week sprints, but the bones are the same. I think of it as a relay race: each phase hands a baton to the next, and the work moves in one direction.

It worked because software was predictable. Write a function, give it the same input, and you get the same output every single time. That one property, determinism, is what makes most of our tooling possible. Binary tests mean something because there’s a correct answer to check against. Version-gated releases are safe because the code you shipped on Friday behaves the same on Monday. Fifty years of Git, Jenkins, Jira, and Terraform are all built on top of that quiet assumption.

The honest limitations are familiar to anyone who’s lived through a big release. Phases gate each other, so a single ambiguous requirement can stall design for a week. Testing lands at the end, which is the worst possible place. Fixing a defect in production has long been estimated to cost 30 to 100 times more than catching it at design. Frozen requirements fight against the reality that everyone changes their mind. None of that is new. We’ve complained about it for decades and shipped anyway, because the model underneath was sound.

The assumption that quietly broke

When a large language model sits at the center of your product, the same input no longer gives you the same output. Ask the agent the same question twice and you might get two different answers, both reasonable, depending on the prompt phrasing, the model version, what was in the context window, and which tool it decided to reach for. Traditional software is rule-based and deterministic, so the same input reliably produces the same output. Agents are goal-based and non-deterministic. They break most of the rules we’ve come to expect from software, and in doing so they break the development lifecycle we built around those rules.

This is the part I wish someone had hammered into me earlier. The non-determinism isn’t a bug you can test out of the system. It’s the feature. It’s why the agent can handle a messy, free-form request that no one anticipated. You don’t get the flexibility without the unpredictability. They’re the same coin.

The consequence shows up fast in production: systems that behave perfectly in a controlled demo turn fragile under real-world variability. Small changes in context compound into materially different behavior. So if your software keeps changing after you ship it, why does your lifecycle still stop at “deployed”?

So what is ADLC, actually?

Here’s the cleanest definition I’ve landed on: ADLC is the practice of building, evaluating, and operating agents whose behavior is probabilistic, context-dependent, and always drifting. SDLC ships deterministic code. ADLC ships something messier and alive.

The sharpest way to see the difference is to ask what each one actually produces. SDLC produces source code. That’s the artifact. You version it, you review it, you ship it.

ADLC produces three things at once, a kind of trilogy: the code, a context layer, and an evaluation suite. The code is the smallest part. The context layer is the governed business knowledge the agent reasons against at runtime, and unlike code, it goes stale on its own when the business changes underneath it. The evaluation suite is how you measure whether the agent is any good, because you can’t just check it against one right answer.

That reframing matters more than it looks. If you think you’re shipping code, you’ll govern it like code, and you’ll be blindsided when the agent drifts without anyone touching the repo. The agent didn’t break. Its context did.

A term worth untangling here: ADLC (“agentic development lifecycle,” building agentic systems) is not the same as using an AI assistant to write your normal app faster. People sometimes call that second thing AI-assisted SDLC. Both are real and both matter, but this piece is about the first one: what happens when the agent is the product, not the tool helping you build it.

The shape of the new lifecycle

Here’s what surprised me as I read across the frameworks floating around. One uses seven stages, another five phases, another seven phases under different labels. The term itself only really emerged around 2024. They use different numbers and different names. But squint, and they’re all describing the same animal.

The framing that stuck with me splits the lifecycle into two loops. There’s an inner loop and an outer loop, and most teams only respect the first one.

The inner loop is where you design and build. You define what the agent is for and, just as importantly, what it is not allowed to do. You map the context it needs, the tools it can call, and the exact moment it should give up and hand off to a human. Then you build in tight cycles: change a prompt, run it against your evals, look at the distribution of results, adjust, repeat. Not once per release, but sometimes dozens of times an hour. One point is worth underlining twice: in agentic work, development and evaluation are inseparable. You cannot build first and test later, because a small prompt tweak can ripple through every downstream tool call.

The outer loop is everything after deployment, and this is the part SDLC simply doesn’t have. You don’t ship and walk away. You ship and start watching. Deployment is the start of active monitoring, not the finish line. The post-launch phase is called the outer loop for a reason. It never closes. You’re tracking hallucination rates, cost per task, latency, and context drift. When the underlying model gets a silent update from the provider, you re-run your evals to catch reasoning changes before your users do.

A few moves show up in every serious version of this lifecycle that have no real equivalent in the old one:

There’s an explicit step for deciding where the human stays in charge, sometimes called human-agent responsibility mapping, sometimes human-in-the-loop escalation. Either way, you’re drawing the line between what the agent decides on its own and what needs a person, before you write a line of code. Skip it and you push accountability problems straight into production.

There’s a real money conversation that happens early. Token economics, the cost per task at production volume, can sink an agent that looks otherwise perfect. Take a contract-analysis agent in financial services: it can pass every traditional gate and still turn out to be ruinously expensive to run at production volume. That failure mode is invisible to a pass/fail test. It only shows up if you’re measuring it.

And there’s continuous learning baked in as an operating discipline, not a “phase 2 maybe.” Models change, user behavior shifts, edge cases pile up. The agent’s quality decays if nobody’s actively keeping it aligned.

SDLC vs ADLC, side by side

Put the two lifecycles side by side and the differences get concrete. The foundation is the split I keep coming back to: SDLC assumes deterministic behavior, the same input giving the same output, while ADLC has to live with probabilistic behavior, where the same input can produce different results from one day to the next. That single difference cascades into everything else.

What you ship is no longer just source code; it’s code plus a governed context layer plus an evaluation suite. The logic stops living neatly in code and config and spreads across prompts, models, tools, and whatever context gets assembled at runtime. Testing stops being a binary pass/fail against an expected answer and becomes a question of evaluation distributions measured against thresholds you decide are good enough. Deployment, which used to be the finish line, turns into the starting line for monitoring. The feedback loop flips from reactive, where users report bugs and you patch them later, to recursive, where telemetry feeds straight back into prompts and context. The human role shifts from executing every step to reviewing, approving, and setting intent. Even failure looks different: instead of a bug, a crash, or a logic error, you get context drift, stale data, hallucinated answers, and costs that quietly creep up per task until someone notices.

The phase names barely change. Both have planning, building, testing, deploying, monitoring. What changes is what each phase is actually doing, and what “done” means. In SDLC, done is a passing test suite and a deployed version. In ADLC, done is an evaluation score holding steady above a threshold you defined, and that is a thing you have to keep earning, not a box you check once.

What this looks like in the wild right now

The lifecycle theory is catching up to something that’s already happening on real teams.

The industry is openly moving toward fully agentic, end-to-end SDLCs, where engineers manage fleets of agents rather than writing every line themselves. Coding agents already take a scoped task, work in the background using the repository’s context, and open a pull request for a human to review. Reference architectures for spec-driven development now run pipelines that turn a PRD and user stories into production-ready code, with a specialized agent at each step. The human writes the intent; the agents fill in the implementation.

Spec-driven development is the phrase I’d pin a sticky note to. Instead of typing code, you write a precise specification and let agents build against it. One team of eight was reportedly restructured into three humans and five digital agents and tripled its output. Whether that exact ratio holds everywhere, the direction is unmistakable: the market is shifting from code assistants to orchestrated SDLC agents.

The adoption numbers back it up. Around 84% of developers now use or plan to use AI tools, and more than half use agents regularly. One controlled study of 4,800 developers found tasks completed about 56% faster with an AI coding assistant, with pull-request time dropping from over nine days to under three.

What gets me about all of this isn’t the speed. It’s the change in what the job is. The center of gravity is sliding from writing code to orchestrating the things that write code. The role starts to look less like a bricklayer and more like someone running a small team: setting direction, reviewing work, deciding what’s good enough. I have complicated feelings about that, and I don’t fully trust anyone who claims they don’t.

The part nobody puts on the conference slide

Now the uncomfortable half.

For all the momentum, most of this is failing right now. On current trends, more than 40% of agentic AI projects are expected to be canceled by the end of 2027, mostly over cost, fuzzy value, and weak risk controls. Some counts are starker: as many as 88% of agent projects never reach production at all. Plenty of organizations are experimenting, maybe 60-odd percent, but only about a quarter have scaled agents anywhere. There’s a graveyard between the demo and the deploy, and it’s crowded.

When I look at why, three things come up again and again.

The first is evaluation, and it’s the one teams most want to skip. The work isn’t getting an agent functionally complete. It’s getting it reliable, and those are very different milestones. A well-built eval suite might be the single biggest predictor of whether an agentic system succeeds. This is hard, harder than it sounds. You’re not asserting that output equals expected. You’re measuring quality across a spread of messy scenarios and deciding what threshold is good enough to ship. Most teams bolt on a few eval scripts and call it covered. It isn’t.

The second is context, and I’d argue this is the failure hiding under most of the others. Teams ground their agents in raw database schema instead of governed, current business meaning, and then act shocked when the agent hallucinates. In controlled tests, feeding agents governed metadata instead of raw schema has produced jumps in accuracy on the order of 38% for SQL generation. Context isn’t a one-time setup step. It has to be built, versioned, monitored, and refreshed with the same seriousness you’d give code, because when the business changes and the context doesn’t, the agent drifts and nobody gets a compiler error.

The third is trust and security, and the numbers here are sobering. Even as adoption climbs, trust is falling. Only about 29% of developers say they trust AI output, down from over 70% a couple of years ago. The caution is earned: one analysis found AI-generated code carried close to three times more vulnerabilities than human-written code, with nearly half of the samples failing security tests outright. Agents that can take real actions, like moving money or changing records, turn a careless mistake into an incident. The risk list is worth keeping on the wall: hallucinations that look correct, security holes that slip past a casual review, debugging that gets harder when you can’t easily trace why the agent did what it did, and the slow atrophy of human skill when people stop reviewing carefully because the machine usually gets it right.

That last one quietly worries me the most. There’s something unsettling about agents grinding away at 3am, opening pull requests nobody fully reads, in a system nobody can entirely explain. Speed without comprehension is just risk with better marketing.

If you build with AI, here’s what I’d actually do

Enough theory. If you’re working in this space, a few things have earned their place for me.

Start somewhere the downside is small. Pick a task where a wrong answer is cheap and obvious, not one where it quietly costs you a customer. Get your loop working there before you point it at anything that matters.

Build the eval suite before you fall in love with the demo. It feels like a detour. It’s the thing that tells you whether the demo was luck. Curate real, ugly inputs: edge cases, bad data, the weird stuff users actually type, not the clean examples that make screenshots look good.

Treat context as a living asset. Know exactly what knowledge your agent leans on, where it comes from, and what happens when it goes stale. If you can’t answer that, you don’t yet have a product; you have a very convincing prototype.

Decide the human’s job on purpose. Draw the escalation line explicitly. What can the agent do alone, and what needs a person? Write it down before launch, not after the first incident.

And keep watching after you ship, because shipping is the beginning. Monitor the behavior, not just the uptime. Re-run your evals when the model under you changes. Assume drift is coming, because it is.

You’ll notice none of this is exotic. It’s mostly the same discipline good engineers already have, pointed at a system that won’t sit still. SDLC and ADLC aren’t enemies, either. In most real programs they run side by side. The plumbing the agent stands on still wants the old rigor. The agent’s behavior wants the new kind.

The role that’s left

I don’t buy the version of this future where the humans are gone. I buy the one where the humans move up a level.

The relay race is ending. What’s replacing it feels more like conducting. You set the intent, you draw the boundaries, you judge whether the result is good, and you stay accountable for it. The agents handle the keystrokes. You handle the judgment, which turns out to be the part that was always hard anyway.

Every serious framework I read lands on the same quiet point under all the diagrams: this is an evolution, not a clean break. We’re not throwing out fifty years of hard-won discipline. We’re learning to apply it to software that learns, forgets, and occasionally surprises us, for better and for worse.

I started with that agent that passed every test and still got it wrong two weeks later. The fix wasn’t more tests of the kind we already had. It was a different way of thinking about what “working” even means once the software keeps changing after you let it go. That shift in thinking is the real move from SDLC to ADLC. The acronym is the easy part.