DEV Community

Saanj Vij
Saanj Vij

Posted on • Originally published at sanjvij.netlify.app

Why the SDLC Is Cracking Under the Weight of AI

#ai #machinelearning #llm #devops

Why the SDLC Is Cracking Under the Weight of AI

Three decades of engineering orthodoxy and the shift no one is talking about clearly enough

I've been thinking a lot about a specific kind of organizational irony that I'm watching play out across engineering teams right now.

A company buys into the AI productivity narrative — they roll out GitHub Copilot, or Claude, or some combination of both — and for the first two weeks, developers feel like superheroes. Code that used to take a day takes an hour. First drafts of feature modules appear almost instantly. Everyone's excited.

Then, about a month in, something strange happens. The sprint velocity doesn't actually go up. Ticket resolution time stays stubbornly flat. The backlog doesn't shrink. And leadership starts quietly asking: "Wait — we just added AI everywhere. Why is nothing faster?"

The answer, almost universally, is that they've installed a jet engine inside a horse-drawn cart.

The Architecture of the Traditional SDLC

For roughly thirty years, software engineering has been structured around the Software Development Life Cycle. Whether an organization runs strict Waterfall or rapid Agile sprints, the structural core of the SDLC has remained functionally identical: a sequential, human-led progression through predictable gates.

[1. Planning] ──> [2. Design] ──> [3. Coding] ──> [4. Testing] ──> [5. Deployment] ──> [6. Ops]
Enter fullscreen mode Exit fullscreen mode

This framework was engineered around two foundational assumptions that made complete sense in their original context:

Assumption 1: Human cognition is the single engine. Every line of code, every architectural diagram, every test script, and every deployment configuration has to be manually produced by a human developer. The speed of the pipeline is bounded by human throughput.

Assumption 2: Hand-offs are deterministic. Phase A must cleanly terminate with a static artifact — a PRD, a compiled build, a signed-off design spec — before Phase B can safely begin. Progress is linear.

These assumptions held up well when humans were genuinely the only viable execution engine. But the moment you introduce AI systems that can draft working code in seconds, both assumptions start to shatter.

The Velocity Bottleneck

Here's the specific failure mode I keep seeing.

When an organization plugs advanced LLMs into their developer workflow, the phase that historically consumed the most clock time — writing raw syntax — collapses from weeks down to seconds. That is a genuine, measurable, remarkable capability gain.

But if you've wrapped an instantaneous code-generation engine inside a traditional, weeks-long corporate approval and manual testing framework, the productivity gains disappear entirely. The bottleneck doesn't go away. It just moves.

If an autonomous agent can draft ten complete, compilable feature updates in an hour, but the team's peer-review scheduling and QA queue takes five days per item, the pipeline still takes fifty days to clear those features. You've added rocket fuel to a car that's stuck in a traffic jam.

The traditional gates weren't built to absorb AI-speed input. They were built around the assumption that input arrives slowly, because humans are slow at writing code.

Phantom Productivity and the Debt Shift

There's a second failure mode that's arguably more dangerous: what I'd call phantom productivity.

When developers use basic AI code-autocomplete extensions without any broader systemic architecture around them, they often generate massive volumes of unverified code very quickly. Surface-level metrics look extraordinary. Lines of code per day skyrocket. Ticket commits accelerate.

But the actual quality of that code frequently doesn't keep pace with its volume. The AI generates plausible-looking syntax that compiles but carries subtle logical errors, violates architectural conventions, or ignores edge cases the human developer would have caught during the act of manual writing. These issues don't surface until they land in QA — or worse, in production.

What's happened isn't productivity. It's a shifting of cognitive burden downstream. The speed gained in the coding phase is extracted, with interest, from the QA and code review phases. The human reviewers get buried. Feedback cycles slow down. The apparent sprint velocity increase masks a growing mountain of hidden debt.

The AI wrote it fast. Doesn't mean the AI wrote it right. And a human still has to read every line of it.

What This Means Structurally

The industry is now being forced to confront a structural reality: you cannot simply insert AI into a traditional SDLC and expect compounding gains. The SDLC's architecture — sequential, human-gated, artifact-driven — is fundamentally mismatched with the properties of modern AI systems.

AI-generated code is probabilistic, not deterministic. Traditional QA processes were designed to validate deterministic human output.

AI operates at asynchronous, non-human speed. Traditional review gates were paced around human throughput.

AI produces high volumes of output that require high-trust validation, not high-volume manual review.

These mismatches aren't incidental friction. They're structural incompatibilities. Patching them with more AI tools in a SDLC wrapper is like upgrading the engine without touching the transmission.

What's emerging as a response is a structural evolution in how engineering pipelines are designed from first principles — not an incremental improvement to the SDLC, but a new architectural model built around AI as the execution engine with humans governing the outputs.

The industry is beginning to call this the AI-Driven Software Development Life Cycle — the ADLC.

In the next post, I'm going to get into the concrete architecture of how these pipelines actually work internally: the multi-agent sandbox, the closed-loop eval framework, and what each phase looks like when you rebuild the pipeline from scratch with AI as the assumed primary actor.

References

This post was drafted with Claude's help to articulate my thinking — the ideas, technical observations, and opinions are entirely my own.

Want to continue the conversation? Find me on LinkedIn.

Top comments (0)