Are they also telling each other what to do? Because I for one can't assign and keep track of 10 things at once.

I create large hierarchical plans, and have a coordinator agent divvy up the work. It's extremely effective.

I created an orchestration skill for myself (using herdr but any persistent mechanism works). So I then only interact with a front session and it will triage and dispatch each request to the relevant spaces (each of them can have multiple worktrees of the same project), summarize movements and pending decisions for me all at once. I do not directly interact with a multiplexer or any dashboard.

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?

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.

Personally, it takes me longer to write the specifications than it takes the model to implement them (and it takes me much longer to review the resulting code, although maybe that makes me old-fashioned). Consequently I do not have enough tasks to run more than one agent at a time.

I'm exactly in this situation, and at the same time I get so many jumpscares when reviewing the code that I'm not going to stop anytime soon.

Exactly. I don't understand how so many developers seem to have a long tail of well written task specifications ready to submit to the LLM. Who produces them?

LLMs are good at cleaning up tech debt. Give them lots of small refactorings or dig out those crusty old P4 tickets. There's a lot of easy stuff for them that requires very little specification and very high probability they'll get it right the first time, especially if you can point them at an example done right.

[delayed]

I have conversations with a smart model, and then the model writes the spec. I review and approve the spec, and it dispatches.

For a concrete example, check out this random plan [0]. A detailed spec followed by the exact implementation tasks that will be executed by the subagents.

[0]: https://github.com/bensyverson/woodcase/blob/main/project/20...

Not sure why I'm being downvoted for stating the obvious. To the parallel agent skeptics: I was also a skeptic until a month or two ago. I would run one agent, watch it carefully, and check its work. However the models got good enough that it was more efficient to do more work in parallel, then have a single agent integrate the changes with a critical eye, then run a code quality pass, and then I would take a look a it and kick the tires behaviorally.

It does involve letting go and not micromanaging every code convention and implementation detail, but that is the same skill you need when leading engineering teams.