Adapt engineer: build the whole feature, split into PRs later

The traditional engineering workflow writes an RFC, splits it into issues, then builds each piece in a locked-in order decided before any code exists. That upfront split was never about making the build easier, the author writes; it was the only affordable way to keep code review manageable, because untangling a week of finished, tangled work by hand used to be the most tedious part of the job.

Three things got dramatically cheaper with AI coding tools, per the post: turning a clear problem into working code (hours, sometimes minutes), reshaping a design at conversation speed, and, the one that matters most here, decomposing a finished branch into a sequence of small pull requests. That last step is now a prompt. Two things did not get cheaper: the judgment half of code review (agents handle the mechanical half, consistency, nits, obvious bugs, nearly for free, but not whether a change belongs where it is or whether an endpoint shape will hurt in six months), and product validation, meaning running the thing and deciding it is the right thing to build.

The workflow the author now follows: interrogate the plan with a tool called grill-me, an adversarial-questioning skill that surfaces gaps such as missing API failure handling; commit a written spec before any code when the design is novel (on one project the first PR was a design document that merged days before implementation began); build the whole feature on a single branch, treating commits as save points rather than review milestones; demo the working result, a short Slack video or a preview deployment, before any code review starts; and only then run a specific prompt asking to split the finished work into the smallest set of independently reviewable PRs, creating a git worktree and branch for each, stacking a PR on another only where a real data dependency exists, and putting any deletion of replaced code into its own final PR.

One refactor the author describes came out as five PRs: two backend endpoint PRs branched as siblings off main, two frontend view PRs each stacked on top of the backend PR whose data it needed, and a final PR that was pure deletion of the old code path, removing several hundred more lines than the whole feature had added.

At Adapt, the company the author works for, an AI agent built on Adapt's own product reviews the resulting PRs: it comments within minutes of a PR opening, and the exchange of questions, clarifications and a small fix that follows typically resolves in under ten minutes, but only for a PR small enough to read quickly, not a large one mixing several concerns. Two costs come with the approach. Rebasing: when a reviewer requests a change on a PR that others are stacked on, every branch above it needs rebasing, though the author notes the chat session that produced the original split can be reused to update the branches instead of doing it by hand. And splitting is not shipping: as the post was written, all five PRs from the example refactor were still open, so the team still had to decide what to merge and when, and nothing had reached a user any earlier than a single batched deploy would have.

The author frames this as a good fit for multi-surface features that cross backend and frontend, for refactors whose final shape is unclear until they are built, and for any work where the alternative is guessing at issue boundaries in advance. It fits poorly for migrations and schema changes that must be sequenced in production, where the ordering is real and should still be planned first, and for features that cannot ship in pieces at all, where late decomposition buys only easier review and nothing more.

Key facts

• The author's new workflow: interrogate the design with a grill-me skill, build the whole feature on one branch, demo it before any code review, then run a prompt that splits the finished branch into independently reviewable PRs.
• One described refactor came out as five PRs: two backend endpoint PRs as siblings off main, two frontend view PRs each stacked on the backend PR it depends on, and a final PR that was pure deletion, removing several hundred more lines than the whole feature had added.
• At Adapt, an AI reviewer agent comments on a new PR within minutes, and the resulting exchange of questions, clarifications and a small fix resolves in under ten minutes, but only when the PR is small enough to read quickly.
• Two costs of the approach: rebasing every branch stacked above a PR that gets review feedback, and the fact that splitting is not shipping, all five PRs from the example refactor were still open as the post was written.
• The author says the approach fits poorly for migrations and schema changes that must be sequenced in production, where planning the order in advance is still necessary.

Why it matters

The post challenges a piece of settled engineering wisdom, plan the PR structure before you build, by arguing that AI coding tools removed the specific cost that made upfront planning worth it: untangling a finished, tangled branch into small reviewable pieces by hand. If decomposing a branch is now a prompt, the argument goes, locking in structure before any code exists trades away information you would otherwise have when the code is already in front of you.

Who it affects

Software engineers and teams already using AI coding assistants for implementation, particularly on multi-surface features that span backend and frontend, or on refactors whose final shape only becomes clear once the work is done. It also assumes a team comfortable reviewing work from a demo, a Slack video or preview deployment, before any PR exists.

How to use it

The described sequence: interrogate the plan adversarially before touching the editor (the author's tool for this is called grill-me); write and merge a spec document first if the design is novel; build the entire feature on one branch, using commits only as personal save points; demo the working result before any code review; then run a prompt instructing an agent to split the finished work into the smallest set of independently reviewable PRs, one git worktree and branch per PR, stacking only where a dependency is real and putting deleted code in its own final PR. No pricing or product tier is mentioned in the piece.

How solid is it

This is one engineer's account of a workflow at Adapt, illustrated with a single worked example (a refactor that became five PRs) and described as tested informally across a few projects, not a controlled study. Adapt is also the company whose own AI product the author uses as the PR-reviewing agent, so the piece doubles as an account of Adapt's own tooling in use.

Risks and caveats

The author names two direct costs: a PR that gets review feedback forces every branch stacked above it to rebase, and splitting finished work into PRs is not the same as shipping it, in the example given, all five PRs were still open and unmerged at the time of writing. The author also flags that the approach fits poorly for migrations and schema changes that must be sequenced in production, and for features that cannot ship in pieces at all, where the late split buys easier review but no incremental delivery.

“Splitting is not shipping.”

— the post's author, an engineer at Adapt