Doing the SDLC in the AI Era: How to Use AI Efficiently

 I haven’t written a blog post in a while, but this topic has been on my mind because so many teams are still struggling with it: where does AI actually fit in the software development lifecycle?

AI is here, and at this point that is no longer the interesting part. The more important question is how to use it strategically. As these tools become more expensive, organizations need a clearer plan for where AI creates real value and where it simply adds cost, noise, or unnecessary complexity.

When generative AI first exploded into the workplace, many companies rushed to experiment with it without fully understanding how it fit into their delivery model. Some teams wanted to use it everywhere. Others pushed back hard, especially when the conversation turned to job security. A few years later, I still see many organizations wrestling with the same underlying problem: they are treating AI as a blanket strategy instead of a tool that should be applied selectively.

So here is my view: if you want to improve time to production without burning through budget, you should be intentional about where AI enters the SDLC. In this post, I am using the traditional SDLC model: Analysis, Design, Development, Testing, and Deployment.

Analysis

Analysis is still, in my view, a deeply human phase. This is where teams define the problem, surface the real requirements, and make sense of business context that is often messy, political, and difficult to capture in a prompt. Could AI help? Sure. But to make it genuinely useful, you would need to feed it a substantial amount of context: organizational history, team culture, domain knowledge, and stakeholder nuance.

At that point, I start to question the return on the effort. Yes, AI can help generate user stories or draft tasks once the thinking is already done. But in most cases, I do not see analysis as the phase where AI gives you the strongest payoff. I would keep its role limited here and rely primarily on people to do the hard thinking upfront.

Design

Design is where AI starts to become much more useful. If your requirements are reasonably clear, AI can help you think through architecture, edge cases, tradeoffs, and supporting concerns such as performance, scalability, cost, high availability, and disaster recovery. This is one of the few phases where iteration with AI often feels worth it.

That does not mean humans step out of the process. The quality of the output still depends heavily on the quality of the input. But if you already understand the problem space, AI can help accelerate design thinking and expose issues you may not have considered on the first pass.

Development

Development is where my opinion tends to differ from the louder AI narratives. Can AI generate code quickly? Absolutely. Can it sometimes produce solid output? Yes. But that still does not automatically make it the best place to lean in heavily.

My concern is cost. Many AI coding tools are effectively metered by usage, and that usage adds up fast. Prompts get longer, context windows expand, files pile on, and before long you are paying a meaningful amount for generated output that your developers still need to review, correct, and own. If you already have capable engineers, I am not convinced that broad AI-driven coding is the most efficient investment. I would rather use AI selectively in development, for example, to help with debugging, small refactors, or code explanations—than make it the center of the coding process. You have great developers within organizations that love to write code let them decide on how much and where using AI makes sense.

Testing

Testing, on the other hand, is where I think AI can deliver some of the clearest wins. In many organizations, testing is still heavily manual, and entire categories of testing are either underdeveloped or skipped altogether. That creates a perfect opportunity for AI to help expand coverage, script repeatable scenarios, and catch edge cases that might otherwise be missed.

No, it will not produce perfectly bug-free software. Nothing will. But it can absolutely improve consistency, speed, and the overall quality of your testing approach. And if better testing prevents hundreds of hours of bug fixing later, the cost of using AI here may be one of the easiest to justify. I would also use AI to help diagnose and fix defects once they are found, with developers staying firmly in control of the final decisions.

Deployment

Deployment is another phase where AI can be genuinely practical. Deployment scripts are usually narrower in scope than application code, and they often require less context to produce useful results. If your team does not have a dedicated platform or release engineering function, AI can be a helpful assistant for building and refining deployment scripts.

There is also a compounding benefit here: once a script is written and validated, it can often be reused with only minor changes. That makes deployment one of the more sustainable places to apply AI, especially for smaller teams trying to move faster without adding new headcount.

Conclusion

So yes, AI can save time and increase productivity across the SDLC. But that does not mean it should be used equally in every phase. If you want the benefits without the runaway cost, the smarter move is to apply it where the payoff is highest and the context is manageable.

·       Design – Use AI to explore architecture, tradeoffs, and edge cases such as performance, cost, high availability, and disaster recovery.

·       Testing – Use AI to improve coverage, generate scripts, and strengthen the overall quality of your testing process.

·       Development – Use AI selectively for bug fixing, small refactors, and support tasks rather than full-scale code generation.

·       Deployment – Use AI to help create and refine reusable deployment scripts and supporting automation.

Your developers should still be focused on building thoughtful, high-quality applications and making the kinds of decisions that require judgment.

If your organization has the budget, tooling, and patience to automate more of the lifecycle with AI, you can absolutely push further. I am not arguing that it cannot be done. I am arguing that for most teams, a disciplined and selective approach will deliver better results than trying to force AI into every phase simply because it is available.