Live data from Hacker News

Claude Code's new hidden feature: Swarms

twitter.com

131–140 of 351 posts

Re: Claude Code's new hidden feature: Swarms

#131

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 isn't sub agents. The gap with existing tooling is that the abstraction is over a task rather than a conversation (due to the issue with third-party apps, Claude Code has been inherently limited to conversations which is why they have been lacking in this area, Claude Code Web was the first move in this direction), and the AI is actually coordinating the work (as opposed to being constantly prompted by the user).…

It isn't "just" sub agents, but you can achieve most of this just with a few agents that take on generic roles, and a skill or command that just tells claude to orchestrate those agents, and a CLAUDE.md that tells it how to maintain plans and task lists, and how to allow the agents to communicate their progress.

It isn't all that hard to bootstrap. It is, however, something most people don't think about and shouldn't need to have to learn how to cobble together themselves, and I'm sure there will be advantages to getting more sophisticated implementations.

Re: Claude Code's new hidden feature: Swarms

#132

> You're not talking to an AI coder anymore. You're talking to a team lead. The lead doesn't write code - it plans, delegates, and synthesizes. They couldn't even be bothered to write the Tweet themselves...

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

Re: Claude Code's new hidden feature: Swarms

#133

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 isn't sub agents. The gap with existing tooling is that the abstraction is over a task rather than a conversation (due to the issue with third-party apps, Claude Code has been inherently limited to conversations which is why they have been lacking in this area, Claude Code Web was the first move in this direction), and the AI is actually coordinating the work (as opposed to being constantly prompted by the user).…

> Claude Code has been inherently limited to conversations

How so? I’ve been using “claude -p” for a while now.

But even within an interactive session, an agent call out is non-interactive. It operates entirely autonomously, and then reports back the end result to the top level agent.

Re: Claude Code's new hidden feature: Swarms

#134

> You're not talking to an AI coder anymore. You're talking to a team lead. The lead doesn't write code - it plans, delegates, and synthesizes. They couldn't even be bothered to write the Tweet themselves...

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

Very much so. It feels like it can't have been that common in the original training corpus. Probably more common now given that we are training slop generators with slop.

Re: Claude Code's new hidden feature: Swarms

#135
post #75

I'd really like to see a regular poll on HN that keeps track of which AI coding agents are the most popular among this community, like the TIOBE Index for programming languages. Hard to keep up with all the changes and it would be nice to see a high level view of what people are using and how that might be shifting over time.

I personally don't want to trawl through Twitter to find the current state-of-the-art, so I read Zvi Mowshowitz's newsletter:

https://thezvi.substack.com/

His newsletter put me onto using Opus 4.5 exclusively on Dec 1, a little over a week after it was released. That's pretty good for a few minutes of reading a week.

Re: Claude Code's new hidden feature: Swarms

#136
post #118

Earlier quoted context omitted.

I just can’t get with this. There is so much beyond “works” in software. There are requirements that you didn’t know about and breaking scenarios that you didn’t plan for and if you don’t know how the code works, you’re not going to be able to fix it. Assuming an AI could fix any problem given a good enough prompt, I can’t write that prompt without sufficient knowledge and experience in the codebase. I’m not saying t…

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 conveying an implicit mental model to the reader.

The first problem is that many of these pathways and edge cases aren’t apparent until the actual implementation, and sometimes in the process the author realizes that the overall app would work better if it were re-specified from the start. This opportunity is lost without a hands on approach.

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.

Re: Claude Code's new hidden feature: Swarms

#138
Ok it might sound crazy but I actually got the best quality of code (completely ignoring that the cost is likely 10x more) by having a full “project team” using opencode with multiple sub agents which are all managed by a single Opus instance. I gave them the task to port a legacy Java server to C# .NET 10. 9 agents, 7-stage Kanban with isolated Git Worktrees.

Manager (Claude Opus 4.5): Global event loop that wakes up specific agents based on folder (Kanban) state.

Product Owner (Claude Opus 4.5): Strategy. Cuts scope creep

Scrum Master (Opus 4.5): Prioritizes backlog and assigns tickets to technical agents.

Architect (Sonnet 4.5): Design only. Writes specs/interfaces, never implementation.

Archaeologist (Grok-Free): Lazy-loaded. Only reads legacy Java decompilation when Architect hits a doc gap.

CAB (Opus 4.5): The Bouncer. Rejects features at Design phase (Gate 1) and Code phase (Gate 2).

Dev Pair (Sonnet 4.5 + Haiku 4.5): AD-TDD loop. Junior (Haiku) writes failing NUnit tests; Senior (Sonnet) fixes them.

Librarian (Gemini 2.5): Maintains "As-Built" docs and triggers sprint retrospectives.

You might ask yourself the question “isn’t this extremely unnecessary?” and the answer is most likely _yes_. But I never had this much fun watching AI agents at work (especially when CAB rejects implementations). This was an early version of the process that the AI agents are following (I didn’t update it since it was only for me anyway): https://imgur.com/a/rdEBU5I

Re: Claude Code's new hidden feature: Swarms

#139
post #74

Earlier quoted context omitted.

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.

Interesting about the level of detail. I’ve noticed that myself but I haven’t done much to address it yet. I can imagine some ideas (ask it for more detail, ask it to make a smaller plan and add detail to that) but I’m curious if you have any experience improving those plans.

I iterate around issues. I have a skill to launch a new tmux window for worktree with Claude in one pane and Codex in another pane with instructions on which issue to work on, Claude has instructions to create a plan, while Codex has instructions to understand the background information necessary for this issue to be worked on. By the time they're both done, then I can feed Claude's plan into Codex, and Codex is ready to analyze it. And then Codex feeds the plan back to Claude, and they kind of ping pong like that a couple times. And after a certain or several iterations, there's enough refinement that things usually work. Then Claude clears context and executes the plan. Then Codex reviews the commit and it still has all the original context so it knows what we have been planning and what the research was about the infrastructure. And it does a really good job reviewing. And again, then they ping pong back and forth a couple times, and the end product is pretty decent. Codex's strength is that it really goes in-depth. I usually do this at a high reasoning effort. But Codex has zero EQ or communication skills, so it works really well as a pedantic reviewer. Claude is much more pleasant to interact with. There's just no comparison. That's why I like planning with Claude much more because we can iterate.. I am just a hobbyist though. I do this to run my Ansible/Terraform infrastructure for a good size homelab with 10 hosts. So we actually touch real hardware a lot and there's always some gotchas to deal with. But together, this is a pretty fun way to work. I like automating stuff, so it really scratches that itch.

Re: Claude Code's new hidden feature: Swarms

#140
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…

In a professional setting where you still have coding standards, and people will review your code, and the code actually reaches hundreds of thousands of real users, handling one agent at a time is plenty for me. The code output is never good enough, and it makes up stuff even for moderately complicated debugging ("Oh I can clearly see the issue now", I heard it ten times before and you were always wrong!) I do use t…

> people will review your code,

People will ask LLM to review some slop made by LLM and they will be absolutely right!

There is no limit to lazyness.

Post reply on HN