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.
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.
So stop pre-deciding boundaries to dodge a cost that no longer exists. The new workflow looks like this:
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.
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.
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. 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 you gain:
What it costs:
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.