Where the SDLC breaks, and what AI changes

What is the software development life cycle?

The software development life cycle is the repeatable sequence a team uses to take software from an idea to a running system: plan, analyse requirements, design, build, test, deploy, maintain. Its job is to make delivery predictable instead of heroic. Following it does not, by itself, make a project succeed, and the evidence on that point has been consistent for decades.

Two terms get used interchangeably and should not be. A phase is a stage of work every project passes through, whatever method the team uses. A model is the rule for sequencing those phases. Waterfall runs them once in strict order. Agile cycles through them repeatedly in short increments. The V-model pairs each build stage with a matching verification stage. Spiral adds a risk review to every loop. Arguments about waterfall versus agile are arguments about sequencing, not about which phases exist. Nobody skips the phases; teams only choose how often to revisit them.

Counting conventions differ too. Some guides list five phases, some six, some seven, depending on whether planning is separated from requirements analysis and whether deployment and maintenance are split. The count is not the useful part. Where each phase reliably breaks is.

What are the SDLC phases, and where does each one fail?

Every phase has a characteristic failure mode. Naming it is more useful than memorising the phase list, because each failure has a control you can add without reorganising the team.

The cost of these misses moves in one direction only. Set the cost of a design-phase fix at one. The same defect costs roughly six times more to fix once it is in code, about fifteen times more if it is caught in testing, and up to a hundred times more once the software has shipped.²

That curve is the whole economic case for taking the front of the life cycle seriously. It is also the strongest argument against generating code straight from a vague prompt. Skipping requirements and design does not remove the curve. It defers the same expensive late rework and relabels it as speed.

Which SDLC models are worth using, and when?

Model choice is a bet on how much you already know. Waterfall assumes the requirement is stable and the cost of change is high, which is why it survives in regulated and safety-critical work where the specification is contractual. It fails badly when the requirement is really a hypothesis, because the first honest feedback arrives after the budget is spent.

Iterative and agile models assume the opposite: the requirement will change, so shorten the loop and learn in public. They fail when the short loop becomes an excuse to write nothing down, which spreads the requirements failure mode across every sprint instead of removing it.

The V-model is worth borrowing from even if you never adopt it wholesale. Its single idea, that every design artefact must be paired with the test that proves it, is a discipline most agile teams would benefit from. Spiral is the right shape when risk rather than scope is the dominant unknown, because each loop is a prototype plus a risk review, which suits novel integrations and unproven platforms.

Low-code platforms are becoming a fifth option rather than a niche one. Gartner has forecast that 70 percent of new applications built by enterprises will use low-code or no-code technology, up from less than 25 percent in 2020.³ The life cycle does not disappear on those platforms. Requirements, testing and release governance still apply, they are just harder to see.

How is AI changing the software development life cycle?

AI has compressed one phase, coding, and left the phases around it roughly where they were. That is the honest summary. The bottleneck has not been removed, it has moved to requirements, review and release governance, which is where most teams were already weakest.

The adoption side is not in question. GitHub now hosts more than 180 million developers and 4.3 million AI-related repositories, and nearly four in five new developers use Copilot within their first week on the platform.⁴ Trust is a different story.

80 percent of developers use AI tools in their workflow and 60 percent view them favourably, but only 29 percent trust the output to be accurate, down from 40 percent a year earlier, and 66 percent say they now spend more time fixing AI-generated code that is almost right but not quite.⁵ Those findings are not in conflict. They describe a tool that is genuinely useful and genuinely unreliable at the same time.

Planning and requirements

AI drafts user stories, acceptance criteria and test plans quickly, which is useful. What it does not do is resolve ambiguity; it renders ambiguity fluently. An unclear specification fed to a coding tool produces confident code built on the wrong assumption, and the confidence of the output makes the wrong assumption harder to spot. Sequence AI after the requirement is agreed, never as a substitute for agreeing it.

Design and build

This is where the measurable gains sit. McKinsey reports that developers using generative AI can complete some tasks up to twice as fast, and that top-quintile organisations, the ones that redesigned their workflow around the tools rather than bolting them on, see gains of 31 to 45 percent in software quality.⁶ The qualifier matters more than the number. The gain comes from the workflow redesign, not from the licence.

Testing, deployment and maintenance

More code arrives per developer per week, so the phases downstream of coding need more structure, not less. AI is good at generating test cases and triaging logs, and poor at deciding what is worth testing. DORA’s 2025 finding is that AI acts as an amplifier rather than a fix: a disciplined team gets faster, and an undisciplined one ships its dysfunction faster.⁷ For teams delivering across web application builds and mobile releases, that amplification shows up first in the release pipeline, where the cost of a bad change is highest.

Why do projects still fail when teams follow the software development life cycle?

Because the life cycle is a container, not a decision. It tells you which conversations to have and in what order. It does not make anyone have them honestly.

Failure rates have not improved as the tooling has. PMI put the project failure rate at 13 percent in 2025, up from 12 percent the year before, and found that professionals with high business acumen were associated with 27 percent lower failure rates.⁸ The second number is the interesting one. It points at understanding the business problem, which is a requirements-phase capability rather than a delivery-phase one.

An ambiguous specification does not get clearer when a machine writes the code for it. It gets more expensive to correct, and it arrives sooner.

The recurring causes are unglamorous. Scope that was never bounded. Stakeholders consulted once at kickoff and never again. Non-functional requirements nobody wrote down. A testing budget that was the first thing cut when the date slipped. None of these are solved by a faster keyboard.

What does a secure SDLC look like now?

A secure SDLC, sometimes written SSDLC, embeds security work into every phase rather than staging it as a gate before release: threat modelling during design, dependency and static analysis running in the editor and the pipeline, secrets scanning on every commit, and a patch path that has been rehearsed rather than assumed. DevSecOps is the operating model for that work; the secure SDLC is its shape.

Two trend lines are moving at once. Exploitation of known vulnerabilities is rising as a route in, and the volume of machine-generated code entering repositories is rising alongside it. Late-stage security review was already a weak control. It does not scale to the volume of code teams now produce.

Which SDLC best practices survive contact with AI?

Six that hold up, in the order we would apply them.

1. Measure where the life cycle actually slows down before adding tools. Most teams add AI to the phase that was already fastest. Cycle time by phase, not by ticket, shows where the queue really sits.
2. Write acceptance criteria before you write prompts. A requirement a tester can verify is also a requirement a model can implement. One that cannot be tested cannot be safely generated.
3. Treat change failure rate as the headline metric. Elite performers deploy on demand, ship 182 times more often than low performers, and still hold change failure rate near 5 percent with service restored in under an hour.¹⁰ Deployment count on its own is vanity once AI raises code volume.
4. Keep review capacity in proportion to generation capacity. If code output rises and reviewer hours do not, review stops being the defect filter and becomes the defect source.
5. Shift security left into the editor. Scanning at merge is late. Scanning at release is decorative.
6. Make rollback boring. Feature flags, progressive rollout and a rehearsed revert turn a bad release from an incident into an inconvenience.

None of this requires a methodology change. It requires deciding which phase you are actually weakest in and putting the control there. If you want a second read on where your pipeline is losing time, our engineering practice runs exactly this diagnostic, and you can start that conversation here.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.