Embracing the parallel coding agent lifestyle

I'm not convinced there is any hope for a productive, long-term, burnout-free parallel agent workflow.

Not while they need even the slightest amount of supervision/review.

Yea, i find success in LLMs overall but the quality of the work is proportional to how much oversight there is.

My suspicion is that it's because the feedback loop is so fast. Imagine if you were tasked with supervising 2 co-workers who gave you 50-100 line diffs to review every minute. The uncanny valley is that the code is rarely good enough to accept blindly, but the response is quick enough that it feels like progress. And perhaps an human impulse to respond to the agent? And a 10-person team? In reality those 10 people would review each other's PRs and in a good organisation you trust each other to gatekeep what gets checked in. The answer sounds like managing-agents, but none of the models are good enough to reliably say what's slop and what's not.

I don't like to compare LLM's to people.

There is a real return of investment in co-workers over time, as they get better (most of the time).

Now, I don't mind engaging in a bit of Sisyphean endeavor using an LLM, but remember that the gods were kind enough to give him just one boulder, not 10 juggling balls.

Yes. The first time I heard/read someone describe this idea of managing parallel agents, my very first thought was that this is only even a thing because the LLM coding tools are still slow enough that you can't really achieve a good flow state with the current state of the art. On the flip side of that, this kind of workflow is only sustainable if the agents stay somewhat slow. Otherwise, if the agents are blocking on your attention, it seems like it would feel very hectic and I could see myself getting burned out pretty quickly from having to spend my whole work time doing a round-robin on iterating each agent forward.

I say that having not tried this work flow at all, so what do I know? I mostly only use Claude Code to bounce questions off of and ask it to do reviews of my work, because I still haven't had that much luck getting it to actually write code that is complete and how I like.

The thing that's working really well for me is parallel research tasks.

I can pay full attention to the change I'm making right now, while having a couple of coding agents churning in the background answering questions like:

"How can I resolve all of the warnings in this test run?"

Or

"Which files do I need to change when working on issue #325?"

I also really like the "Send out a scout" pattern described in https://sketch.dev/blog/seven-prompting-habits - send an agent to implement a complex feature with no intention of actually using their code - but instead aiming to learn from which files and tests they updated, since that forms a useful early map for the actual work.

It's less about a direct comparison to people and more what a similar scenario would be in a normal development team (and why we don't put one person solely in charge of review).

This is an advantage of async systems like Jules/Copilot, where you can send off a request and get on with something else. I also wonder if the response from CLI agents is also short enough that you can waste time staring at the loading bar, because context switching between replies is even more expensive.