The Four AI Development Risks Every SDLC Was Built to Prevent

Every control in your SDLC has a story behind it.

The code review process exists because someone shipped a bug that cost the company. The change tracking exists because something broke in production and nobody could explain what changed. The approval gates exist because someone deployed the wrong thing at the wrong time.

Your SDLC isn't a bureaucratic obstacle. It's a record of expensive lessons learned the hard way.

AI generates code that carries none of that history. It also generates code faster than the people who own those lessons can review it. If you want to understand AI development risk, start here. Start with what the SDLC was built to prevent.

5 Hours That Cost Millions

A regional toll collection system on a major Canadian highway operates automated license plate readers that identify vehicles and bill their accounts instantly. The system has been running reliably for years. It generates roughly $1 million in revenue per hour.

A developer writes code to improve part of the OCR (optical character recognition) function. The code isn't tested thoroughly. It's deployed to production.

The code has a bug. The OCR function breaks. Completely.

Now the system can detect that cars are entering the highway, but it can't read the license plates. The system has no way to identify which car belongs to which account. It has no way to bill anyone.

For five hours, everyone who drives on that highway drives for free.

In those five hours:

• Every vehicle that enters the highway goes unbilled
• No toll charges are collected
• No audit trail of the transaction is created
• The operations team notices immediately when charges stop flowing
• But it takes them the full five hours to isolate the bug, understand what broke, fix the code, and redeploy the fix

The cost: roughly $5 million in lost revenue.

The lesson wasn't about the quality of the code or the intelligence of the developer. The lesson was about the visibility of the change. It was about testing before deployment. It was about the fact that nobody reviewed that code before it went live.

That's what the SDLC was designed to prevent.

The Four Risks, Explained

Software delivery methods started to emerge in the 1970s and 80s. They weren't built to slow teams down. They were built to stop serious failures in systems where getting it wrong cost millions.

Every control in your SDLC - the code reviews, the change tracking, the testing requirements, the approval gates - was designed to address one of four risks.

1. Traceability

Can you trace every change that goes into production? Can you explain why it was made? Can you reverse it if something goes wrong?

Without Traceability, you don't have an audit trail. You don't know what changed, when, or why. When something breaks, there's no path back to a known-good state.

The toll module passed every technical check. But nobody was tracking what it was actually deciding - only that it was running. Traceability would have caught the gap between what the module was meant to validate and what it was actually doing.

2. Operability

Can your team run this system? Can they understand it? Can they change it safely?

Without operability, you have code that works until it doesn't. Systems run fine until something goes wrong - and then nobody knows how to fix them because nobody fully understands how they work.

The toll module was invisible to the operations team. It was doing its job quietly - wrong, but quietly - with no way for anyone to see that something was off. We looked at what operability debt looks like in practice in a previous post. The pattern is consistent across organizations.

3. Security

Does this code break your security controls? Does it create risks? Does it expose data?

Without security controls, you ship vulnerabilities at production speed. The Veracode 2025 GenAI Code Security Report tested more than 100 AI models across 80 coding tasks. It found that 45% of code samples introduced OWASP Top 10 security vulnerabilities. Security failure rates stayed flat no matter how large or advanced the model was.

The models are getting better at writing code that runs. They're not getting better at writing code that's safe.

4. Data Integrity

Does this code protect your data? Does it respect your data contracts? Does it check inputs correctly?

Without data integrity controls, bad data flows downstream. It corrupts everything that depends on it. By the time you find the problem, months of decisions have been made on bad data.

Sonar's 2025 research looked at more than 4,400 coding tasks. It found that as AI models score better on benchmarks, high-severity bugs often go up too. In one case, a 6.3% score gain came with a 93% rise in high-severity issues. Passing tests and being correct are not the same thing.

The toll system's five-hour window of bad data meant a manual audit of millions of records.

Why Code Trust Is the Real Problem

Writing code is easy. Trusting code is hard.

A developer can write a lot of code in an hour. The organization has to trust that code for years. That trust needs visibility, clear records, and understanding. Someone has to know what the code does and why it was the right call. Not every line of syntax, but the decisions and trade-offs being made at the system level.

Your SDLC creates the conditions for that trust. It makes changes visible. It requires understanding before deployment. It checks for known problems. It validates data inputs.

These controls exist because the cost of skipping them is severe. That hasn't changed. What's changed is the volume and speed of code entering the system.

How AI Development Changes Your Risk Profile

AI generates code much faster than humans do. The gap between what a team produces in a day and what an AI-assisted team generates has grown by an order of magnitude. And it's still growing.

Your SDLC was built for humans writing code. The pace was slow enough that careful review was possible. The reasoning was visible. The trade-offs were clear.

AI-generated code moves faster than most SDLC controls can keep up with.

A code review that used to catch gaps now only checks that the linter passes. A change audit that used to trace decisions now only logs that a deployment happened.

The Sonar State of Code Developer Survey 2026 found that 95% of developers spend time reviewing and fixing AI output. And 59% say that effort is moderate or heavy. The review is happening. The understanding isn't.

The four risks don't go away when you adopt AI. They get worse.

SDLC Redesign: Deciding Which Risks Need Human Oversight

You can't patch your way out of this. Adding more automation to an SDLC built for humans won't fix it. Using more AI to review what another AI wrote isn't a solution. It's a delay.

Tracy Bannon made the point clearly at QCon London: "Fix your SDLC before adopting Gen AI." AI-generated code needs clear governance at the right points. Without it, you lose the ability to trace changes, prove decisions, and show your work.

The redesign starts with one question: which of these four AI development risks can we accept at speed, and which ones need a human decision before code ships?

For a toll collection system, the answer to all four is no. Every change has to be traceable. The ops team has to understand how the system works. Validation logic has to be checked. Bad data costs money and trust.

For other systems, some answers may differ. But the question is the same: where does the human have to stay in the loop?

The SDLC exists to answer that question. Right now, most organizations haven't redesigned theirs to ask it. Unsurprisingly, given the rate of change AI is bringing and the expansion of contributors to software systems.

Before Your Next AI Feature, Know What Risks You're Accepting

Know where your gates are. Know where a human has to say yes before code goes live.

AI generates code faster than you can review it. If you don't decide where your governance sits, it fails quietly - until five hours later, when you find out your toll system has been charging the wrong people.

That's what the SDLC was built to prevent. The question worth sitting with is whether yours can still do that job.

If you're not sure where your gaps are, let's find out together.