AI has changed where the bottleneck is in software development. The practices we built around slow code-writing don't all survive that shift. Here's what still holds up and what to rethink.
I’ve worked with a lot of development teams over the years — as a developer, a lead, a product owner. Most of them were “agile” in some form. Scrum, Kanban, or something that started as Scrum and gradually adapted to reality. And for the most part, it worked.
But lately, something feels a bit off.
Not because Agile is wrong. Because the way many teams practice it doesn’t really match how we build software anymore — especially now that AI is part of the picture.
The core still holds up
Some of the ideas behind Agile are genuinely solid and haven’t aged at all.
Building in small increments. Showing progress frequently. Staying close to real user needs. Adjusting as you learn. If anything, these matter more now than they did before.
But some things feel outdated
Where it starts to break down is in how Agile gets implemented in practice.
Take sprint planning. I’ve sat through a lot of those sessions — two hours breaking work down, estimating tasks, debating edge cases. Then halfway through the sprint, things change anyway. That used to make sense when writing code was the slow part. It makes less sense when you can go from idea to working prototype in a few hours.
The same goes for detailed task breakdown. We used to spend significant time splitting work into very small pieces. Now you can often just describe what you want and get surprisingly far with AI before you’ve even finished writing the subtasks. Planning still matters — but the level of detail often doesn’t.
Velocity is another one. It was never a perfect metric, but at least it gave some signal. Now one developer with the right setup can suddenly do several times more than before. That makes velocity hard to interpret in any meaningful way.
And the ceremonies. Stand-ups, retros, reviews — they can all be useful. But I’ve also seen plenty of teams running them purely because the framework says to. That’s usually a sign something needs to change.
What AI is actually changing
The biggest shift isn’t really about speed, even though that’s what gets talked about most.
It’s about where the bottleneck is.
It used to be writing code. Now it’s much more about figuring out what actually makes sense to build — and whether it solves a real problem. You can build things very quickly now, which also means you can build the wrong thing very quickly. The cost of a bad decision has gone up, even as the cost of implementation has come down.
What I’d do differently
I wouldn’t throw Agile away. But I would simplify it and focus on what actually helps the team move forward.
Direction over detail. Instead of heavy sprint planning, I’d focus on the question: what are we trying to achieve this week, and what are the most important things to move? The rest can be worked out as you go.
Faster feedback loops. If something takes two weeks to show to a user or stakeholder, it’s probably too big. The real learning happens when you see how something works in practice — not in a planning session.
Stand-ups about problems, not status. What’s blocking us? Where do we need help? What did we learn yesterday that changes what we do today? That’s a useful stand-up. A round-the-table status update is not.
Ship when it’s ready. Fixed sprint boundaries made sense when releasing was expensive. Waiting for the calendar to say it’s time rarely adds value now.
Retros are still worth it — if done well. One question I’d add as a recurring prompt:
Where are we still working like AI doesn’t exist?
Or more directly: what did we spend time on this week that we probably shouldn’t be doing manually anymore? Keep asking that, and the way the team works will gradually change on its own.
This isn’t about replacing Agile
Agile isn’t going away. But we need to stop treating frameworks like Scrum as something fixed. They were always meant to be adapted.
Right now, the way we build software is changing quite a lot. Ignoring that and continuing exactly as before doesn’t make much sense.
You can move faster than ever. But speed only helps if you’re moving in roughly the right direction.
So if I had to boil it down: spend less time planning tasks, more time understanding problems. Build quickly, see what happens, adjust. That’s still Agile — just without some of the parts that no longer pull their weight.