A few months ago, I sat in on a retrospective with a development team at a mid-sized financial services company. They had adopted AI coding assistants six months earlier. The mood was… complicated.

On one hand, individual developers were writing code faster than ever. On the other, the team’s sprint velocity metric had become meaningless. Some stories that used to take days were done in hours. Others, the ones that required architectural judgment, integration thinking, or compliance alignment, still took just as long. Story points had lost their calibration. Sprint planning felt like theater. The Scrum Master, half-joking, asked: “Are we still doing this because it works, or because we don’t know what else to do?”

That question has been echoing in my head ever since.

Because the honest answer, for most enterprise teams I work with, is the latter. We’re running AI through processes designed for a world where AI didn’t exist. And the cracks are showing everywhere.

The Faster Horse Problem

In previous posts, I’ve written about the mismatch between AI code assistants and enterprise software development and about the governance gap that causes enterprise AI initiatives to fail at scale. Both posts diagnosed the same underlying tension: organizations are bolting AI onto processes that were never designed for it.

But I want to go further now. The problem isn’t just governance or alignment. The problem is the process itself.

Scrum, Kanban, SAFe: these frameworks were designed for human-only teams working in week-long or month-long cycles. They assumed that planning takes time, that estimation is necessary because execution is unpredictable, and that handoffs between roles are inevitable. Daily standups exist because coordination is hard. Retrospectives exist because feedback loops are slow. Story points exist because the gap between simple and complex tasks is wide enough to matter.

AI collapses all of those assumptions. When AI can decompose and elaborate requirements in minutes, planning no longer needs a dedicated ceremony. When it generates code, tests, and infrastructure in hours, the gap between a simple task and a complex one narrows to the point where story points lose their calibration. When AI maintains context across the full stack, handoffs between specialized roles become friction rather than necessity. And when feedback can be generated continuously through AI-driven validation, waiting for a retrospective to surface what went wrong is just waiting.

When AI can decompose requirements, generate domain models, produce code, and create tests, all in a matter of hours, what happens to a two-week sprint? When the boundary between a “3-point story” and an “8-point story” blurs because AI handles the mechanical complexity, what does velocity even measure?

The answer most organizations have landed on is: keep the process, add AI as a tool. Retrofit.

I think that’s the wrong answer. It’s the faster horse.

Why Retrofitting Fails

I’ve seen the retrofitting pattern play out dozens of times. It usually follows a predictable arc.

Phase 1: Excitement. Teams adopt AI coding assistants. Individual output spikes. Everyone celebrates.

Phase 2: Friction. The existing process can’t absorb the speed. Code reviews become bottlenecks. Sprint ceremonies feel disconnected from reality. Quality gates designed for human-paced delivery can’t keep up.

Phase 3: Workarounds. Teams start bending the process. Some skip reviews. Others inflate story points to make velocity look stable. Shadow AI usage spreads; developers use tools that aren’t sanctioned because the official process is too slow.

Phase 4: Disillusionment. Leadership sees inconsistent results. Quality issues surface. Governance teams raise alarms. The organization either pulls back on AI adoption or doubles down on controls that slow everything further.

The root cause isn’t the AI. It’s the container we’re trying to pour it into.

Traditional SDLC methods were built around a fundamental constraint: human cognitive bandwidth. Planning ceremonies, estimation rituals, role specializations: all of these exist because humans can only hold so much context, process so much information, and coordinate across so many boundaries at once.

AI doesn’t have those constraints. But when we force AI into a process designed around them, we get the worst of both worlds: the overhead of human-era ceremonies with none of the benefits of AI-era speed.

What Reimagining Looks Like

If we accept that retrofitting is a dead end, the question becomes: what would a development lifecycle look like if we designed it from scratch for the AI era?

I’ve been working with and studying a methodology called the AI-Driven Development Lifecycle (AI-DLC), and its core thesis resonates deeply with what I’ve observed in the field. Rather than patching existing frameworks, AI-DLC starts from first principles and asks: given what AI can do today, what is the minimum viable process that maintains quality, governance, and human oversight while maximizing flow?

The central shift is this: AI-DLC moves the unit of coordination from time-boxed effort to intent-driven flow.

In traditional methods, everything orbits around the timebox. A two-week sprint defines when you plan, what you commit to, and how you measure progress. The timebox is the heartbeat. But when AI compresses execution from weeks to hours, that heartbeat becomes a constraint, not a cadence. You end up waiting for the sprint to end so you can start the next thing, or cramming AI-generated output into ceremonies designed for a slower pace.

AI-DLC organizes work differently. It starts with Intents, high-level statements of purpose that capture what needs to be achieved, whether it’s a business goal, a feature, or a technical outcome. AI decomposes those Intents into Units: cohesive, self-contained work elements designed to deliver measurable value independently. And Units are executed through Bolts, rapid, intense iteration cycles measured in hours or days, not weeks.

The difference isn’t just vocabulary. It’s a fundamentally different organizing principle. Work doesn’t flow because a timebox started. Work flows because an intent exists, AI has decomposed it into actionable pieces, and the team validates and steers as those pieces move through design, implementation, and testing continuously, not in batches.

This changes where human energy goes. Instead of spending hours in planning meetings debating story sizes and sprint capacity, teams focus on what actually matters: Is the decomposition right? Are the boundaries between Units clean? Is the business intent preserved? Are quality and compliance criteria met?

Why Estimation Loses Its Purpose

Perhaps the most provocative implication of intent-driven flow: traditional estimation becomes largely irrelevant.

Story points exist because the gap between tasks of different complexity is significant enough to affect planning. But when AI handles the mechanical complexity (generating code, writing tests, creating infrastructure) the remaining human work is primarily judgment: reviewing, validating, deciding. AI can generate ten implementations in the time it used to take to write one, but a developer can’t evaluate ten architectural trade-offs ten times faster. The bottleneck shifts from production to judgment, and that shift is what makes effort-based estimation meaningless.

AI-DLC doesn’t eliminate measurement. It shifts the focus from effort estimation to value validation. Instead of asking “How many points is this story?”, teams ask “Does this Unit deliver the intended business value? Does it meet quality and compliance criteria?”

That’s a fundamentally different, and more useful, question.

The Human Role Doesn’t Shrink. It Sharpens.

One concern I hear frequently: “If AI is doing the planning, decomposition, and coding, what’s left for developers?”

Everything that matters.

AI-DLC is built on a principle I find compelling: reverse the conversation direction. Instead of humans initiating tasks and AI assisting, AI proposes plans, generates artifacts, and recommends approaches. Humans validate, correct, and decide.

Think of it like navigation software. You set the destination. The system proposes the route, warns about traffic, suggests alternatives. But you’re still driving. You still decide whether to take the highway or the scenic road. You still pull over when something doesn’t feel right.

In AI-DLC, developers become system thinkers, domain experts, and quality gatekeepers. They focus on the questions AI can’t answer: Does this design align with our business reality? Does this architecture handle the edge cases our customers actually encounter? Does this approach comply with our regulatory obligations?

As I wrote in Bridging Strategy and Execution in Tech Leadership, the most valuable skill in technology leadership is translating between vision and reality. AI-DLC makes that skill the center of the developer’s role, not a side activity.

Familiarity as a Bridge, Not a Cage

One thing I appreciate about the AI-DLC approach is that it doesn’t demand a complete break from everything teams know. It preserves familiar concepts (user stories, acceptance criteria, risk registers) because these artifacts serve a genuine purpose: they align human and AI understanding of what needs to be built.

What changes is the cadence, the flow, and the division of labor.

User stories still exist, but they’re elaborated collaboratively with AI in hours, not refined over multiple sprint planning sessions. Design still happens, but AI generates the initial domain models and developers validate them rather than building from scratch. Testing still matters, but AI generates and executes test suites while humans focus on scenario coverage and edge case thinking.

The terminology shifts intentionally (Bolts instead of Sprints, Intents instead of Epics) not to be different for its own sake, but to signal that the underlying dynamics have changed. When you call something a Sprint, teams unconsciously import all the assumptions that come with it: two-week timebox, planning poker, velocity tracking. Renaming breaks that mental model and creates space for new habits.

The Real Risk: Doing Nothing

Some leaders I talk to acknowledge the mismatch but hesitate to act. “Our current process works well enough,” they say. “We’ll adapt when we need to.”

I understand the caution. But I’ve seen what “well enough” looks like in practice: teams where AI adoption is fragmented, where governance is reactive, where the gap between what AI enables and what the process allows grows wider every quarter.

And here’s what makes this different from previous technology shifts: AI acceleration is not a cycle that will stabilize. Model capabilities are compounding. What feels experimental today will feel primitive in eighteen months. The organizations waiting for AI to “settle down” before redesigning their processes are designing for a moment that has already passed. Static thinking about a dynamic capability is itself a form of technical debt.

The organizations that will thrive in the AI era aren’t the ones with the best AI tools. They’re the ones that redesign their processes to match what those tools make possible, and keep redesigning as capabilities evolve. New platforms are already emerging to provide observability and governance specifically for AI-agent-generated code, categories that didn’t exist a year ago. Just as Agile didn’t succeed because it had better project management software (it succeeded because it reimagined how teams work) the next leap requires reimagining the development lifecycle itself.

Retrofitting is comfortable. It’s incremental. It doesn’t require anyone to rethink their role or their rituals.

But comfort is not a strategy.

Where to Start

If you’re a CTO, VP of Engineering, or technical leader reading this, you don’t need to overhaul everything tomorrow. But you do need to start asking different questions:

• For every ceremony your team runs, can you articulate the constraint it solves in an AI-accelerated environment? If sprint planning feels like overhead rather than alignment, that’s a signal.
• Are your metrics still meaningful? If velocity has become a vanity number that doesn’t correlate with business value, it’s time to rethink what you measure.
• Where is human judgment most valuable? Identify the decisions that only humans can make (architectural trade-offs, compliance alignment, business prioritization) and design your process around those moments.
• Can you run a pilot? Pick a small, greenfield project. Try working in rapid cycles with AI-driven decomposition and human validation. Measure cycle time, quality, and team satisfaction. Compare it honestly against your current approach.

The goal isn’t to adopt a specific methodology overnight. The goal is to stop assuming that processes designed for a pre-AI world will carry you through the AI era without fundamental change.

The Automobile, Not the Faster Horse

There’s a quote often attributed to Henry Ford: “If I had asked people what they wanted, they would have said faster horses.”

Whether Ford actually said it doesn’t matter. The insight does.

When we take Scrum and add AI coding assistants, we’re building a faster horse. It looks impressive. It moves quicker. But it’s still constrained by the same fundamental architecture: the same ceremonies, the same roles, the same assumptions about how work flows from idea to production.

The automobile wasn’t a better horse. It was a different paradigm built on different principles for a different era.

AI is not asking for a faster sprint. It is demanding a new machine entirely.

The organizations that recognize this early, that have the courage to reimagine rather than retrofit, will define the next era of software engineering.

The rest will be left wondering why their faster horses can’t keep up.

Ricardo