Build Wide, Ship Narrow | Blog<br>Table of contents<br>What changedDesign still goes firstBuild wideDemo before anyone reads the codeShip narrowWhat it bought, what it costsWhen to reach for it

Share this article<br>X IconLinkedIn Icon

Get $100 in free credits when you add Adapt to Slack.<br>Get started

Work AI

Aug 6, 2026<br>Build Wide, Ship Narrow

Bruno Quaresma<br>Product Engineer

Table of contentsWhat changedDesign still goes firstBuild wideDemo before anyone reads the codeShip narrowWhat it bought, what it costsWhen to reach for it

li]:marker:font-medium [&_table]:w-full [&_th]:border [&_th]:border-border-subtle [&_th]:px-12 [&_th]:py-10 [&_th]:text-body-regular [&_th]:font-medium [&_th]:text-content-primary [&_th]:text-left [&_td]:border [&_td]:border-border-subtle [&_td]:px-12 [&_td]:py-10 [&_td]:text-body-regular [&_td]:text-content-secondary [&_td]:text-left [&_pre]:bg-bg-secondary [&_pre]:border [&_pre]:border-border-subtle [&_pre]:rounded-md [&_pre]:p-16 [&_pre]:overflow-x-auto [&_code]:font-mono [&_code]:text-body-regular [&_h2]:scroll-mt-20 [&_table_p]:!text-body-regular [&_hr]:border-border-subtle">Good engineers plan before they build. The workflow I grew up seeing: write an RFC describing the feature, split it into smaller issues, then build them, each issue often blocking the next. The structure of the work was locked in before a single line of code existed.

This is reasonable. It keeps code reviews manageable and avoids big-bang merges. 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. And the one that matters most here, 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, which is exactly why we avoided it. It's now a prompt.

Two things didn't get cheaper. The first is 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.

The second is 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.

My workflow now 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 I touch the editor, I have a plan, and every feature starts with an interrogation. I run grill-me, a skill that interviews you about your idea in adversarial rounds until it has real decisions in it. What's the fallback if the API call fails? I run it on everything, including small changes, and it keeps surfacing gaps I didn't know were there.

When the design is novel, the plan becomes a spec committed before any code. On a different 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, I build. I often work in steps, but I 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...