ADLC vs SDLC: The Moment I Realized Software Engineering Had Changed

Ever since I was a little kid, software engineering felt structured to me. There was always a process. A flow. A lifecycle.

In university, in tutorials, in interviews, in my first job — SDLC was everywhere.

Requirements -> Design ->Development ->Testing -> Deployment -> Maintenance

It almost felt sacred.

The idea that good software came from predictability was deeply wired into me as a developer. If something broke, there had to be a reason. If the logic was correct, the system should behave correctly too.

And honestly, for the longest time, that belief worked.

For decades, the Software Development Lifecycle (SDLC) has been the backbone of modern engineering. Requirement gathering, design, development, testing, deployment, and maintenance formed a predictable pipeline for building software systems.

AI agents are now changing the nature of software itself. And not just the software we ship. The way we make it.

The moment it broke for me

The realization didn’t arrive as a headline. It arrived while I was staring at a pull request.

The code was good. Clean, idiomatic, well-structured. It handled edge cases I hadn’t even thought to mention. It was, in a few places, better than what I would have written. And I hadn’t written a line of it 🤷🏻‍♀️

GIF credits : https://giphy.com/

An agent had. I’d described what I wanted — the intent, the constraints, the shape of the thing — and it produced the implementation. My job, in that moment, wasn’t to write. It was to read, judge, and decide whether to trust it.

My first feeling was excitement. This was fast. This was powerful.

My second feeling, arriving about ten seconds later : if I’m not the one writing the code anymore, what exactly am I? 🤔

That’s the moment. A small, disorienting tilt in the floor.

For my entire career, “development” meant me, typing, translating logic into syntax. That act was the job. It was also, if I’m honest, the part of my identity I was proudest of.

Now the act had moved. I was still responsible for the outcome — but I was no longer the author of it.

Two things people call “ADLC” (and why the difference matters)

Before I go further, a quick untangling, because the acronym is overloaded and it caused me real confusion.

Some people use “ADLC” to mean the Agent Development Lifecycle — the phases of building an agent as your product. There, the agent is the thing you ship, and the lifecycle changes because the product itself is non-deterministic.

That’s not what this article is about.

I’m talking about the other one: the Agent-Driven Development Lifecycle — where AI agents become active participants in how software gets built, rather than tools that merely autocomplete. The product might be perfectly ordinary software. What’s changed is who does the building.

In SDLC -> the human executes and the tools assist. In the agent-driven model -> the human orchestrates and the agent executes. Humans move toward the what and the why. Agents increasingly own the how.

That inversion is small to describe and enormous to live inside.

How the lifecycle actually bends into the software development processes

Here’s the part I find genuinely interesting: the phases don’t disappear. They shift who’s doing them and where the hard part lives.

• Requirements stop being a document and start being a conversation with the machine. The clearer your intent, the better the output. Vague requirements used to produce delayed code; now they produce confidently wrong code, fast. The skill of specifying — precisely, unambiguously, with the right constraints — becomes the front-line engineering skill. Your prompt is your spec, and an incomplete spec is a sloppy build.
• Development becomes delegation and steering. You’re not writing the loop; you’re deciding whether the loop the agent wrote is the right one, in the right place, doing the right thing. The bottleneck moves off your keyboard. It’s no longer how fast can I type — it’s how fast and how well can I direct, and then verify.
• Testing shifts from “did my code work” to “did the code I didn’t write work — and do I understand it well enough to sign off?” This is the uncomfortable one. Reviewing volume you didn’t author is a different cognitive load than reviewing your own work. You lose the built-in understanding that comes from having typed every line. You have to reconstruct comprehension after the fact.
• The bottleneck becomes review capacity and trust. When an agent can produce more code in an hour than you can carefully read in a day, the constraint on shipping isn’t generation anymore. It’s verification. The engineer becomes the rate limiter — and the quality gate.
• Maintenance gets stranger. You may end up maintaining systems no single human fully holds in their head, because no single human wrote them. The documentation, the intent capture, the “why is it like this” — those become survival tools, not nice-to-haves.

Notice the pattern: almost every phase moves the human up a level of abstraction — from doing the work to directing and validating it.

The part I’m genuinely torn about

I want to be honest, because pretending this is all upside wouldn’t be true.

The benefits are obvious. I can ship faster than I ever could before. I spend less time writing boilerplate and more time thinking about architecture, product decisions, and solving the problems that actually need human judgment. That’s real, and it’s hard to ignore.

But there are still things that bother me.

I wonder what happens to our engineering instincts if we stop writing the hard parts ourselves. A lot of the judgment I use today — spotting edge cases, questioning implementations, knowing when something feels off — came from writing code. If we skip that journey, where does that intuition come from?

I also find myself trusting code I didn’t write. Most of the time it’s fine, but reviewing agent-generated code isn’t the same as reviewing something I built line by line. That’s a different kind of responsibility.

And if I’m being completely honest, I do miss writing code sometimes. Not because AI can’t do it, but because I genuinely enjoyed it. There’s something satisfying about building a clean solution yourself that prompting an agent doesn’t quite replace.

What survives

Here’s what steadies me when the unease gets loud.

The instincts that made me good didn’t come from typing. They came from thinking — about failure modes, about what “correct” really means, about what the user actually needs, about the difference between code that works and code that’s right.

Those instincts don’t get automated away by an agent writing the implementation. If anything, they become the whole job. Taste, judgment, the ability to know what good looks like and catch what’s wrong at a glance — that’s exactly what you need when you’re reviewing more than you’re writing.

The craft didn’t vanish. It moved. From writing the answer to knowing the right answer when you see it, and demanding it when you don’t.

The pipeline, one more time

I started with that sacred pipeline. Requirements → Design → Development → Testing → Deployment → Maintenance. Cause to effect. Correct logic to correct behavior. Me, commanding the machine, line by line.

Image credits : https://imgflip.com/i/6pdgaz

The pipeline is still there. But my place in it has moved.

I used to be inside the “Development” box, hands on the keys. Now I’m standing over the whole thing — describing intent, steering the work, deciding what to trust, catching what’s wrong. Less author, more director.

Some days that feels like a promotion. Some days it feels like a loss. Most days, honestly, it feels like both.

And maybe that’s the real signal that software engineering has changed — the question has shifted from “can I build this?” to “can I direct, and trust, something else to build it — and stay a good engineer while I do?”

I’m still figuring out the answer …. I just no longer think the old lifecycle is going to give it to me.

Photo by Rifki Kurniawan on Unsplash