Comment by replwoacause
14 days ago
I've done plenty of vibe coding even though I know how to program but I mostly work with a single agent through its CLI. The progress is really good and more importantly, I can follow it. I can read the output, test it, and understand what changed and why. I don't see much upside in swarms. But I do see the downside which is losing the ability to keep the whole system in my head. The codebase starts growing in directions I didn't choose and it seems decisions will get made I didn't review. Early AI autocomplete that could finish a function already felt like a big productivity win and then AI that could write whole files was an even bigger jump. Like pretty massive. Running one agent at a time, watching what it does, and vetting the output still works well for me and still feels like a strong multiplier. But now there's so much more ceremony: AGENTS.md, SKILLS.md, delegation frameworks. I guess I'm not convinced that leads to better outcomes but I'm probably missing something. It just seems like a tradeoff that sacrifices understanding for ostensible progress.
Ya I saw a comment a few weeks ago about "leaving productivity on the table!". I'm generating 3 long files at a prompt now, how much more productivity do I need? Any more and I'll have zero idea what is going on.
My understanding is that this system just produces much better result (it’s all about clean context windows) so you just don’t have a choice. What they could improve on is logs where you can easily see what subagents do. I think subagents are still relatively new and immature.
I can barely keep up with one instance of Claude Code. In fact even that one sits iddle half the time as I test its output and try to explain what it did wrong. What are people programming that needs 10 agents?
I think the highly parallel setups make more sense if you fully embrace vibe coding, but there's value to be had outside of that as well. Delegating tasks to sub-agents to help with context management is a good place to start.
I don't yolo much code, but even so, there are some times where you reach a point where parallelism starts to make sense.
Once you have a stable workflow and foundation, and you front load design and planning, you might see opportunities appear. Writing tests, testing loops, simple features, documentation, etc.
I'm not in research, but I could imagine trying to solve hard problems by trying different approaches, or testing against different data, all in parallel.