DEV Community

Ordewell
Ordewell

Posted on

How I stopped my coding agents from writing files before I could see the plan

Disclosure up front: I built the tool this article walks through. It's
free and Apache-2.0, so my interest is "people find this useful" more than
"people pay me."

The failure that sent me down this path is probably familiar. I give an agent a
multi-step goal: refactor this module, update the README, add tests. Everything
goes fine until step 4 — where I discover it misread step 1 back at the start.
By then files are written. There's no plan to correct, because the plan lived in
the model's head. There's only something to undo.

That's the core problem: the plan is a side effect of the session, not an
artifact you can inspect and edit.
This post is about the design decision I
landed on to fix it — make the plan the thing you approve, not the thing you
hope for.

The plan is a typed artifact

The tool reads your repo read-only, then hands back an ordered list of tasks.
Each task carries four pieces of metadata: the runner (Claude Code, Codex, or
OpenCode), the model, the thinking effort, and the mode. That's not decoration —
those four are what the task actually runs as. You can rewrite any prompt, add
or delete a task, rewire dependencies (task 4 depends on task 2), or change
the model on a single task. Completed work stays done. Nothing round-trips the
AI while you edit.

Why a separate planner

The natural question is "why not just use plan mode?" Two reasons.

First, plan mode plans inside the session that then executes — the plan is
advisory and the model can drift from it. Here, the plan is produced by a
separate process that physically cannot write to your repo. Its exploration is
strictly read-only; commands that would write are refused before an approval
prompt even exists, so there's no "allow once" to click through. Mutation
belongs to the runners, not the planner.

Second, per-task assignment. A security refactor and a README update do not
deserve the same model. The planner makes that portfolio decision across the
whole plan, in the open, before you spend a single execution token — and you can
override any of it.

Verdicts from evidence, not opinion

The part I care most about happened later. Agents are bad at grading themselves
— and worse, they'll announce success on a build that doesn't compile. So a task
here is marked done only when its unique completion marker appears in the
runner's output, with the exit code retained beside it as separate evidence. The
model is never the tie-breaker. If the session finished and claimed the work
without the marker, it fails loudly.

If you've watched an agent say "done" and then open a file that's still broken,
that's the whole motivation.

Honest limits

The planner is still an LLM and writes bad plans sometimes. The argument isn't
that it's always right — it's that a bad plan you can see and edit costs a
minute, and one you can't costs an afternoon.
The completion marker proves the
session finished and claimed the work, not that the code is correct.

Also: the TUI needs tmux on every platform (on Windows, that means WSL). The CLI
and the VS Code extension run natively without it.

Try it

npm install -g ordewell && ordewell
Enter fullscreen mode Exit fullscreen mode

Point it at a repo you know well and read the plan it hands back. That first
plan is the whole argument.

  • GitHub: github.com/ordewell/ordewell
  • Apache-2.0, free, no paid tier.

Happy to answer anything, including "why not just do X."

Top comments (0)