The SDLC Is Dead. Long Live the SDLC.
June 10, 2026 10 min read 112 views
AI-native engineering is where everything is heading. The mistake leaders are making is assuming they can get there in a single jump.
I was in a meeting last quarter when a director asked a question that quietly changed the temperature of the room.
“If AI can write code, why is our backlog still 18 months long?”
Nobody answered straight away. Not because the people in the room were unprepared — they were some of the sharpest engineering leaders I’ve worked with — but because everyone understood the question was fair. And in twenty-five years of building and delivering software, I’ve learned to pay attention to the questions that produce silence rather than answers. They’re usually pointing at something structural.
So let me say where I stand before I complicate it, because I don’t want to be mistaken for a skeptic. AI-native engineering is the destination. I have no doubt about that. The organizations that redesign how they build software around AI will, within this decade, operate at a level the rest simply won’t be able to match. This isn’t a passing wave of tooling enthusiasm. It’s a genuine shift in the operating model, the same way cloud was, and the same way the web was before it.
But here’s the part the conference keynotes tend to skip: you cannot teleport to the destination. You have to build the road that gets you there. And most organizations right now are trying to do the former while neglecting the latter — which is exactly why their backlog is still 18 months long despite every developer having an AI assistant open in a second window.
I’ve Watched This Movie Before
Twenty-five years in this industry means I’ve now lived through several iterations of the same story. Client-server was going to change everything. Then the web. Then offshore delivery. Then Agile. Then cloud. Then mobile, microservices, and DevOps. Each one arrived wrapped in the same promise — this is the thing that transforms how we work — and each one produced the same split in the market.
A small group of organizations treated each shift as an operating-model change and rebuilt themselves around it. Everyone else bought the tools, kept their existing processes, and wondered a few years later why the promised transformation never quite arrived.
Cloud is the cleanest example. Plenty of enterprises bought the infrastructure, migrated their workloads, and declared victory — while still running waterfall governance, siloed teams, quarterly releases, and the same decision bottlenecks they’d always had. They modernized part of the stack without changing how the organization actually worked. The ones who understood
that cloud was an operating model rather than a destination built capabilities the laggards still can’t replicate today.
We are doing the same thing again with AI, and I’d argue we’re doing it faster and with more money behind the mistake.
Handing a developer Copilot or Claude and calling the organization “AI-native” is like giving someone a Formula 1 steering wheel and expecting them to win Le Mans. The wheel is real. The speed is real. But you haven’t touched the track, the pit crew, the race strategy, or the rules of entry. You’ve just made one part of the system faster and slightly more confusing.
What AI-Native Actually Means — and Why the Bottleneck Moves
Let me be precise about the term, because it’s thrown around far too loosely.
The traditional SDLC is, in most organizations, still a sequence of human handoffs. Product defines. Design interprets. Architecture decides. Engineering builds. QA validates. Operations deploys. Every handoff adds latency. Every handoff loses a little context. And the whole system moves at the speed of its slowest, most overloaded node.
AI-native isn’t about inserting an assistant into one or two of those steps. It’s about asking why the steps exist in that shape at all — and redesigning the lifecycle so that AI is woven into how work moves through the system, not bolted onto a single stage of it.
Here’s the consequence most leaders haven’t fully absorbed. When a clear requirement can become a working prototype in hours, the expensive question is no longer, “How do we build this?” It’s, “Are we building the right thing, on sound architectural foundations, in a way we’ll still be able to reason about in six months?” The bottleneck inverts. Product thinking, architectural discipline, and review culture stop being supporting functions. They become the core delivery mechanism.
And this is precisely where I’ve watched organizations get burned. I’ve seen teams visibly increase output with AI tooling and end up in a worse position a few months later. More code produced. More tickets closed. Velocity healthier on paper. But underneath, complexity compounds, consistency erodes, and technical debt accumulates faster than anyone was tracking. The team felt faster right up until it felt stuck.
Speed on its own was never the prize. Speed only compounds value when it’s paired with judgment. Without that, you’ve just built a faster way to make a mess.
Paving the Road: The Foundations Nobody Wants to Fund
This is the heart of what I want CXOs to take away, so I’ll be direct. AI-native is not a switch you flip. It’s a road you build, in roughly this order, and skipping ahead is how programs stall.
The road starts with legible systems. AI is only as useful as the context it can be given, and most enterprise systems have never been legible enough for a new participant — human or machine — to understand quickly. New engineers used to absorb that context over months, through proximity and conversation. AI needs it to be explicit. The architectural decisions, the data models, the undocumented constraints living in three senior people’s heads — that debt didn’t matter as much when the only newcomers were humans willing to spend a year learning. AI surfaces it immediately and expensively. So the unglamorous work of making systems comprehensible isn’t preparation for the AI-native journey. It is the first stretch of road.
The next stretch is workflow redesign over task automation. Most AI adoption today is additive — take an existing process, inject AI, measure the efficiency gain. That’s a reasonable place to start and a terrible place to stop. The real returns come from stepping back and asking the uncomfortable question: if we were designing this engineering organization today, knowing what AI can do, would we structure it the same way? The honest answer is usually no. And that answer implicates team boundaries, decision rights, and management layers that have calcified over years. That discomfort is the work, not a distraction from it.
Then comes the shift from individual productivity to collective intelligence. Today’s tools are built around the individual contributor — one person, one context window, one flow state. But software at scale is a team sport, dependent on shared context, architectural alignment, and review discipline across many people. This is why teams get a visible personal lift from AI and still struggle at the system level: they’re generating more output than the organization is structured to absorb coherently. The next stretch of road is team-level orchestration — shared standards, common context, and AI woven into the system rather than the individual keyboard.
And running alongside all of it: governance built into the workflow, not into a policy document. Here’s the uncomfortable truth for any leader who signed an AI policy and considered the matter closed — your policy is almost certainly not where your engineers actually are. If the approved path is clumsy and the unofficial one works better, shadow usage appears whether you sanction it or not. That’s not an indiscipline problem. It’s a governance design problem. Guardrails around data, code provenance, security, and auditability have to live in the day-to-day flow of work — invisible enough not to create friction, yet robust enough to actually protect you.
None of these stretches are optional, and the order matters. Try to build collective intelligence on top of illegible systems and you’ll automate confusion. Try to govern through policy alone and you’ll govern theatre. The road has a sequence for a reason.
The Talent Conversation We Keep Avoiding
There’s a human dimension here that I don’t think we’re discussing honestly enough, so I’ll be blunt about it.
The role of the software engineer is changing materially. Not disappearing — changing. The engineers who will thrive in an AI-native environment are not the ones who produce syntax fastest. They’re the ones who can hold a complete mental model of a system, make trade-off calls under genuine ambiguity, challenge a bad assumption before it ships, and take ownership of outcomes rather than outputs. Those capabilities are becoming more valuable, not less.
Which means a lot of organizations are now measuring the wrong things. If your performance culture still rewards lines of code, tickets closed, and PR throughput, you may be optimizing hard for exactly the skills AI is making abundant — while starving the ones becoming scarce. Judgment. Systems thinking. Architectural maturity. The discipline to ask the right question before reaching for the keyboard.
And most reskilling efforts are aimed too low. We’re teaching people to use the tools, which is fine but incomplete. The harder, more important work is helping engineers think more like architects, helping QA redefine what quality means when code is generated rather than deliberately authored, and helping engineering leadership rethink where the control points and feedback loops actually belong. That doesn’t happen spontaneously. Someone in the C-suite has to name it and fund the space for it.
Where This Leaves You
I’m not going to hand you a neat five-step framework, partly because the ground is still moving too fast for any framework to stay current, and partly because the honest truth is that all of us — including the organizations that look composed from the outside — are still figuring this out through trial and error.
But after twenty-five years of watching these transitions, I’m confident about the dividing line. The organizations that come out of this decade ahead won’t be the ones that bought the most tools first. They’ll be the ones that understood early that this is an organizational redesign story wearing a developer-productivity costume. They’ll be the ones who paved the road deliberately — legible systems, redesigned workflows, embedded governance, and the right definition of talent — instead of pouring AI onto an unchanged delivery model and hoping for a step-change that the structure was never built to deliver.
The SDLC as we’ve known it for thirty years is not surviving this decade intact. I don’t say that as a threat. I say it as someone genuinely optimistic about what comes next. AI-native engineering is real, it’s coming, and it’s worth building toward with conviction.
But it has to be built toward. The backlog won’t shrink because a tool writes code faster. It’ll shrink when the organization around that tool is finally structured to keep up with it.
That’s the road. The only real question is whether you start paving it now, or wait until your competitors have already reached the other end.
Your business results matter
Achieve them with minimized risk through our bespoke innovation capabilities. Fill in the form below.