My biggest hesitation about this is being stuck in merge hell. Even a minute or two needing to deal with that could negate the benefits of agents working in parallel. And I've tried some relatively simple rebase type operations with coding agents where they completely messed up. But if people are finding this is never an issue even with big diffs, I might be convinced to try it.
Typically people use sub agents from what I've seen to work in different parts of large code bases at a time.
If your hitting merge conflicts that bad all the time you should probably just have a single agent doing the work. Especially if they're intertwined rightly
Any setups without Claude Code? I use CoPilot agent heavily on VSCode, from time to time I have independent grunt work that could be parallelized to two or three agents, but I haven't seen a decent setup for that with CoPilot or some other VSCode extension that I could use my CoPilot subscription with.
Co-pilot has a new execute prompt tool in preview that lets it spin out its own requests to LLMs
> why not use the AI itself to come up with a proven paradigm? Because AI can only imitate the language it has seen. If there are no texts in its training materials about what is the best way to use multiple coding agents at the same time, then AI knows very little about that subject matter. AI only knows what humans know, but it knows much more than any single human. We don't know "what is the best way to use multip…
I'm sorry, but the whole stochastic parrot thing is so thoroughly debunked at this point that we should stop repeating it as if it's some kind of rare wisdom. AlphaGo showed that even pre-LLM models could generate brand new approaches to winning a game that human experts had never seen before, and didn't exist in any training material. With a little thought and experimentation, it's pretty easy to show that LLMs can…
>AlphaGo showed that even pre-LLM models could generate brand new approaches to winning a game that human experts had never seen before, and didn't exist in any training material.
AlphaGo is an entirely different kind of algorithm.
Any setups without Claude Code? I use CoPilot agent heavily on VSCode, from time to time I have independent grunt work that could be parallelized to two or three agents, but I haven't seen a decent setup for that with CoPilot or some other VSCode extension that I could use my CoPilot subscription with.
You can use Rover (disclaimer, I am one of the cofounders) which is an open source tool that you can use to parallelize the work of coding agents that in addition to Claude also works with Gemini, Codex and Qwen https://github.com/endorhq/rover/
There are quite a few products designed to help manage multiple agents at once. I'm trying out Conductor right now - https://conductor.build/ - it's a pretty slick macOS desktop app that handles running Claude Code within a GUI and uses Git worktrees to manage separate checkouts at the same time.
We have built Rover, an OSS tool that allows you to run multiple instances of Claude (and Codex, Gemini...) while keeping them from stepping on each other toes using containerized environments and Git worktrees https://github.com/endorhq/rover/
Radioactivity was discovered before nuclear engineering existed. We had phenomena first and only later the math, tooling, and guardrails. LLMs are in that phase. They are powerful stochastic compressors with weak theory. No stable abstractions yet. Objectives shift, data drifts, evals leak, and context windows make behavior path dependent. That is why experts hedge. “Cookbooks about cookbooks” are what a field does w…
We’re in the alchemist phase. If I’m being charitable, the medieval stone mason phase. One thing worth pointing out is that the pre-engineering building large structures phase lasted a long time, and building collapses killed a lot of people while we tried to work out the theory. Also it wasn’t really the stone masons who worked out the theory, and many of them were resistant to it.
While alchemy was mostly para-religious wishful thinking, stone masonry has a lot in common with what I want to express: it‘s the tinkering that is accessible to everyone who can lay their hands onto the tools. But I still think the age of nuclear revolution is a better comparison due to a couple of reasons, most importantly the number of very fast feedback loops. While it might have taken years to even build a new idea from stone, and another couple of years to see if it’s stable over time, we see multi-layered systems of both fast and slow feedback loops in AI-driven software development: academic science, open source communities, huge companies, startups, customers, established code review and code quality tools and standards (e.g. static analysis), feedback from multiple AI-models, activities of regulatory bodies, etc. pp. - the more interactions there are between the elements and subsystems, the better a system becomes at doing the trial-and-error-style tinkering that leads to stable results. In this regard, we’re way ahead of the nuclear revolution, let alone stone masonry.
Could be that it's a bit harder to get started with? You have to configure your "environment" for it correctly - with a script that installs the dependencies etc before the container starts running. That's not an entirely obvious process.
Good point. The environments I’ve set up have been pretty easy but I’ll admit that at first I was very annoyed that it couldn’t just use a pre-existing GitHub action workflow. Edit: environment setup was also buggy when the product launched and still is from time to time. So, now that I have it set up I use it constantly, but they do need to make getting up and running a more delightful experience.
Also, Codex Cloud and similar services require you to give fully access to your repository, which might trigger some concerns. If you can run it locally, you still have the control, same development environment, and same permissions.
I can't seem to get myself to focus when one of these things is running. I transition into low effort mode. Because of this I've decided to have my good hours of the day LLM free, and then in my crappy hours I'll have one of these running.
This is why I uninstalled Cursor and moving to the terminal with Claude Code. I felt I had more control to reduce the noise from LLMs. Before, I noticed that some hours were just wasted looking at the model output and iterating.
Not sure if I improved using agents over time, or just having it in a separate window forces you to use them only when you need. Having it in the IDE seems the "natural" way to start something and now you are trapped in a conversation with the LLM.
Now, my setup is:
- VSCode (without copilot) / Helix
- Claude (active coding)
- Rover (background agent coding). Note I'm a Rover developer
No, it's more like a winner take all market, where a few winners will capture most of the value, and those who sit on the sidelines until everything is figured out are left fighting over the scraps.
> it's more like a winner take all market I'm not sure, why must it be so? In cell-phones we have Apple and Android-phones. In OSes we have Linux, Windows, and Apple. In search-engines we used to have just Google. But what would be the reason to assume that AI must similarly coalesce to a single winner-take-all? And now AI agents are much providing an alternative to Google.
>I'm not sure, why must it be so? In cell-phones...
And then described a bunch of winners in a winner take all market.
Do you see many people trying to revive any of the apple/android alternatives or starting a new one?
Such a market doesn't have to end up in a monopoly that gets broken up.
Plenty of rather sticky duopolies or otherwise severely consolidated markets and the like out there.
If you really want your mind blown, see what Jesse is doing (successfully, which I almost can’t believe) with Graphviz .dot notation and Claude.md: https://blog.fsck.com/2025/09/29/using-graphviz-for-claudemd...
this is just 21st century voodoo
One AI tool dev shared me his prompts to generate safe SQL queries for multi-tenant apps and I was surprised at the repetitiveness and the urging.