You spend three days on a big feature and open a pull request with 40 changed files. Your reviewer reads it and says "this should have been built on the existing notification module". They are right, and now the choice is between a rewrite and merging something the team doesn't want.
The pull request is the most expensive place to find a design problem. By then the code is written, the tests are written, and everyone is reluctant to throw the work away.
Move the design review to the front. For any complex feature, write a short implementation plan first and get a teammate to review it before you write code. This is front-loading the review: the big questions are answered at the plan, and the pull request only has to confirm that the code matches the agreed plan.
AI coding agents make this more important, not less. An agent can produce a large, working, wrong implementation in an hour. It can also produce a detailed plan in a few minutes, so having a plan to review costs almost nothing.
A plan is cheap to change - Rewriting a paragraph takes a minute. Rewriting a feature takes days
The reviewer sees the approach, not the noise - One page of decisions is easier to judge than 40 files of diff
The reviewer brings what you don't know - Existing modules, past attempts, upcoming changes and client constraints rarely show up in the code you are reading
The pull request review gets faster - The reviewer already agreed with the approach, so they only check the execution
Nobody has to reject finished work - Reviewers often approve a questionable design because the code already exists. At plan stage, saying "do it differently" is easy
Not everything. A typo fix or a small bug doesn't need a second pair of eyes before you start. Ask for a plan review when the work:
Takes more than a day or two
Changes the data model, a public API or a contract between services
Crosses module or team boundaries
Introduces a new library, pattern or piece of infrastructure
Can be solved in several reasonable ways and you had to pick one
Touches an area you don't know well
Keep it to what a reviewer needs to judge the approach. One or two pages is enough:
The problem - A link to the PBI and the acceptance criteria
The approach - What you will build and how it fits into the existing code
Alternatives you rejected - And why, so the reviewer doesn't suggest them again
What changes - Data model, API, files and modules affected
Risks and open questions - What you are unsure about. This is where the reviewer helps most
How you will test it
Out of scope - What you are deliberately not doing
If an AI agent wrote the plan, review it yourself first. See Do you review your AI coding plans? Never send a teammate a plan you haven't read. Their time is for the things you couldn't catch on your own.
Write the plan, or have your AI agent write it in plan mode, and review it yourself
Share it where the team can comment - on the PBI, in a draft pull request that contains only the plan file, or in a plan review tool
Ask a specific person, ideally someone who knows that part of the system. Tell them what you are least sure about
Update the plan with what you agreed, and record who reviewed it
Start coding. Link the plan in the pull request description so the code reviewer can compare the two
Keep the review short. A plan review is a 15 minute conversation, not an approval gate that blocks work for days. If the reviewer can't get to it today, ask someone else.
Bob picks up the "Export invoices" PBI
Bob and his AI agent build it over three days
Bob opens a pull request with 40 changed files
Alice reviews it and points out that the reporting module already has an export pipeline
Bob rewrites most of the feature
❌ Figure: Bad example - The approach is reviewed for the first time in the pull request, after the work is done
Bob picks up the "Export invoices" PBI
Bob and his AI agent write a one page plan in 20 minutes
Alice reviews the plan and points out that the reporting module already has an export pipeline
Bob updates the plan in 5 minutes and builds on the existing pipeline
Bob opens a pull request that links the plan. Alice only checks that the code matches it
✅ Figure: Good example - The approach is reviewed at the plan, where changing it costs 5 minutes
It will. You find things during implementation that nobody saw in the plan. Small deviations are fine - note them in the pull request description. If the approach itself changes, go back to your reviewer before you continue. A surprise in the pull request is exactly what the plan review was meant to prevent.