[nxtfari]

This is really smart, like the author said, old idea but cleverly applied.

In case anyone wants a summary: don’t one shot, don’t use plan mode and hand off the plan to cheap executors, ask the frontier model to explore, create a todo list, and then start when it feels confident; stop it after first code edit, then prefill the context to cheap executor to continue.

[brookst]

How is that different than just having the frontier model write a build plan and store it, then have a cheaper model execute? That’s pretty normal practice.

The build plan should be better than the context that generated it since it strips out wrong turns and other noise. I think?

[xutopia]

The article actually explains it better than I can but essentially you do not want the agent to get desperate which causes it to burn extra tokens. Planning phase doesn't test assumptions by going straight in the code and testing out parts of the ideas to execute so it has to consider way more in planning than it would if it could go quicker into the coding phase.

[brookst]

Hmm. When I have Opus or Fable write build plans, then invariably invariably read code extensively, but it’s true they don’t make changes and run tests.

I guess the way to formalize this would be to add a “make minimal change to confirm approach” instruction to the build planning prompt. Probably can even parallelize that so as the build planning prompt iterates subagents get launched to validate, similar to what research modes do.

I’m a little skeptical, but will give it a try.

[diarized]

Would it be `/superpowers:brainstorming` + `/superpowers:writing-plans` on stronger model and `/superpowers:subagent-driven-development` on smaller model?

[hombre_fatal]

The article isn't about plan vs no plan but rather that instead of a weak hand-off of "here's a plan describing what I hope works" you can do a much stronger hand-off with "here's an approach that survived first contact with the code".

[Imanari]

So its basically (a plan + a bunch of file reads + a first edit) injected into the context of a cheap model so the cheap model does not feel like it has to re-read the files and just continues executing and editing?

[trash_cat]

Yes this is correct. It essentially biases the cheaper model into procedural action grounded by the frontier model. To put it mode generally, it injects the cheap model context with more useful information, where it might not need to read all the files again.

[swingboy]

Refilling the context of the cheap executor == just switching the model mid-conversation instead of /clear’ing and passing some plan doc?