Iterative planning loop
Turn a request into verified work
01 · Request
State the outcome and boundaries.
02 · Explore
Inspect code, history, tests, and decisions.
03 · Ask
Surface unknowns and interview the human.
04 · Prototype
Make options visible and cheap to change.
05 · Refine
Write the current plan and finish line.
06 · Prove
Test the riskiest assumption on a small slice.
07 · Record
Log discoveries and deviations while building.
08 · Revise
Update the plan when evidence changes it.
09 · Verify
Use tests, domain evidence, and a fresh reviewer to check the result.
Planning continues during implementation. New evidence can send the work back to exploration, a prototype, or a revised plan.
Plan the decisions, not every keystroke
As coding agents improve, they can make more routine execution choices. Humans still need to decide what should be built, what must remain true, and what evidence counts as done. Anthropic’s analysis of about 400,000 Claude Code sessions found that people made most planning decisions while Claude made most execution decisions. It also found that task-specific domain expertise was linked to more successful sessions. (Anthropic) This changes the useful level of detail. Describe the outcome, constraints, risky decisions, and finish line. Let the agent inspect the repository and propose the mechanical steps. Add detail when it prevents a costly mistake, not because a long plan looks thorough. In a July 2026 interview, Claude Code engineer Thariq Shihipar said the team had cut its system prompt by 80 percent as models improved. His point was that many examples and absolute rules had begun to constrain newer models. This was a team-specific change, not a target for every repository. AuditCLAUDE.md, AGENTS.md, and skills for stale instructions, keep hard constraints that still matter, and explain the reason behind softer preferences. (Full interview, Peter Yang’s public notes)
The right column does not mean vague delegation. It gives the agent freedom over routine execution while people keep control of product intent, irreversible choices, and final acceptance.
Use this nine-step planning workflow
1. Start with the request
State the user or operator outcome, why it matters, and the boundaries the work must respect. Include hard constraints such as data handling, compatibility, permissions, migration rules, and systems the agent may change. Do not start by dictating a file list unless the files are part of the requirement. The repository may contain a better path.2. Ask for technical exploration
Have the agent inspect the relevant code, tests, documentation, recent history, prior attempts, and current runtime behavior. Ask it to report evidence before it recommends an approach. Claude Code’s official guidance describes its loop as gathering context, taking action, and verifying the result. It also recommends exploring before implementation and giving the agent something concrete to verify against. (Claude Code documentation) The same planning pattern works with other coding agents that can inspect a repository and run its tools.3. Turn unknowns into questions
Ask the agent what could change the architecture, user behavior, security boundary, migration, or validation strategy. Then have it interview you one question at a time, starting with the answer that would change the plan most. Shihipar’s public blind-spot example scans code and history before proposing an authentication change. His interview example orders questions by architectural impact. The useful pattern is evidence first, then focused questions.4. Prototype choices that words cannot settle
Use a small prototype, visual explainer, trace, benchmark, or reference implementation when you will only know the right choice after seeing it work. Ask for several meaningfully different options when the task involves interaction or visual judgment. HTML is useful for interactive mockups and explainers. Markdown remains better for compact plans and durable text. The HTML vs. Markdown guide helps choose the format.5. Write the refined plan
Fold the exploration, answers, and prototype decisions into a plan. Put the choices a human might change near the top. Keep routine refactoring and plumbing concise. Use the AI coding plan template for the outcome, scope, evidence, implementation, risks, validation, and documentation. If you need a broader method with durable project state or feature specifications, use the planning framework index.6. Build the smallest useful proof
Test the assumption most likely to invalidate the plan. A proof might be one migration against realistic data, one API round trip, one browser interaction, or one performance measurement at a representative size. Do not use the easiest task as the proof. Prove the part that would make you choose a different design.7. Keep implementation notes
Ask the agent to record what the code revealed, where reality differed from the plan, what choice it made, and what still needs human judgment. For an unexpected but reversible detail, give it a conservative default: preserve existing behavior, data, and access; avoid a new dependency or external side effect; and log the choice. The agent should stop when a surprise would change product behavior, security, data ownership, a public contract, or an irreversible operation. Shihipar’s implementation-notes example separates discoveries, conservative deviations, and decisions that belong to a human.8. Revise the plan when the evidence changes
Planning did not fail because implementation found something new. Update the current plan, explain the deviation, and retire assumptions that no longer hold. For a material change, return to review before continuing. Use Plan Diff to compare an agent’s revised plan with the earlier version. The plan-approval guide covers the separate decision to approve the current plan before execution.9. Verify with fresh evidence
Keep coordination, execution, and verification distinct. The coordinator preserves the goal and decisions. The builder implements them. A fresh reviewer, test harness, or domain expert checks the result without inheriting all of the builder’s assumptions. Anthropic’s official loops guide recommends a second agent for code review because a reviewer with fresh context is less influenced by the main agent’s reasoning. It also recommends clear stop criteria and a pilot before a large run. (Anthropic loops guide) Independent review still needs repository evidence and human judgment for consequential changes.Copy this planning and interview prompt
Choose the right finish line
Use a measurable exit condition when the measurement directly proves the requested result. Use a rubric or human judgment when the result includes taste, meaning, risk, or tradeoffs that one number cannot capture.
Anthropic recommends goal-based loops for tasks with verifiable exit criteria. In the interview, Shihipar contrasts a measurable target with visual work that needs a rubric and a separate verifier. (Anthropic loops guide, interview)
A blind-spot prompt is not a completeness check
An agent can search only the evidence it can reach and reason from the models it already has. If neither the human nor the agent knows what complete looks like, asking for unknown unknowns may produce a polished list that misses the real failure. Ground the pass with:- current code, tests, logs, migrations, and prior incidents;
- domain standards, regulations, and security or accessibility checklists;
- reference behavior and representative data;
- explicit rubrics and failure cases;
- an interview with the person who owns the problem; and
- independent verification after implementation.