AI Doesn’t Fix Queues
Why Coding Assistants Don’t Always Improve Organizational Performance
You’ve seen the headlines, read the articles in your leadership newsletter, and set aside some budget for the tools. You announce to your team that everyone has access to, and must use, GitHub Copilot (or OpenAI Codex, or Gemini Code Assist, or Claude Code, or insert-your-tool-of-choice-here). Productivity will grow exponentially. Features will ship in a fraction of the time. Parades will be held in your hometown, heralding your achievements.
Then reality kicks in.
Weeks or months after the roll out, you review the key metrics you identified to measure impact (you did identify metrics to measure impact, right?) and see that pull request throughput is up significantly: engineers are opening more PRs now than they were before the rollout of the coding assistant.
But wait…PR cycle time isn’t down. In fact, it might be flat or even climbing. Your engineers are writing more code faster, but you’re not shipping features any faster. Local speed increased while end-to-end delivery did not. What gives?
It’s a Queueing Problem
This is a classic queueing problem.
When I was studying for my undergraduate degree in Industrial and Systems Engineering, one of my courses centered around queueing theory: the mathematical study of waiting lines. It was in this course that I learned the basic principles of work-in-progress (WIP), scheduling policies, and customer waiting behavior. It also helped explain why intuitive local optimizations often fail at the system level.
In queueing theory, the major components include the arrival process, service process, number of servers, queue capacity, and the customer population.
To use a non-technical example, think of a coffee shop. Customers arrive and get in line behind one or more registers, where a barista takes a customer’s order and makes their coffee. When the customer receives their coffee, they leave the shop.
How efficiently that queue runs depends on several factors:
How many people are in line?
How many baristas are working?
How long does each order take to complete?
Is it the 7 AM rush or the 4 PM lull?
This relationship is often summarized in Little’s Law, which describes how work accumulates in a system over time:
L = λW
In practical terms, if people arrive faster than they can be served, the size of the queue will grow. Pretty obvious, right?
The Software Development Queue
I first began connecting queueing theory to software development when trying to understand why a team’s velocity didn’t improve even after finding ways to speed up coding time. Even adding engineering capacity didn’t drive meaningful results. It followed a familiar pattern: a local improvement that failed to produce a system-wide result.
Sure, there’s the whole mythical man month problem, but surely adding just a single engineer should have a positive impact. My explanation ultimately had less to do with the number of software engineers and more to do with the number of QA engineers.
In a team where dedicated QA is part of the process, and where software must be verified before it can be considered complete, accelerating development simply increases the size of the queue. In the equation above, λ represents the arrival rate of work in the form of tickets requiring verification, while W represents the time it takes a QA engineer to review and verify a single ticket.
If QA capacity remains fixed, writing more software increases arrivals without increasing service capability. Waiting time grows, work piles up, and overall throughput remains unchanged. To resolve this, we had to either increase QA capacity or reduce verification time. Only then did throughput across the system improve.
Coding Assistants Don’t Speed Up The System
Software development is a series of interconnected queues. There’s a queue for planning and estimation, a queue for writing code, a queue for reviewing that code, and a queue for deploying to production.
A coding assistant improves the code-writing queue, but on its own it does nothing to change the service rate of the others. The output of the writing queue becomes the input to the review queue, increasing the arrival rate. If the rest of the system remains unchanged, throughput does not increase.
Just like in Braess’s Paradox, where adding roads can decrease traffic flow, adding more PRs to be reviewed can slow down overall team productivity.
Addressing Service Time In AI-Enabled Systems
A recent study from FarosAI found that while AI significantly improved individual developer performance, code review time increased by 91%. Code was produced faster than it could be reviewed, creating a bottleneck that resulted in no measurable improvement in organizational performance.
Software development is a symphony of systems that must work together to produce quality output. Improving a single component can generate impressive local gains while leaving overall system performance unchanged. To see real impact, service time must be addressed across the system, not just at the point of code creation. That means looking beyond where AI feels productive and applying it deliberately at the constraints that limit flow. Some practical ways to address constraints on flow include:
Incorporate AI into later stages of the SDLC, including code review and deployment. Productivity gains achieved during code writing must propagate downstream. When review and deployment service times decrease alongside code creation, queues stabilize and throughput improves.
Consider automatic approval of certain classes of pull requests. This approach requires mature test automation, observability, and governance, and may not be viable in highly regulated environments.
The 2025 DORA report describes AI as an organizational mirror, reflecting existing strengths and weaknesses. Teams lacking clear standards, documentation, testing, or release discipline will see those gaps amplified. Teams with mature systems in place are more likely to experience AI as an accelerant.
Wrapping It Up
As an industry, we are still early in AI adoption. Even with widespread use, teams continue to grapple with tools that do not fully understand intent and occasionally produce incorrect output. But we have moved past asking whether AI is useful and into the harder work of learning how to use it well.
There are no silver bullets. Bolting an AI tool onto existing workflows is not enough. Teams that ground themselves in fundamental software engineering principles, then deliberately adapt those principles to new tools, new collaboration patterns, and new delivery models, will see the greatest benefit.
AI does not fix queues. It makes them visible. If you want organizational impact, start by mapping your delivery system end to end, then invest where AI increases arrival rates or reduces service time to improve flow across the system.