What is SDLC with AI: The Software Cycle Rethought

When someone says they're "using AI to program," they typically imagine a chat window generating a function. This vision is narrow and, worse, hinders the decision-making of those who lead technical teams.

Software development has never been just about writing code. It's a cycle, and the acronym that describes this cycle is SDLC: Software Development Life Cycle. The right question is not "does AI write code?" It's "what happens to each phase of the cycle when AI participates in it?"

This text is about that. No magic, with process.

What is the SDLC, without romanticism

The SDLC is the sequence of steps a software goes through from ideation to retirement. The classic phases are: requirements, design, implementation, testing, deployment and maintenance.

Nobody lives these phases in a straight line. Agile teams iterate, go back, cut corners. But the structure remains useful because each phase has a different type of work, with different risks.

Requirements is where you decide what to build. Design is where you decide how. Implementation is where you write. Testing is where you check. Deploy is where you deliver. Maintenance is where you live with what you delivered, sometimes for years.

Most conversations about AI focus only on implementation. It's the most common mistake I see among technical leaders.

The SDLC is also a quality contract. Each phase exists to reduce a specific risk: poorly designed requirements generate expensive rework, bad design generates technical debt, weak tests generate an incident in production. When you change who does the work in each phase, you also change where the risks are concentrated. Therefore, AI cannot enter the cycle as a tool detail. It comes as a redistribution of risk, and risk is a matter for whoever leads.

Why "generating code" is the least interesting part

Code generation is the most visible phase because it is the most demonstrable. You enter an order, a functional part comes out, everyone is impressed.

The problem is that writing code has never been the real bottleneck for most teams. The bottleneck usually lies in understanding the problem, aligning the design, keeping the base healthy and not breaking production. Just speeding up typing solves the easy part and leaves the difficult part intact.

Worse: if AI produces faster code, you generate more code to review, test, and maintain. The bottleneck moves, it does not disappear. Those who treat AI as a typing accelerator end up with a faster conveyor belt dumping work on a human proofreader who remains the same.

That's why I defend a simple thesis: AI in the SDLC is a process change, not a productivity plugin.

What changes in each phase

In requirements, AI helps transform loose conversations into acceptance criteria, find contradictions in a document and generate questions that no one asked. It doesn't decide what matters to the business, but it reduces the friction of moving from the vacant lot to the concrete.

In design, it serves to explore alternatives. You describe a constraint and ask for three approaches with trade-offs. The value is in expanding the range of options before making a decision, not in outsourcing the decision.

In implementation, it generates, completes and refactors. It is the most mature phase and also the most dangerous, because the code seems ready before it is correct. I talk more about trusting AI-generated code in another text.

In tests, it covers edge scenarios that haste would make you ignore, generates masses of data and writes cases based on expected behavior. Testing is, in my experience, one of the phases in which AI yields the most results with the least risk.

In deploy, she helps write scripts, review pipeline configuration, and explain why a build broke. It continues to be an area where errors are costly, so supervision needs to be greater.

In maintenance, perhaps the most underrated phase, it helps to understand code that no one wrote yesterday, to map the impact of a change and to document what was undocumented. Those who maintain a legacy system know that this phase takes more time than the entire initial construction.

Note one important thing when looking phase by phase: the gain is not uniform. AI yields a lot in testing and maintenance, it yields care in implementation and deployment, and it yields little where the decision depends on a business context that the tool does not have. Treating every stage as if you gain the same is the quickest path to frustration. A good leader calibrates expectations by phase, not by hype.

The paradox that every leader needs to face

The numbers from this cycle are revealing. According to the 2025 Stack Overflow Survey, with more than 49 thousand respondents, 84% of developers already use or plan to use AI in the development process, compared to 76% in the previous year.

Adoption has gone up. Trust, no. In the same survey, 46% of developers distrust the accuracy of AI tools, compared to 33% who trust them, and only 3% trust them strongly.

This mismatch is not a contradiction, it is maturity. People are using the tool and, as they use it, discovering where it fails. A leader who ignores this paradox will promise gains that are not sustainable and frustrate the team with the first bad deployment.

The correct reading is different: AI enters the cycle as a competent and sometimes overconfident collaborator, and the process needs to absorb this with review and governance, not with faith.

What does this require of those who lead

Rethinking the SDLC with AI means redesigning where quality control is. If generation has become faster, the review needs to become more rigorous, not more relaxed.

It means deciding, phase by phase, what you delegate and what remains under non-negotiable human responsibility. Generating a test is one thing. Approving a database migration in production is another.

And it means measuring the entire cycle, not just typing speed. If the lead time does not improve, if the defect rate increases, if the base becomes more difficult to maintain, AI is not helping the SDLC. It's just accelerating one phase and pushing the cost onto the others.

Rethinking the cycle is exactly the type of work that distinguishes a team that uses AI with a method from one that just pastes chat responses.

If you are responsible for a team, start by mapping its six phases and asking, in each one, where AI reduces risk and where it introduces new risk. It's an afternoon exercise that's worth more than any demo. To get down to the details of each stage, see the AI in each phase of SDLC.