The Six Phases of the Software Development Life Cycle, Rethought for the AI Era

The six-phase software development life cycle - requirement analysis, system design, implementation, testing, deployment, maintenance - has been taught the same way for thirty years. The phases have not changed. What has changed, and changed fast, is where the work, the cost, and the risk now sit inside them. Treating the SDLC as a tidy linear diagram is no longer harmless simplification; it actively hides the two forces reshaping every phase: AI-generated code and the platform engineering that either contains it or doesn't. This is a briefing on how each phase behaves under those forces for teams operating at scale or under regulatory scrutiny.

Diagram of the six software development life cycle phases - requirement analysis, system design, implementation, testing, deployment, and maintenance - arranged as a continuous cycle

Start with the fact that reorders everything else. AI is no longer an experiment in the implementation phase. The 2025 DORA Report, drawing on nearly 5,000 technology professionals, found that 90% now use AI at work and over 80% say it raises their productivity. Gartner forecasts that 75% of enterprise software engineers will use AI code assistants by 2028, up from less than 10% in early 2023 - one of the steepest enterprise adoption curves the firm has projected. AI is now a cross-cutting input to all six phases, and it does not distribute its effects evenly. It accelerates the phases where humans were the bottleneck and applies pressure to the phases that were supposed to catch mistakes.

Requirement Analysis and System Design: where human judgment concentrates

These two phases answer "what" and "how," and they are precisely where AI helps least and where mistakes cost most. The widely cited rule of thumb still holds: a defect introduced in requirements or design is roughly 100x cheaper to fix there than in production. The CISQ 2022 report put the price of poor software quality in the US at an estimated $2.41 trillion, including roughly $1.52 trillion of accumulated technical debt - debt that overwhelmingly originates in decisions made during these early phases and compounds silently afterward.

Gartner's read on the trajectory is that the developer role is shifting from writing code toward orchestration and system design as AI absorbs routine implementation. That makes requirement analysis and design the durable human centre of the SDLC. For regulated teams, design is also where traceability is established - the chain from a stated requirement, to the component that satisfies it, to the test that proves it. AI can draft a requirements document; it cannot own the accountability for whether that document is correct, complete, and defensible to an auditor. Treat these phases as the place where you spend senior time deliberately, because everything downstream inherits their errors at 100x markup.

Implementation: faster, and that is the problem

Implementation is where AI's acceleration is real and measurable, and where the SDLC's clean diagram becomes dangerous. The same DORA programme exposed a paradox worth sitting with. In the 2024 report, across more than 39,000 respondents, a 25% increase in AI adoption was associated with an estimated 1.5% drop in delivery throughput and a 7.2% drop in delivery stability. The mechanism was not that AI wrote worse code; it was that AI inflated change-set sizes, and large changes are harder to review, test, and roll back.

By 2025 the throughput relationship had turned positive - AI now correlates with shipping more. But the stability relationship remained negative. Read those two findings together and the implication for the SDLC is sharp: AI speeds up the implementation phase while transferring load onto testing, review, and deployment. The bottleneck does not disappear; it moves downstream to the phases least able to absorb a sudden surge in volume. A team that adopts AI in coding without hardening the phases after it is not getting faster - it is accumulating risk on a delay.

Testing: more important as AI writes more, not less

The instinct that AI reduces the need for testing is exactly backwards. The 2025 DORA data found that even with 90% adoption, 30% of practitioners report little or no trust in AI-generated code. That distrust is rational, and it has to be operationalised rather than felt. As AI generates a larger share of the codebase, the verification phase becomes the load-bearing control of the whole life cycle.

Concretely, that means automated test coverage that scales with output rather than headcount, mandatory human review with deliberately small change sets so reviewers can actually reason about a diff, and DevSecOps guardrails - security scanning, dependency checks, policy-as-code - running inside the pipeline rather than as a quarterly audit. The economics make the case on their own. When poor quality and technical debt carry trillion-dollar aggregate costs, the testing phase is not a gate to clear before shipping; it is where the financial return of the entire SDLC is decided. Under-investing here to ship faster is borrowing against production at a punishing interest rate.

Deployment: the control point under the most new pressure

Deployment is where increased change volume meets reality. If implementation now produces more and larger changes, the deployment phase has to enforce the discipline that keeps stability from degrading: small, frequent, reversible releases; progressive delivery and staged rollouts so blast radius stays bounded; and automated rollback that does not depend on a human noticing fast enough. The DORA stability signal is, in practical terms, a warning that deployment controls are where AI-driven speed gets converted into either reliable delivery or incidents - depending entirely on whether those controls exist before the volume arrives.

Maintenance: the phase that holds the money

The original framing of the SDLC as cyclical is correct but understated. Deployment is not the finish line; for most systems, maintenance is the longest and most expensive phase, and it is where the trillion-dollar quality and technical-debt costs actually land. Every shortcut taken in design, every under-reviewed AI-generated change, every skipped test resurfaces here as an outage, a vulnerability, or a slowdown that quietly taxes every future release. Maintenance is also where regulated teams live or die on traceability: when something breaks, can you reconstruct why a change shipped, who approved it, and which requirement it served?

The variable that actually decides the outcome

Across all six phases, the 2025 DORA Report lands on a conclusion that should reframe how any engineering leader reads the AI hype: AI amplifies what is already there. The decisive factor is not the assistant a team buys - it is the quality of the internal platform underneath it. The report found that 90% of organizations have adopted at least one internal platform, and that high-quality platforms are what let teams convert AI speed into real value. For low-quality platforms, the measured AI benefit was negligible.

This is the through-line for any leader auditing their own SDLC. AI in implementation without strong testing and deployment controls produces the 2024 outcome: more code, worse stability. The same AI on top of a mature platform - paved CI/CD paths, automated verification, traceability, fast rollback - produces the 2025 outcome: more throughput without sacrificing the rest. The six phases have not changed. What determines whether AI makes them better or worse is the platform and DevOps foundation running underneath all six. That foundation is where the leverage is, and it is the work worth funding before the next assistant rollout, not after.