Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Code's new hidden feature: Swarms

twitter.com

Post reply on HN
Print view View original

341–350 of 351 posts

Re: Claude Code's new hidden feature: Swarms

#341

Post by chickensong »

stingraycharles wrote: post #50
joshribakoff wrote: post #42

This is just sub agents, built into Claude. You don’t need 300,000 line tmux abstractions written in go. You just tell Claude to do work in parallel with background sub agents. It helps to have a file for handing off the prompt, tracking progress, and reporting back. I also recommend constraining agents to their own worktrees. I am writing down the pattern here https://workforest.space while nearly everyone is buildi…

It’s even less of a feature, Claude Code already has subagents; this new feature just ensures Claude Code actually uses this for implementation. imho the plans of Claude Code are not detailed enough to pull this off; they’re trying to do it to preserve context, but the level of detail in the plans is not nearly enough for it to be reliable.

> the plans of Claude Code are not detailed enough

You can make a template and tell Claude to make a plan that follows the template.

Re: Claude Code's new hidden feature: Swarms

#342

Post by chickensong »

asimeqi wrote: post #337
replwoacause wrote: post #230

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 direct…

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.

Re: Claude Code's new hidden feature: Swarms

#343

Post by adastra22 »

skippyboxedhero wrote: post #324
tobyjsullivan wrote: post #154

Earlier quoted context omitted.

I believe they’re talking about Claude Code’s built-in agents feature which works fine with a Max subscription. https://code.claude.com/docs/en/sub-agents Are you talking about the same thing or something else like having Claude start new shell sessions?

Okay...and continue to work up the levels? Why do you think OAuth might be limiting? Why do you think they started building subagents first? What is the difference between subagents and products like Aider? If they were able to wrap the API directly, this is relatively easy to implement but they have to do this within Claude Code which is based on giving a prompt/hiding API access. This is obvious if you think carefu…

What does OAuth have to do with any of this? I think you are deeply confused.

Re: Claude Code's new hidden feature: Swarms

#344

Post by stingraycharles »

throwup238 wrote: post #339
stingraycharles wrote: post #90

Earlier quoted context omitted.

I’m trying to solve this myself by implementing a whole planner workflow at https://github.com/solatis/claude-config Effectively it tries to resolve all ambiguities by making all decisions explicit — if the source cannot be resolved to documentation or anything, it’s asked to the user. It also tries to capture all “invisible knowledge” by documenting everything, so that all these decisions and business context are ca…

> The downside is that it takes 30min - 60min to write a plan Oof you weren't kidding. I've got your skills running on a particularly difficult problem and it's been running for over three hours (I keep telling it to increase the number of reviews until its satisfied).

Yeah I’m working on some improvements in this area, should make things faster. But yeah I’ve frequently had 1h-2h planning sessions as well, depending upon the complexity of the task.

Re: Claude Code's new hidden feature: Swarms

#345

Post by ryanjshaw »

joshuaisaact wrote: post #309
ryanjshaw wrote: post #288

Earlier quoted context omitted.

I don’t follow. You said it’s over engineering and then proposed what appears to be functionally the exact same thing? Isn’t a “role” just a compact way to configure well-known systems of constraints by leveraging LLM training? Is your proposal that everybody independently reinvent the constraints wheel, so to speak?

Fair push back. The distinction I'm drawing is between: A. Using a role prompt to configure a single function's scope ("you are a code reviewer, focus on X") - totally reasonable, leverages training B. Building an elaborate multi-agent orchestration layer with hand-offs, coordination protocols, and framework abstractions on top of that I'm not arguing against A. I'm arguing that B often adds complexity without propor…

Thanks for clarifying. I’ve queued up that paper.

I’m building an agentic solution to a problem (monitoring social media and news sources, then building world views of different participants).

A single agent would have insufficient context window size to achieve this in one API call, which means I need parallel agents. Then I have to consolidate the parallel outputs in a way that correctly updates state. I feel like multi-agent is the only way to solve this.

Effectively I’m treating the agents as threads and the roles as functions, with one agent managing writing state to avoid shared state surprises. Thinking of it with the actor model (= mailboxes) makes orchestration fairly straightforward and not really much more complex than the way we already build distributed/multi-threaded applications so I was wondering if I was missing something about why this would be an issue just because the implementation is an LLM prompt instead of a typical programming language.

Re: Claude Code's new hidden feature: Swarms

#346

Post by vidarh »

skippyboxedhero wrote: post #323
vidarh wrote: post #196

Earlier quoted context omitted.

> Have you actually tried to do this? i.e. not within a Claude Code chat instance but by one-shot prompting. You ask if I've tried to do this, and then set constraints that are completely different to what I described. I have done what I described. Several times for different projects. I have a setup like that running right now in a different window. > It is hard to bootstrap because this isn't how Claude Code works.…

I can tell you based on your description that you did not do this. Subagents are completely different and cannot be used in this way. No, it isn't how Claude Code works because Claude Code is designed to work with limited task queues, this is not what this feature is. Again, I would suggest you trying to actually build something like this. Why do you think Anthropic are doing this? They just don't understand anything…

> I can tell you based on your description that you did not do this. Subagents are completely different and cannot be used in this way.

And yet I have used them exactly in the way I described. That you assume they can't just demonstrate that you haven't tried very hard.

> No, it isn't how Claude Code works because Claude Code is designed to work with limited task queues, this is not what this feature is.

Claude allows your setup to execute arbitrary code that gets injected into context. The entire point is that you don't need to rely on built in capabilities of Claude Code to do any of this.

> No, it doesn't work within that context. Again: sharing context between subagents, single instance running for months...I am not even sure why someone would think this could work.

I know what I described works because I am doing it. You can achieve what I described in a variety of ways: Using skills to tell the agents how to access a shared communications channel. Using MCP servers. Just using CLAUDE.md and describe how to use files as a shared communications channel.

This is only difficult if you lack imagination.

> You are talking about having some CLAUDE.md files like you have invented the wheel, lol. HN is great.

No, the exact opposite: I'm saying that this isn't hard, that it isn't anything revolutionary or even special. It's pretty basic usage of the existing facilities. There's no invention there.

You're the one trying to imply this is more revolutionary than it is.

Re: Claude Code's new hidden feature: Swarms

#347

Post by mrtesthah »

TeMPOraL wrote: post #189
mrtesthah wrote: post #132

Earlier quoted context omitted.

isn’t it interesting how often this rhetorical construction is overused by AI?

Partly because it's a good construct . Most people's writing is garbage compared to what LLMs output by default. But the other part of it is, each conversation you have, and each piece of AI output you read online, is written by LLM instance that has no memory of prior conversations, so it doesn't know that, from human perspective, it used this construct 20 times in the last hour. Human writers avoid repeating the sa…

>But the other part of it is, each conversation you have, and each piece of AI output you read online, is written by LLM instance that has no memory of prior conversations, so it doesn't know that, from human perspective, it used this construct 20 times in the last hour.

In theory we should be able to use these properties to detect LLM-generated output better if we can explore how they originate in the “default” trained feature space.

Re: Claude Code's new hidden feature: Swarms

#348

Post by yencabulator »

czhu12 wrote: post #66

The problem I’ve been having is that when Claude generates copious amounts of code, it makes it way harder to review than small snippets one at a time. Some would argue there’s no point reviewing the code, just test the implementation and if it works, it works. I still am kind of nervous doing this in critical projects. Anyone just YOLO code for projects that’s not meant to be one time, but fully intend to have to be…

> when Claude generates copious amounts of code, it makes it way harder to review than small snippets one at a time.

I find Claude Code to be very steerable. Ask it to make small atomic commits and it will.

Re: Claude Code's new hidden feature: Swarms

#349

Post by atonse »

mrtesthah wrote: post #136
atonse wrote: post #118

Earlier quoted context omitted.

I don’t know what your stack is, but at least with elixir and especially typescript/nextJS projects, and properly documenting all those pieces you mentioned, it goes a long way. You’d be amazed.

I would never use, let alone pay for, a fully vibe-coded app whose implementation no human understands. Whether you’re reading a book or using an app, you’re communicating with the author by way of your shared humanity in how they anticipate what you’re thinking as you explore the work. The author incorporates and plans for those predicted reactions and thoughts where it makes sense. Ultimately the author is conveyin…

> The second problem is that, the less human touch is there, the less consistent the mental model conveyed to the user is going to be, because a specification and collection of prompts does not constitute a mental model. This can create subconscious confusion and cognitive friction when interacting with the work.

Which is why, on the one hand, the talk about "this is replacing software devs" is going to still be premature for many use cases. Because there is more to software than just the code output.

But on the other hand, a lot of software is riddled with inconsistent mental models today, depending on its age, who the UX people were, etc. This is not something unique to vibe coded apps.

Re: Claude Code's new hidden feature: Swarms

#350

Post by sothatsit »

daxfohl wrote: post #327
sothatsit wrote: post #256

Earlier quoted context omitted.

The solutions you suggest are multiple agents. An agent is nothing more than a linear context and a system that calls tools in a loop while appending to that context. Whether you run them in a single thread where you fork the context and hotswap between the branches, or multiple threads where each thread keeps track of its own context, you are running multiple agents either way. Fundamentally, forking your context, o…

I guess there needs to be a definition of "agent". To my intuition, the "agent" approach means multiple independent AI automata working in parallel and communicating via some async channels, each managing only its own context, each "always on", always doing something. The orchestrator is its own automaton and assigns agents to tasks, communicating through the same channels, mimicking the behavior and workflow of an e…

The bigger change is just to manage multiple contexts at all. I think how that is implemented will be determined through experimentation. I don't think the problems get much harder when you have multiple API requests in flight at once vs. doing them serially as you suggest. And for today's models, the speed increase would be nice, so it seems like it would be worthwhile.
Post reply on HN