Let the agent write the plan

Agents write plans fast. A long plan.md can land in a few minutes. Rollout steps, risks, "obvious" next moves, the whole theater of competence.

I think the expensive step is not writing the plan. It is running it before anyone else has looked. That is opinion, not a metric. I do not have data that "plan review" ships faster or breaks less. I do know what it feels like to watch an agent execute a plan I skimmed alone. The sinking feeling when step four was wrong and step one already mutated production-shaped state in a staging env you treated too casually.

So: let the agent write the plan. Do not let it run the plan alone.

The job

You have a coding agent. It produced (or is still producing) a plan, spec, or rollout doc as markdown. You want a second engineer on that file before the agent executes, and before the file is worth committing.

The reviewer is not in your agent session. They have a browser. That is the whole setup. Plan is still plan.md. Teammate has a browser. Review before execute.

When to review relative to git is a sibling cut. Who can review without your IDE is another. This post is timing relative to execute: writing is cheap, running is not.

I have started saying that out loud in standups. People nod. Then someone still hits execute because the plan looked long and confident. Length is not review. Confidence is not review. A second human on the live file is review.

What people do today

Solo in the IDE or agent chat. Zero ceremony. You already have the session open. In the coding agent a long plan is often even harder to read than in the editor, and you still lose the second human and any durable thread the agent can act on from outside the session. Fine when you really are the only reviewer. Risky when you are pretending you are.

Screenshare / pairing. Great for two minutes of verbal nuance. Bad as a review surface: calendar tax, no line-anchored threads, nothing the agent can pick up later. Screenshare is not plan review. A live link with threads is.

Slack paste. Interrupts someone now with zero new tools. Also freezes a snapshot. You lose the live local file, and the agent does not hear structured comments on that file. Paste the plan into Slack and you lose the live file. Comment on the link before the agent executes.

Early PR. Commit the plan just so someone can use GitHub review. Familiar UI, real audit trail after commit. If the plan is not worth committing yet, you are adding PR noise while the agent is still rewriting. When the plan is commit-ready, hand off to a PR. Do not fight GitHub there. Do not use GitHub as a pre-execute comment bus either.

"Just let it run, we will fix forward." Sometimes true for tiny tasks. For a migration plan, a permissions rewrite, or anything with a blast radius, fix-forward is a story you tell yourself after you skipped the cheap review.

None of those are wrong tools. They are wrong moments. The moment after the agent writes and before it runs is the cheap one. Spending it on a frozen paste or a premature commit is how you buy expensive cleanup later.

Before execute, before git

Gander sits in the gap before the plan is worth committing and before you treat it as ready to run.

That is before git, not instead of git. When the file is ready, open the PR. The review job for a still-moving plan is earlier. The execute job is later still. Review sits between "agent wrote it" and "agent runs it."

I used to collapse those moments. Plan lands. I skim. I say go. Git comes later if anything is worth saving. That order feels fast until step three was wrong and steps one and two already ran. Now the "fast" path includes a rollback conversation you could have had while the text was still soft.

Writing is free. Running is not. Review is how you spend a little of the free part to protect the expensive part.

The loop

Gander is live review for markdown an agent is still writing. The product is the loop, not a wiki, not a gist, not "share markdown."

1. Watch: gander watch plan.md (you or the agent). Every save updates a hosted page.
2. Comment: reviewer opens the URL. Docs-style inline threads. No install for them. No IDE, no repo, no agent account.
3. Act: comments that start with @agent land in the agent session via MCP. The agent edits the file. The same link updates.
4. Then: execute when the plan is ready, or git when it is worth committing.

Local file stays source of truth. Hosted page is the live view plus threads. Comments anchor to lines and survive rewrites. Full loop is shipped.

gander watch plan.md

Hosted watch, not local --watch. Local preview will not take your lead's comments from a phone. Hosted watch will.

gander watch plan.md → comment → @agent → same link updates → then run it.

Install MCP once so the session hears the summons (gander mcp install), or fall back to gander comments. Human threads stay human. Only the prefixed ones become work. That keeps the model out of debates that are still open.

A scene I keep replaying

Friday afternoon. Agent dumps a 30-page cutover plan. I skim. It looks fine. I almost say "go." Instead I send the live link to the on-call who actually owns the service. They are in a grocery store. They open the link on their phone, leave one @agent on the dual-write window, and a human note that the rollback section assumed a flag we already removed. Agent rewrites both. Same link. Twenty minutes. Then we run it.

Would we have caught that in a PR later? Maybe. After the agent had already started. The point of review-before-execute is that changing the plan was still cheap.

I have the other Friday too. Same confidence. No link. Execute. Staging gets a migration order that assumed a flag we had deleted two weeks earlier. Nobody was reckless on purpose. We spent the free rewrite window alone with a confident document.

What this is not

Not a planning platform. Not agent governance. Not "AI collaboration." Not a PM launch pitch. Not Google Docs for markdown as the headline. Not a replacement for git, PRs, or Notion.

Same product as the short "review what the agent is writing" story. "Plan before execute" is why you open the loop. Gander is how.

It is also not a claim that every plan needs a committee. Tiny tasks can run. Blast radius is the tell. If the plan touches permissions, data movement, cutover windows, or anything you would not casually undo at 6pm, buy the second look while the text is soft.

Objections I hear

"We are a small team. I am the only one who can review." Then you are the second human. Step out of the agent chat, open the hosted link yourself on a phone, and read it like a stranger. Solo skim inside the same session that wrote the plan is not the same as review. Different surface. Different posture.

"Review will slow us down." Skipping review speeds up the start and slows down the incident. I am not claiming a metric. I am claiming a feeling you already know when step three was wrong and steps one and two already ran.

"The agent will just rewrite whatever we say." Good. That is the point while the plan is soft. @agent on a live file is how rewrite stays cheap. Paste culture makes rewrite expensive because someone has to re-explain context every time.

"We will catch it in the PR." Maybe. After execute risk has already started, or after you forced a commit so GitHub would show a diff. The PR is the right tool when the file is ready for history. It is a late tool for a plan that is about to run.

Then execute

The next time an agent dumps a plan, the interesting question is not "can I run this?" It is whether anyone else has looked while changing it was still cheap.

Review the live plan. Fix it with @agent if needed. Then run it, or commit when it is worth a PR. Let the agent write the plan. Do not let it run the plan alone.