The backlog is finally getting its moment

I’ve been having the same conversation with many engineering leaders lately: how has AI actually changed the shape of day-to-day work on your team? Despite everyone working at different companies, the themes are nearly the same for AI-forward companies. PR counts are climbing, but the review queues behind them haven't caught up at the same pace. Agents can draft a plan or open a PR in minutes, but someone still has to decide if the plan is good. (Please.) Moving faster doesn't help if the system around the work can't keep up.

PR review time is solvable, and most teams are already working on it. But the bottleneck we're not naming yet is what happens once more work becomes possible to do.

I want to be clear about what I don't mean by this. I haven't personally seen a team reach some magical "nothing left to do" state, and I doubt most teams ever will. There's always more work, more bugs, more customer requests, and more systems quietly held together by a few engineers who know which parts not to touch. Incident rates may not even be climbing. What’s changed is that AI is now writing more of the code, helping review parts of it, and sometimes diagnosing the regression that caused the incident in the first place.

If anything, agentic building can create more follow-on work. Moving faster usually means more code today and a bigger pile of decisions to revisit later, especially in greenfield spaces. So no, I'm not arguing AI is going to wipe out every team's backlog and leave engineers wandering around Slack asking for purpose. We should all be so lucky.

What's actually changing is the shape of engineering capacity, not the size of the backlog. The old model was usually one engineer, one ticket, one thread of work at a time. That's an oversimplification, but it's roughly how we planned: capacity measured in hours or days, one task in flight at a time. An engineer picked up a ticket, built the thing, tested it, opened the PR, and waited on review before moving to the next one.

_{A thank you from this week’s sponsor:}

Wispr Flow turns your voice into clean, professional text you can send the moment you stop talking. Not rough transcription you have to clean up. Actual polished text — ready for email, Slack, or any app.

Speak the way you think. Go on tangents. Change your mind mid-sentence. Flow strips the filler, fixes the grammar, and gives you text that reads like you spent five minutes writing it.

89% of messages sent with zero edits. Millions of professionals use Flow daily, including teams at OpenAI, Vercel, and Clay. Works on Mac, Windows, and iPhone.

Start flowing free

The newer pattern in an AI-forward engineering team looks a little different. An engineer might still have one larger piece of work that requires real human judgment: breaking down the problem, making tradeoffs, coordinating with product and design, understanding the system, and deciding where the sharp edges are. This typically involves a lot of back-and-forth with an agent, but it doesn't require 100% of an engineer's attention at every moment.

Alongside that larger piece of work, they may also have a few smaller pieces of work moving through agents: a small bugfix, a package update, the service maturity work I never stop speaking about to my EMs and Tech DRIs. These are the types of tickets where an agent can go spelunking, propose a solution, and attempt to fix it without much human intervention until review.

This doesn't mean the engineer is solving five gnarly problems at once. It means work that used to require enough attention and setup to not feel worth picking up can now be mostly agent-driven and human-reviewed. There's still context-switching, but it's cheaper than it used to be.

Engineering backlogs tend to have a weird middle layer of work. It isn't useless, but it's rarely urgent. It's not a big roadmap item. Sometimes it's follow-on work from a previous bet that didn't make the cut for an MVP. Sometimes it's a bug that's annoying, but not annoying enough. Sometimes it's cleanup everyone agrees would be nice to do, right before they move on to the thing that actually made the roadmap.

So it sits. And 3-6 months later, or 12+ months if we're being honest, someone opens the ticket and has to ask whether the problem still exists.

Historically, this work was expensive to pick up. It took context, setup, time to actually test the fix, enough of all three that it became a decent onboarding task for a new engineer. It's not something an experienced engineer would grab in the middle of higher-priority work.

None of this means the work suddenly got more important. It just got cheaper to move forward. The cost dropped from "needs a dedicated block of focus" to "needs someone to review what an agent put together."

This changes how leaders need to plan. It also puts new responsibility on PMs and EMs specifically.

PMs have a real advantage here. They're closer to the customer pain and the support queue than anyone else on the team. They should have a strong point of view on which papercuts are worth pulling forward, the ones that show up again and again in support, the "small" issues that keep generating outsized frustration because customers keep hitting the same wall.

A lot of those things used to lose in prioritization because they were too small to become roadmap work and too distracting to pull engineers away from bigger projects. They were typically relegated to a "customer love week" at best once a quarter. Some of that work is now cheap enough to revisit, but only if it's shaped ahead of time.

Teams need a ready queue, not just a backlog: current, scoped work that's small enough for agents to help with and valuable enough for humans to review. The EM's charter is the engineering counterpart to the PM's, and it needs to be just as loud about which engineering-side opportunities just became realistic now that execution is cheaper. Take tech debt that's been sitting around because it was annoying, not impossible. Package upgrades that touch dozens of files across repos are the clearest example: miserable to do by hand, much easier to hand to an agent now.

Quality-of-life work that used to be too annoying to justify finally has a practical path forward. EMs should be building a bench of well-shaped work, ready to go, in a range of sizes. Teams still need the big bets and the product strategy. That's not going away. But alongside that, they need a clearer view of the smaller work that's worth doing now that the cost has changed.

A mixed ready queue might look something like this:

This matters because the pressure to move faster is already real, whether it's coming from leadership, from the team itself, or just from watching what the tools can do now. Engineers aren't going to run out of work. What they might run out of is a clear sense of what's actually worth doing next.

That's where momentum gets wasted. Once a team has it, stopping is expensive, harder to recover from than it was to build in the first place. A gap between finishing one piece of work and starting the next can look small on paper, but it feels much larger in practice when the team has to stop, reorient, revalidate old tickets, and decide what still matters.

This is one of the places where EMs and PMs need to meet in the middle. The PM should be asking what customer problems are newly worth solving, the EM should be asking what engineering problems are newly worth addressing, and together they should be asking what they're still going to deliberately ignore, because cheaper work isn't automatically better work. Some of it should just get deleted, not revisited.

I expect this topic to be an ongoing conversation. We're still learning where AI is taking engineering output, but it's safe to say that output will continue to increase. This is a conversation worth having now, before the backlog fills back up with things nobody decided were actually worth doing.