I have shipped software through four of these and watched the other four arrive. A stand-up that quietly replaced a sign-off gate. An API contract that seventeen 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. Eight 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.
- Nine 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. Three are ways an AI does the building. And the SDLC is none of those – it is the spine the rest rearrange.
- One feature, eight ways; a fingerprint for each; and the exact point where every one of them tends to break.
Ask ten engineers how software gets built and you will hear the same handful of words, usually as if they were nine competing answers to one question. Waterfall. Agile. Mobile-first. API-first. AI-first. Spec-driven. Vibe coding. Agentic. 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 nine 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 three first stances are lenses you hold over whichever lifecycle you already run. The three AI-era styles change how the build phase happens, not how the whole thing is steered. And the SDLC is not a tenth contender at all. It is the spine the other eight 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.
One Feature, Eight 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 eight 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 bottom three rows are simply where it has reached now.
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.
Eight 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 |
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. 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 a ninth 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 three 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. Both bets are about the spine, not about the model.
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.