The most useful shift in coding agents this year is not that they can write more code. It is that several tools now let product and engineering teams stop before code exists, inspect the proposed plan, and decide whether the task is ready to spend implementation time on.
I treat that as a product delivery gate, not a model feature. A plan is where scope, sequencing, risk, ownership, and review cost become visible while the change is still cheap to redirect. The gate is small, but it changes the question from "can an agent build this?" to "is this the change we want built?"
The format: a plan review gate
The gate sits between backlog selection and implementation. It is not a full design review. It is a lightweight checkpoint for work that is big enough to damage velocity if the first branch goes in the wrong direction.
GitHub's current Copilot cloud agent docs now separate research, plan creation, iterative code changes, and pull request creation. That separation matters. The session can research the repository, produce a plan, and wait for a human to refine the approach before a PR exists. Microsoft's Visual Studio Plan agent pushes the same idea further by saving plans as Markdown under .copilot/plans/ and handing the final plan to Agent mode only after approval.
The product lesson is simple: plan artifacts are becoming first-class workflow objects. If teams keep treating them as chat residue, they lose the main control surface.
What must be in the plan
I want five things before I let an agent start a feature branch.
First, the plan must name the user-visible outcome. Not "update onboarding components," but "new users can connect a data source before seeing the empty dashboard." The phrasing should make the product bet reviewable.
Second, it must list the likely files, services, migrations, flags, and tests. GitHub says well-scoped tasks should include the problem, acceptance criteria, and file direction. The plan should either confirm that map or explain why discovery found a better one.
Third, it must call out irreversible or expensive moves. Schema changes, payment logic, authorization, data deletion, analytics contracts, and public API behavior need explicit review before code generation starts.
Fourth, it must say what the agent will not do. This is where scope control actually happens. A clean exclusion such as "no billing plan changes" saves more review time than a vague success criterion.
Fifth, it must define proof. If the branch cannot produce a screenshot, test run, trace, query result, or manual verification note, the task is not ready for an autonomous implementation pass.
The approval checklist I use
I would keep the gate boring:
| Check | Pass condition |
|---|---|
| Outcome | A reviewer can tell what customer behavior changes |
| Scope | Includes touched areas and explicit exclusions |
| Risk | Names security, data, migration, and rollout hazards |
| Proof | Names the smallest evidence needed after implementation |
| Owner | Says who decides product tradeoffs during follow-up |
This is intentionally smaller than a spec template. A long plan can still hide uncertainty. A short plan with these five checks exposes it.
When to require it
Do not route every issue through plan review. That is process theater.
Use the gate when the task crosses a product boundary, changes a workflow, modifies stored data, touches permissions, depends on fuzzy acceptance criteria, or asks the agent to choose between implementation paths. Skip it for copy fixes, tiny visual tweaks, isolated tests, and chores where the desired diff is obvious.
This pairs well with the backlog shaping I described in the agent-ready issues checklist. The issue says what should change. The plan confirms how the repository will absorb the change.
How planning changes review cost
The review burden moves earlier. That sounds like more work until you compare it with reviewing a wrong branch.
A wrong branch consumes reviewer attention in three layers: reading the code, inferring the intent, then explaining why the direction is off. A wrong plan is cheaper. You can reject one step, add a missing constraint, split the work, or downgrade the task without untangling a diff.
The OpenAI Codex docs describe a coding agent that can work locally or in the cloud, run tests, review code, and operate with workspace controls. The ChatGPT Work and Codex help docs also emphasize progress review, direction changes, and approval of important actions in longer tasks. Anthropic's Claude Code docs describe Plan mode as read-only exploration and proposal before edits. Different products, same delivery pattern: the human should steer when intent is cheapest to change.
What I would store
For important work, store the accepted plan with the issue or PR. Markdown is enough. The artifact should include the prompt, the accepted plan, unresolved questions, and any human edits.
That becomes useful later when the agent edits a spec, changes a task, or generates a PR body. It also connects cleanly to the provenance gate for agent-edited specs: the plan is the point where provenance starts, not an afterthought added during review.
I would not create a new database table, status taxonomy, or workflow tool for this first. Add one checkbox to the issue template, one plan artifact location, and one reviewer rule: no agent implementation for risky product work until the plan names outcome, scope, risk, proof, and owner.
The trap to avoid
The bad version of this gate is a prettier way to rubber-stamp agent output. If every plan gets approved, the gate is theater. If plans are verbose but do not name risks, the gate is decoration. If product decisions happen in private chat and only code reaches the team, the gate failed.
The useful version is small and a little strict. It lets agents move faster on the work they should do, while making unclear work more visible before it turns into review debt. I expect the next useful delivery pattern to be less about assigning more tasks to agents and more about deciding which plan artifacts deserve implementation.