The PM's Guide to Reviewing an AI Agent's Plan, Not Its Code

A product manager gets pulled into a pull request and asked to "sign off." On screen is a 600-line diff across four files, in a language they don't write. They approve it, because the sprint is ending and the demo looked fine — and they have no real idea what they just approved.

A PM reviewing AI-generated code is reviewing in the wrong place. A product manager cannot verify a diff they can't read, and the decisions that actually matter — scope, intent, what's explicitly out of bounds — were already made in the plan the agent wrote before any code existed. The PM's review belongs there, where the questions are product questions and a wrong answer still costs a sentence instead of a release.

Key Takeaways

• A PM reviewing a finished diff is reviewing the one artifact they're least equipped to judge. The decisions that were theirs to make happened earlier, in the plan.
• An agent's plan is readable by a non-engineer: it states the problem, the scope, the acceptance criteria, and what it will touch. That is exactly the surface a PM should own.
• The expensive misses are omissions, not bugs — a requirement nobody wrote down. An agent never flags the requirement it was never given; it just builds around the hole.
• Split the review: the PM judges whether it's the right thing to build; engineering judges whether the approach is sound. Both review the plan, for different reasons.
• A sign-off is only worth something if it travels. An approval that lives in one chat session, with no record of who approved what, isn't governance — it's a vibe.

Why a PM reviewing AI-generated code is already too late

By the time there is code to review, every product decision has already been made — by the agent, from whatever the plan did or didn't say. The agent chose the data model, the error states, which service owns the write, what happens on the edge case nobody mentioned. It made those choices silently and shipped them as clean, passing, well-formatted code. A diff shows you the answer, never the question, and the question was the PM's to begin with.

This is why "just have the PM review the PR" quietly fails. A diff is the worst possible format for a product conversation. It assumes the reader can hold the whole system in their head, read the language, and spot the thing that isn't there — the requirement that was never implemented because it was never written down. Even a strong engineer struggles to see an omission in someone else's diff. A PM has no chance, and shouldn't be asked to.

Modern agent workflows make the earlier checkpoint concrete. Tools like Claude Code ship a plan-first mode that keeps the agent read-only while it drafts what it intends to do, and only writes code once a human approves the plan. That approval step exists precisely because the plan is where a human still has leverage. The PM's job is to be the human at that gate — not the one rubber-stamping the diff two steps later.

What a PM can actually judge in an agent's plan

A good agent plan is written in product language before it's written in code. It states the outcome, the scope, what's out of scope, the acceptance criteria, and the parts of the system it expects to touch. Every one of those is something a PM is better positioned to judge than any engineer — because they're questions about intent and value, not implementation. The plan is the first artifact in the whole workflow a non-engineer can read end to end.

That changes the PM's role from reviewer-of-last-resort to the person who owns the top half of the plan. Is this the problem we agreed to solve? Is the scope what we scoped, or has it quietly grown a feature? Do the acceptance criteria describe behaviour a user would actually notice, and can each one be checked? These are not technical questions. They are the questions a PM answers every day — the agent has just written them down in a place where answering them is still cheap.

The split matters. A PM who starts trying to judge the implementation ("should this be a queue or a cron job?") is back in the diff, out of their depth, and adding noise. A PM who stays on intent, scope, and acceptance criteria is doing the one review no one else in the room is equipped to do. Reviewing the plan isn't a watered-down version of reviewing the code — it's a different job, and it's the PM's. The companion piece on what an agent actually needs to execute covers the fields that make a plan reviewable in the first place.

The PM's plan-review checklist

Run this on the agent's plan, before it writes a line of code. It's six passes, each one a product question with a yes/no answer. If any answer is "I'm not sure," that's not a reason to approve anyway — it's the exact thing to send back.

1. The problem. Does the plan restate the problem in a way you recognise? If the agent's framing of why this work exists doesn't match yours, every decision downstream inherits the mismatch. Correct the framing here, not after it's built.
2. The scope — both sides. Is the in-scope list what you agreed, and is there an explicit out-of-scope list? The out-of-scope list is the one that stops an agent from "helpfully" refactoring an adjacent feature or adding a setting no one asked for. A plan with no out-of-scope section hasn't been bounded.
3. Acceptance criteria you can test. Can each criterion be checked by someone who isn't the author? GitHub's open-source Spec Kit frames these as "Given [initial state], When [action], Then [expected outcome]" and requires success criteria be "technology-agnostic and measurable." If a criterion can't be read as a test, it isn't one yet.
4. The missing requirement. Read for what isn't there. What does a real user need that the plan never mentions — the empty state, the permission check, the "what happens to existing data" question? Omissions are where agents fail, because an agent never asks for a requirement it was never given.
5. The flagged unknowns. Does the plan say where it's guessing? A plan that marks its own gaps — Spec Kit uses a literal [NEEDS CLARIFICATION] marker — is safe to hand to an executor. A plan with no unknowns on a non-trivial task is usually hiding them, not free of them.
6. The blast radius, in plain terms. Not how it's built, but what it touches — which users, which data, which existing behaviour could change. You don't need to read the code to ask "does this affect anyone already using the old flow?" and an honest plan answers it.

The checklist is deliberately short because a review that takes an hour won't happen every time, and the value is entirely in doing it every time. Six questions is a thing a PM can run on a plan in ten minutes and still catch the error that would have cost a release.

The five questions that catch the expensive misses

The costly failures in agent-built work are almost never a bug the agent introduced — they're a decision the agent made because no one made it first. These are omissions, and they don't show up in a diff as red lines. They show up as code that works perfectly and does the wrong thing. A few blunt questions surface them while they're still free to fix.

Take a concrete shape of this. An agent is asked to swap in a new payment processor and drafts a tidy plan: update the integration, migrate the config, handle the webhooks. It reads as complete. But nowhere does the plan say how money actually gets collected under the new processor — because the ticket never said, and the agent had no way to know that mattered. A PM who understands the intended change reads the plan and immediately asks the question the agent couldn't. That one question is the entire value of the review.

The five that earn their place:

• "What happens to the data/users that already exist?" — migrations and backfills are the classic silent omission.
• "What's the behaviour when this fails?" — agents optimise the happy path and leave error states implicit.
• "Who is allowed to do this?" — permissions and access rarely make it into a thin ticket.
• "What did we decide not to do here, and does the plan respect that?" — catches silent scope creep.
• "Where in this plan are you guessing?" — forces the unknowns into the open, which is the whole point of reviewing early.

None of these requires reading code. All of them are things an agent cannot ask on your behalf, because the answer lives in product context the agent was never given. This is the same reason agentic teams need collaborative planning rather than a better prompt — the gaps are social, not technical, and a human has to close them before the build.

Plan review is a product decision, not a code review

Reframing the PM's involvement as plan review instead of code review isn't a demotion or a dodge — it moves the review to where a product decision is still a decision. A pull request is a record of decisions already taken. A plan is a proposal, and a proposal can be changed by a sentence. The cheapest moment to redirect an agent is before it has written anything; the most expensive is after it has shipped, and every step between those two only raises the price.

It also fixes the accountability problem that approving a diff creates. When a PM approves a PR they can't read, the approval is theatre — it transfers blame without transferring any actual judgment. When a PM approves a plan they can read, the approval means something: they are vouching for the product decisions, which are the decisions that were theirs. Engineering still vouches for the approach and the blast radius. Two people sign off on the two halves each is qualified to judge, and neither is pretending.

That division is exactly what a formal spec approval workflow encodes — who signs off on what, before the agent builds, so that "approved" is a specific claim by a specific person rather than a shrug at the end of a sprint.

Where the PM's sign-off has to go next

A plan review is only worth the time if the approval survives contact with the rest of the toolchain. The failure mode here is subtle: the PM reviews the plan carefully, approves it in a chat window, and then the agent runs — and the approved plan and the thing that actually gets built drift apart with no record connecting them. Three weeks later, when someone asks "who approved this and against what plan?", the answer is a scrollback no one can find.

For the review to count, the approved plan has to be the artifact the agent builds against, the sign-off has to be attached to a specific version of that plan, and both have to travel into the tools where the work actually happens — Jira, Linear, the coding agent itself. Otherwise the PM's review is real but unenforceable: nothing stops the plan changing after approval, and nothing proves it didn't. Keeping one approved plan traceable from review through to the agent's output is the connective layer Enact is built to provide.

Reviewing the diff felt like the PM's job because it was the step with a big "Approve" button on it. But the button is in the wrong place. Move the review upstream to the plan, run the six-question checklist, split the sign-off with engineering along the line each side can actually judge, and make sure the approval travels with the work. The agent will still build fast — it'll just be building the thing you actually reviewed.