AI Killed the Backlog
What's left is the work everyone has been avoiding.
Here’s a test for any engineering leader reading this: Delete your backlog.
I’m serious. Delete the whole thing.
If something in there was actually important, you’ll hear about it again. Real bugs get reported again by the next person who hits them and real customer needs get raised again by the next person who has them.
The rest was junk you were never going to do anyway, no matter how many times you groomed it.
Most teams won’t try it. Everyone will be mad if we delete their half-baked idea from the list. It also looks like proof that the team is thinking ahead and that nothing is being forgotten. The future is queued up and ready.
The backlog mostly looks like job security.
But that’s the problem. The backlog was never an asset, it was a liability of all the crap we thought we had to do. It was a graveyard with a project management interface.
Then AI changed everything. Claude Code showed up and could clear the whole backlog in a weekend.
The Backlog Was Always the Junk Drawer
Walk through the average engineering team’s backlog and you’ll find a museum of things nobody is going to do. There’s a feature request from a customer who churned in 2023, a bug ticket nobody can reproduce, an “improvement” idea from a product manager who left the company, and a research spike that was supposed to inform a decision that ended up getting made six months ago without it.
Then there’s the engineering side of the junk drawer, which is its own ecosystem.
You’ll find the refactor someone proposed two years ago that everyone agreed was important, the library migration that keeps getting bumped because it’s not customer-facing, and the monitoring overhaul that’s been there long enough that nobody remembers what problem it was supposed to solve.
Engineers loved these tickets because they felt productive and serious without requiring anyone to sit in a room arguing with product about priorities. Product loved them right back, because keeping engineers busy meant nobody had to make a hard call about what actually mattered.
That was the whole point of the backlog. It was the place where decisions went to be deferred indefinitely.
The Real Reason Teams Hid in the Backlog
Strategic roadmaps are hard. They force executives to disagree with each other in the open, push product to tell engineering why something didn’t make the cut, and force engineering to push back when product is wrong. They require choosing winners and losers, naming what won’t get done, and standing behind the choice when your competitor ships the feature you decided not to do.
Backlog grooming requires none of that. A team can spend a 90-minute meeting refining estimates on tickets that will never ship and walk out feeling like they accomplished something. The whole exercise lets the team look busy and serious without anyone having to make the call about whether they’re building the right product in the first place.
That’s the path of least resistance for any team that doesn’t want to fight about priorities. It’s also the reason most engineering orgs feel busy and frustrated at the same time. Everyone is moving, but nobody can point to what mattered.
My favorite backlog grooming was always deleting the whole thing... until AI showed up.
AI Burned Down the Hiding Place
Claude Code can chew through a well-defined backlog at a pace that would have seemed absurd two years ago. Even the engineering wish list, the refactors and migrations and monitoring improvements, can be knocked out at speed when AI knows the codebase well enough.
Which means the activity of “working through the backlog” has lost its cover.
You can’t claim the team is heads-down on important work when the same work could be done by AI in a long weekend. You can’t justify a quarter on cleanup when cleanup is what AI is best at. Execution stopped being the constraint, which means execution stopped being a place anyone can hide.
For teams that are good at strategy, this is a gift. They get less wasted effort, more focus on outcomes, and more time on the conversations that actually move the business. For teams that have been deferring strategy for years, it’s terrifying. There’s nothing left to do except the thing they’ve been avoiding.
The New Problem Nobody Is Ready For
This is where I want to be honest. Killing the backlog is the easy part of the story. The harder part is what comes after.
When a team is producing two or five times the volume of code, review becomes the bottleneck. PRs pile up faster than humans can read them. Most of the code looks fine on the surface, but somewhere in the diff is a subtle bug, a wrong abstraction, or a solution that solves the problem you described instead of the problem the user actually has. You can’t tell which PRs have those issues without careful review, and careful review at AI speed is exhausting.
The shape of engineering work shifts too. Engineers who used to write code now spend their days editing code that AI wrote, which is a different muscle, and most engineers were never trained for it. Senior engineers who used to mentor junior engineers through code reviews are now reviewing the AI’s code while the junior engineer waits to be told whether to accept it. Junior engineers themselves are stuck in a strange limbo where they’re supposed to be learning the craft, but the craft is increasingly being done before they touch it.
Then there’s the architectural challenge that everyone is trying to figure out. AI is great at building what you asked for. It’s not great at maintaining the conventions of your codebase, the principles your team has agreed on, or the long-term shape of the system. If your review process isn’t catching those things, your codebase is getting messier in ways that won’t show up for a year, and by then the cleanup will be enormous.
Most teams are not set up for any of this.
They cleared their backlog and high-fived. They didn’t notice that the work they had been doing was the easy part of engineering, and the work they’re left with is the part they were never very good at.
Product Thinking Is the Whole Job Now
The Product Driven thesis is that engineers who think like owners outperform engineers who wait for tickets, that engineering teams need vision, focus, clarity, ownership, and courage more than they need process, and that the bottleneck in most software orgs has never been technical skill. It’s been product thinking.
This is the thing I think about constantly at Full Scale. The engineers our customers value most aren’t the fastest builders. They’re the ones who can sit in a planning meeting and ask whether the team is solving the right problem. That skill was always valuable. Now it’s the price of entry.
For most of the last decade, you could ignore that argument. You could keep your team busy on tickets, ship features that didn’t matter, and call it engineering. The backlog gave you cover for not doing the hard work of figuring out what to build.
That cover is gone. AI handles the ticket work. The only thing left for engineering teams to do is the work that AI can’t do, the work that requires judgment, taste, customer empathy, and the willingness to say “we shouldn’t build this.” Which is to say, the work that’s left is exactly the argument of Product Driven.
The teams that build that muscle right now are going to win the next decade. The teams that don’t will look back in a year wondering why their AI-cleared backlog produced nothing of value, while a smaller team somewhere else used the same tools to build something customers actually wanted.
The Backlog Was a Treaty
The backlog was a peace treaty between product and engineering. Both sides agreed not to have the hard conversations as long as everyone stayed busy. That treaty is over now.
Now the only work left is the work everyone has been avoiding.
The hard conversations are the only ones left.
P.S. You can grab a free copy of Product Driven. The whole book is about how to build engineering teams that can have the hard conversations.