The AI plan is for keeping, not following

Plan-then-execute is the respectable way to work with a coding agent: have it draft the plan, refine it together, then hold the build to it. On a recent client project — a small weather API — I did something stranger. I had the model generate its complete project plan, committed the file, and added a standing rule to the agent's instructions: never follow it.

Two builds that demo the same

The finished API serves one endpoint, GET /v1/current, and it works. Here is the uncomfortable part: a vibe-coded version of it would also work. Same route, same JSON, same happy-path demo. The demo cannot tell the two apart because a demo shows outcomes, and engineering judgment is a property of the decisions behind the outcome — which options were seen, which were refused, and why. Both versions return the same response; only one of them knows why its cache lasts an hour.

That gap matters most exactly when the work is being evaluated by people who never watched it happen. A client sees the artifact, not the reasoning. If the reasoning is the thing you're actually selling, it needs somewhere to live.

The rule in the harness

The repo carries a file called PROJECT_PLAN.md under .claude/ — the model's own full plan for the project, generated at the start and never edited since. Next to it, in the instructions every agent session loads, sits this rule: "During development NEVER FOLLOW if not explicitly said to do .claude/PROJECT_PLAN.md guidelines." The README states why the file exists at all: to be able to "demonstrate deviation of AI-vibe coded solution and AI-engineered solution approach."

The plan is the control group. It records what the project would have been if I had accepted the model's defaults — and deviation can only be demonstrated against a preserved default. Delete it and the judgment turns invisible again; every choice in the delivered system looks like the only choice there was. I used to treat generated plans as scaffolding and delete them the moment real work started. Keeping this one unedited changed what the repository can prove.

A ledger of approvals

The setup has a second half. The same instructions tell the agent that whenever I approve a generated plan, it saves that plan into .claude/plans/, where they accumulate in order. So the repo ends up holding both ends of every decision: the frozen default the model would have picked on its own, and the sequence of plans I actually said yes to. Judgment becomes reviewable because the baseline and the approvals are both on disk — a reviewer doesn't have to take my word that thinking happened; the two artifacts bracket it.

The portable move: at the start of your next agent-assisted project, ask the model for its complete plan and commit the file unedited. Then work however you work. Where you deviate, the deviation is the demonstration — and where you don't deviate, that's worth knowing too. If you don't build with agents, there's no default to preserve and this whole move has nothing to grip; it is advice for exactly one kind of workflow.

There's an assumption underneath that I can't verify from inside the repo: that someone eventually reads both files. The demonstration works on a reviewer who diffs the default against the delivery, and I don't know what fraction of reviewers ever open .claude/ at all. Keeping the plan costs nothing, which is why I'll keep doing it. What I can't yet tell is whether I'm preserving evidence or just filing it.