Agile coaches, where are you at? Product managers, are you challenging your teams? Leaders, are you asking the right questions and looking at the right metrics? In most of the teams I sit with, I don't think we are. Let me show you what I mean.
Picture a staff meeting. A VP of engineering puts a slide on the screen, and she is beaming. Her organization rolled out AI coding tools this year, which is a common story right now, and her key metric is up about 40%. That metric is pull requests opened per developer.
For the non-technical folks: think of a pull request like submitting a tracked-changes draft of the company handbook, or a legal contract, to an editor before anyone updates the official copy. Someone has to review it before it becomes real.
Then the product leader in the room asks a great question. "So how much faster are we actually shipping to production?"
The room goes quiet. The time it takes to reach the customer hasn't gotten one day shorter. So where did her speed go? It didn't disappear. I'd bet it's waiting in a line somewhere. Let's go find it.
Her Developers Really Are Faster. Faster at What?
I want to give that VP her due. Her developers really are faster, and I don't want to take that away from her. Pull requests are a reasonable signal of progress in writing code, because an open pull request usually means the work is ready for a peer to review.
The bigger question is whether code writing was ever what slowed us down to begin with. Maybe it was for your team. Maybe it wasn't for others. So I went looking for data.
What the Opsera benchmark shows
The clearest data I've seen on this is Opsera's 2026 AI Coding Impact Benchmark Report. It draws on telemetry from more than 250,000 developers at more than 60 enterprises, collected across 2025. Things this year may have shifted.
Before I show you any numbers, you should know who's talking. Opsera sells a DevOps platform. Surprise, surprise. This is a vendor's benchmark, not a neutral audit, so I read it as directional. I still think it's worth exploring with your own teams.
Some of what it shows is good news. Their own table puts deployment frequency up 39 to 49% against what they call a pre-AI baseline.
DORA points the same direction
Opsera isn't the only one looking at this. We reference DORA a lot on this show, and their 2025 State of AI-assisted Software Development report surveyed nearly 5,000 technology professionals. DORA found higher AI adoption associated with higher software delivery throughput, and that relationship flipped from negative in 2024 to positive in 2025.
That's an association from a survey. It doesn't prove AI caused the change. To me it points the same way, though. So I'm not here to tell you AI did or didn't speed anything up. The interesting part is that deployment frequency isn't the number our VP put on her slide. Her slide shows pull requests opened.
Follow the Pull Request
In Opsera's data, what they call time to pull request improved 48 to 58% on average. In the same data, AI-generated pull requests waited 4.6 times longer than human-written ones to be picked up for review.
Put those two numbers next to each other. One is speed at the keyboard. The other is wait time in a queue. They only make sense as a pair.
A few cautions on reading them. The 4.6 figure compares AI-written pull requests to human-written ones, and the wait sits mainly before anyone starts the first review. Opsera also doesn't say what unit they measured the wait in, so I can't tell you whether we're talking four hours or four days. We'll get through it anyway.
Opsera's own reading is that outer-loop friction neutralizes much of the benefit at the keyboard. By "outer loop" they mean everything after the code gets written: review, testing, deployment, you name it. That's their interpretation rather than something they directly measured. They also don't measure lead time at all, meaning how long a change takes to reach a customer, and I think that's the number that matters most.
So where their data stops, let's use it to point back at our own processes and see what improvement areas show up. My hunch is that the speed is reaching the keyboard far more than it's reaching delivery, and the place to look is the line in front of review.
Queues Are the Enemy of Flow
Queues are our enemy in flow optimization. That's why I opened by calling out the agile coaches. Asking "what are we optimizing for?" is part of our job.
There's an idea that explains all of this, and it's been around a long time. It's the theory of constraints, from Eliyahu Goldratt's book The Goal, first published in 1984. The theory says a system only moves as fast as its constraint: the slowest station, the one everything else ends up waiting on. We're only as fast as that station, which means we're only as agile as that station.
The messy part of software development
When I sat down with teams to figure out where we could speed things up, the conversation almost always led to the branching and merging process. That's the messy part of software development, and I don't want to deny it. Many hands are changing a common code base. You make a change right now without knowing someone else is changing the same thing. When you both try to put your changes into the one primary copy, you get conflicts, and someone has to resolve them.
Back in the day, a lot of teams would wait forever before pushing their code into the main repository where others could see it. The more often you merge, the less it hurts, but it never feels that way in the moment. Small, frequent pull requests tend to produce fewer merge conflicts. When you have 20 teams changing one repository, I get it. I've been there.
The pipeline to production
Speed up any station along that path and you don't necessarily get more out the far end. You get a pile of work sitting in front of the constraint.
Picture your delivery system as a pipeline to production. I used to tell teams they were only as fast as their branching and merging process. Writing code is the front of the pipe. Review sits in the middle. Deployment is at the far end. Now add AI coding tools. They widen the front of the pipe, and nobody widened the middle. Maybe deployment gets a little faster too.
So when our VP opened with 40% more pull requests, where did the extra work go? Is anybody asking? It didn't flow faster. It stacked up in front of the review column, and nobody's first instinct was to go look there.
That's what it means to optimize a non-constraint. She made a station faster, and it was never the station setting the pace.
Where to Look for Your Constraint
People ask me, "Where would you look, Lance?" Probably not where everybody looks busy. I'd go find the place where the work isn't moving. That's where you're stuck. We know how to troubleshoot this way in every other part of life, and for some reason we don't do it with our delivery systems.
Your dashboard can't see it, either. Pull requests opened measures the front of the pipe. It tells you nothing about the middle or the end. That's the trap: the chart you already have measures exactly the part that got faster. It's close to confirmation bias. "Let me show you the stuff I optimized."
Software isn't a factory, and that works in your favor
Here's where the factory analogy bends a little, and it bends in your favor if you build software. In a plant, the machine in the middle of the line can't walk over and do the work of the machine in front of it while it waits. A bottle-filling machine can't become a labeling machine for the afternoon.
On a software team, people can. In the teams I coach, the people who review code are usually the same people who write it. They're not some mysterious panel. So your review capacity comes down to how the team chooses to spend its hours, and that's a choice you can change next week. Sometimes we're just paralyzed by the process.
Let's Put Numbers on It
I'm going to use a made-up team and keep the math easy, because numbers are the only way to show the mechanics.
This team has two reviewers, and between them they can close 10 pull requests a day. Before AI tools, the team opened 10 a day. Ten in, ten out. The line in front of review holds steady at, say, 20 open pull requests at any given moment.
Little's Law, in plain English
There's a queuing formula that tells us what that means. It's called Little's Law, and it dates back to 1961, so it's foundational rather than new. Little's Law covers a queue that's holding steady. In that queue, the number of items waiting equals the number you finish per day multiplied by how long each one stays.
Flip it around: open pull requests divided by pull requests closed per day gives you the average number of days a pull request stays open, review included. That's a different measure from Opsera's pickup wait, so don't mix the two.
For our team, 20 open divided by 10 closed a day is two. On average, a pull request stays open two days. That's a number most teams can live with.
Now triple the input
Enter the AI tools, or anything else that helps your team go faster. We should be looking for those things. The team starts opening 30 pull requests a day, triple what it was. The reviewers are the same two people, and they still close 10 a day.
Every day, 30 go in and 10 come out, so 20 more join the line than leave it. After one work week, that's 100 more waiting than there were on Monday. After a month of work days, it's around 400.
Notice what happened to the formula. Little's Law only works when the queue holds steady, and this queue grows every single day. A growing queue doesn't settle at some new, longer wait. It keeps growing until something changes. And who decides when that changes? People. Machines can't.
For the non-technical folks, think of a sink. The faucet is wide open and the drain is the same size it always was. The water doesn't find a new resting level. It keeps rising until somebody turns the faucet down or opens up the drain.
So I can't give you an average time open for this team, because there isn't a steady one to give. Meanwhile, look at the dashboard. Pull requests opened just tripled, and every chart is going up and to the right. Nobody closed anything faster. The work got written. It just didn't get delivered.
What are we optimizing for in agile? Delivery. Deliver the highest business value items as early as possible with the least cost.
Put a Limit on the Line
So what do you do? You put a limit on the line.
Work in progress, or WIP, is everything started and not yet finished. A WIP limit caps how much you allow at once, and the people doing the work set it. Say your team caps open pull requests at 20. When the line hits 20, nobody opens a new one. They go review one instead.
This is where the bend in the factory analogy pays off. Your writers can become reviewers for an afternoon. A bottle-filling machine can't.
Notice what we didn't have to do. A manager didn't have to walk in and start moving people around. Leave them alone. The limit showed the team where help was needed. That's the work of a flow coach, a Scrum Master, an agile coach, a flow engineer, whatever you want to call it. That's where we should be helping teams.
Same people, same tools, double the delivery
Say the limit moves the team from 10 closed a day to 20. Now 20 go in and 20 come out, and the line holds steady again, so Little's Law works again. Twenty open divided by 20 closed a day is one day open on average. That's down from two days, with the same people and the same tools.
| Scenario | Opened / day | Closed / day | Review line | Avg. days open |
|---|---|---|---|---|
| Before AI tools | 10 | 10 | Steady at 20 | 2 |
| AI tools, no limit | 30 | 10 | +20 a day, ~400 after a month | No steady answer |
| AI tools, WIP limit of 20 | 20 | 20 | Steady at 20 | 1 |
Now look at what the team delivers: 20 a day. Before the AI tools, it was 10. The speed is finally reaching delivery because somebody worked the constraint.
And it didn't come from writing more code. It came from writing less than the team could and reviewing twice as much. That feels backwards, I know. Writing is what the dashboard rewards, and we're always trying to keep people busy and maximize utilization.
If You Run an Organization, Change the Slide
If you lead an organization, change the slide, for crying out loud. Put pull requests opened right next to pull requests waiting for a first review. It's that simple.
Show the speed and the line together, the same way Opsera's two numbers only make sense together. When both climb at once, that's your constraint talking.
Try this next week
Open your busiest repository and count the pull requests waiting on a first review. That one number is probably your line. You may have other queues that are worse, but start here. Count it again a week later. If it's climbing, work is arriving faster than your team reviews it.
On Wednesday, we're publishing a free worksheet on our blog called the Queue Locator. It starts with one question: where did we add speed? Then it asks which station absorbed it, and it scores whether your review work in progress has a limit.
You Can't Out-Type the Constraint
Let's go back to our VP and her 40%. Her developers really did get faster. Great. But what we optimize for is delivery. She focused on speed at the keyboard more than speed to the customer, and the difference was sitting in a line nobody was watching.
A chart of pull requests opened was never going to show her that. On its own, it's a metric with nothing to compare it to. Widen the middle of the pipe before you widen the front again.
You can't out-type the constraint. That's the moral of this story. Our goal is progress over perfection, and every team can improve somewhere.
If you want help finding the constraint in your own delivery system, or you want your coaches and Scrum Masters equipped to work it with their teams, take a look at our upcoming classes. I'd love to help.