Writing code used to be the bottleneck. It isn’t any more. A developer can generate a change in seconds; the effort to understand it has barely moved. As Michaela Greiler puts it, code can now be generated faster than people can meaningfully understand and verify it.
So the time your team spends has shifted from writing changes to reviewing them. Addy Osmani’s line captures it: if your pull request doesn’t contain evidence that it works, you’re not shipping faster, you’re moving work downstream. The numbers behind why review latency moved in the first place and the wider map of the verification collapse are covered separately.
This article walks through four levers, each a different kind of fix: stacked pull requests (structure), intent-driven verification (information), context and harness engineering (input quality), and the decision of where to invest.
What are stacked pull requests, and do they actually fix review latency compared with one large PR or feature flags?
Stacked pull requests are a sequence of small dependent PRs, each targeting the branch below it, each reviewable in isolation, and merged in order. The verdict: they reduce per-review load and the time until a reviewer’s first substantive comment, but add coordination cost and depend on tooling.
GitHub’s engineering team frames this as reducing review scope rather than accelerating review itself. One large PR hands a single reviewer unbounded cognitive load in one long round trip; a stack splits that work into bounded, parallel-reviewable units. Feature flags solve a different problem: they decouple deploy from release. Rootly dropped its small-PR rule once blast radius was controlled by rollout. A flag is a release control: it gates when unreviewed code ships, and does nothing to make that code easier to review.
Does stacking fix latency? Partly, and only with tooling. GitHub’s native support is still in public preview, and merge queues and dependent branches remain the friction points. The workflow of slicing, ordering and rebasing layers carries the friction: a change to a lower layer cascades a rebase and re-runs CI through every layer above it. For distributed teams the payoff is clearest, because a single round trip costs a calendar day when the reviewer is asleep; reducing round trips matters more than raw speed.
Published stacked-PR material skews to the largest organisations. The empirical record for small and mid-size companies is thin, and the closest small-team evidence is a single team reporting its queue draining, not measured numbers. Treat stacking as a hypothesis to instrument, and consider risk-based routing inside a stack.
What is intent-driven verification, and how do I make author-side verification visible before a change reaches a reviewer?
Stacking restructures the load but doesn’t remove the moment a reviewer first understands a change. That is where intent-driven verification comes in.
Intent-driven verification means the author declares, before a reviewer is asked to look, what the change is meant to do and what evidence shows it does that. Evidence is attached as named checks, and the reviewer checks the delta between intent and implementation.
Even a small diff leaves the reviewer as the first person who actually understands the change. The reviewer’s job is to decide whether this is the right change, and answering it takes three things: what the change intends, what it deliberately does not do, and what evidence shows the intent is met. The New Stack describes it as writing the session’s decisions down as acceptance criteria before the change is submitted.
Intent has to be recorded at authoring time, not reconstructed afterwards; a form filled in after the fact reproduces the same problem. The payoff is legibility: the reviewer reads a few lines of decisions rather than hundreds of lines of code. This is the remedy for reviewer exploitation, when you feel you are doing all the understanding yourself.
Intent plus named evidence makes Conditional LGTM (‘looks good to me’) workable: approval contingent on named checks rather than impression, so a green tick means something specific. One example is Cloudflare’s review orchestration, which maps approval to stated conditions. Agents can be made to produce intent and evidence as part of the task, as GitHub’s stack guidance shows. That means controlling what the agent saw, which is context engineering.
What is context engineering, and why does it change what arrives at review?
Context engineering is deciding what the model sees before it acts: the relevant files, repository conventions, architectural constraints, prior decisions and explicit exclusions. It changes review because an under-contextualised agent produces plausible code that ignores local reality, leaving the reviewer to discover every unstated constraint.
LinearB defines it directly: prompting is what you say to a model, context engineering is what the model can see when you say it. The discipline works by subtraction. You trim context down to what is relevant, and relevance, rather than raw capacity, sets the limit. When context is compressed into a single prompt, models fill the gaps with assumptions from public training data, producing code that is technically plausible but organisationally wrong.
Alongside context sits harness engineering: tests, linters, sandboxed execution and guardrails that constrain what a model can produce regardless of what it was told. Context is what you say, harness is what you enforce. Enforcement is often the higher-leverage half, because it does not degrade with model variance.
The second-order cost of getting context wrong is cognitive debt, the gap between how the system works and how much of it your team can hold in its head. It shows up when something breaks and nobody knows where to look. That leads to the investment question the next section takes up: context engineering or better review tooling, and how the fixes stack up.
Context engineering vs better review tooling: which investment moves first-pass quality more?
Context engineering moves first-pass quality more. First-pass quality is the quality of a change as first submitted. Context engineering reduces what is wrong in the diff in the first place, while review tooling only finds more of what is already wrong.
Tooling is buyable and fast, but it is replaced when you switch vendors. Context work is slow and organisation-specific, but it compounds across every model and tool you later adopt. No reviewer, human or machine, recovers time spent on changes that should never have been authored that way.
The limits run both ways. Tooling does real work. One illustration, Microsoft’s internal deployment, caught real bugs. But independent benchmarks put top agents at 40 to 70 per cent false-positive rates, and benchmarks published by vendors favour the vendor. Context engineering has almost no benchmarks at all, which quietly biases procurement towards the buyable option.
For what tooling can and cannot cover, see the AI review tool comparison.
Conclusion
Review load is created upstream and detected downstream. Stacking and review tooling operate on a diff that already exists, so they can only recover part of the load. The durable levers stop bad changes being authored: intent captured before review, context decided before authoring. The question becomes “what should this change have been, and what did the author or agent actually see when it was made”. For the full set of fixes and where they fit, see the pillar article.
Frequently Asked Questions
What is the difference between a stacked pull request and simply splitting a large change into several pull requests?
A stack is ordered by dependency, not just divided by size. Each pull request targets the branch below it and merges in sequence, so a reviewer can read one layer in isolation while knowing exactly what it rests on. Independently split pull requests can land in any order and often still hide shared assumptions. Splitting reduces size; stacking also makes the dependency structure explicit.
How small should each pull request in a stacked series be?
Small enough that one reviewer can hold the whole change in their head in a single sitting, which usually means one logical change rather than a target line count. Coherence matters more than a number: a layer should be independently understandable, reviewable and revertible. If a layer needs a paragraph of setup before it makes sense, it probably belongs lower in the stack.
What happens if a reviewer asks for changes to a lower layer of the stack?
Every layer above it has to be rebased and re-run through CI, which is the coordination cost stacking quietly adds. That cascade is why stacks are shaped so the lowest layers are the most stable and the least likely to change. Where a lower layer is genuinely uncertain, review it first and in isolation before the upper layers are written.
Do I need special tooling to run stacked pull requests?
Not strictly, but tooling is what makes the workflow tolerable at scale. GitHub has been shipping native stack support in public preview alongside merge queues, and behaviour there may still change. Without it you manage branches, retargeting and per-layer CI by hand, which is workable for two or three layers and painful beyond that.
Isn’t intent-driven verification just a pull request template with extra fields?
No. A template is a container; the principle is about timing and evidence. Intent has to be recorded when the change is authored, not reconstructed by the reviewer afterwards, and it has to be paired with named checks showing the intent was met. A template can host that, but a form filled in after the fact reproduces the same problem.
What counts as a named check in conditional LGTM?
A named check is a specific, individually visible piece of evidence tied to a claim in the stated intent: a reproduction test that now passes, a trace showing the new path, a migration dry run, a screenshot of the fixed state. Approval becomes contingent on those names rather than on a reviewer’s overall impression, so a green tick means something specific.
Does context engineering just mean writing longer, more detailed prompts?
No, and longer is often worse. Context engineering is about what the model can see, not how much you say: the relevant files, repository conventions, architectural constraints, prior decisions and explicit exclusions. Padding a prompt with more prose adds noise and competes for attention. The skill is selection and exclusion, not volume.
What is cognitive debt, and why does it matter for review?
Cognitive debt is the shared understanding a team loses when changes arrive faster than anyone internalises them. Review can look healthy while nobody can explain how the system fits together, and the cost surfaces later as slower changes, duplicated work and longer incidents. It is the second-order effect of reviewing diffs without ever absorbing them.
How do I tell whether context engineering is actually reducing review load?
Measure what reaches review rather than how fast review runs: first-pass approval rate, the mix of comment types, and how often reviewers raise constraints the author should have known. Constraint-discovery comments, the “this breaks our caching layer” kind, are the signal to watch. They should fall. Published benchmarks for this are scarce, so instrument your own.
Where can I find peer case studies from companies of 50 to 500 engineers that have redesigned review?
Honestly, they are scarce. Most published stacked-PR material comes from very large organisations with dedicated developer-productivity teams, whose constraints differ from those of a 200-person company. The practical substitute is generating your own evidence: instrument review latency and rework before and after, and treat any borrowed case study as a hypothesis to test rather than a template to transplant.
How do I get an AI agent to state its intent and evidence before it opens a pull request?
Ask for it as part of the task, not as a follow-up. The same harness that generates the change can be required to output what it was asked to do, what it deliberately excluded, and which checks it ran, then attach those to the pull request as named checks. If the agent cannot state its intent, that is itself a signal the context was too thin.
