The PR queue keeps getting longer. The feedback in it keeps getting more painful. Both have the same root cause, and it isn't agents writing too much code — it's that every alignment touchpoint that used to be spread across the week has collapsed onto the pull request, which was never built to carry that weight.
1. Alignment used to be distributed; now it isn't
Where teams converged on "what are we building" two years ago:
| Stage | Where alignment happened | Cost of being wrong |
|---|---|---|
| Scoping | Slack thread, ten messages | Free |
| Design | A whiteboard, a Figma comment | Cheap |
| Approach | Draft PR with stub commits, two reviewers | Cheap |
| Implementation | Comments on intermediate commits | Moderate |
| Final review | PR approval | Expensive |
Cheap touchpoints early, expensive ones late, and most of the alignment work happened before the implementation was real. By the time the PR landed, the team had been on roughly the same page for days.
Where it happens when an agent writes the PR:
| Stage | Where alignment happens | Cost of being wrong |
|---|---|---|
| Scoping | A two-line prompt | Free |
| Design | (skipped) | — |
| Approach | Local plan mode, no one else sees it | — |
| Implementation | (fifteen minutes, nobody looks) | — |
| Final review | PR approval on completed code | Very expensive |
Every cheap touchpoint disappeared. The expensive one stayed and is now carrying all the work the cheap ones used to do.
2. The PR was never the alignment checkpoint
The pull request was designed as a code review checkpoint — an answer to "is this implementation correct, well-named, well-tested, free of foot-guns." It assumed the team already agreed on what was being built. That's why "this should have been three smaller PRs" feedback feels so unfair: the reviewer is being asked to re-litigate a scoping decision at the most expensive possible moment.
When alignment touchpoints upstream of the PR existed, the PR could stay narrow. Strip those touchpoints away and every PR review balloons into a "do we even want this?" forum — a fight the PR template can't run.
Symptom check: if your last three PR reviews ended with "let's revisit the approach," you don't have a code review problem. You have a missing-upstream-checkpoint problem.
3. The cheap signals you stopped sending
Three of them, all small, all gone.
- "I'm about to touch X." The offhand Slack note that prevented two people from grabbing the same file. Fifteen seconds to send, an hour of merge conflict avoided.
- "Here's my plan, anyone object?" The half-formed approach pasted into a thread before any code was written. Reviewers have no context on whether the approach is right when they see it for the first time inside a 600-line diff.
- "I'd do it differently." The senior dev's drive-by suggestion when they saw a junior wandering toward a known-bad pattern. With local plan mode, no one wanders past the screen.
None of these are technical problems. They're attention-routing problems, and they used to be solved by the fact that work was slow enough to be visible.
4. Shift-left patterns that don't need new tools
Things you can do today on the stack you already have.
Plan-first commits
Make the agent's first commit on every branch a PLAN.md at the repo root, before any implementation. Open a draft PR with that commit alone. Get plan review on the markdown — the diff is small, and the cost of "scrap this and try again" is minutes of a model's time, not a day of a human's. Implementation commits land on top of the same branch once the plan is signed off.
By the time the PR is non-draft, you're back to reviewing code, not strategy.
When not to use it: trivial PRs — typo fixes, dependency bumps, one-line config. The plan ceremony costs more than the code review.
File-level intent locks
A #dev-intent channel where humans and agents both announce the directory they're about to touch:
maya: starting refactor on src/api/billing/* (~1hr)
agent-mark: touching src/components/Checkout.tsx for the address form
No tooling required. The discipline is: scan it for ten seconds before kicking off an agent. That ten seconds buys you the merge conflict you didn't have.
When not to use it: if your team is three people, this is overkill — you'll just yell across the desk. The pattern starts paying off around eight concurrent contributors.
The plan-or-code rule for review feedback
Train reviewers and yourself on one question: would this same comment have made sense on a plan, before any code existed? If yes, the comment belongs upstream of the PR, and the system that produced this PR is broken.
This is a metric, not a workflow change. Track it for two weeks. If half your PR comments are plan-shaped, you've quantified the missing checkpoint.
Draft PRs as planning surfaces
Every agent-driven branch opens a draft PR immediately, with the plan as the body. The PR description is the artifact under review for the first hour of the branch's life — not the code. Comments on the description ("I don't think this approach handles the multi-tenant case") get answered before the agent writes anything substantive.
When not to use it: when the work is small enough that the plan is "do the obvious thing." Don't mandate plan review on changes that don't have an interesting plan.
5. Plan reviews are cheaper than code reviews
The asymmetry is the whole point.
| Review target | Cost to fix a "wrong direction" comment |
|---|---|
| Plan (markdown, 200 lines) | Edit the markdown. Minutes. |
| Implementation in flight | Stop, re-prompt, re-run. Tens of minutes. |
| Completed PR (1,200 lines, tests written) | Throw out the branch. Hours to a day. |
| Merged code in production | Migration, rollback, postmortem. Days to weeks. |
A plan review that catches "we should not be building this at all" is the highest-leverage review in the entire pipeline, and almost no team explicitly schedules it.
6. The decision rule
When a piece of PR feedback shows up, ask:
| Question | If yes | If no |
|---|---|---|
| Could this comment have been made before any code was written? | Plan-review failure. Move it upstream. | Genuine code-review feedback. |
| Is the comment about what we're building, not how? | Plan-review failure. | Implementation comment. |
| Does fixing it require throwing out the implementation? | Plan-review failure. | Refactor in-place. |
| Would a senior on the team have flagged this in a hallway conversation? | Plan-review failure. | Fine where it is. |
Plan-review failures stack. Each one is a sign that the upstream checkpoint is missing or being skipped, not that the PR review process is broken.
7. What you can't fix without better tools
A #dev-intent channel is a workaround for ambient awareness, not a replacement. A draft PR with the plan in the body is a workaround for shared planning surfaces. These patterns buy you most of the value at three or four concurrent agents per developer. They start to fray around ten, where the broadcast cost itself becomes the bottleneck and you need infrastructure that surfaces work proactively rather than relying on humans to remember to announce it.
Several teams are building that infrastructure now. None of it is generally available yet. Plan for it; don't wait for it.
The pull request is a checkpoint, not a forum. Every minute of "what are we even building" debate that happens inside one is a minute spent in the wrong room, with the wrong artifact, at the wrong stage of the work.