The reason I use plan then implement is because I can adjust the plan, whereas if I get it to implement straight away, it might (and often does) make the wrong decisions that will be harder to adjust, or I'd have to adjust it after the fact.
canpan 2 hours ago [-]
One big pain point is not seeing the thinking trace. I noticed using pi with a self hosted model that I could spot, stop and correct my prompt much faster. With claude etc I have to first wait for it to think 3 minutes and then notice it got completely off the path I wanted.
I still use a plan, because my local model is not as smart as opus, but I can iterate much faster.
carterschonwald 1 hours ago [-]
this so true. its really hard to make sure a model isnt going off the rails if i dont see full cot. the fact that oai and anthropic models hide it now has made them less reliable. which is a shame
wrs 5 hours ago [-]
Lately I'm trying a variation on this: Have the main agent make a phased implementation plan, then for each phase, have it start an implementation subagent with a focused prompt, then review that agent's work in the main session. The theory being that the main session still contains all the research, but it can review just the diff rather than have the entire implementation session in context as well.
The post doesn't include a review in the cost comparison, but I find that immediately doing a review catches lots of mistakes.
sgc 11 minutes ago [-]
Actually it does include an important level of review. They say "init a TODO list with a validation step for each item", and then the last several sections of the execution are within the TODO - where it is validating the code.
To me that was the heart of the article and of what they did - create a self-validating todo list that deterministically forces the agents to stay on task, and then trim out just the right extraneous context (the actual planning) without messing with the read-file context which is where they found subagents burning most of their tokens.
Just a few days ago I was speculating about forking context to implement instead of spawning subagents here on hn. This is similar to that just several more steps more sophisticated.You could even fork the trimmed context here for very large tasks.
pqdbr 2 hours ago [-]
I’m using Claude code dynamic workflow like this. I tell Fable to use a workflow. He is the planner, orchestrator and reviewer. Opus agents are implementers. Works unbelievably well.
danielciocirlan 1 hours ago [-]
“He”
llbbdd 25 minutes ago [-]
I call him "my son"
hankbond 3 hours ago [-]
Does anyone have a name for that really neat "the bar chart is a bookshelf, you can hover a spine to see the cover" vis? I've never seen it before.
nchmy 3 hours ago [-]
This entire argument rests upon the fact that Gemini Flash ain't cheap.
Try plan with opus 4.8 and then implement with Deepseek v4 flash - its 35x cheaper for reads, 90x cheaper writes, and 18x cheaper cache reads.
Or plan with Deepseek Pro, or even Flash itself. I've been impressed with both.
pistoriusp 5 hours ago [-]
Apparently "/prewalk" is built into https://github.com/can1357/oh-my-pi, which I guess is a lot like "Oh My ZSH?" Pi with batteries included.
There are a lot of interesting ideas in it, mostly none that I have applied to my own workflows. Curious if anyone has used it?
AshamedBadger56 5 hours ago [-]
I've played around with all the popular agent CLI's and I've landed on omp/ohmypi as my favorite for now. It's definitely the opposite of a lean install like Pi, but I find it works a lot better than OpenCode. It's also very very active, with a lot of cool new ideas like this prewalk in it.
rwc 4 hours ago [-]
Just specify that the more efficient model should only be used if the cost of doing the task would be less than using the higher horsepower model. Fable has no problem routing based on that instruction.
pphysch 3 hours ago [-]
> Any agent, any model, any scaffold: the bill is essentially O(reads)
Therefore token sellers have incentive to produce verbose, unreadable code
pixl97 2 hours ago [-]
Whichever token seller defects can capture a larger chunk of the market with slimmer code.
Almondsetat 4 hours ago [-]
Did they also use Gemini Flash to write this article? Because, frankly, it's unbearable
viccis 3 hours ago [-]
From what I can tell, I have a similar workflow. I get Fable 5 / Sol on High to talk to me about requirements until it's ready to design. I then have it break the design into tickets. I use kata, an agent-oriented issue tracker. If it ever starts to get bloated, I'll just make my own as it doesn't need too many features. Anyway, I tell it to include sufficient context in each such ticket to be picked up by a new implementation agent. Explicit user stories, Cucumber style acceptance criteria, etc.
When it's done, I switch to a smaller model and tell it to start a /goal of calling `kata ready` to get tickets ready to be worked. Work one ticket on each goal iteration, committing changes when done. Stop when all the tickets are either closed out or are blocked on actions from me.
It works fantastically. I can get entire (relatively straightforward) iOS apps done in under my $20/month five hour session window.
I get even better results if I do the QA session with the frontier model with two output artifacts: an implementation spec and a design prompt for Claude Design. I push the design prompt through Claude Design, tweak the results, and get a design spec. When I have the frontier model do the planning, I have it read the implementation spec from before, along with the design spec's overview file.
When I do it this way, I've done A/B tests between Fable 5 and Sol, and the apps they wrote were basically identical. It's so much cheaper than the "let loose the subagent fleet!" form of context management.
I haven't even added any kind of frontier model validation cycle into this loop yet. Everyone keeps talking about a subagent flow in which the big boy reviews the work of the drones, but I've found that if it encodes its acceptance criteria well enough, they do a satisfactory job of it themselves.
I still use a plan, because my local model is not as smart as opus, but I can iterate much faster.
The post doesn't include a review in the cost comparison, but I find that immediately doing a review catches lots of mistakes.
To me that was the heart of the article and of what they did - create a self-validating todo list that deterministically forces the agents to stay on task, and then trim out just the right extraneous context (the actual planning) without messing with the read-file context which is where they found subagents burning most of their tokens.
Just a few days ago I was speculating about forking context to implement instead of spawning subagents here on hn. This is similar to that just several more steps more sophisticated.You could even fork the trimmed context here for very large tasks.
Try plan with opus 4.8 and then implement with Deepseek v4 flash - its 35x cheaper for reads, 90x cheaper writes, and 18x cheaper cache reads.
Or plan with Deepseek Pro, or even Flash itself. I've been impressed with both.
There are a lot of interesting ideas in it, mostly none that I have applied to my own workflows. Curious if anyone has used it?
Therefore token sellers have incentive to produce verbose, unreadable code
When it's done, I switch to a smaller model and tell it to start a /goal of calling `kata ready` to get tickets ready to be worked. Work one ticket on each goal iteration, committing changes when done. Stop when all the tickets are either closed out or are blocked on actions from me.
It works fantastically. I can get entire (relatively straightforward) iOS apps done in under my $20/month five hour session window.
I get even better results if I do the QA session with the frontier model with two output artifacts: an implementation spec and a design prompt for Claude Design. I push the design prompt through Claude Design, tweak the results, and get a design spec. When I have the frontier model do the planning, I have it read the implementation spec from before, along with the design spec's overview file.
When I do it this way, I've done A/B tests between Fable 5 and Sol, and the apps they wrote were basically identical. It's so much cheaper than the "let loose the subagent fleet!" form of context management.
I haven't even added any kind of frontier model validation cycle into this loop yet. Everyone keeps talking about a subagent flow in which the big boy reviews the work of the drones, but I've found that if it encodes its acceptance criteria well enough, they do a satisfactory job of it themselves.
Sounds like a consulting slaughterhouse. Picture Java Enterprise Solutions. As we all know, the pinnacle of software engineering.
That said, it takes me a while to reads plans and often I'll take a break, by when the cache has expired. At that point it may be better to start over