Engineering at Scale - Why Flow Matters More Than Vibes

Abstract

Unlocking Faster, Safer, Stronger, Further Engineering in the Age of AI

Originally published on Medium on April 3, 2026

An Illusion of Productivity

An executive sees or even creates a vibe-coded prototype built over a weekend and asks a reasonable question: why does it take your team three months to ship a feature?

It’s not an unfair question. The demo is real. The tools are real.

If an AI can scaffold an entire application in an afternoon or even an hour or two, surely a team of experienced engineers can move faster than this?

They can. That’s the thing. The code is already coming out faster. I’ve been coding for a long time and AI coding tools are genuinely game changing— they supercharge coding by autocompleting your thoughts, generating boilerplate, and scaffolding entire features. The benchmarks are real. The productivity gains at the keyboard are real.

Here’s the thing:

Code was never the constraint. It still isn’t.

Code sits in review queues. Builds back up in CI. QA becomes a bottleneck. Releases cluster and conflict. Long before AI arrived, the constraint in software delivery was everything that surrounds the code itself — before it, after it, and in between.

AI has made the faucet flow faster. But the pipes are the same size.

When you pour more water into the same pipes, you don’t get faster delivery. You get pressure. You get queues. You get the system straining at every joint.

This is an article about the pipes.

Press enter or click to view image in full size

Photo by Christina Deravedisian on Unsplash

An Analogy: The Faucet Problem

Think, for a moment, about how water gets from a source to your tap.

There’s a pump. There are pipes. There are filters, pressure regulators, junction points, and valves. The water moves through all of it before it reaches you. And the amount that reaches you isn’t determined by the strength of the pump. It’s determined by the pipes.

You can have the most powerful pump in the world. If the pipes are blocked, you get a trickle.

Software delivery works the same way. Code is the water. The pump is your engineering team and right now, AI is making that pump more powerful pushing out code faster than ever. However, value doesn’t reach your users at the pump. It reaches them at the tap. And to get there, it moves through a pipeline: planning, development, review, testing, deployment, monitoring.

Every stage is a pipe.

Every handoff is a joint.

Every delay is presswure building somewhere in the system.

The speed of delivery isn’t set by how fast code is written. It’s set by the narrowest point in the pipeline.

Engineers have a word for that narrowest point. They call it the constraint. Before you invest another dollar or token in tools that help your team write code faster, it’s worth asking: is the code really the constraint?

In most organizations, it isn’t. It never was.

Most organizations think software delivery is a coding problem.

It isn’t.

It’s a flow problem.

An Experience: The Faucet Problem!

Last December, my well water pump nearly blew.

The pump runs under pressure, and when that pressure spiked dangerously high (nearly injuring the Plumber checking the valves—sorry Joe!), the whole unit had to be replaced — emergency callout, significant cost, the kind of thing you don’t want to as a present for winter. We went from a 30/70 pressure switch to a 40/60 while we were at it and I learnt a lot about how these systems work.

But that wasn’t the end of the problem.

Shortly after the new pump was installed, the pressure at every faucet in the house was terrible. A dribble. Barely enough to wash your hands. The pump was brand new and running fine. So what was wrong?

The whole-house filtration system was clogged.

I have three Big Blue filters running in sequence after the pump — a 20 micron yarn filter that catches the large sediment, a 5 micron carbon block that handles chemicals and taste, and a 1 micron sediment filter as the final stage—real plumbers call it the polish stage. Each filter progressively finer than the previous. Each one protecting the next.

Embarrassingly, I hadn’t changed any of them in over three years since we bought the house.

The filters weren’t broken. They were doing exactly what filters are supposed to do — catching everything that came through them. But after three years of well water, they were saturated. The blockage wasn’t dramatic nor sudden. It had built up quietly, gradually, invisibly until the pressure everywhere downstream told the story.

Replacing the filters solved it immediately. Full pressure. Problem gone.

The pump was never the issue. It was the system around it.

The Flow Problem

My filtration system works in stages. Each filter has a job. Each one protects the next. Each one has a capacity limit — a point beyond which it can no longer do its job without affecting everything downstream.

Software delivery pipelines work exactly the same way.

Each stage protects what comes after it. Each stage has a throughput limit. And when the volume coming in exceeds what the stage can handle, the pressure builds — not just at that stage, but everywhere downstream.

This is the part that’s easy to miss.

When a CI pipeline slows down, it looks like a CI problem.

When review queues grow, it looks like a resourcing problem.

When QA becomes a bottleneck, it looks like a QA problem.

However, these symptoms are connected. They’re pressure readings. They’re telling you that somewhere in the system, a filter is saturated.

Critically: the filters don’t fail loudly. They degrade quietly. Gradually. Invisibly. Just like mine did over three years of well water. Until one day the pressure everywhere in the house told the story.

The question isn’t whether your pipeline has filters. It does. Every software delivery pipeline does.

The question is: when did you last change them?

PANIC

Here is what many organizations do when delivery feels slow or want to accelerate:

They hire more engineers. They adopt AI coding tools. They push for larger releases to justify the time spent in review. They add more work to the pipeline, reasoning that more input will produce more output.

It doesn’t. The pressure builds. The queues lengthen. The releases destabilize. The teams that were supposed to move faster are somehow moving slower.

Engineers know this feeling. Leaders know this feeling. It has a name: PANIC.

More code enters the pipeline. The filters stay the same size. The pressure builds.

Beth Andres-Beck and Kent Beck wrote about forest and desert conditions in software teams — the idea that some teams are already operating in fertile ground, with the foundations in place to absorb and amplify new tools, while others are surviving under an oppressive sun, where those same tools find no purchase. They’re correct. Their argument is about readiness. Mine is about what happens next.

Even in the forest, if you flood the irrigation system, you drown the crops.

Agentic AI doesn’t just increase coding speed. It increases the rate at which work enters the pipeline. More merge requests. More features in flight. More changes queuing for review, for testing, for deployment. The faucet opens wider. But the filters are the same clogged filters and they haven’t changed in years.

The symptoms are familiar:

A CI pipeline that once ran in 6 minutes now takes 45 minutes once the organization scales.
Review bottlenecks where code sits waiting for attention
QA backlogs that delay releases by days or weeks
Releases that cluster, conflict, and destabilize production

Each one looks like a local problem. A resourcing issue. A process issue. Something to fix within that team, in that stage.

But they’re pressure readings. The system is telling you something.

FLOW

The answer to PANIC is not fewer tools. It’s not slower engineers. It’s not a moratorium on AI.

It’s FLOW — Feedback Loops, Optimized Workflows.

Where PANIC is what the system feels like under pressure, FLOW is what it feels like when the pressure is gone.

Before we go further, let’s address the question sitting in the back of every leadership meeting right now.

We’ve adopted AI tools. Our engineers are coding faster. So why isn’t the roadmap moving twice as fast?

The simple answer:

The roadmap doesn’t move at the speed of code. It moves at the speed of the slowest loop in the system.

In high-performing teams studied by DORA, lead time is measured in hours, not weeks.

Pipelines don’t just move work forward.

They also generate signals that tell us whether we’re moving in the right direction. These signals are feedback loops and revealingly, there are more loops than most organizations realize.

Feedback loops exist at every stage of delivery, not just in CI and testing, but upstream in ideation, planning, and prioritization, and downstream in production. A feedback loop is simply the time between making a decision and learning whether it was the right one. The longer that loop, the longer bad decisions survive, the more work accumulates behind them, and the more pressure builds in the pipeline.

Here are the loops that matter:

THE PLANNING LOOP. The time between identifying a problem and aligning on a solution. Measured in days and weeks. When this loop is long, teams build the wrong things confidently. AI accelerates execution but if the planning loop is slow, it accelerates building the wrong things faster.
THE REFINEMENT LOOP. The time between an idea and work that’s ready to build. Measured in days. When this clogs, engineers sit idle or context-switch while they wait for clarity. The sediment builds before a line of code is written.
THE DEVELOPER LOOP. The time between writing code and knowing it works. Measured in seconds and minutes. Shortened by fast test suites, local CI, and tight tooling.
THE CI LOOP. The time between a merge request and a confident signal. Measured in minutes and hours. Shortened by parallelization, test selection, and pipeline optimization.
THE REVIEW LOOP. The time between code being ready and code being approved. Often invisible in metrics, painful in practice. Shortened by smaller merge requests, clear ownership, and team norms around responsiveness.
THE PRODUCTION LOOP. The time between shipping and knowing the impact. Measured in hours and days. Shortened by observability, feature flags, and deployment frequency.

AI makes individual engineers faster. That said, if the planning loop runs on two-week cycles, if refinement is a calendar-dependent ceremony, if review is a queue that moves when people get around to it — the code arrives faster at a bottleneck that was already there.

The roadmap doesn’t move twice as fast because the code was never the bottleneck.

In a well-functioning filtration system, you don’t wait until pressure drops to check the filters. You monitor the readings. You maintain the system on a schedule. You keep the flow moving before it degrades.

That’s what FLOW means. Not a single metric. Not a single tool. A system designed so that value keeps moving from idea, through build, through ship, through feedback with nothing quietly saturating in between.

Keeping it Small — Batch Sizes

If feedback loops are the pipes, batch size is the volume of water you try to push through them at once.

This is the most important lever in software delivery. More important than tooling. More important than team size. More important, in the short term, than almost anything else you can change.

A large batch is a big release. Many changes, many authors, many features bundled together to justify the overhead of shipping. It feels efficient. It is not. Large batches move slowly through every stage of the pipeline. They take longer to review, longer to test, longer to debug when something goes wrong and something always goes wrong. When it does, you’re not looking for a needle in a haystack. You’re looking for a needle in a stack of needles.

A small batch is a single change, a single feature, a single fix.

It moves quickly. It’s easy to review because there isn’t too much to review. It’s easy to test because the surface area is small. It’s easy to roll back because you know exactly what changed. When it reaches production, the feedback loop is tight since you learn quickly whether it was the right thing to build.

Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim, is unambiguous on this point. Small batches are one of the strongest predictors of both delivery performance and organisational stability. High-performing teams ship more frequently, not less. They don’t save up changes for one big release. They move work through the system continuously, in amounts the pipeline can handle.

AI changes this equation in an important way. It becomes much easier to generate large amounts of code quickly. Which means the temptation to batch it up and to bundle a week’s worth of AI-assisted output into a single release, is stronger than ever. Resist it. The code moving faster doesn’t mean the pipeline can absorb more at once. It means you have more opportunity to ship small, ship often, and learn faster.

The goal is not a bigger wave. It’s a steadier current.

AI That Improves Flow

So far in this article it might seem that we’ve painted AI as the source of pressure. That’s not quite right. AI is a multiplier. What it multiplies depends entirely on what you point it at.

Most organizations point it at code generation. That’s the most visible use case, the easiest to benchmark, and the one that produces the demos that end up in leadership and investor presentations. It’s also, as we’ve established, the least constrained part of the pipeline.

The more interesting question is: what happens when you point AI at the loops?

Used well, AI doesn’t just accelerate coding. It compresses feedback. And compressed feedback is what flow is actually made of.

In the:

PLANNING LOOP, AI can help teams move from a rough problem statement to a structured and unambiguous specification faster. It can help stress test assumptions, surfacing edge cases, and identifying dependencies before a line of code is written. The goal isn’t to automate planning. It’s to shorten the time between a question and a clear enough answer to act on.
REFINEMENT LOOP, AI can accelerate the journey from rough idea to something actually buildable and right-sized. This means fully specified by acceptance criteria, decomposing epics into stories, flagging ambiguities before they reach an engineer’s desk. The goal isn’t to automate refinement. It’s to shrink the calendar gap between “we know what we want to build” and “someone can actually start.”
DEVELOPER LOOP, AI-assisted test generation means coverage that once took hours to write can be scaffolded in minutes. Faster tests mean faster signals. Faster signals mean shorter loops.
CI LOOP, AI can analyze failure patterns, suggest flaky test candidates, and prioritize which checks matter most for a given change. The pipeline gets smarter, not just faster.
REVIEW LOOP, AI can handle the mechanical parts of code review like style, standards, common patterns, freeing human reviewers to focus on logic, architecture, and intent. Reviews get faster without getting shallower.
PRODUCTION LOOP, AI-assisted observability means incidents surface faster, root causes are identified sooner, and the feedback from production reaches the team while the context is still fresh.

None of this is about replacing engineers. It’s about removing the friction that causes loops to slow down and pressure to build. The teams seeing the most benefit from AI right now are not the ones generating the most code. They are the ones using AI to keep the pipeline moving, catching problems earlier, learning faster, and reducing the cost of each handoff.

There’s something else worth noting. Practices that once required specialist expertise or significant investment are now within reach of teams that couldn’t previously afford or make time for them: comprehensive test coverage, deep observability, fast CI pipelines. AI doesn’t just compress feedback for mature teams. It lowers the floor for everyone.

The Forest & Desert article is right that AI amplifies what’s already there. A team with strong foundations uses AI to move faster through a system already designed for flow. A team without those foundations uses AI to generate more work for a pipeline that was already struggling.

The tools will follow the conditions — and building those conditions is itself a maturity journey, one I explored in the context of agentic teams here. Build the conditions first.

Designing Teams for Flow

Delivery pipelines don’t exist in a vacuum. They’re shaped by the teams that run them.

The insight that Conway’s Law, first observed in 1968, brought is that organisations ship systems that mirror their communication structures— your organisational structure and your software architecture are not independent choices. They influence each other, constantly and inevitably. If your teams are fragmented, your pipeline will be fragmented. If your handoffs are slow, your delivery will be slow.

Most delivery bottlenecks have an organisational root or history.

The review queue that nobody owns or prioritizes. The QA team that sits outside the stream of work and receives it in batches. The platform team that every other team depends on but nobody funds properly. The architecture decision that requires four teams to coordinate before anything ships. These aren’t process failures. They’re structural ones. And no amount of AI tooling fixes a structural problem.

Stream-aligned teams or squads own a flow of work end to end — from idea to production — without handing off to another team at every stage. Enabling teams like platform or core technology teams exist to reduce cognitive load (the overall context requirement) for stream-aligned teams, not to create dependencies. Platform teams provide self-service capabilities that let others move without waiting. The goal, in every case, is to reduce the friction between a decision and its outcome.

In flow terms, this means three things, three ‘C’s, matter above all else.

Cognitive load. A team that owns too much whether too many services, too many domains, or too many responsibilities — cannot maintain the quality of attention that flow requires. Work slows down not because of tooling but because of overload. Reducing cognitive load is pipeline maintenance at the team level.
Cross-team dependencies. Every dependency between teams is a joint in the pipe. Every joint is a potential blockage. The more a team must wait for another team to act before it can move, the more pressure accumulates. Minimising dependencies isn’t about isolation — it’s about designing for flow.
Clarity of ownership. Ambiguous ownership is sediment. It builds up quietly. Who reviews this? Who deploys it? Who is on call when it breaks? Whenever the answer is “it depends” or “everyone” the answer is effectively “no one” — and the pipeline slows accordingly.

The most discussed version of this question right now is Marty Cagan’s 2024 forecast that product teams will shrink from eight people to three — one PM, one designer, one engineer — as AI handles the engineering throughput. It’s an interesting answer to the question of how teams should be structured in the age of AI. But for me it’s asking the wrong question. The question isn’t how small a team can be. It’s whether the system that team works inside is designed for flow.

A team of three working inside a fragmented pipeline, with ambiguous ownership and unexamined dependencies, won’t deliver faster than a team of eight. It will just have fewer people to absorb the pressure and lack the redundancy to maintain flow.

A team of three also has no redundancy. One engineer. If that engineer is sick, on holiday, or simply pulled into something else, the pipeline stops entirely. Water doesn’t flow when the only pipe is blocked.

AI does not resolve these questions. It makes them more urgent. A team that is cognitively overloaded, dependent on three other teams, and unclear on ownership will not benefit from moving faster. It will produce more work for a system already straining at the joints.

Design and resolve the team structure first. The throughput will follow.

In an earlier piece in this series I explored what that looks like in practice — how squads, tribes, and eventually agentic cliques apply the same coordination-cost logic to the shape of the organisation itself: Tribes, Squads, and Agentic Cliques

Again, build the conditions first.

Practical Experiments

Everything in this article is actionable. But transformation is not a project. It’s a series of small, safe steps (atomic habits) — the kind that compound quietly until one day the pressure everywhere in the system tells a different story.

Start here.

Measure your loops. You cannot improve what you cannot see. Pick one loop — the CI loop is usually the easiest place to start — and measure it. How long does a pull request take from open to merge? How long does a build take? How long between a deployment and knowing it worked? Write the numbers down. First they will surprise you. Then they will focus you.

Reduce your merge request size. This is the single highest-leverage change most teams can make. If your average merge request touches hundreds of files, you don’t have a review problem. You have a batch size problem. Set a team norm. Make it smaller. Then make it smaller again. Watch what happens to your review loop.

Shorten your CI runtime. A CI pipeline that takes forty minutes is a pipeline that engineers learn to ignore. They context-switch. They batch up more changes while they wait. They lose the thread. Every minute you take off your CI runtime is a minute you can add back to your feedback loop. Parallelise. Prune. Prioritise.

Add a smoke test. Not a full regression suite. A smoke test — the smallest set of checks that gives you confidence that the critical path still works. Run it on every deployment. Make it fast enough that the result arrives before the engineer closes their laptop.

Track lead time. Lead time is the time from a commit to that commit running in production. It is the single most revealing metric in software delivery. High-performing teams measure it in hours. Most teams don’t measure it at all. Start measuring. Then start asking why it’s as long as it is. What we measure, we improve.

Visualise your queues. Make the invisible visible. Where is work waiting right now? In refinement? In review? In QA? In a dependency on another team? A simple board, honestly maintained, will show you where your sediment is building before the pressure becomes a crisis.

Deploy more frequently. This one feels counterintuitive. If delivery is painful or full of ceremony, the natural instinct is to do it less often. But frequency reduces batch size, which reduces risk, which reduces the pain of each deployment. The teams that deploy daily don’t do it because they’re brave. They do it because they’ve made it safe and making it safe required doing it more often.

None of these experiments require a reorganization. None require a new tool. None require executive sign-off on a multi-quarter transformation programme.

They require attention. And the willingness to treat your pipeline the way you’d treat a filtration system — with regular maintenance, honest readings, and the discipline to fix small problems before they become pressure everywhere downstream.

Last December I stood in my basement looking at three clogged filters and a brand new pump that couldn’t push water to the rest of the house.

The pump was fine. The water supply was fine. The problem was in the system between them — quiet, gradual, invisible until it wasn’t. Three years of sediment, building up one particle at a time, until the pressure everywhere downstream told the story.

I’ve been thinking about that a lot when I look at software organizations adopting AI. The success stories. The failure stories.

The enthusiasm is real. The tools are at times unbelievable. The founder asking why their team can’t move as fast as a quick prototype on Claude is asking a fair question. But the answer was never more pump pressure. It was always the filters.

AI is turning the faucet on faster. That’s genuinely exciting. I’ve been doing this for years and I can’t recall any advance in tooling nearly as impactful. That said, delivery performance, especially when engineering at scale depends on the pipes — on the feedback loops that surface problems early, the batch sizes that keep work moving, the team structures that reduce friction at every joint, and the maintenance discipline that stops sediment from building quietly until the pressure becomes a crisis.

AI amplifies what’s already there.

A system designed for flow will use AI to move faster, learn sooner, and ship more safely. A system that isn’t will use AI to generate more pressure for a pipeline already straining at the joints.

AI will make every engineer faster.

But faster engineers do not create faster organizations.

Flow does.

AI accelerates coding.

Flow accelerates learning.

The companies that win in the age of AI will not be the ones that produce code the fastest.

They will be the ones where value flows the fastest. ""

Engineering at Scale - Why Flow Matters More Than Vibes

An Illusion of Productivity

An Analogy: The Faucet Problem

An Experience: The Faucet Problem!

The Flow Problem

PANIC

FLOW

Keeping it Small — Batch Sizes

AI That Improves Flow

Designing Teams for Flow

Practical Experiments

Recommended Reading

Books:

Articles:

Next