Back to News
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

ramon156about 3 hours ago
i would love a deterministic program that can confidently make plans for lower-cost models like deepseek. ofcourse the LLM part wont be deterministic, but its a lot easier to measure quality like this. you could argue an AGENTS.md is this, but from experience its not enough to make non-frontiers act have a high success rate.
jedbrookeabout 2 hours ago
I’ve had success with writing eg shell scripts that have a deterministic scaffold for the thing I’m actually trying to do, then call off to the agent for only the things that actually need it. For example I was trying to find a race condition flaky bug in my code, so the shell for loop ran the build N times, and called out to the agent to analyze the build logs if the tests failed, then the shell would ping me on slack when it was done, so the whole thing could run in the background.

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

ac-cianoabout 2 hours ago
I like your analogy. The main problem though is context and keeping it clean as much as possible as long a parallelization. This is what drove to build this tool: having control of everything that the LLMs will do, controlling all with one main planner that orchestrates the rest. This way we can have cheaper LLMs with a short context window used (less intelligence degradation) while still obtaining the same objective. And again, you can have a clear picture of everything structured as tasks. until we can get to rely on huge swarms of agents (tasks) being directed on the planner alone I don't see how we can get a better framework.
hedgehogabout 2 hours ago
There are a lot of ways to slice the problem of getting the agents to complete a goal without getting lost, and the right solutions are somewhat problem-specific. For the projects I've done 35B Qwen is about the smallest that seems to make useful progress in a general purpose harness while 4B Qwen is workable with a task-specific harness. At the lower end the plan has to be traditional search/planner techniques in code not something the model has any control over, of course that limits the kinds of problems that fit. The high end coding models are perfectly capable of making a functional 1-off harness for those jobs so it ends up not being that bad to implement.
ac-cianoabout 2 hours ago
Yeah it's exactly what I've seen as well. Ordewell is close to your high end case: a frontier model builds the plan once, then it's fixed, the executing model can't reinterpret it. Won't get you to 4B, but should help a small model that only has to execute, not plan and execute at once.
hedgehogabout 2 hours ago
Have you quantified the performance on any particular benchmark?
formvoltronabout 3 hours ago
What sort of determinism do you have in mind?
ac-cianoabout 3 hours ago
Fair — AGENTS.md is prose the model has to re-interpret every session, and that reinterpretation is exactly where weaker models lose the thread. Here the plan is parsed and enforced as structured data: tasks with declared dependencies and one prompt each, so the per-step job is smaller and the plan isn't up for renegotiation. Nothing in that needs a frontier model I just haven't benchmarked it against deepseek-class runners, and the runner is pluggable if you want to be the one who does.
Lalabadieabout 2 hours ago
I opened the page looking for a differenciator, but everything about the project is AI-written (including author replies in these comments).
ac-cianoabout 2 hours ago
Fair, and I won't pretend otherwise. I heavily used AI to help write the docs and code. The thing is though... I designed it and I stand behind it.
scandoxabout 2 hours ago
But why write these comments with AI?
BarryMiloabout 1 hour ago
Complete brainrot lol
ac-cianoabout 2 hours ago
To me that's not the embarrassing part... unmaintainable would be. Using AI for coding and writing doc is standard practice now, not using it would be insane.
dominotwabout 2 hours ago
so why did it get upvotes and a place on coveted frontpage?
sharathrabout 1 hour ago
ac-cianoabout 1 hour ago
nope but I will check it out, thanks
ac-cianoabout 3 hours ago
Ordewell author here.

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.

    npm install -g ordewell && ordewell
    code --install-extension ordewell.ordewell
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.

sniderthanyouabout 2 hours ago
How does this compare with Matt Pocock's /grill-me -> /to-spec -> /to-tickets ? I see that Ordewell recommends model and effort, but is the workflow overall the same?
ac-cianoabout 2 hours ago
Yeah absolutelly. I just wanted that exact framework in a simple controllable UI, where I could also plug in any of my subscriptions/API keys such as Claude Code or Codex at the same time. With Ordewell you get all layed out as tasks that are easily manageble (Matt's specs) in a UI.
formvoltronabout 2 hours ago
kind of amazing how much thought /grill-me gets. have you looked inside those skills? grill-me is literally 4 sentences!
ac-cianoabout 2 hours ago
Absolutelly, it is brilliant! I use it daily myself from Ordewell