How to Approve AI Coding Plans Before Execution

Approve an AI coding plan only when it states the intended outcome, boundaries, important implementation choices, risks, and validation well enough for the agent to proceed. Open-source Plannotator can pause a supported coding agent, show the Markdown in your browser, and return Approve or Send Feedback to that local session. Keep a shared authorizing record in Git, an issue, a pull request, or another document system when the decision must be available to the team.

​

Decide how much review the change deserves

Start with the AI coding plan template. If the document needs to stay current after implementation, use the technical specification template as a separate maintained record. If the request still contains major unknowns, use the iterative planning workflow to explore the codebase, interview the human, and test the riskiest assumption before submitting a plan for approval.

​

What happens during plan review

For agents that support automatic plan review, the plan-mode hook starts Plannotator and opens the proposed Markdown in your browser. You can:

• select text and add a comment;
• mark text for deletion;
• edit the Markdown directly;
• add overall feedback;
• approve the current plan; or
• send feedback to the agent.

Choose Approve when the current plan needs no changes. Plannotator returns an approval result to the blocked agent session so the agent can continue. Choose Send Feedback when you added comments, deletions, edits, or overall feedback. Plannotator formats that feedback and returns it to the agent. The agent can then revise and submit another plan.

​

Review the plan before you approve it

A useful plan gives you enough information to find a wrong assumption before the agent changes code. Check the parts that could change the implementation:

• intended behavior and explicit non-goals;
• affected files, services, data, or APIs;
• security and compatibility constraints;
• migration, rollout, and rollback steps where relevant;
• tests and other evidence the agent should produce;
• unresolved questions that require a decision.

Small, reversible changes may need only a short plan. Security, data, migration, infrastructure, and public API changes usually need more detail because an incorrect direction is expensive to undo. The Rust project’s RFC process is a useful source of review questions for consequential design changes. Warp’s public APP-2527 specification shows one way to separate product behavior from technical implementation. You do not need to copy either structure. Use only the sections that help you verify the proposed work.

​

Use Plan Diff for revised plans

Plannotator saves each arriving plan to local version history before opening the review. When the agent submits a revision, select the +N/-M badge to compare it with the previous version. Use the rendered view to inspect changed sections in context. Use the raw view when the exact Markdown matters. The Version Browser lets you choose an older stored version as the comparison base. Before approving a revision, check that it:

1. addresses the feedback you sent;
2. keeps decisions that were already correct;
3. does not introduce a new unsupported assumption; and
4. still describes the version the agent is about to implement.

If other people need to review the plan or cite the decision later, commit the exact Markdown to Git or review it in the issue, pull request, or document system your project already uses. The Workspaces plan and technical-decision workflow covers the separate job of sharing one plan or specification with several people and agents. Its versions record document change, not named approval.

​

Keep the reviewed plan tied to the implementation

An agent may discover that the plan cannot work as written. Ask it to stop and return to plan review when new evidence changes a consequential decision, such as:

• an incompatible API client;
• an unsafe migration path;
• a missing authorization boundary;
• a requirement that conflicts with current behavior; or
• validation that cannot demonstrate the promised result.

Review the revised plan with Plan Diff, then approve the current version or send another round of feedback. Do not rely on an earlier approval after the plan has materially changed. Plan review also does not replace code review. After implementation, inspect the actual diff, run the relevant checks, and compare the result with the plan.

​

A practical review loop

1. Let the supported agent enter plan mode and open Plannotator.
2. Read the proposed behavior, scope, constraints, and validation steps.
3. Add comments or edit the plan where it is incomplete or incorrect.
4. Select Send Feedback.
5. When the agent resubmits, open Plan Diff and inspect the changes.
6. Select Approve only when the current plan is ready for implementation.
7. Review the resulting code separately.

​

Frequently asked questions

​

What happens when the plan changes after I approve it?

Treat the changed plan as a new proposal. Review its diff and decide again before the agent implements the new direction.

​

Can the agent review its own plan?

The agent can critique the plan, investigate the repository, and surface uncertainty. You still choose Approve or Send Feedback in the local review.

​

Should every task use plan review?

No. Use it when reviewing the direction will reduce meaningful implementation risk. A small, reversible edit may be faster to verify in the code diff. Last reviewed July 18, 2026. Maintained by the Plannotator project.