Does AI improve software development? Only if your SDLC is already sound

Nowhere is more divided on the topic of AI than a modern engineering team. On the one hand, you’ve got engineers claiming they’ve achieved x10 or x100 velocity with agentic tools like Claude Code and Cursor. On the other, you’ve got those saying AI tool use is creating code review bottlenecks and turning seniors into full time garbage collectors, leeching productivity as well as joy from their teams.

Who’s correct? In all likelihood, both.

AI is a force multiplier. You’ve likely heard that saying thrown around a lot, but not many truly appreciate what it means. More than a pithy saying, it means that what you get from AI is going to depend on how good your software engineering processes are before AI is added to the mix.

Software engineering maturity matters more than flashy AI tools

If your existing software engineering processes are falling short of best practice without AI, then adding these tools to the mix will only amplify these problems. For example, if you don’t have a quality software testing culture—such as running unit and regression testing regularly and making quality a shared responsibility across all teams—then the AI can easily run rampant and your engineering teams wouldn’t notice.

You might be tempted to solve your QA problems above by having your engineers use AI tools to create tests. Normally, that’s a great use case, since this stage can often be skipped due to how much of a pain it is to write tests. However, if the AI writes bad tests (and your engineers don’t know what a good test looks like to catch this) you can wind up with more of a mess than when you started.

Measuring weaknesses in your existing SDLC processes

Below is a non-exhaustive list of questions you might want to ask:

• Do your existing tickets tend to have missing or incomplete acceptance criteria before work gets started? If so, an agent is going to go in the wrong direction, engage in scope creep, and provide results that don’t meet user needs.

• Do engineers have to frequently stop work to get clarification from the product side of things? AI is more likely to skip this step than a human, exacerbating your issues.

• Do you have architecture documented where an engineer or AI agent can read it? If you don’t have documented conventions, an AI is going to invent its own.

• Are pull requests small enough to be reviewed properly in one sitting? AI will be producing a lot of code at volume, so you don’t want AI-generated PRs simply getting rubber-stamped as well.

• What is your current testing culture like? Could your engineers tell a good test from one that merely passes? 

• Can you roll back a bad release in minutes? AI increases the rate of change, so recovery time decides whether that's an asset or a liability.

• Do you track change failure rate at all? If you can't measure it, you can't tell whether AI is helping or hurting.

• Can your engineers explain the code they merge? If not, they can't debug it when it breaks in production.

When applying AI to the SDLC, don’t do it all at once

Start with one aspect that needs fixing, and consider AI as a candidate to do that. This allows you to mitigate the risk of adoption and roll things back if anything goes wrong. 

More on building AI-ready engineering teams that get results

Want to learn more about getting actual results from AI in engineering? Read Pluralsight’s guide, ‘Five steps for building AI-ready engineering teams and proving ROI.’