Hacker News Reader

This seems complex and expensive, and I suppose the only reason to do this is because you want to generate code faster? Do you really have so much code to write that a single LLM is too slow?

And then on top of that you need another agent to manage merging all of the subagent code together?

View on HN

I don't do this at my day job (coworkers would be pretty mad). This is for software ideas that come up weekly that I need to execute to at least MVP before I ever need branching/merging

Not complex at all, only one extra session other than the ones doing work and it's on a dumb model and can be thrown away & restarted because it only dispatches work, not doing anything.

I do everything in there, collecting requirements, kick off research, branching, merging, not one other agent on top. I considered making that orchestration command llm-powered but it's not justified at my current use.

It's not more expensive, in fact I could have just chugged along with the slow and manual session by session work but I have a claude subscription and another GLM one (the most low cost basic tier, not even much), that just sit there collecting dust if I don't put them to use in a more efficient way.

And doing session by session would face your problem when context switching too much become unscalable.

Reply on news.ycombinator.com