Managing Spec-Driven Flow Takes More Than PR Metrics

The pattern I keep running into: coding got dramatically faster, and end-to-end cycle time did not move at all. People are shipping code into branches in minutes. The time from “we decided to do this” to “a customer has it” looks about the same as it did before any of the tools arrived.

This is the oldest result in constraint theory. Speed up something that is not the constraint and you do not get throughput, you get inventory piling up in front of the thing that is. For most engineering teams that thing is review and integration, and it is staffed by the same humans it was staffed by last year.

So the question is not how to make coding faster. It is how to see where the work is actually waiting. My argument here is that you can get that from Git itself, for free, if you change one habit: open the pull request when you start rather than when you finish.

The reflex when work slows down is to look at pull requests: how many are open, how long they sit, how big they are. That was a reasonable proxy when a PR roughly equalled a person working for a day or two. In spec-driven agentic development it stops being one.

A spec can produce one pull request or six. An agent can open a PR ninety seconds after the spec is written, so PR age tells you almost nothing about how long the actual work has been alive. And the expensive waiting has moved earlier: it now happens between “the spec is written” and “a human has looked at what came back,” which the PR record does not capture at all because the PR did not exist yet for most of it.

So a PR-shaped dashboard reports a healthy system while the real queue builds up somewhere it cannot see. What you want to know is how many specs are in flight, how long each has been alive since intent was captured, and where it is currently sitting. Draft-first is how you get Git to record that without asking anyone to maintain a second board.

Worth asking where the pull request came from, because almost nobody chose it deliberately. It comes from public open source, and in that setting it does a specific job well.

On a public project you do not know the contributor. Review capacity is scarce, the maintainers are volunteers, and a bad merge is expensive to undo. The PR is a defensive gate, and it is supposed to be slow. Keeping code out until somebody has scrutinized it is the entire point.

Now look at your internal repo. You know every contributor. They are on your payroll, working toward goals you set. Code sitting unintegrated is not safety, it is unshipped value plus a merge conflict getting worse by the day. Almost every condition that made the defensive gate correct is absent, and the process stayed anyway.

That was survivable when a PR was roughly one person working for a day or two. With agents in the loop it stops being survivable, because the batches got bigger and more frequent while the review capacity did not change. Now the gate is a traffic jam.

The fix is one habit change, and it is small enough that a team can try it this week without asking anyone’s permission.

Instead of working in a local black box and pushing a finished thing, you open a draft pull request the moment you start. It holds the spec, then the work in progress, then the finished implementation. The moment it is ready for a human, you mark it ready. Nothing else about how you work has to change.

What that buys you is a timestamp on every transition, which is what turns Git into a flow record instead of an archive:

[Issue Created] ➔ [Draft PR Opened] ➔ [Ready for Review] ➔ [PR Merged]
       │                 │                    │                 │
       └─ Backlog Wait ──┴── Spec & Coding ───┴── Review/Test ──┘

An issue is something waiting to be picked up. Opening the draft PR is the pull signal, the moment work actually starts, and it covers spec, design alignment, and the building. Marking it ready is the handoff into the review queue. Merging is when it counts.

The side effect matters as much as the measurement. A draft PR is not a private scratchpad, it is a visible signal that you are working on this. Somebody can see the direction on day one and say “that overlaps what I am doing” before there are four hundred lines to argue about. The defensive gate assumed you would find out at the end. Opening early means you find out at the start.

Once the transitions are recorded, the flow metrics fall out of the metadata. No separate tracking tool, no asking people to move cards to describe work they already did.

Where the work in progress actually sits

Stop counting open PRs as one number. Split them: drafts are work being built, ready-for-review are work waiting on a human.

That one split usually answers the question people hire me to answer. If the drafts are piling up, your constraint is building, or more often spec clarity, because people are stuck on what to build rather than how. If the ready column is piling up, your constraint is review, and no coding tool will touch it.

How much of the time anything is actually being worked on

Draft opened to ready-for-review is time spent building. Ready-for-review to merged is time spent waiting. Divide the building time by the total and you have flow efficiency, which is the number I would look at first.

It is usually worse than people expect. A team at 10% is spending nine tenths of its cycle time with work sitting still, and that is not unusual once you measure it honestly.

Here is the part worth sitting with. If you are at 10% and you make coding twice as fast, flow efficiency does not improve. It gets worse, because you shrank the only part of the cycle that was actually work. The number going down is the tools doing exactly what they promised, and it is also the clearest possible signal that you sped up the wrong thing.

What is getting old

Age is the metric that changes behaviour fastest, because it is about work that is still open rather than work already finished. A draft sitting for two weeks means somebody is stuck and has not said so. A ready-for-review sitting for two weeks means the queue is not moving and everyone has quietly accepted it.

Both are worth a conversation while you can still do something. Cycle time tells you about work that is already gone.

Your Git history is already recording how work moves. Opening the PR at the start instead of the end is what makes it legible, and it costs one habit change rather than a tool purchase or a process rollout.

What you get is the ability to tell the difference between a team that is fast and a team that is busy. That distinction is worth more now than it was two years ago, because the tools got very good at making busy look like fast.

If your team is struggling to translate AI velocity into shipped business value, let’s look at your system constraint. Book a brief diagnostic session.