You only need the frontier model for one single edit
1–10 of 107 posts
Re: You only need the frontier model for one single edit
#2Apparently "/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?
Re: You only need the frontier model for one single edit
#3Apparently "/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?
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.
Re: You only need the frontier model for one single edit
#4> Senior architect, junior engineer. Sounds great, right?
Sounds like a consulting slaughterhouse. Picture Java Enterprise Solutions. As we all know, the pinnacle of software engineering.
Re: You only need the frontier model for one single edit
#5[flagged]
Re: You only need the frontier model for one single edit
#6> Senior architect, junior engineer. Sounds great, right? Sounds like a consulting slaughterhouse. Picture Java Enterprise Solutions. As we all know, the pinnacle of software engineering.
[deleted]
Re: You only need the frontier model for one single edit
#7Lately 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.
Re: You only need the frontier model for one single edit
#8Did they also use Gemini Flash to write this article? Because, frankly, it's unbearable
Re: You only need the frontier model for one single edit
#9Just 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.
Re: You only need the frontier model for one single edit
#10From 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.