Everyone says Scrum is dead in the AI era.
I think they’re wrong.
Not because AI made process more important.
Because AI made direction more valuable.
I recently finished myCSPO®, and one idea has been sitting with me ever since:
Scrum was never really about managing people who type code. It was about helping teams solve complex product problems under uncertainty.
That matters a lot more now, not less.
Vibe Coding is obvious in its appeal.
Andrej Karpathy described it as a way of building where you “give in to the vibes,” barely touch the keyboard, and prompt your way toward something working.
That resonates because it captures what AI changed:
The cost of execution collapsed. On tightly scoped tasks, AI pair programming can produce real speed gains.
So, I understand why people abandon structure.
If you can go from idea to prototype in an afternoon, Scrum can look like ceremony cosplay. Why plan, estimate, or groom anything when the model can just build?
And for some contexts, that instinct is right.
Weekend projects. Internal demos. Rough concept validation. 0 → 1 exploration.
@karpathy himself framed Vibe Coding as fine for throwaway projects. In those moments, speedis the whole point.
But the argument weakens the second the software stops being disposable.
The moment real users show up, the conversation changes.
The moment another engineer has to maintain the system, the conversation changes.
The moment security, dependencies, pricing logic, analytics, compliance, or cross-team coordination enters the picture, the conversation really changes.
That’s where the current data gets interesting. AI adoption is high, but trust is not.
More developers distrust AI’s accuracy than trust it.
Professional developers rate AI weakly on complex tasks. And most still don’t want AI doing project planning for them.
That’s the real debate.
Not AIversus Scrum.
Speed versus structure. Intuition versus shared context. Momentum versus coherence.
Vibe Codingoptimizes for motion.
Scrum optimizes for clarity.
And when execution gets cheaper, clarity becomes the scarce resource.
At its best, Scrum is a thinking system.
What CSPO® helped me relearn is that Scrum is badly misunderstood when it’s reduced to meetings and rituals.
Product vision forces the question Vibe Coding often skips: what are we actually trying to change for the user?
A roadmap translates that vision into sequence. It reminds you that not everything valuable is valuable now.
The backlog turns ambition into an ordered set of choices. Not scattered prompts. Not random ideas. Not whatever the model happens to make easy today.
And relative estimation is more useful than I used to think. Not because story points are magical, but because they stop teams from pretending uncertain work can be forecast to the hour.
Good relative estimation is really a conversation about complexity, risk, and effort.
Then come the iterations.
Sprints are not there to slow you down. They’re there to create an inspectable rhythm.
Build something. Review what happened. Adapt. Repeat.
That rhythm matters more in the AI era because you can now produce more output than your product judgment can realistically absorb.
Scrum gives that output a cadence, a container, and a quality bar.
This is why I don’t think Scrum lost relevance.
I think its job changed.
Before AI, Scrum helped teams ship.
With AI, Scrum helps teams decide what is worth shipping.
That distinction is everything.
AI is an accelerator.
DORA’s 2025 research says AI mainly amplifies whatever system already exists underneath it. I keep coming back to that idea because it explains why AI feels magical in some teams and chaotic in others.
But an accelerator is only useful if you know where you’re going.
That’s where the moat appears.
A team using AI without product discipline can generate more code than ever.
A team using AI with strong product vision, an honest roadmap, a living backlog, relative estimation, and tight sprint learning loops can generate more value than ever.
Those are not the same thing.
The first team moves fast.
The second team compounds.
Closing
To be fair, I’m not arguing every builder should wrap every experiment in full Scrum mechanics.
Some work benefits from looser systems. Some discovery work should stay messy. Some prototypes should absolutely be built on instinct.
But even the recent academic work on Vibe Coding lands in a familiar place: it highlights accessibility and rapid flow, while also finding a clear speed quality tradeoff, widespread skipped QA, and persistent reliability and maintainability concerns.
So my working takeaway is simple:
- Use AI to compress execution time, not to outsource product judgment.
- Keep one clear product vision and one living backlog, even if the team is small.
- Estimate comparatively when uncertainty is high; cheap output makes bad prioritization more expensive.
- Treat each sprint as a learning loop, not a theater performance.
- Let Vibe Coding win the prototype. Let Scrumwin the product.
I’m still not convinced the debate is settled.
Maybe agentic tooling will absorb more of product development than we expect. Maybe tomorrow’s best teams will use something lighter than Scrum. Maybe the strongest builders will look less like software teams and more like creative directors of autonomous systems.
But right now, the teams that seem most dangerous to me are not the ones choosing between vibes and structure.
They’re the ones learning how to use both.
If this challenged one of your assumptions, that’s probably the point.
TL;DR:AI and Vibe Coding dramatically lowers the cost of building software, making speed abundant but direction more critical.
Scrum’s real value isn’t ceremonies, it’s providing shared clarity through vision, prioritization, and continuous learning loops.
Vibe Coding works best for fast, disposable exploration, but as soon as software must scale, be maintained, and serve real users, structure becomes necessary.
The advantage today isn’t choosing between speed and structure. It’s combining AI driven execution with Scrum driven judgment to build what actually matters.
I write about AI, product thinking, and how to balance speed with direction based on what I’m actually learning building with AI.
Follow @chaosengineerr for more.
