A familiar engineering exercise goes like this: write an RFC, break the feature into tickets, decide which pieces belong in which PR, then start building.
It sounds disciplined. Often it is. But there's a strange problem hiding inside that process: you're making some of your most important architectural decisions before you've built enough of the feature to understand it.
You don't yet know which components naturally belong together. You don't know where the real dependencies will appear. You might not even know whether the approach in the RFC survives contact with the codebase.
Traditionally, engineers accepted that trade-off because the alternative was worse. Building an entire feature on one branch and then manually untangling it into reviewable changes could turn a week's work into another week's work.
AI changes that calculation.
A development workflow called Build Wide, Ship Narrow takes advantage of it.
The Problem With Deciding Everything Up Front
RFCs aren't the problem. Good engineers still need to think through a feature before touching the editor, particularly when the architecture is unfamiliar or the change introduces new trust boundaries, APIs, or data models.
The questionable part is deciding exactly how the implementation should be divided into PRs before you've seen the implementation.
Imagine you're adding a new workflow that crosses your backend, API layer, and frontend. You might decide that PR one should contain the database changes, PR two the backend endpoints, and PR three the UI.
Then you start building.
The database model doesn't quite support the API you imagined. The API needs a different shape once the frontend consumes it. A supposedly independent piece turns out to depend on another. Suddenly the carefully planned sequence of tickets isn't describing the system anymore.
Now you're either rewriting the plan or forcing the code to follow a decomposition that no longer makes sense.
That's the weakness Build Wide, Ship Narrow is designed to address.
Build Wide Means Building the Whole Thing
The first half is deliberately uncomfortable for engineers who grew up treating small PRs as the safest way to work.
Once the design is settled, you build the feature end to end on a working branch. You cross the boundaries that need crossing. Backend, frontend, APIs, tests, refactors; if they're required to make the feature work, they stay together while you're discovering the shape of the solution.
The branch isn't the thing reviewers will eventually see. Think of it as scratch space.
You can commit frequently, but those commits are save points rather than a carefully curated narrative for someone else to review. If an approach fails, you can roll back. If the architecture needs to change, you can change it without worrying that three downstream PRs have already been built on top of the old decision.
That distinction matters because the goal isn't to eliminate structure. It's to delay implementation decomposition until you actually have an implementation.
And that gives you something an RFC can't: context.
Once the feature works, you can see the real data flow. You know which components depend on each other. You know which changes are genuinely independent and which only looked independent on a whiteboard.
The Working Feature Gets Reviewed Before the Code
There's another important part of the workflow that can easily get lost in the catchy name.
Before turning the branch into PRs, you can actually use the feature.
That might mean deploying a preview environment, recording a short demo, or simply putting the working flow in front of the people who need to validate it.
This catches a different class of problem from code review.
A reviewer can tell you that an endpoint is poorly designed. They aren't necessarily the person who will catch that the workflow feels wrong, the UI pattern doesn't fit the product, or the frontend needs data in a form the backend wasn't designed to provide.
Finding those problems after you've created five carefully structured PRs is expensive.
Finding them while the feature is still sitting on one working branch is much cheaper.
Adapt's workflow explicitly puts this validation before code review: get the feature working, show it, iterate on the product, and only then prepare the implementation for reviewers. citeturn0view0
That's a subtle but important shift. Code review stops being the place where you discover whether you built the right thing.
Then AI Does the Tedious Part
This is where the workflow becomes practical.
Once the feature has been built wide, an AI coding assistant can inspect the finished branch and determine how to divide it into smaller changes.
Instead of asking a developer to manually reverse-engineer a week's worth of work into PRs, the agent can examine the actual dependencies and propose a sequence of independently reviewable changes.
A backend endpoint might become one PR. Another endpoint can branch separately if it doesn't depend on the first. A frontend view that requires that endpoint can sit on top of it. Code being replaced can wait until the new path is working and then disappear in its own cleanup PR.
The important word is actual.
The split is based on the architecture that emerged during implementation rather than the architecture someone predicted before writing the first line of code.
In Adapt's example, a single refactor was eventually divided into five PRs: two backend endpoints, two dependent frontend views, and a final deletion PR that removed the old implementation. citeturn0view0
That would have been tedious to construct manually. With an AI agent doing the first pass, it becomes a much smaller problem.
Narrow PRs Still Matter
The point isn't that large branches are suddenly good.
They're still difficult to review. The reason for building wide is that the messy branch isn't the artifact you intend to merge.
The final PRs should be small enough for a reviewer to understand what changed, why it changed, and what could go wrong.
There's also a useful distinction between mechanical review and engineering judgment.
AI can catch obvious inconsistencies, repetitive mistakes, and certain classes of bugs. It can't decide whether an API boundary will create architectural problems six months from now. It can't take responsibility for whether a trust boundary makes sense. And an AI-generated approval doesn't mean the engineer reviewing the change understands it.
That's why narrow PRs become even more useful in an AI-heavy workflow.
If you didn't personally type every line, reading the code carefully is how you develop ownership of it.
The Rules Get More Interesting Once You Try It
The workflow isn't simply "build everything, then ask AI to make PRs."
There are a few boundaries that matter.
Real dependencies should stay real. If a frontend change genuinely needs a backend endpoint, stack those PRs. Don't pretend they're independent just to make the graph look cleaner.
But don't stack changes merely for convenience. Every unnecessary dependency creates another branch that has to be rebased when someone requests a change lower in the chain.
Cleanup also deserves its own treatment.
If you're replacing an old implementation, don't mix deleting the old code with introducing the new path unless there's a strong reason to do so. Ship the new path, verify it, then remove the old one in a focused change. That makes review easier and gives the team a clean rollback point. citeturn0view0
The final distinction is important too: splitting isn't the same as shipping.
You can create five beautifully structured PRs and still merge them all together. You get the review and rollback benefits, but you haven't necessarily delivered the feature incrementally.
That's fine when the work requires it. The workflow isn't promising that every feature can magically become five independently deployable releases.
It's solving a different problem: making a large amount of exploratory development reviewable without forcing the engineer to predict the final structure in advance.
Where This Workflow Actually Fits
Build Wide, Ship Narrow makes the most sense when the shape of the implementation is uncertain.
A feature crossing several surfaces is a good candidate. So is a refactor where you won't know the right boundaries until you've worked through the code. If you're staring at an RFC and spending an hour arguing about whether something should become PR two or PR three, that's a strong signal.
Some work shouldn't be handled this way.
Production migrations with strict sequencing requirements need that sequencing designed upfront. A schema change that must happen before an application deployment isn't going to become safer because an AI agent reorganized the commits afterward.
The same applies when the implementation has one obvious boundary or when no part of the work can possibly stand alone.
The workflow is useful precisely because it isn't a universal rule.
AI Changes What We Have to Plan
The deeper idea behind Build Wide, Ship Narrow isn't really about Git or PR management.
It's about recognizing that AI has made some engineering tasks dramatically cheaper.
Writing the initial implementation is cheaper. Exploring an approach is cheaper. Iterating on a working feature is cheaper. And, perhaps most importantly, taking a tangled branch and turning it into a sensible sequence of changes is no longer the manual chore it used to be.
That means engineers don't have to optimize their workflow around avoiding a cost that has largely disappeared.
You still plan the product. You still make architectural decisions. You still review code.
But you don't necessarily have to decide how the finished implementation should be sliced before you've built it.
Build wide enough to learn what the system actually needs. Then ship narrow enough that another engineer can understand, review, and safely change what you built.
The structural decision didn't disappear.
You just stopped making it blind.
