Now you can do 4X more code reviews!

This resonates- my engineering workflow has started shifting from highly focused, long periods of building out a feature to one that has much more context switching, review, and testing.

ooh i was exploring this path, aider is so slow. thanks for validating it.

i dont see uzi code on github.

I completely see the benefit for this strategy. Defaulting to something like this would seem to inflate costs though, as a tradeoff for time. I know certain LLM usages can be pretty pricy. I hope that something like this doesn't become the default though as I can see parallelization being a dark pattern for those making money off of token usage.

Very cool! Actually practical use of scaling parallel test time compute. I've been using worktrees + agents to work on separate features but never considered allocating N agents per task.

I posted some notes from a full setup I've built for myself with worktrees: https://github.com/anthropics/claude-code/issues/1052

I haven't productized it though; uzi looks great!

thank you for not writing this in python

This is a good strategy we (sketch.dev) experimented with a bit, but in the end we went with containers because it gives the LLM more freedom to, e.g. `apt-get install jq` and other tools.

I love how the one non-broken toggle still wasn't great. Now you can save time while wasting your time ;)

I find that my bottleneck with LLMs on a real project is reviewing their code, QAing it, and, if it's novel code, integrating it into my own mental model of how the code works so that I can deliberately extend it in a maintainable way.

The latter is so expensive that I still write most code myself, or I'll integrate LLM code into the codebase myself.

I've used parallel Claude Code agents to do chore work for me.

But I'd be curious about examples of tasks that people find best for OP's level of parallelization.

I'm in a different direction on this, worktrees don't solve the problem for me, this is stuck in 1 agent = 1 task mode. I want a swarm of agents on 1 task.

There's a couple of agent personas i go back to over and over (researcher, designer, critic, implementer, summariser), for most tasks i reuse 90%+ of the same prompt, but implementer has variants, one that's primed with an llms.txt (see answerdotai) for a given library i want to use, another that's configured to use gemini (i prefer its tailwind capabilities) rather than claude etc.

To organise these reusable agents i'm currently test driving langroid, each agent contributes via a sub task.

It's not perfect yet though.

What I don't like about this approach is that it mainly improves the chances of zero-shotting a feature, but I require a ping pong with the LLM to iterate on the code/approach. Not sure how to parallelize that, I'm not gonna keep the mental model of 4+ iterations of code in my head and iterate on all of them.

For visual UI iteration this seems amazing given the right tooling, as the author states.

I could see it maybe useful for TDD. Let four agents run on a test file and implement until it passes. Restrict to 50 iterations per agent, first one that passes the test terminates other in-progress sessions. Rinse and repeat.

I like to think about maximizing throughput while minimizing attention: both matter, and the proposal here is expensive on my attention. Optimizing per-task latency matters less than enabling longer non-interactive runs.

For parallelism, I'm finding it more productive to have multiple distinct tasks that I multitask on and guide each to completion. Along the way I improve the repo docs and tools so the AI is more self-sufficient the next time, so my energy goes more to enabling longer runs.

Ex: One worker improving all docs. I can come back, give feedback, and redo all of them. If I'm going to mess with optimizing agent flows, it'd be to make the repo style guide clearer to the AI. In theory I can divide docs sections and manually run sections in parallel, or ask for multiple parallel versions of it all for comparison... But that's a lot of overhead. Instead, I can fork the repo and work another another non-docs issue in parallel. A. Individual task is slow, but I get more tasks done, and with less human effort.

I'd like tools to automate fork/join parallelism for divide-and-conquer plans, and that feels inevitable. For now, they do fairly linear CoT, and easier for me to do distinct tasks vs worrying about coordinating.

This looks like a much more sophisticated version of my setup. I had Aider vibe code me a script that just manages cloning a repo into a subfolder, optionally with some kind of identifying suffix on it, and then wrote a tiny script to automate calling that script, `cd`ing into the directory, and then running codex-cli on it. The resulting workflow: I open a new terminal, type `vibe --suffix=<suffix> <prompt>`, and then I can go do something else.

I wonder why we should spend so much effort to do this vs. say using checkpoints in Cline for example. You could restore task and files to a previous state and try a different prompt/plan. And, the bonus is you have all of the previous context available.

No wonder software is so slow today when we're this profligate. "let's run four AIs and ignore 3/4 of them!" ugh.

I avoid using my own API keys, especially for Sonnet 4 or Opus, because LLMs can rack up unexpected costs. Instead, I use Augment Code’s remote agents and Google’s Jules, which charge per message rather than by usage. This setup is ideal for me since I prefer not to run the model locally while I’m actively working on the codebase.

If AI coding agents were actually any good, you could preface your prompt with "attempt the following task four times in parallel" and that would be it.

Coincidentally, I just posted this[1] earlier today where I made a simple change against a 210 LOC vs 1379 LOC file, comparing parameters: LOC, filename vs URL path for that webpage, playwright verification.

My question is how does the author get things done with $0.10 ? My simple example with the smaller file is $2 each.

[1] https://x.com/hboon/status/1927939888000946198

I run 2 "developers" and myself. Also with tmux, in 3 windows, but I just clone the repo for the 2 developers and then manually pull into my copy when I think it's done. I see various people/sites mentioning git worktrees. I know what it is, but how is it better?

The fact that you consider this “saving time” might show that you are not being diligent with your code.

So what if the BDD is done?

Read >> Write.

As the final step, you should be cleaning up AI slop, bloated code, useless dependencies, unnecessary tests—or the lack thereof—security gaps, etc. Either way, any fine-tuning should happen in the final step.

This review stage will still eat up any time gains.

Is the AI result good enough? fix it, or refeed to AI to fix it.

Hmm this strategy only makes sense if you can trivially evaluate each agent's results, which I haven't found to be the case.

I expect a common case would be: one agent wrote code that does the thing I want. One agent wrote code that isn't unmaintainable garbage. These are not the same agent. So now you have to combine the two solutions which is quite a lot of work.