AI is splitting developers in two. The tool isn't the difference.
Same AI tools, same speedup. One group runs out of tickets, the other runs out of hours. The gap is what you do with the time you get back.
“If AI made my team twice as fast, why doesn’t it feel like we’re getting twice as much done?”
The short answer
AI gives every developer time back. Whether that becomes value depends on what they do with it: close the backlog and wait for the next ticket, or point the time at work that used to be out of reach.
I saw a post this week arguing that AI is creating two kinds of developers, and it matches what I see with the teams I work with.
The first group finishes Jira tickets faster than ever. Work that took a week takes a day. Tech debt shrinks, bugs get fixed, and suddenly there’s slack in the sprint.
The second group has never been busier. They’re building things they wouldn’t have tried a year ago, starting projects that used to need a whole team, and testing ideas that weren’t worth the effort before. Every time AI makes something easier, they find three more things to build.
Same tools. Same speedup. One group is running out of work and the other is running out of hours.
Speed is the commodity now
Every developer on your team has access to roughly the same models and the same coding agents. Faster typing, faster scaffolding, faster debugging: that advantage gets handed to everyone at once, which means it stops being an advantage.
What doesn’t get handed out is judgment about what’s worth building. That’s where the two groups split.
The first group isn’t doing anything wrong
I want to be fair here. Clearing tech debt and closing bugs is real value. A team that finally pays down the backlog it’s ignored for two years is in better shape than it was.
The problem is that the backlog is finite, and it was written for a world where engineering hours were scarce. When the backlog is the only definition of work, getting faster just means you reach the end of it sooner. Then what?
If the honest answer is “wait for product to write more tickets,” you haven’t gained capacity. You’ve created idle time, and idle time on an engineering team doesn’t stay idle for long. It turns into polishing, gold-plating, or headcount questions from finance.
The second group changed the question
The developers who are busier than ever didn’t just get faster at the same job. They stopped asking “how fast can I close this?” and started asking “what can I build now that I couldn’t before?”
That looks like:
- The internal tool everyone wanted but nobody could justify a sprint for.
- The prototype that answers a product question in two days instead of a quarter of debate.
- The migration, test harness, or observability work that was always “next year.”
- The side bet that might turn into a product line.
Their backlog isn’t a list someone handed them. It’s a list of opportunities that used to be too expensive, and that list keeps growing.
This is a leadership problem, not a developer problem
It’s tempting to sort people into “the ambitious ones” and “the ticket closers.” I don’t think that’s the useful frame. Most developers in the first group are doing exactly what the system asks of them. If the system measures tickets closed, you’ll get tickets closed, just faster.
If you lead an engineering team, a few questions are worth asking this quarter:
- Where is the reclaimed time going? If you can’t answer that, it’s going nowhere in particular.
- Who decides what gets built with the extra capacity? If it’s only the existing roadmap, you’re under-using it.
- Is there room to propose work, not just receive it? The second group usually has permission, explicit or not, to bring ideas forward.
- Are you measuring outcomes or throughput? Tickets per sprint looks great right up until the backlog is empty.
What I’d do
Treat AI capacity like a budget, not a bonus. Decide on purpose how it gets spent: some on debt and reliability, some on the roadmap, and some on things that weren’t possible before. Give developers a real channel to pitch that third bucket, and give it a small, time-boxed home so it doesn’t depend on someone working nights.
The tools are going to keep getting better for everyone. The teams that pull ahead won’t be the ones that code fastest. They’ll be the ones that decided what to do with the time.
What have you seen on your teams? Which group is growing?