DE version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
33% Positive
Analyzed from 1237 words in the discussion.
Trending Topics
#code#planner#model#task#ordewell#plan#agents#each#agent#tasks

Discussion (27 Comments)Read Original on HackerNews
I’ve been thinking more about how this deterministic + agents style could work, it’s kinda like the analogy of factories in the 1800s going from the central shaft to electric motors on each desk (where the central shaft in this case is a chat window, and the motor on a desk is calling the llm api from wherever you want just like a normal api call)
Of course, maybe in a few months the agents would just be reliable enough to do the shell part on their own too, but we’ll just have to wait and see
What I kept hitting wasn't coding agents writing bad code. It was one agent trying to hold a whole change in its head. I'd give it a multi-step goal, it would start work, and its misreading of the first step only surfaced once the fourth one was on disk. The plan itself was never anywhere I could read it, so there was nothing to correct — only something to undo.
So I built Ordewell: the plan is a typed artifact here, not agent state. You describe a goal, a planner explores your repo read-only and comes back with an ordered list of tasks, each carrying its own runner, model, thinking effort and mode. You rewrite prompts, add or delete tasks, rewire dependencies, or swap the model on one task — before anything runs. Then each task runs as one real agent session, and the board holds the rest: done, running, blocked, left. Manual steps sit in the same list as checkboxes.
Four things that may be worth your time even if the tool isn't:
- One task, one session, one small context. The planner's sizing rule is explicit: each slice must fit one fresh session's context window, or it gets split. A task then starts clean and is handed only what it needs — its own prompt, a window of the plan marked "you are here", and a short tail of its direct dependencies' output. Nothing else from the run, and nothing from another task's transcript. A long session doesn't announce that it has lost the thread — it just keeps going, which is the part that costs you. Writing the plan down is what buys the alternative: no session has to carry it.
- The planner isn't asked not to write — it's prevented. Every research command is lexed the way a shell lexes it (quotes, backslashes, command substitution) and classified per segment into run / ask-once / refuse. The refuse tier returns before the approval seam is reached, so there is no prompt that unlocks it and no system-prompt wording that talks it into one. Anything reaching outside the workspace asks once. The read-only-planner / writing-runner split is the whole architecture.
- Completion is decided by evidence; the judgement calls are decided by you. Each task gets a unique marker, and it's done when that marker appears in the runner's output, with the exit code retained beside it as separate evidence. The model is never asked whether it thinks it succeeded — a clean exit without the marker fails loudly. The planner also classifies each task up front as autonomous or human-in-the-loop, and a human-in-the-loop task stops before the step you can't take back: it prints what it's about to do and why, and waits for approve or reject.
- There's no extra API key. Claude Code, Codex and OpenCode can each be the planner as well as the runner, on the subscription you already pay for. Enable more than one and the planner assigns a different one per task — the argument being that a security refactor and a README update do not deserve the same model. Other agents are a plugin manifest, not a code change.
What it is not: the planner is still an LLM and writes bad plans sometimes — the whole bet is that a bad plan is cheap when you can see and edit it, and expensive when it's hidden. The command classifier is a classifier, not a sandbox; container it if you want a hard boundary. The marker proves the agent finished and claimed the work, not that the code is correct — that's what your tests are for. TUI needs tmux; VS Code and the HTTP daemon don't. Node >= 20.
The second line is the VS Code panel; it carries its own core, nothing to install from npm.Apache-2.0, no paid tier, nothing to sign up for. Docs and a demo at https://ordewell.ai
What I'd most like to hear: whether the per-task model assignment is real value or a knob nobody wants, and where the read-only planner boundary is too strict to be useful.