Most development pipelines optimize for the wrong thing. They optimize for correctness theater. Lengthy review cycles, bikeshed comment threads, approval queues that exist to make managers feel safe. The actual goal of a software delivery pipeline is simpler and more aggressive than that. Every merge makes the software better. Never worse. Everything else is overhead.

A glowing pipeline flowing forward with incremental improvements passing through gates

The One Rule

A healthy SDLC maximizes positive-improvement throughput. That phrase carries weight, so let me unpack it.

Positive-improvement throughput means: the rate at which incremental improvements reach production. Not the rate at which code is written. Not the rate at which PRs are opened. The rate at which the software gets better in the hands of users. I wrote about the principle of flow years ago. The principle hasn’t changed. What’s changed is that we now have operators fast enough to expose every ounce of pipeline drag.

Every merge should leave the product in a better state than before. If a change introduces a bug, a regression, a usability problem: block it. Rework it. That’s the only valid reason to slow down.

Everything else flows forward.

What Gets Blocked

The bar for blocking work is high and specific. A PR gets blocked when it would make the software worse:

It introduces a bug that didn’t exist before
It regresses performance, reliability, or correctness
It creates a usability problem users will hit
It ships an incomplete unit, something half-built that a user would encounter in a broken state

That last point matters. Every unit of work that reaches production must be complete and workable as-is. It doesn’t have to be the final form. It doesn’t have to cover every edge case. But it has to function. If the feature isn’t ready for users, it lives behind a feature flag until it is. The enforcement layer here is automated architecture tests and CI gates, not human vigilance.

What Flows Forward

Infographic: Forward Flow. Improvements pass through the quality gate to MERGE, regressions get deflected to REWORK

Everything else. Specifically:

A PR that makes the software incrementally better, even if it’s small, even if you’d do it differently, even if there’s a follow-up improvement someone already sees: that PR merges. You don’t hold incremental improvement hostage to imagined perfection.

This means non-blocking comments are the default. A reviewer who sees a potential improvement doesn’t block the merge. They note it. If it matters, it becomes a ticket. If it doesn’t matter enough to ticket, it doesn’t matter enough to block. This is why code review as a practice is dying. The gatekeeping version of it, anyway. Product review lives. Blocking-comment review is drag.

Discovered Work Gets Ticketed, Not Hoarded

Here’s where most teams leak value. During implementation or review, someone spots related work. A better abstraction. A nearby refactor. A feature evolution. A test gap.

The wrong move: stuff it into the current PR. Expand the scope. Delay the shipment of something that was already an improvement.

The right move: create the ticket immediately. The moment the work is known, it enters the backlog. Not in someone’s head. Not in a comment that gets buried. In the system, ready to be prioritized and picked up.

This requires frictionless ticket creation. If making a ticket takes more than thirty seconds, the system is broken and discovered work will silently die in comment threads. Back-and-forth is the bottleneck in most delivery systems, and the #1 source of back-and-forth is discovered work that has no home.

The Fixup Heuristic

Not all discovered work should become a ticket. Some of it is trivial. A typo, a missing null check, a rename that takes fifteen seconds.

The rule: if the fix is fast and cheap, fix it now. If it would delay the shipment of the current improvement by any meaningful amount of time, cost, or effort, ticket it.

This heuristic works identically whether the operator is human or AI. An AI agent that can fix a lint error in two seconds should fix it. An AI agent that would need to restructure three files to address an improvement idea should ship what it has and create a follow-up ticket.

The boundary is effort relative to the value of shipping the current improvement now. Specification is the bottleneck, and shipping a clear, complete unit of specified work today beats shipping a sprawling half-specified mega-PR next week.

Same Pipeline, Any Operator

Forward Flow is operator-agnostic. The pipeline doesn’t care whether a human opened the PR or an agent did. The rules are the same:

Does it make the software better? Merge.
Does it make the software worse? Block and rework.
Is it incomplete? Feature-flag it or break it smaller.
Did you discover related work? Ticket it.
Is the fix trivial? Just fix it.
Would the fix delay shipping? Ticket it.

Humans and AI agents operate inside the same system with the same constraints. The pipeline is the authority, not the operator’s identity. This is why the operator role matters more than “developer” or “AI” as labels. The person running the pipeline has one job: keep improvements flowing forward and catch regressions before they land.

Velocity Comes From the Pipeline, Not the People

Teams that ship fast don’t have faster typists. They have pipelines that refuse to accumulate drag. Every blocking comment that could have been non-blocking is friction. Every improvement idea that lives in someone’s memory instead of a ticket is lost work. Every PR that sits in review while someone debates naming conventions is a completed improvement rotting in a queue.

A great SDLC pipeline flows fast, and faster. Throughput increases over time because the pipeline itself is being improved by the same principles it enforces. Each process improvement (faster CI, better auto-review, lower-friction ticket creation) is itself an incremental improvement that flows forward. The same close-the-loop principle that makes agents effective makes pipelines effective: tighten the feedback cycle, ship, measure, repeat.

Forward Flow is the pipeline improving the pipeline.

The velocity ceiling isn’t talent. It isn’t tooling. It’s the drag your process imposes on work that’s already good enough to ship. Cycle time is the product, and Forward Flow is how you protect it at the PR level.

Remove the drag. Let improvements flow.