How to Redesign Your SDLC for AI in 4 Structural Shifts

Most engineering leaders already know their SDLC wasn't built for what AI has done to software delivery. The harder question is how to redesign your SDLC for AI in practice. What to change, in what order, with a real team, under real constraints, while the work doesn't stop.

There are four concrete shifts. Most teams have already started on two of them. The other two are where the invisible debt piles up fastest - and most haven't touched them yet.

← Read the previous post: why organizations know they need to redesign and still don't

Shift 1: Velocity Metrics to Operability Metrics

We've written about this at length already, so we'll keep it brief here.

Speed metrics tell you how fast you're moving. They don't tell you whether anyone can own what you shipped. The diagnostic that actually matters is operability. Can your team understand, modify, and operate the AI-generated code they're shipping? And it shows up around month three, long after the velocity numbers looked great.

The numbers bear this out. Faros AI analysis of 10,000 developers found that teams with high AI adoption merge 98% more pull requests. But PR size grows 154% and review time increases 91%. More code, larger batches, slower understanding. That's not a velocity win. That's operability debt being manufactured at scale.

The shift: add at least one operability signal to every sprint review. Not "did it pass tests" - "can someone on this team confidently own this code six months from now?"

Shift 2: Phase Gates to Enabling Constraints

This is where most SDLC redesign actually needs to happen, and where the opportunity is largest.

Traditional governance puts controls at the end. Code review happens before merge. Security scanning happens before release. UAT happens before go-live. The design assumes that humans reviewing finished work is the safest way to catch problems.

That held true when humans wrote code at human speed. At AI-generated volume, the gate model fails. The code review bottleneck is documented - PR volume, PR size, and review time have all surged together in high-AI-adoption teams. Agents keep submitting PRs but human review capacity is saturated - the pipeline fills at the review gate regardless of how fast generation runs.

2025 was the year of AI speed. 2026 is the year of AI quality - the shift from "how fast can we generate?" to "how confident can we be in what we ship?" The gate model was not designed for the first question. It cannot answer the second one at volume.

Thomas Dohmke, former GitHub CEO, raised $60M in early 2026 specifically to address this. His thesis: "Just like when automotive companies replaced the traditional, craft-based production system with the moving assembly line, we must now reimagine the software development lifecycle for a world where machines are the primary producers of code." The production model has changed. The review model hasn't.

In the organizations we work with, the code review queue isn't a staffing problem. It's an architectural one. The system was designed to filter human output, not govern machine-generated volume. Moving the controls earlier is what changes it.

The solution isn't to remove the controls. It's to move them earlier.

What's the difference between a gate and an enabling constraint?

A gate is a stop after the fact: "We will review this before it ships, and the outcome of that review determines whether it ships." It requires human judgment on finished work.

An enabling constraint is an upfront agreement: "Before any work begins, we agree on the architectural rules, the automated checks that constitute compliance, and the criteria that allow a change to proceed without manual review." It shapes what gets built before anyone writes a line.

And it's worth being precise about what "constraint" means here. An enabling constraint is an acknowledgment, or even a purposeful placement, of a limitation. A definition of the boundaries we must remain within. Cost is usually a big one: we only have $X, or we can only spend so many tokens on AI. They enable because they force us to think about how to do as much as possible within the limit.

In practice, this is harder than it sounds - not technically, but organizationally. Agreeing on what an automated check can cover, and what still needs human judgment, takes time. We helped a bank work through it. The discussion took four to five months. Every change type had to be categorized. Compliance, engineering, and security had to agree on every automated check together. Nobody wanted to make a call that would be second-guessed later.

But once that work was done, it applied to every later change automatically. Approval used to take months per change. It became same-day for anything that met the agreed criteria. The compliance didn't go away - it moved to the front, where it could run at machine speed.

What's the first enabling constraint a team should put in place?

Architectural clarity. Before any AI agent touches your codebase, define your system's main components, their responsibilities, and how they connect. This context shapes what AI generates. Without it, AI produces code that's technically functional but architecturally incoherent. That debt stays invisible until the system becomes unmaintainable.

Shift 3: Process Documentation to Living Context

This shift gets its own post next week - context engineering is complex enough that a paragraph would undersell it. The short version: your documentation strategy has to change. If it hasn't, it will.

Context now has to serve two audiences: humans and AI agents. Stale documentation was always a problem for humans. For AI agents, stale context doesn't just slow things down - it produces wrong outputs, confidently. The shift isn't just "keep documentation up to date." It's about where documentation lives. Documentation that lives next to the code and is versioned with it is what an AI agent can actually use. Documentation sitting in project folders from last sprint is not.

More on this next week. For now: if your documentation strategy hasn't changed since you started using AI, it needs to.

Shift 4: Uniform Governance to Blast-Radius Oversight

Not all code carries the same risk. A billing pipeline is not an internal reporting tool. A customer-facing authentication system is not a background data migration script. We've covered the four specific risks every SDLC was built to manage - traceability, operability, security, and data integrity. All four still apply with AI. What changes is how much oversight each type of work should get.

Most organizations apply the same governance process to everything. This creates two problems at once. It over-governs low-risk work, adding friction that serves no real protective function. And it under-governs high-risk work, where the consequences of failure are far higher but the oversight is identical.

With AI in the loop, this mismatch gets worse. AI makes it easier for more people to build more things faster. Some of those things quietly become load-bearing before anyone realizes it. A developer builds a small automation to copy data between systems and save an hour a week. No SDLC, no documentation, no owner. It works. Others start depending on it. The developer leaves. The automation fails. Nobody knows what it was doing.

This is shadow IT made easier. As Reworked put it: "Feeding an intelligent tool a chaotic mess of unindexed, unverified data expands the blast radius of every output it generates." AI will confidently help someone build a high-blast-radius system without flagging a single concern. It will even recommend approaches that create operational risk.

The security dimension compounds this. CVE-2025-53773 - command injection in GitHub Copilot and Visual Studio - received a CVSS score of 7.8 HIGH. An unauthorized attacker can execute code locally. The blast radius of an AI-assisted development environment isn't just operational. It's a security surface that didn't exist before.

How do you map blast radius?

Two questions. First: what depends on this? If the answer involves customer data, financial transactions, or systems other teams rely on, the blast radius is significant. If it's a few internal users and nothing downstream, it's small. Second: what does recovery look like if it fails? Fast and self-contained means manageable. Requires coordination across teams, regulatory notification, or customer communication means significant.

High blast radius: deep controls - architectural review, security scanning, staged rollouts, explicit ownership, runbooks. Low blast radius: lightweight controls - automated checks, documentation requirements, clear ownership. The same criteria that determine blast radius can be built into the triage process itself. The right level of oversight then applies automatically.

Regulation is already pointing in this direction. The EU AI Act's requirements for high-risk AI systems cover financial services, healthcare, critical infrastructure, and similar domains. They were originally set to reach full enforcement on August 2, 2026. A May 2026 political agreement on simplified and streamlined rules has since pushed those dates back. Stand-alone high-risk AI systems now have until December 2, 2027. High-risk systems embedded in products have until August 2, 2028. The direction is unchanged. The timeline moved. Organizations building AI into regulated systems are being asked to demonstrate exactly what blast-radius thinking requires. Documented ownership. Defined scope. Clear accountability for what each system does and what happens if it fails.

How to Redesign Your SDLC for AI - The Underlying Pattern

These four shifts aren't independent. They're all responses to the same reality. AI has changed where the constraint sits in software delivery. The SDLC hasn't been redesigned to reflect that.

AI-generated code is fast and plentiful. The constraint is no longer writing it. It's understanding it, governing it, and operating it over time. Each shift moves the delivery system toward that constraint instead of ignoring it.

The teams getting real value from AI aren't the ones shipping fastest. They're the ones who can still understand, fix, and improve what they shipped six months ago.

Teams don't need to slow down. They need systems designed for AI-scale delivery. Success comes from understanding and operating what gets generated - not from writing it fastest.

Most teams find one of these four shifts is already urgent - and two of the others will be in six months. In a 30-minute call, we'll help you find which one to tackle first and what that actually looks like in your context.

Part of Xodiac's Week 5 series on SDLC Redesign. [Continue to Week 6: context engineering and living documentation]