The Old Way: Decide Boundaries Before You Build
Good engineers plan before they build. The traditional workflow goes: write an RFC describing the feature, split it into smaller issues, then build them sequentially — each issue often blocking the next. The structure of the work was locked in before a single line of code existed.
This approach is reasonable. It keeps code reviews manageable and avoids big-bang merges. But it also asks you to make your most critical structural decisions at the moment you know the least about the problem. Before you've built anything, you're guessing: which pieces are separable, how complex each one will be, whether step 3 will force you to rethink step 1.
Sometimes you're right. Often you're not, and step 1 gets thrown away. You learned something building it, but you'd have learned it faster by building the whole thing first.
We paid that cost for a good reason: the alternative was building everything and untangling it by hand, and untangling a week of work is harder than planning ahead. Deciding boundaries up front was never about making the build easier — it was about making review possible, and it was the only affordable way to get there.
That's the part that changed.
What Changed
Three things got dramatically cheaper:
Building: An AI assistant turns a clear problem into working code in hours, sometimes minutes.
Design: You can interrogate a plan and reshape it at conversation speed.
Decomposing a finished branch: Splitting a week of tangled work into a sequence of small PRs used to be the most tedious part of the job — exactly why we avoided it. It's now a prompt.
Two things didn't get cheaper:
The judgment half of code review. Agents made the mechanical half (consistency, nits, obvious bugs) nearly free, but they don't settle subtle correctness or the questions around it: does this change belong where it is, will this endpoint shape hurt six months from now. A bot approving your PR isn't the same as you understanding the code, and if you didn't type the code, reading it is how you come to own it. Narrow PRs make that reading possible.
Product validation. Running the thing and deciding it's the right thing to build is still slow. What's new is having the whole feature working early enough to show someone before anyone reads a line of it.
The New Workflow
So stop pre-deciding boundaries to dodge a cost that no longer exists. The new workflow looks like this:
- Grill the plan until it has real decisions in it
- Commit the spec before any code, when the design is novel
- Build wide, committing save points as you go
- Demo and iterate before anyone reads the code
- Split into PRs along the boundaries the code revealed
- Merge, cleanup last: pure deletion in its own final PR
Design Still Goes First
To be clear: this isn't "skip planning and start coding." Before you touch the editor, you have a plan, and every feature starts with an interrogation — running adversarial rounds against your idea until it has real decisions in it. What's the fallback if the API call fails? What happens when the database is down?
When the design is novel, the plan becomes a spec committed before any code. On one project, the first PR was a document: what the feature was, how it would work, where the trust boundaries sat. It merged days before any implementation existed, so the team could push back first.
What never gets committed is a decomposition into PRs. Decide what to build before you build it; decide how to slice it after.
Build Wide
Once the design is settled, you build. You work in steps, but you don't stop at each one to open a PR and wait for review. Everything stays on one branch until it works end to end, across whatever files are in the way.
Commits happen, but they aren't milestones for anyone else. They're save points: a concept is proven, or you're about to try something risky and want a rope to pull back to. A recent refactor ran to a dozen-plus commits in a single day across dozens of files. Waypoints to see where you've been, not a story for a reviewer.
This is the part that makes some engineers uncomfortable, and understandably: git history is supposed to be the record. But this history never becomes the record. The PRs at the end are cut fresh off main, and the build branch is discarded.
Demo Before Anyone Reads the Code
The feature works. Show it to someone. Not the code — the working thing. This is the fastest validation you've ever had. If it's wrong, you haven't wasted anyone's review time on a doomed direction.
If the demo lands, you now have a finished branch and a clear signal that the direction is right. Time to make it reviewable.
Ship Narrow
This is where the AI cost collapse matters most. You have a working branch that does the thing. Now you ask the agent to split it into a sequence of small PRs, each one a clean, independently reviewable chunk.
The key insight: the code itself tells you where the boundaries are. You don't have to guess them in advance. The natural seams in what you built — the new module, the changed interface, the migration — those are your PRs. You just couldn't see them clearly before you built it.
Each PR is cut fresh from main, so they're not stacked — they're sequential but independent. Reviewers see clean, focused changes. You see real ownership of the code because you're reading narrow slices, not reviewing a week of tangled work.
What It Bought, What It Costs
What you gain:
- You learn faster by building the whole thing first
- Your structural decisions are informed by reality, not prediction
- Product validation happens before review investment
- Reviews are narrow and focused — the part humans are actually good at
- The decomposition cost that used to be prohibitive is now trivial
What it costs:
- You need an AI assistant good enough to split branches coherently
- Your team needs to trust that "build wide" doesn't mean "skip review"
- You need discipline to not ship the wide branch directly
- The demo-first culture requires someone willing to look at unfinished things
When to Reach for It
This workflow shines for features where the boundaries are genuinely uncertain — the kind where your RFC is mostly guesses. If the feature is "add a field to an existing form," the old way is fine. If the feature is "introduce a new abstraction for handling async background jobs across our services," build wide and let the code show you where to cut.
The economics shifted. The question is whether your workflow has caught up.
Based on a blog post by Bruno Quaresma at Adapt.com. The "Build Wide, Ship Narrow" philosophy represents a practical application of AI-assisted development that rethinks when we make structural decisions — not whether to plan, but when.
Top comments (0)