Planning and editing the same retry handler

A retry handler looks like a small task until it touches timeouts, duplicate requests, and tests that wait on real clocks. It is a useful place to separate two activities within one coding session: deciding what should change and making that change. Planning mode and doing mode work best as distinct contracts, not as competing ways to use a coding assistant.

§ The same task, two different contracts

Suppose an API client retries every failed request immediately. The goal is to add bounded exponential backoff without retrying requests that could create duplicate writes. Keep that goal visible in both modes, but ask each mode for a different result.

• Planning mode: Inspect the retry path, identify existing behavior, and propose a bounded change. The output is a decision you can review.
• Doing mode: Implement the accepted decision, run relevant checks, and report the actual outcome. The output is a patch with evidence.

Mode names and permissions vary by coding tool. Do not assume that a planning label guarantees read-only behavior. Check the tool’s permission settings, and state explicitly whether edits and command execution are allowed.

§ Inspection beside intervention

• Planning mode: Read the client, its callers, and nearby tests. Locate timeout handling, cancellation, and any existing retry policy. Separate verified facts from assumptions.
• Doing mode: Change the smallest relevant surface. Reuse existing abstractions where they fit, and avoid restructuring unrelated request code merely because it is nearby.

A useful planning instruction is: “Inspect the retry implementation and tests. Propose a minimal change for bounded backoff. Do not edit files. Identify any decision that needs my approval.” This asks for repository-specific reasoning rather than a generic tutorial.

§ Questions beside acceptance criteria

• Planning mode: Surface unresolved choices. Which failures are retryable? Does the attempt limit include the first request? Can cancellation interrupt a delay? Is request replay safe?
• Doing mode: Treat approved answers as acceptance criteria. Add tests for the attempt limit, delay progression, cancellation, and requests that must not be retried.

The distinction matters because an unanswered design question can become an accidental implementation decision. Before editing begins, record the intended behavior in a short paragraph. That paragraph should be specific enough to reject a plausible but incorrect patch.

§ A proposal beside a bounded patch

The handoff should carry decisions, not the entire planning conversation. For example: “Proceed with the agreed retry policy. Make the delay testable without real waiting. Preserve cancellation behavior. Limit changes to the client and its tests. Stop and ask if this requires a public interface change.”

• Planning mode: Name the expected files, risks, and checks. Explain why the proposed scope is sufficient.
• Doing mode: Follow that scope, but report discoveries that invalidate it. A missing cancellation mechanism is a reason to revisit the plan, not permission to redesign the client silently.

§ Expected evidence beside observed evidence

• Planning mode: Specify what would demonstrate correctness: focused tests, relevant type checks, and a review of replay safety.
• Doing mode: Report which checks actually ran, their results, and anything left unverified. Distinguish a passing test from an inferred property.

Finish by reviewing the diff against the accepted plan. A successful command does not prove the patch stayed within scope, and a clean-looking diff does not prove the behavior works.

§ Keeping the session continuous

You do not need a different provider for each phase. Vana API provides an OpenAI-compatible endpoint at https://api.vanaapi.com and also supports Anthropic Messages and Gemini native protocols. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDKs, so the planning-to-editing handoff can remain part of your existing workflow.

Billing is per real token with no monthly fee. Keep planning proportionate: ask for enough analysis to resolve risk, then move to implementation. Create a Vana API account if you want to try this workflow with your coding tool.

The useful boundary is simple: planning ends with an approved decision; doing ends with a reviewed change and an honest account of verification.