The Vibe Father
GitHub’s August 4 guidance addresses a familiar agent-era failure mode, one sprawling pull request that contains data modeling, APIs, prompting, UI, tests, and cleanup in a single review. Its answer is stacked pull requests—small dependent changes, each with one concern and its own review surface.
The technique matters more when an agent writes quickly. A large diff can be syntactically clean, fully formatted, and still be impossible for one reviewer to reason about. The issue is not that the code came from an agent, it is that the delivery shape removes the boundaries humans need to validate it.
Turn one feature into a reviewable chain
Instead of asking an agent to “build the feature,” give it a chain of deliverables. A product-search example might become, a typed data layer, then a validated API, then the agent or chat integration, then the interface that presents grounded results. Each pull request depends on the previous one, so reviewers can judge the data contract before debugging the UI built on top of it.
| Layer | What reviewers can prove |
|---|---|
| Foundation | Types, schema, fixtures, and validation rules are correct. |
| Service | The API behaves correctly against known inputs and failures. |
| Agent integration | Tool calls, grounding, and error behavior follow the service contract. |
| Experience | The UI presents the result clearly without hiding upstream failures. |
Give agents a layer contract
For every layer, specify the allowed files, dependencies, test command, and “not in this change” list. This prevents the agent from solving an inconvenient problem by reaching across the entire stack. It also makes a bad run recoverable, discard one branch or revise one layer without losing the whole feature.
- Write the dependency order before implementation starts.
- Give each layer a single owner—human or agent—and a narrow definition of done.
- Require tests at the layer where behavior is introduced.
- Review and merge from the bottom of the stack upward.
- When a lower layer changes, rebase or regenerate the dependent layers and rerun their checks.
Keep the human review where it pays off
Stacking does not eliminate review, it concentrates it. A data owner can review the foundation while an API owner evaluates the service, rather than both trying to decode a thousand-line composite diff. Automated code review can flag local issues, but it cannot decide whether the stack’s boundaries match the product’s risks. That remains an engineering judgment.
GitHub also calls out a practical caveat, a web-based stack rebase can alter commit authorship and signing behavior. If signed commits or a particular provenance trail matter to your branch protection, test the rebase path before making it the default automation.
Trend signal
In the August 4 U.S. Google Trends snapshot through Kimi WebBridge, broad searches for Codex, Cursor, and Claude Code were all active. The values are relative and the terms are imperfect, but the workflow implication is plain, as more teams delegate implementation, review structure becomes a first-class part of the harness.
Bottom line
When an agent can generate a large change in an afternoon, asking a human to review it all at once is not a serious control. Break the work into dependency-ordered pull requests, make the acceptance test for each layer explicit, and preserve a reviewable story from the first commit to the merge.
