I have shipped software through four of these and watched the rest arrive. A stand-up that quietly replaced a sign-off gate. An API contract that more than a dozen squads built against at the same time. An evening last week when I handed an agent a goal and reviewed what it had written. The same phases underneath every time. Only the choreography changed.
Every team builds through some lifecycle – Waterfall, Agile, Lean, and now the agentic loop. Ten approaches, one SDLC spine, and a single ruler they all answer to: working software in front of a real user. AI changes the loop, not the spine.
- Eleven names get thrown around. Sort them into three layers and most of the confusion goes away.
- Only two are rival lifecycles. Three are priority lenses. Five are ways the building happens once an AI is in the loop. And the SDLC is none of those – it is the spine the rest rearrange.
- One feature, ten ways, a fingerprint for each – plus the thirty corrective years between Waterfall and Agile, whose lessons the AI era is quietly re-running at machine speed.
Ask ten engineers how software gets built and you will hear the same names, usually as if they were eleven competing answers to one question. Waterfall. Agile. Mobile-first. API-first. AI-first. Spec-driven. Vibe coding. Agentic. Loop engineering. Harness engineering. And the plain old SDLC underneath all of them. Lined up like that, they look like a menu you choose one item from. They are not. They are not even the same kind of thing.
That is the single idea that makes the rest of this guide easy. These eleven names live on three different layers, and once you can see the layers, you can stop arguing about which one is right and start asking which one fits the work in front of you.
Read it once more from the top: only Waterfall and Agile are full, rival lifecycles – the two still standing, that is; the thirty years of corrections between them get their own stop further down. The three first stances are lenses you hold over whichever lifecycle you already run. The five AI-era styles change how the build phase happens, not how the whole thing is steered. And the SDLC is not an eleventh contender at all. It is the spine the other ten rearrange, which is exactly why we will come back to it at the end.
Where Each One Came From
None of these arrived in a vacuum. Each was a reaction to the pain of the one before it, and you can read the whole history as a single line bending toward shorter feedback loops and faster correction. Here is the lineage, in the order it actually happened.
Notice that the colours cluster. The blue era was about organising people. The amber era was about choosing a constraint to respect. The purple era is about who, or what, is holding the keyboard. Three different questions, which is why they never really competed.
The two youngest purple names sit a little apart, and the gap is the point. Agentic coding hands the model the keyboard; these two are the disciplines that grew up around it once it left the demo. Loop engineering gives each task a lap the agent can run – write, run, read the failure, fix – and a finish line it cannot fake. Harness engineering equips the repository those laps happen in: the context an agent loads before its first edit, the tools it is allowed to hold, the checks that stand whether or not anyone is watching. More of my evenings now go into the files an agent reads before it touches the code than into the code itself.
The Thirty Years Between the Staircase and the Sprint
Most tellings of this story jump from 1970 to 2001 in one stride, as if the industry slept between Waterfall and the manifesto. It did not. It spent three decades correcting Waterfall one painful lesson at a time, and the models that era produced – prototyping, iterative and incremental delivery, Boehm's spiral and its WinWin variant, Martin's RAD, the V-model, the Unified Process, Beck's test-first XP – were still the canon in every software engineering textbook when I entered the industry. The enterprises I have worked in carry their fossils to this day: a sign-off gate here, a risk review there, long after anyone stopped saying the model's name out loud.
Read the era as one argument unfolding. Every model in it found a different way to buy back the thing Waterfall deferred, feedback, and each paid for it with a new kind of overhead. Feedback against overhead is the axis the whole era slides along – and, as the last column below is about to show, the axis the AI era is sliding along again.
| Model | The correction it made | Where it broke | Its AI-era echo |
|---|---|---|---|
| Prototyping mid-1970s |
Build a rough version first to force the real requirements out of hiding, then discard it and build properly. | The prototype was rarely discarded. Demos became products, and the quick hack became the foundation. | Vibe coding – the same promise at minute scale, and the same throwaway quietly shipping to production. |
| Iterative & incremental 1970s–80s |
Deliver in slices; let each delivered slice correct the plan for the next one. | Without a real user in the loop, the slices never converged – each iteration just rehearsed the same guesses. | The agent's inner lap. Every loop is an iteration; the increment shrank from a release to a diff. |
| Spiral 1986 |
Boehm made risk the driver: each cycle sizes the biggest remaining unknown, attacks it, and lets the result steer the next cycle. | It assumed someone senior enough to name the risks honestly. Most projects spiralled by calendar instead. | Loop engineering with human gates: choosing the agent's next lap by what might fail worst is Boehm's cycle at minute scale. |
| WinWin Spiral 1990s |
Before each cycle, every stakeholder states a win condition, and the plan is negotiated until all of them can win. | Negotiation theatre. Win conditions were written once, filed, and never consulted again when the schedule bit. | Spec-driven development – the spec as the negotiated contract, except one signatory is now a model that holds you to what you wrote. |
| RAD 1991 |
Martin's timebox: sixty to ninety days, users in the workshop, assembly from reusable parts over writing from scratch. | The timebox held only while the parts library fit the problem. Off the beaten path, speed collapsed into rework. | The closest ancestor of AI-assisted building itself. Assembly from prior work, except the parts library became the training corpus. |
| V-model 1980s |
Pair every building phase with a checking phase: requirements to acceptance tests, design to integration tests, code to unit tests. | All the verification was planned early and executed late – the right arm of the V arrived after months of compounding mistakes. | The loop's finish line. Fold the V until its two arms touch and you get write-and-verify in one lap, run every few seconds. |
| Unified Process (RUP) 1999 |
The grand synthesis: use-case driven, architecture-centric, iterative inside four named phases. | It sank under its own artifacts. Teams produced documents about the process instead of software through it. | A warning, not a technique: harness engineering is one committee away from becoming RUP for agents – files nobody reads, gates nobody trusts. |
| XP / TDD 1999 |
Kent Beck's Extreme Programming pulled verification in front of the code: write the failing test, make it pass, clean up. Feedback arrived in minutes instead of at phase ends. | It ran on discipline alone. Under deadline pressure test-first slid into test-after, and test-after into test-never. | Loop engineering. The agent's lap is red, green, refactor run by a machine, and the failing test is the scope you hand it. |
Agile did not defeat these models in argument. It absorbed their corrections – prototyping's learning-by-building, the spiral's nose for risk, RAD's timebox and its users in the room, XP's test-first discipline – and cut away the ceremony they had accumulated. That is what 2001 actually was: less a new idea than a weight reduction. Which is why this era has started to matter again. The AI-era styles further down this page are the corrective era's second run, with the loop time collapsed from quarters to seconds now that a model can hold the keyboard. Every failure in the middle column above is available again at that speed. Knowing what killed each correction the first time tells you where to stand guard on your own team now.
One Feature, Ten Ways
Abstractions are slippery, so make it concrete. Take one small, universal job: let a user who forgot their password get back into their account. Here is how each of the ten named approaches would actually go about it. Same destination every time. Very different journeys.
Read top to bottom and you can feel the loop tightening. Months, then weeks, then an afternoon, then minutes. That tightening is the whole story of the last fifty years. And the last two rows mark where it turns: once the loop runs faster than you can watch it, your work moves out of the loop and into building it.
What Each One Feels Like to Work In
A methodology has a texture. You can tell which one you are in by the rhythm of your week long before anyone says its name. Here is each approach by its characteristic shape – what it feels like, what it is genuinely good for, and the moment it tends to fall apart. The colour of each card tells you which layer it belongs to.
A staircase you walk down once. Each phase finishes and is signed off before the next one begins, and turning back up the stairs is expensive.
A short loop you run again and again. Plan a slice, build it, ship it, learn, and let what you learned reshape the next slice.
Designing for the hardest seat in the house first – the small screen, the thumb, the flaky network – on the bet that if it works there, it works anywhere.
Agreeing the handshake before anyone builds. The contract is the product, and teams build against it in parallel. The direct ancestor of spec-driven development.
Starting from what the model and the data can do, and designing the product around that capability rather than bolting a model onto something already shipped.
Writing the blueprint so precisely that the building falls out of it. The spec is the source of truth; the AI implements it and is measured against it.
Conducting rather than typing. You describe intent, the model writes, you keep what feels right. Karpathy's phrase for giving in to the vibes and barely reading the diff.
Delegating to a tireless junior that plans, edits across the repository, and runs the tests, while you own the goal and stand at the gates where it matters.
Designing the lap instead of running it. You stop steering each edit and build the circuit – a fast build, honest tests, errors a model can read – then let the agent circle until the work passes.
Building the workshop rather than the furniture. Your effort goes into what every agent task shares – the context loaded first, the tools allowed, the gates that hold – and pays out on every task that follows.
Ten Approaches, Side by Side
If the cards are for feel, this is for decisions. The same five questions asked of every approach, so you can scan down a column and compare like for like. Read across a row and you have its fingerprint.
| Approach | Layer | Unit of work | Who drives | Loop length | Where AI sits |
|---|---|---|---|---|---|
| Waterfall | Methodology | A signed-off phase document | Analyst and project manager | Months | Absent |
| Agile | Methodology | A user story in a sprint | A cross-functional team | One to two weeks | Optional assistant |
| Mobile-first | Stance | The smallest-screen experience | Designer and front-end | Rides the host method | Assistant |
| API-first | Stance / bridge | The API contract | Architect and API designer | Contract up front, then parallel | Assistant |
| AI-first | Stance | The model capability and its data | Product with ML and data | Experiment-driven | The core of the product |
| Spec-driven | Execution | A precise feature spec | Author writes spec, AI builds | Hours to days | Pair, then driver |
| Vibe coding | Execution | A natural-language prompt | The developer and model, by feel | Seconds to minutes | Driver, loosely held |
| Agentic | Execution | A goal handed to an agent | The agent acts, a human checks | Minutes to hours | Driver, gated |
| Loop engineering | Execution | The feedback lap around a task | Human builds the lap, the agent runs it | Seconds to minutes per lap | Driver, checked every lap |
| Harness engineering | Execution | The environment agents work in | Senior engineers as toolsmiths | Compounds across tasks | Driver, on rails you built |
One column repays a slow read: where AI sits. It moves from absent, to a helper at your elbow, to a pair at the keyboard, to the thing actually driving while you watch the road – and, in the last two rows, while you lay it. That migration is the real reason the old process questions feel unsettled. We changed who holds the keyboard without changing the road.
The One Ruler They All Measure Against
So where did the SDLC go? It never left. The software development lifecycle is not an eleventh approach you would choose instead of Agile or vibe coding. It is the set of phases that every one of them rearranges. Strip away the branding and the same nine stages are always there, from first conversation to long-lived change. The methodology decides how you move through them; it does not get to skip them.
Here is the spine in full – the same nine phases this series uses elsewhere – with who acts, the gate that says a phase is done, and what it leaves behind.
| Phase | Who acts | Milestone gate | Deliverable |
|---|---|---|---|
| 01 · Analyze | Analyst, product, stakeholders | Requirements agreed | Acceptance criteria |
| 02 · Design | Architect | Design signed off | Architecture, domain model, contracts |
| 03 · Develop | Engineers, increasingly with AI | Code complete | The implementation |
| 04 · Test | QA and engineers | Quality gate passed | A passing suite and coverage |
| 05 · Build | Release engineering | Artifact produced | A deployable artifact |
| 06 · Deploy | DevOps and SRE | Released to production | A running system |
| 07 · Monitor | SRE and on-call | Observability in place | Dashboards, alerts, SLOs |
| 08 · Deliver | Product and delivery | Value accepted by users | The outcome, demo, sign-off |
| 09 · Change | The whole team | Change managed safely | Versioning and a rollback path |
Now the trick that makes the whole landscape click. Every approach in this guide is just a way of weighting and reordering these nine phases. Lay them side by side against the same spine and the differences stop being slogans and become choices about where the work goes.
Look at the bottom five rows again. The AI-era styles do not invent new phases. They move the human's attention to different ones. Vibe coding bets you can skip the back half. Agentic coding bets you can delegate the middle if you guard the ends. Loop and harness engineering bet the guarding itself can be engineered – per task as a loop, per codebase as an environment. Every one of these bets is about the spine, not about the model.
One more column belongs on the spine before we leave it. Every phase has a deliverable, and for every deliverable the industry long ago wrote down a standard that defines it. In the AI era those standards stop being shelf documentation and become the working scope you hand an agent: a boundary that says what the deliverable is, while leaving the approach open inside it. A model that receives the arc42 template, the failing test, or the SLO definition holds the same definition of done the team holds. Chapter 6 makes the full argument for why this amplifies rather than restricts. Here is the mapping, phase by phase.
| Phase | The standard that scopes an agent |
|---|---|
| 01 · Analyze | User stories with acceptance criteria; a definition of ready |
| 02 · Design | DDD bounded contexts; arc42 as the document template; the C4 model for structure at four zoom levels; UML where precision pays |
| 03 · Develop | Test-driven development: the failing test as the task's boundary |
| 04 · Test | The test pyramid for shape; orthogonal arrays for sizing the functional matrix; evals for AI output |
| 05 · Build | Pipelines as code; reproducible builds |
| 06 · Deploy | Deployment checklists; progressive delivery rules |
| 07 · Monitor | SLOs and error budgets; runbooks written to be executed |
| 08 · Deliver | The definition of done; acceptance owned by a human |
| 09 · Change | Semantic versioning; architecture decision records; the rollback path written first |
The choreography changed. The phases did not. Which is why teams that struggle with AI rarely have a tooling problem. They have a process pointed at the wrong phase – writing for the spine they used to have, not the one they are standing on now.
You have the lifecycles. Next, the pressures reshaping them: the eight forces the AI era puts on how software gets built – the overview map before the next four chapters walk it phase by phase. That is Chapter 8.