Build Wide, Ship Narrow: Does It Work Without Reviewers?

Build wide, ship narrow is the AI coding workflow making the rounds right now: build the entire feature on one branch, then get an agent to split it into small, independently reviewable PRs after the fact. It inverts the advice most of us were trained on.

I think the core observation is correct. I also think the reasoning stops one step short, because it quietly assumes you have reviewers. For a lot of teams I know here, that assumption is the whole ballgame.

---

🔍 The claim: pre-planning was a workaround, not a virtue

The post is Build Wide, Ship Narrow by Bruno Quaresma on the Adapt blog. The argument runs like this: we wrote detailed RFCs with PR boundaries decided up front not because early decomposition produces better designs, but because decomposing a finished branch was tedious manual work. Remove the tedium and the reason for the ritual goes with it.

What AI made cheap versus what it didn't:

Activity	Cost before	Cost now (per the post)
Writing the code	High	Low
Iterating on the design	High	Low
Splitting tangled work into a clean PR sequence	High	Low
Substantive review (correctness, architectural fit)	High	Still high
Product validation (did we build the right thing?)	High	Still high

The workflow itself is six steps:

1. Interrogate the plan properly before starting.
2. Commit a spec when the design is genuinely novel.
3. Build end-to-end on a single branch.
4. Demo working software before asking for code review.
5. Split into PRs along the boundaries the finished work reveals.
6. Merge cleanup and deletions last.

Two rules carry most of the weight: "Stack only when the dependency is real" and "Cleanup ships last." The splitting prompt is quoted directly as "Split the current work into the smallest set of independently reviewable PRs, each safe to merge on its own." Their worked example produced five PRs: two backend endpoints, two dependent frontend views, and a final deletion-only PR removing hundreds of old lines.

That deletion-last rule is the smartest part. It means every intermediate merge leaves the system in a state where both the old and new paths still work, so nothing is load-bearing until the last PR lands.

---

💰 "Cheap to build" is a currency-dependent claim

Here is the first place the reasoning needs a local adjustment. Building wide means you deliberately generate code you will restructure or throw away. That throwaway is not free. It's tokens, and tokens are billed in USD while most of us are paid in LKR.

Warning: "The agent can just rebuild it" is a rational sentence when your token spend is a rounding error against your day rate. It is a different sentence when your API bill and your monthly income are quoted in different currencies.

The practical consequence is the opposite of what you'd expect. Step 1 of the workflow, interrogating the plan, matters more on a small budget, not less, because the wide-build phase is where the money goes. Cutting planning and cutting spend are not the same move here.

Before you adopt this as a default, work out what a wide build actually costs you per feature. I'd rather you run your own numbers than trust a figure I made up, so: our AI agent cost calculator and AI API cost calculator will give you a per-run estimate for your model and your token volume. Do that once, honestly, before restructuring how you work.

---

👥 The bet is that review is the bottleneck. Is it yours?

The whole workflow is a trade: spend more agent time so that scarce human review time gets spent on small, clean, mergeable units. That trade only pays if human review is genuinely your bottleneck.

Team shape	Is review the bottleneck?	Verdict on build-wide
Solo freelancer, no reviewer	No. You are the only reader.	Split PRs anyway, but for rollback, not review
Two or three devs, one senior	Yes, sharply. The senior is the queue.	Strong fit
Small product team, everyone reviews	Partly	Good fit, watch the demo step
Client work with an external approver	No. Product validation is the bottleneck.	Demo early, split later

That last row is worth sitting with, because it describes a lot of Sri Lankan agency and contract work. If your real risk is that the client didn't want what you built, then step 4 (demo before review) is the valuable step and the PR-splitting is administrative. Reordering the workflow around the wrong bottleneck just gives you tidier PRs for the wrong feature.

Key takeaway: Build wide, ship narrow optimises for scarce reviewer attention. If you don't have reviewers, keep the demo-first step and the deletion-last rule, and treat the PR split as a rollback strategy rather than a review strategy.

---

🛠️ How I'd run it on a two-person team

Adapted, with the parts that survive a small team intact:

1. Interrogate the plan harder than the post suggests. You are paying for the wide build. Ten minutes of argument with yourself is cheaper than a rebuild.
2. Build wide on one branch. Genuinely one branch. Half-branching gets you the costs of both approaches and the benefits of neither.
3. Demo it to a human before any review. A client on WhatsApp counts. A co-founder counts. This is the step that catches the expensive mistake.
4. Split into PRs sized for rollback, not for reading. Ask: if this breaks in production at 11pm, what is the smallest thing I want to revert? That's your boundary.
5. Deletions last, always. Non-negotiable, and it's what makes step 4 possible.
6. Skip it entirely for migrations. The post concedes this too: work that requires strict sequencing, especially anything touching production data, is a bad fit. Plan those the old way.

The post is right that this suits multi-surface features, where the backend and frontend shapes only become clear once both exist. It's wrong for anything where the order of operations is the design.

---

💡 What this means for you

If you're building alone, take two things from this and leave the rest: demo working software before you polish it, and land your deletions last. Those are good practice regardless of how you use AI.

If you're on a small team with one overloaded senior reviewer, the full workflow is worth a trial on exactly one feature. Measure the thing that actually matters, which is not lines shipped:

• How long did the reviewer spend, versus a comparable feature done the old way?
• How many PRs could be merged independently without breaking anything?
• What did the wide-build phase cost in tokens?

If review time drops and the token bill is affordable, keep it. If the reviewer is still doing three-hour sessions on a stack of "small" PRs, the splitting didn't help and the planning you skipped was doing real work.

The underlying insight holds up: the bottleneck in software has moved, and workflows built around old bottlenecks are worth re-examining. Just check which bottleneck is yours before you rearrange everything around someone else's.