I wrote recently about how AI exposed the process debt teams have been ignoring. The short version: code got cheap, and suddenly the bottleneck is scoping, estimation, and communication. All the human skills that teams treated as optional for years.
But there’s a second-order effect I didn’t get into. It’s not just that process matters more now. It’s that the unit of work itself is changing shape.
When rewriting is cheaper than refining#
Agile’s core promise is small, incremental slices. Build a little, ship a little, learn, adjust. That model assumes writing code is expensive. The assumption drives everything: small stories, thin vertical slices, iterative enhancement over multiple sprints. You build the minimum, get feedback, and layer on improvements because starting over would be wasteful.
But what happens when starting over takes ten minutes?
With AI-assisted development, generating a complete feature implementation is fast and cheap. If you get the approach wrong, you don’t carefully refactor your way to a better design. You throw it away and regenerate with a better prompt. The cost of a wrong decision dropped from “days of rework” to “another conversation with your AI agent.”
This changes the shape of how work actually gets done. Instead of building a feature in five thin slices across five sprints, you write the whole thing in one pass. Then you iterate on that complete implementation, adjusting the design, reworking the approach, regenerating entire components when they don’t fit. It’s not waterfall in the traditional sense, because you’re still iterating and responding to feedback. But it’s not the classic Agile slice-and-dice either.
I’ve been calling it “Agile Waterfall” in my head, and the name keeps fitting.
What Agile Waterfall looks like in practice#
Let’s say you’re building a new notification preferences system. In traditional Agile, you’d break that into stories: “user can toggle email notifications,” “user can set quiet hours,” “user can choose notification channels per event type.” Each one ships independently. Each one gets its own review cycle.
With AI, the natural workflow looks different. You describe the entire notification preferences system to your agent. It generates the data model, the UI, the API endpoints, and the test suite in one shot. Maybe that first pass gets the data model wrong, or the UX doesn’t feel right. So you iterate on the whole feature. You might regenerate the entire backend with a different schema. You might throw away the UI and start fresh with a different component library. Each iteration is a complete, working implementation.
The feedback loop is still there. You’re still learning and adjusting. But the unit of iteration isn’t a thin slice of functionality. It’s the entire feature.
The production boundary#
Here’s where this falls apart: code that’s already running in production.
You can’t throw away and regenerate a feature that has users, data, and integrations depending on it. Production code comes with migration paths, backward compatibility requirements, and the accumulated weight of real usage patterns. An AI agent can regenerate your notification preferences system from scratch, but it can’t magically migrate 50,000 users’ existing preference records to a new schema without careful, incremental work.
This is where traditional Agile still earns its keep. Refactoring production systems, evolving existing APIs, migrating data: these are inherently incremental problems. You can’t “regenerate” your way out of a schema migration. You need small, safe, reversible changes deployed one at a time with rollback plans.
So the picture isn’t “Agile is dead.” It’s more nuanced than that. For greenfield work and new features, AI pushes teams toward larger, more complete iterations. For production systems, the incremental discipline of Agile is still the safest approach. Most teams are doing both simultaneously, which means the process needs to flex.
The ticket size problem#
This shift creates a practical tension that engineering leaders need to think about now. If AI makes it natural to work on entire features in one pass, then the traditional advice of “break your tickets down into the smallest possible unit of work” starts to fight the grain.
I’ve seen this already on teams using AI heavily. Engineers pick up a well-decomposed set of tickets and end up implementing three or four of them in a single AI session because the agent doesn’t think in thin slices. It generates the whole thing. The engineer then spends more time figuring out which parts to commit against which ticket than they spent on the actual implementation.
That’s process serving itself instead of serving the team.
The likely correction is larger tickets that describe complete features or capabilities, with iteration happening within the ticket rather than across a series of tiny ones. The definition of “done” doesn’t change. The size of what gets done in one pass does.
What I think happens next#
I don’t think Agile goes away. The principles of iterating based on feedback, delivering working software frequently, and responding to change are timeless. Those ideas predate the Agile Manifesto and they’ll outlast whatever comes next.
But I do think the specific practices built on top of those principles are going to shift. Story pointing, sprint planning, and task decomposition were all calibrated for a world where writing code was the bottleneck. That’s no longer true for a growing share of development work. The bottleneck is moving to design decisions, integration testing, and production operations.
My bet: we’ll see best practices adapt. Teams that lean into AI will naturally gravitate toward larger units of work per ticket, fewer but more complete iterations, and more emphasis on the parts that AI can’t shortcut (production migrations, system integration, user feedback loops). The Agile Manifesto’s values survive. The specific rituals and ticket structures that grew up around those values? Those are going to look very different in two years.
If I’m being honest about what I wish would happen, it looks a lot like what 37signals described in Shape Up. Fixed time appetites instead of open-ended sprints. Shaped work that defines the boundaries of a problem without prescribing the implementation. Teams that own the entire scope and make their own tradeoffs within the appetite. That model already aligns with how AI-assisted work naturally flows: here’s the shaped problem, here’s the time box, go build the whole thing and iterate until it fits. Whether the industry actually moves in that direction or just bolts AI onto existing Scrum ceremonies is an open question. I know which outcome I’m betting on, but I’ll admit it might be more wish than prediction.
The teams that figure this out first will ship faster. The teams that force AI-assisted work into 2015-era Scrum processes will wonder why their velocity metrics look great but their engineers feel like they’re fighting the process instead of using it.