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 7 hours ago | parent | next [-]

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.

	▲	diarized 40 minutes ago \| parent \| next [-]
		Would it be `/superpowers:brainstorming` + `/superpowers:writing-plans` on stronger model and `/superpowers:subagent-driven-development` on smaller model?
	▲	brookst 6 hours ago \| parent \| prev [-]
		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.

▲

hombre_fatal 7 hours ago | parent | prev [-]

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".