Coding plans that lower agent cost

The cheapest way to cut agent cost is to write five lines before the run, not after. A coding plan is a short contract you agree on before an agent starts: the goal, the paths it may touch, the paths it may not, the command that proves the work, and the person who owns the merge. The token dashboard is the small bill. The big bill arrives later, in review threads that turn into archaeology and in reverts that erase a whole run.

This holds across the tools teams actually use, whether that is Cursor, Anysphere's AI code editor, or a CLI agent driving the same repo. The plan is the part that travels.

Write the five lines before you prompt

Start with the plan, then start the agent. The whole thing fits in the parent chat, and it pays for itself the first time a run tries to wander.

Goal: add rate limiting to the public API
Allowed: src/api/**, tests/api/**
Forbidden: src/auth/**, infra/**, migrations/**
Verify: pnpm test:api && pnpm lint
Merge owner: @priya

Lead with the goal so the agent and the reviewer share one sentence. List allowed paths so the diff has a shape you agreed on. List forbidden paths so a helpful detour does not quietly rewrite auth. Name the verify command so green means something specific. Name the merge owner so approval is a person, not a queue.

Smaller diffs come out of this almost by accident. When the agent knows where it may work, it stops sprawling, and the review gets shorter because there is less to reconstruct.

Make the agent explain itself in the PR

A green build does not tell a reviewer why this approach. If that answer lives only in a chat thread, the same debate reruns on the next similar PR, and rerun debates are pure cost. Put the reasoning in the pull request itself.

Three lines do the job: the constraints you considered, the alternatives you rejected, and the proof it works. Now the approach gets litigated once, in writing, instead of every time someone with taste opens the diff.

This matters more with CLI agents, where the reviewer never saw the terminal. Ask the run to leave an intent line, the command transcript, and a short diff summary in the PR body before anyone is asked to approve. Review goes back to reading at a desk instead of standing behind someone's keyboard.

State which rules win, in writing

Agents read rules files, and on a shared machine those rules drift. Bash approvals become muscle memory, and a session can invent policy halfway through a run. When the policy is unclear, runs get aborted and restarted, which is the most expensive kind of redo.

Fix it by writing precedence down at the top of your rules file. In a CLAUDE.md, that means stating which hooks win, which folders need a human before any change, and where temporary overrides are allowed to live. Cursor's .mdc files and a Codex-style AGENTS.md get the same treatment: say what the agent may not assume.

Keep a small shared snapshot of those boundaries so every tool reads the same map.

- Cursor: keep scopes explicit in `.mdc`; forbid undeclared MCP domains.
- Claude Code: cite `CLAUDE.md` precedence before expanding bash scope.
- Codex: ensure `AGENTS.md` carries replay-friendly verification notes for CLI runs.

Every connector you add widens what the plan has to cover. The MCP specification is where a server states its capabilities up front, so you can declare them in the plan instead of discovering them in a diff. For the full version of this idea, our agentic coding governance topic collects the habits that keep merges honest, and we map this one to Review in our methodology.

Hold the merge to a short checklist

When you are unsure, shrink scope and widen transparency. At merge time, transparency means a few questions the reviewer can answer from the PR alone.

Run the same four checks on every agent PR and the answers stop being a debate. Protected boundaries still deserve their own reading: the OWASP Top 10 for LLM applications and the NIST AI Risk Management Framework are the two worth knowing before an agent touches anything regulated.

Common questions

• Do coding plans slow delivery down?

  No, they speed it up. The plan is five lines, and the savings are structural: smaller diffs, fewer aborted runs, no re-litigated approaches, and reviews that read a transcript instead of rebuilding one. The plan is where surprises go to die, and surprises are the thing that actually scales your cost.

• What makes an agent run expensive?

  Rarely the tokens. The cost lives in rework after scope creep, in review threads doing archaeology, and in permission drift nobody signed off on. A run that ends in a revert costs more than every prompt that produced it. That is why the plan caps paths and permissions first, before it worries about prompt length.

• Where should the plan live?

  In two places. First in the parent chat as the five-line ledger, before the agent starts. Then in the PR body, next to the diff and the verification output, so a reviewer finds it where they find the change. A plan that sits in a document nobody opens is just a note with a timestamp.

• Does this work for both editor agents and CLI agents?

  Yes, and the CLI case needs it more. An editor reviewer can scroll the chat, but a CLI reviewer often sees only the diff. Asking the run to leave an intent line, command transcript, and diff summary makes the work reproducible, so the review happens at desk speed instead of over someone's shoulder.

Start with one run

Write the five-line ledger before your next agent run and paste it where the reviewer will look. If you want the team version of this, our training walks groups through it on their own repos.