How AI Changed the Software Development Life Cycle

The software development life cycle (SDLC) is the path a piece of software takes from an idea to a running product you have to maintain: planning, requirements, design, development, testing, deployment, and maintenance. Seven phases, the same arc whether you call it the system development life cycle or the software development life cycle. The two terms get used interchangeably, and for a working team the distinction doesn’t matter much.

What matters is that the model most people learned hasn’t caught up to the job. The seven phases are still right. But AI moved where the time, the money, and the risk actually sit, and most teams are still staffing the old shape of the work. Spotting where the real risk in your work sits is what lets a team move fast without breaking things.

I’ve been building software for more than twenty years. I started writing VB6 desktop applications, co-founded VinSolutions and sold it, founded Stackify and sold that, and now I run Full Scale, where we staff engineering teams for companies that are scaling. I’ve watched this life cycle run hundreds of times from every seat. Here is what actually changed, phase by phase, and the part nobody talks about: who should be doing the work in each phase now.

What the SDLC actually is

The SDLC is just the route an idea travels to become working software, and then to stay working. Each phase moves the work forward and hands it to the next, so the decision about what to build doesn’t get lost on the way to something running in production.

The methodology you run on top of the phases is a separate choice. Waterfall runs the phases in one long line. Agile chops them into two-week sprints so you do a little of each at once. Those are delivery styles, and we cover the full menu of methodologies elsewhere. The phases underneath them don’t change. A team still plans, builds, tests, and ships. Even on an agile team that runs all seven inside a single sprint, the phases don’t disappear. They recur every two weeks instead of marching past once.

Here’s the thing that quietly broke. For most of my twenty-plus years building software, one phase cost more than the rest combined: writing the code. It was the slow part, the expensive part, the part everything else got arranged around. AI made that part cheap, and the math the whole sequence was built on stopped holding.

The 7 phases of the software development life cycle

Here is the standard model, plus the thing the textbook version leaves out: what AI did to each phase, and where the work moved.

Phase	What it produces	What AI changed
Planning	Scope, budget, feasibility	Faster research and rough estimates
Requirements / analysis	The spec for what to build	Where the risk concentrates now
Design and architecture	How it will be built	Generates options fast, owns none of the consequences
Development	The working code	No longer the slow, expensive part
Testing / QA	A product that works as specified	AI writes tests, humans still judge them
Deployment	Software in production	Automated, but “done” still needs defining
Maintenance	A system that keeps running	More code, written faster, for someone to look after

Phase 1: Planning

Planning is where you decide whether the project is worth doing and what it will cost. Scope, budget, timeline, the rough shape of the thing.

AI helps here at the edges. It’s good for early research, pulling together comparable approaches, and sanity-checking a project timeline before you commit. It will not make the call for you. The judgment about what’s worth building and what you can afford is still yours.

This phase didn’t change much. The trap is treating it as paperwork and rushing through it to get to the “real” work. The real work now starts one phase later, and it depends entirely on how honestly you plan.

Phase 2: Requirements and analysis

This is the phase that changed the most, and almost nobody has restaffed for it.

Requirements is where you decide exactly what the software needs to do. Back when writing the code took weeks, a fuzzy spec wasn’t fatal, because you had time. The developer would hit the unclear parts, come back with questions, and you’d sort it out before much got built on a wrong assumption.

That buffer is gone. The code lands the same day now. A bad spec doesn’t get caught slowly anymore. It gets built in full, before anyone stops to ask whether it was the right thing.

The data backs this up, and it predates AI. The Project Management Institute found that 47% of projects that miss their goals do so because of poor requirements management. That was the top-cited cause of missed projects before AI made building cheap. AI didn’t fix it. It made it more expensive, because now you find out faster and at higher volume that you built something nobody needed.

So the most valuable person on the team is no longer the fastest coder. It’s the person who can write a clear, correct requirement and knows what a product owner actually does. That’s where your best people belong now.

The obvious objection is that AI will eventually write the requirements too. It can already draft a spec. What it can’t do is decide that the spec is the right one for your business, your customers, and the bet you’re making. That call is judgment, not generation, and it stays human.

Phase 3: Design and architecture

Design is where you decide how the thing gets built. The data model, the services, the technical conventions.

AI is genuinely useful here. Ask it for three ways to structure a feature and you’ll get three reasonable options in a minute. What it won’t do is stand behind your conventions or think about the codebase you’ll still be living in five years from now. It optimizes for the prompt in front of it, not the system you have to live with.

The other trap is over-building, and AI makes that easier too. At VinSolutions we scaled to $35 million in annual revenue running on essentially one maxed-out Dell server plus read replicas, before microservices were the default answer to everything. I babysat that server because adding capacity meant a purchase order and a drive to the data center. The constraint forced good decisions. AI will happily design you a distributed system you don’t need yet. Knowing what to ignore is still a human skill.

Phase 4: Development

Development is the coding, and it’s the phase AI hit hardest. The work that used to be slow and expensive is now fast and cheap.

That doesn’t mean the developer’s job went away. It moved. When AI writes most of the code, the human job becomes reviewing that code and knowing what good looks like. I tell clients half-jokingly that we’re all paying developers to babysit AI now, to review what it generates, catch what it gets wrong, and steer it toward something useful. The joke oversimplifies, but the point holds: the value shifted from writing the code to judging it.

This is also where the “if you’re just a coder, you’re done” line comes from. The durable skill is product thinking, not typing speed. One of the best developers I ever worked with was a senior engineer at Stackify who owned our monitoring support across Java, Node, PHP, and Python. He decided himself which languages to support and what “done” meant. His title was senior developer; he operated like a product manager. That’s the kind of ownership that’s worth more now, not less.

Phase 5: Testing and quality assurance

Testing is where you confirm the software does what it was supposed to do. AI changed this phase in two directions at once.

It’s a strong tool here. AI can write its own automated tests and even check its work against the original spec. But it tests what it was told to test, and it has no judgment about whether that was the right thing to build. A human who carries the history of the product can look at something and know it’s wrong in a way the model can’t.

The bigger shift is volume. AI ships more code, so there’s more to review, and review is where teams now stall. The 2025 Stack Overflow Developer Survey found that 84% of developers use or plan to use AI tools, but 46% don’t trust the accuracy of what it produces. Their biggest frustration, named by 66%, is AI code that’s almost right but not quite, and 45% say they lose real time debugging it.

There’s a quality and security cost hiding in that speed, and it’s the part most buyers are actually nervous about. Veracode’s 2025 report found that 45% of AI-generated code carried a known security flaw, and newer, larger models were no safer, so the gap is structural. The DORA research frames it well: AI amplifies what’s already there. A team with good habits gets quicker, and a team without them just reaches its mess sooner. None of that gets solved by typing faster. It gets solved by a human who knows what good looks like, which is exactly why the right testing strategy matters more now than it did when people wrote every line.

Phase 6: Deployment

Deployment is the move to production. For most teams this is the most automated phase, handled by continuous integration and delivery pipelines that take a commit to live with little manual work.

AI didn’t change the mechanics much. What it changed is the pressure on the definition of done. When you can generate features in an afternoon, the temptation is to ship them before they’re actually finished. A clear definition of done is the thing that keeps speed from turning into a mess in production.

Phase 7: Maintenance

Maintenance is keeping the software running and fixing what breaks. It’s the longest phase and the one teams consistently understaff.

AI made this harder in a quiet way. More code shipped faster means more code to maintain, and a lot of it was written fast by a model that didn’t document its reasoning. GitClear’s study of 211 million lines of code found that duplicated code blocks jumped about eightfold in 2024 while refactoring fell, which is exactly the kind of debt that’s invisible at ship time and expensive a year later. I spent years at Stackify building monitoring tools that watched production software fall over, so I have a bias here: the bill for sloppy code always comes due, and it comes due in maintenance. Plan for it as a real, ongoing cost, not a rounding error after launch.

The real question isn’t which phases you can offshore

Once you see that the work has moved, the next question is who does it, and that’s where most advice about offshoring the software development life cycle gets it backward. The usual line is that you can safely offshore the “grunt” phases, the coding and testing, but keep the thinking, the requirements and design, close to home.

I don’t buy it, and I’ve run this experiment directly. Over the years I’ve personally hired developers in Russia, Uruguay, Colombia, and the Philippines. Any phase of the life cycle can be done offshore, because an offshore engineer is no different from any other employee. The only variable that matters is how much you involve them in the process.

When I had a development firm in Uruguay, their product owner genuinely owned the direction of what we built. That’s a requirements-phase job, the one you’re supposedly never supposed to hand off, and it worked so well I later hired those developers directly. It worked because we involved them like teammates, not like a vendor at the end of a phone line.

This is the part that trips people up. I said the requirements phase is where your best people belong now, and I also said you can staff that phase offshore. Both are true, because “your best people” was never about where they sit. It’s about who you bring into the decision and hold accountable for the outcome. Involvement is a process choice. Geography isn’t what makes a phase ownable.

That’s the same lesson AI just taught everyone. The thing that breaks a project isn’t where the developer sits. It’s bad communication, a vague spec handed off with no context. Involve people in the process and they can own any phase. Treat them as a cost to be minimized and they can’t own anything, no matter where they are.

This is exactly why cheapshoring fails. When you offshore for the lowest price alone, you’ve already decided not to invest in communication, and that decision is what sinks the work, not the time zone. The practical lever is overlap: we run three to four hours of shared working hours a day so the team is actually in the conversation. That’s a scheduling choice, not a geographic limit. The staff augmentation model works for the same reason, because the engineers join your team and your process instead of sitting behind a wall. We go deeper on this in our offshore and agile practices writeup.

It’s also why we staff out of the Philippines specifically. What you’re buying isn’t cheap hours, it’s engineers who communicate clearly in English and treat your problem like their own. That communication is the whole game, in every phase.

As I put it to clients: AI without product thinking is just a slop machine, and the developers I want on my team know how to avoid that trap. They think first, use AI for the parts where judgment doesn’t add value, and own the outcome of what they ship. Where they live has nothing to do with it.

The life cycle is a communication relay, not an assembly line

The old model treated the SDLC as a line of stations, each one handing a finished part to the next. That made sense when the slow step was a person typing. It doesn’t anymore.

The phases that survived unchanged are the ones built on judgment and communication: deciding what to build, knowing what good looks like, and keeping people in the conversation. The phase that got cheap, the typing, is the one we used to organize everything around. If your team is still putting its best people on execution and treating requirements as paperwork, you’re staffing the wrong life cycle.

The thinking behind all of this, how to build teams that own outcomes instead of taking orders, is the subject of my book, Product Driven.

If you’re trying to figure out how to staff the lifecycle for the way work happens now, let’s talk. It’s what we do every day.