Adapt Proposes 'Build Wide, Ship Narrow' Workflow to Decouple Coding from Review
The new method uses AI agents to decompose large, experimental feature branches into small, reviewable pull requests.
Adapt.com has proposed a new software development workflow called "Build Wide, Ship Narrow," which fundamentally changes when engineers decide how to slice a feature into pull requests. The method advocates for building entire features on a single "scratch" branch to discover actual boundaries through implementation, then using AI agents to decompose that work into focused PRs for human review.
The workflow follows a six-step process: grilling the plan, committing the spec, building wide on a single branch, demoing and iterating, splitting the work into PRs via AI, and merging with a final cleanup PR. According to the Adapt Blog, the goal is to shift structural decisions from the planning phase to the post-implementation phase. The author summarizes the philosophy: "Decide what to build before you build it; decide how to slice it after."
The Shift from Pre-Planning
Traditionally, engineers use Request for Comments (RFCs) to split features into small issues before coding begins. This ensures that reviews remain manageable and atomic, but it requires developers to make structural decisions at the moment they know the least about the problem.
By contrast, the "Build Wide" approach treats the initial build branch as "scratch paper" that is eventually thrown away. This allows the developer to prioritize working software and discovery over pre-planned boundaries. The rise of AI assistants has made the process of building and decomposing code significantly cheaper, enabling this decoupling of the build process from the review process.
AI-Driven Decomposition
To avoid the tedious manual labor of breaking a large branch into smaller pieces, the workflow leverages AI agents. These agents automate the mechanical aspects of code review and the process of splitting a tangled branch into multiple small, focused PRs.
To maintain stability, the method includes specific rules for shipping. The author recommends "stacking" PRs only when a genuine dependency exists—such as a frontend component depending on a backend API—to avoid complex rebase chains. Additionally, a key rule of the method is that any code deletion or cleanup must be shipped in its own final PR only after the new path is live.
Industry Implications
This approach attempts to resolve the tension between the need for atomic PRs for safety and the reality of "tangled" development where boundaries are discovered during the act of coding. By separating the developer's needs during implementation from the reviewer's needs during audit, the workflow aims to reduce the time reviewers spend on incorrect implementations and accelerate feedback loops through early demos.
What's Next
As teams integrate more AI agents into their CI/CD pipelines, the viability of this workflow depends on the reliability of AI-driven decomposition. Developers will need to monitor whether AI-split PRs maintain the same logical coherence as human-sliced ones and if the "scratch branch" approach reduces the overall time from first commit to production merge.