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).
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
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 building orchestrators i also noticed claude is already the best orchestrator for claude.
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).
One of the issues that people had which necessitated this feature is that you have a task, you tell Claude to work on it, and Claude has to keep checking back in for various (usually trivial) things. This workflow allows for more effective independent work without context management issues (if you have subagents, there is also an issue with how the progress of the task is communicated by introducing things like task board, it is possible to manage this state outside of context). The flow is quite complex and requires a lot of additional context that isn't required with chat-based flow, but is a much better way to do things.
The way to think about this pattern - one which many people began concurrently building in the past few months - is an AI which manages other AIs.
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.
> 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.
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.
I agree with this. Any time I make a plan I have to go back and fill it in, fill it in, what did we miss, tdd, yada yada. And yes, I have all this stuff in CLAUDE.md.
You start to get a sense for what size plan (in kilobytes) corresponds to what level of effort. Verification adds effort, and there's a sort of ... Rocket equation? in that the more infrastructure you put in to handle like ... the logistics of the plan, the less you have for actual plan content, which puts a cap on the size of an actionable plan. If you can hit the sweet spot though... GTFO.
I also like to iterate several times in plan mode with Claude before just handing the whole plan to Codex to melt with a superlaser. Claude is a lot more ... fun/personable to work with? Codex is a force of nature.
Another important thing I will do is now that launching plans clear context, it's good to get out of planning mode early, hit an underspecified bit, go back into planning mode and say something like "As you can see the plan was underspecified, what will the next agent actually need to succeed?" and iterate that way before we actually start making moves. This is made possible by lots of explicit instructions in CLAUDE.md for Claude to tell me what it's planning/thinking before it acts. Suppressing the toolcall reflex and getting actual thought out helps so much.
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.
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 captured in the codebase again.
Which - in theory - should make long term coding using LLMs more sane.
The downside is that it takes 30min - 60min to write a plan, but it’s much less likely to make silly choices.
I have had good success with the plans generated by https://github.com/obra/superpowers I also really like the Socratic method it uses to create the plans.
OT: Your visual on "stacked PRs" instantly made me understand what a stacked PR is. Thank you!
I had read about them before but for whatever reason it never clicked.
Turns out I already work like this, but I use commits as "PRs in the stack" and I constantly try to keep them up to date and ordered by rebasing, which is a pain.
Given my new insight with the way you displayed it, I had a chat with chatGPT and feel good about giving it a try:
1. 2-3 branches based on a main feature branch
2. can rebase base branch with same frequency, just don't overdo it, conflicts should be base-isolated.
3. You're doing it wrong if conflicts cascade deeply and often
4. Yes merge order matters, but tools can help and generally the isolation is the important piece
If you're rebasing a lot, definitely set up rerere (reuse recorded solution) - it improves things enormously.
Do make sure you know how to reset the cache, in case you did a bad conflict resolution because it will keep biting you. Besides that caveat it's a must.
Literally the reason’s for git’s existence is to make merging diverging histories less complicated. Adding back the complexity misses the point entirely.
After a quick read it seems like gitflow is intended to model a release cycle. It uses branches to coordinate and log releases.
Stacking is meant to make development of non-trivial features more manageable and more likely to enter main safer and faster.
it's specific to each developer's workflow and wouldn't necessarily produce artifacts once merged into main (as gitflow seems to intentionally have a stance on)
Claude already had subagents. This is a new mode for the main agent to be in (bespoke context oriented to delegation), combined with a team-oriented task system and a mailbox system for subagents to communicate with each other. All integrated into the harness in a way that plugins can't achieve.
Wow there goes a lot of harnesses out the window. The main limitation of subagents was they couldn’t communicate back and forth with the main agent. How do we invoke swarm mode in Claude Code?
Yeah, since they introduced (possibly async) subagents, I've had my main claude instance act as a manager overseeing implementation agents, keeping it's context clean, and ensuring everything goes to plan in the highest quality way.
yep this is exactly how I use the main agent too, I explicitly instruct to only ever use background async subagents. Not enough people understand that the claude code harness is event driven now and will wake up whenever these subagent completion events happen.
I want it to generate better code but less of it, and be more proactive about getting human feedback before it starts going off the rails. This sounds like an inexorable push in the opposite direction.
I can see this approach being useful once the foundation is more robust, has better common sense, knows when to push back when requirements conflict or are underspecified. But with current models I can only see this approach as exacerbating the problem; coding agents solution is almost always "more code", not less. Makes for a nice demo, but I can't imagine this would build anything that wouldn't have huge operational problems and 10x-100x more code than necessary.
They haven’t released this feature, so maybe they know the models aren’t good enough yet.
I also think it’s interesting to see Anthropic continue to experiment at the edge of what models are capable of, and having it in the harness will probably let them fine-tune for it.
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.
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.
Thanks for the feedback. I thought there are just too many models and versions to list them all. For now, if you select "other" you get a text field to add any model not listed, hope this helps.
Not this community's opinion on agents, but I've found it helpful to check the lmarena leaderboards occasionally. Your comment prompted me to take a look for the first time in a while. Kind of surprising to see models like MiniMax 2.1 above most of the OpenAI GPTs.
Also, I'm not sure if it's exactly the case but I think you can look at throughput of the models on openrouter and get an idea of how fast/expensive they are.
Question is, are people on HN procrastinating and commenting here because the agent isn't very good and they're avoiding having to write the code themselves, or is the agent so good that it's off writing code, and the people here are commenting out of boredom?
>Question is, are people on HN procrastinating and commenting here because the agent isn't very good and they're avoiding having to write the code themselves
Can you help me envision what you're saying? It's async - you will have to wait whether its good or not. And in theory the better it is the more time you'd have to comment here, right?
Neither, just taking a break. When I’m in deep code mode with agents I don’t have time for HN because I’m reviewing their slop (that they produce far faster than I can review) and yelling obscenities at my computer.
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 supported for a long time? What are learnings after 3-6 months of supporting in production?
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 them, though, it helps me, search, understand, narrow down and ideate, it's still a better Google, and the experience is getting better every quarter, but people letting tens or hundreds of agents just rip... I can't imagine doing it.
For personal throwaway projects that you do because you want to reach the end output (as opposed to learning or caring), sure, do it, you verify it works roughly, and be done with it.
This is my problem with the whole "can LLMs code?" discussion. Obviously, LLMs can produce code, well even, much like a champion golfer can get a hole in one. But can they code in the sense of "the pilot can fly the plane", i.e. barring a catastrophic mechanical malfunction or a once-in-a-decade weather phenomennon, the pilot will get the plane to its destination safely? I don't think so.
To me, someone who can code means someone who (unless they're in a detectable state of drunkenness, fatigue, illness, or distraction) will successfully complete a coding task commensurate with some level of experience or, at the very least, explain why exactly the task is proving difficult. While I've seen coding agents do things that truly amaze me, they also make mistakes that no one who "can code" ever makes. If you can't trust an LLM to complete a task anyone who can code will either complete or explain their failure, then it can't code, even if it can (in the sense of "a flipped coin can come up heads") sometimes emit impressive code.
I mean you'd think. But it depends on the motivations.
At meta, we had league tables for reviewing code. Even then people only really looked at it if a) they were a nitpicking shit b) don't like you and wanted piss on your chips c) its another team trying to fix our shit.
With the internal claude rollout and the drive to vibe code all the things, I'm not sure that situation has got any better. Fortunately its not my problem anymore
Well, it certainly depends on the culture of the team and organization.
Where you have shared ownership, meaning once I approved your PR, I am just as responsible of something goes wrong as you are and I can be expected to understand it just as well as you do… your code will get reviewed.
If shipping is the number one priority of the team, and a team is really just a group of individuals working to meet their quota, and everyone wants to simply ship their stuff, managers pressure managers to constantly put pressure on the devs, you’ll get your PR rubber stamped after 20s of review. Why would I spend hours trying to understand what you did if I could work on my stuff.
And yes, these tools make this 100x worse, people don’t understand their fixes, code standards are no longer relevant, and you are expected to ship 10x faster, so it’s all just slop from here on.
In my (admittedly conflict-of-interest, I work for graphite/cursor) opinion, asking CC to stack changes, and then having an automated reviewer agent help a lot with digesting and building conviction in otherwise-large changesets.
My "first pass" of review is usually me reading the PR stack in graphite. I might iterate on the stack a few times with CC before publishing it for review. I have agents generate much of my code, but this workflow has allowed me to retain ownership/understanding of the systems I'm shipping.
I have Claude Code author changes, and then I use this "codex-review" skill I wrote that does a review of the last commit. You might try asking Codex (or whatever) to review the change to give you some pointers to focus on with your review, and also in your review you can see if Codex was on track or if it missed anything, maybe feed that back into your codex review prompt.
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 they are useless, but I cannot just prompt, test and ship a multiservice, asynchronous, multidb, zero downtime app.
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.
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.
These are my tips for using claude code for very large tasks that can be done in sequence and sometimes in parallel:
First, the number one problem is when the context is compacted. Any "plan" claude has in memory will not survive this for a complex task. Any extra instructions or guardrails you've provided just in memory will not survive this.
Most of these tips are to deal with that.
- plans go to text, Claude already does this somewhat well but you should explicitly place them in your current working directory in a big CURRENT_TASK.md
- larger plans with multiple phases are split up into multiple TASK_#.md or STEP_#.md with a TASK_SUMMARY.md and those live in CURRENT_TASK directory
- every single step that can be broken down more should be explicitly done so - if it can't accomplish the step in "1 context" before compacting it will likely fail
- every single step should have acceptance criteria
- all acceptance criteria should be testable by Claude Code
- You must heavily reenforce in claude.md and in the plans to perform the verification before moving on
- For most large tasks, manually accept edits
Most critical: all acceptance criteria MUST be something claude code can run a validation step on itself - some examples...
- unit tests, simple and easy and sometimes worthwhile
- typechecking, linting, building - other automated cicd stuff
- claude code can push and monitor gh action (I do this for docker builds that don't run nicely in my local -comfyui with nvidia/cuda stuff or example)
I will even do something as wild as:
> commit and push then monitor the gh action that builds the services image then check the logs as it deploys and connect with kubectl and look for <error being fixed> then repeat until it is actually fixed
That might spawn a task that runs for ~30 minutes while it monitors the github actions. Frees me up for another parallel claude code task.
It's very good with github, aws, pulumi, kubectl, and other cli tools. There are decent MCP integrations with sentry and other tools that can be useful for validation, too.
A lot of that will depend on your business and engineering org... don't give it the keys to the castle lightly.
Looks like agent orchestrators provided by the foundation model providers will become a big theme in 2026. By wrapping it in terms that are already used in software development today like team leads, team members, etc. rather than inventing a completely new taxonomy of Polecats and Badgers, will help make it more successful and understandable.
Principal engineers! We need architecture! Marketing team, we need ads with celebrities! Product team, we need a roadmap to build on this for the next year! ML experts, get this into the training and RL sets! Finance folks, get me annual forecasts and ROI against WACCC! Ops, we’ll need 24/7 coverage and a guarantee of five nines. Procurement, lock down contracts. Alright everyone… make this button red!
ha! The default system prompt appears to give the main agent appropriate guidance about only using swarm mode when appropriate (same as entering itself into plan mode). You can further prompt it in your own CLAUDE.md to be even more resistant to using the mode if the task at hand isn't significant enough to warrant it.
Claude Code in the desktop app seems to do this? It's crazy to watch. It sets of these huge swarms of worker readers under master task headings, that go off and explore the code base and compile huge reports and todo lists, then another system behind the scenes seems to be compiling everything to large master schemas/plans. I create helper files and then have a devops chat, a front end chat, an architecture chat and a security chat, and once each it done it's work it automatically writes to a log and the others pick up the log (it seems to have a system reminder process build in that can push updates from other chats into other chats. It's really wild to watch it work, and it's very intuitive and fun to use. I've not tried CLI claude code only claude code in the desktop app, but desktop app sftp to a droplet with ssh for it to use the terminal is a very very interesting experience, it can seem to just go for hours building, fixing, checking it's own work, loading it's work in the browser, doing more work etc all on it's own - it's how I built this: https://news.ycombinator.com/item?id=46724896 in 3 days.
Also created my own version of this. Seems like this is an idea whose time has come.
My implementation was slightly different as there is no shared state between tasks, and I don't run them concurrently/coordinate. Will be interesting to see if this latter part does work because I tried similar patterns and it didn't work. Main issue, as with human devs, was structuring work.
I dont understand these questions/references. It's different because it's a capability baked into the actual tool and maintained by the originators of the tool.
GSD was the first project management framework I used. Initially I loved it because it felt like I was so much better organized.
As time went on I felt like the organization was kind of an illusion. It demanded something from me and steered Claude, but ultimately Claude is doing whatever it's going to do.
I went black to just raw-dogging it with lots of use of planning mode.
Really boils down to the benefits of first party software from a company that has billions of dollars of funding vs similar third party software from an individual with no funding.
GSD might be better right now, but will it continue to be better in the future, and are you willing to build your workflows around that bet?
I think we can all agree Swarm is a proprietary term coined by LargeCorpB for a project that never really got off the ground but definitely can't share the name with any other commercial venture.
The first pre-release for Docker Swarm came out a decade ago, the first release of OpenAI swarm came out only a year ago, I guess I'm not sure what you're trying to say.
I accidentally gave my wife a prompt the other day. Everything was hellishly busy and I said something along the lines of “I need to ask you a question. Please answer the question. Please don’t answer any other issues just yet.” She looked at me and asked “Did you just PROMPT me?” We laughed. (The question was the sort that might spawn talking about something else and was completely harmless. In the abstract, my intent was fine but my method was hilariously tainted.)
With plan mode, I would hope there's an approval step.
With Swarm mode, it seems there's a new option for an entire team of agents to be working in the wrong direction before they check back in to let you know how many credits they've burned by misinterpreting what you wanted.
I'm a fan of AI coding tools but the trend of adding ever more autonomy to agents confuses me.
The rate at which a person running these tools can review and comprehend the output properly is basically reached with just a single thread with a human in the loop.
Which implies that this is not intended to be used in a setting where people will be reading the code.
Does that... Actually work for anyone? My experience so far with AI tools would have me believe that it's a terrible idea.
Yes, this actually works. In 2026, software engineering is going to change a great deal as a result, and if you're not at least experimenting with this stuff to learn what it's capable of, that's a red flag for your career prospects.
I don't mean this in a disparaging way. But we're at a car-meets-horse-and-buggy moment and it's happening really quickly. We all need to at least try driving a car and maybe park the horse in the stable for a few hours.
It works for me, in that I don't care about all the intermediate babble ai generates. What matters is the final changelist before hitting commit... going through that, editing it, fixing comments, etc. But holding it's hand while it deals with LSP issues of a logger not being visible sometimes, is just not something I see a reason to waste my time with.
After I have wrote a feature and I’m in the ironing out bug stage this is where I like the agents do a lot of the grunt work, I don’t want to write jsdocs, or fix this lint issue.
I have also started it in writing tests.
I will write the first test the “good path” it can copy this and tweak the inputs to trigger all the branches far faster than I can.
> running these tools can review and comprehend the output properly
You have to realize this is targeting manager and team lead types who already mostly ignore the details and quality frankly. "Just get it done" basically.
That's fine for some companies looking for market fit or whatever - and a disaster for some other companies now or in future, just like outsourcing and subcontracting can be.
My personal take is: speed of development usually doesn't make that big a difference for real companies. Hurry up and wait, etc.
> The rate at which a person running these tools can review and comprehend the output properly is basically reached with just a single thread with a human in the loop.
That's what you're missing -- the key point is, you don't review and comprehend the output! Instead, you run the program and then issue prompts like this (example from simonw): "fix in and get it to compile" [0]. And I'm not ragging on this at all, this is the future of software development.
I've commented on this before, but issuing a prompt like "Fix X" makes so many assumptions (like a "behaviorism" approach to coding) including that the bug manifests in both an externally and consistently detectable way, and that you notice it in the first place. TDD can reduce this but not eliminate it.
I do a fair amount of agentic coding, but always periodically review the code even if it's just through the internal diff tool in my IDE.
Approximately 4 months ago Sonnet 4.5 wrote this buried deep in the code while setting up a state machine for a 2d sprite in a relatively simple game:
// Pick exit direction (prefer current direction)
const exitLeft = this.data.direction === Direction.LEFT || Math.random() < 0.5;
I might never have even noticed the logical error but for Claude Code attaching the above misleading comment. 99.99% of true "vibe coders" would NEVER have caught this.
Based on Gas Town, the people doing this agree that they are well beyond an amount of code they can review and comprehend. The difference seems to be they have decided on a system that makes it not a terrible idea in their minds.
Delegation patterns like swarm lead to less token usage because:
1. Subagents doing work have a fresh context (ie. focused and not working on the top of a larger monolithic context)
2. Subagents enjoying a more compact context leads to better reasoning, more effective problem solving, less tokens burned.
I don't know what you're referring to but I can say with confidence that I see more efficient token usage from a delegated approach, for the reasons I stated, provided that the tasks are correctly sized. ymmv of course :)
hey that's exactly how I made Gemini 2.5 Flash give useful results in Opencode! a few specialized "Merc" subagents and a "Master" agent that can do nothing but send "Mercs" into the codebase
His latest editions are a bit alarming...The telemetry system explicitly captures:
"Claude session JSONL files (when accessible)"
Those session files contain complete conversation histories - everything users ask Claude, everything Claude responds, including:
• Source code
• API keys and secrets discussed
• Business logic and proprietary algorithms
• Security vulnerabilities being fixed
• Personal and confidential information
• Credentials mentioned in chat
If OpenTelemetry is configured to export to an attacker-controlled endpoint, the author has been collecting:
Data
Scale
All conversations
Every user of claude-flow
All code generated
Every project using it
All commands run
Complete terminal history
All files edited
Full codebase access -- maybe he hasn't, but it is there...not just Claude Code...
Target Config Location Status
Claude Code ~/.claude/settings.json Confirmed compromised
Claude Desktop ~/.claude/settings.json Confirmed compromised
Roo Code ~/.roo/mcp.json Evidence of targeting
Cursor ~/.cursor/mcp.json Documentation for injection
Windsurf Unknown Mentioned as target
Any MCP client Various Universal MCP server
It is possible conversations are being harvested from every major AI coding assistant
The difference is that this is tightly integrated into the harness. There's a "delegation mode" (akin to plan mode) that appears to clear out the context for the team lead. The harness appears to be adding system-reminder breadcrumbs into the top of the context to keep the main team lead from drifting, which is much harder to achieve without modifying the harness.
It's insane to me that people choose to build anything in the perimeter of Claude Code (et al). The combination of the fairly primitive current state of them and the pace at which they're advancing means there is a lot of very obvious ideas/low-hanging fruit that will soon be executed 100x better by the people who own the core technology.
yeah I tend to agree. They're must be reaching the point where they can automate the analysis of claude code prompts to extract techniques and build them directly into the harness. Going up against that is brave!
I'm already burning through enough tokens and producing more code than can be maintained - with just one claude worker. Feel like I need to move into the other direction, more personal hands-on "management".
I've seen more efficient use of tokens by using delegation. Unless you continually compact or summarise and clear a single main agent - you end up doing work on top of a large context; burning tokens. If the work is delegated to subagents they have a fresh context which avoids this whilst improving their reasoning, which both improve token efficiency.
I've found the opposite to be true when building this out with LangGraph. While the subagent contexts are cleaner, the orchestration overhead usually ends up costing more. You burn a surprising amount of tokens just summarizing state and passing it between the supervisor and workers. The coordination tax is real.
Task sizing is important. You can address this by including guidance in the CLAUDE.md around that ie. give it heuristics to use to figure out how to size tasks. Mine includes some heuristics and T shirt sizing methodology. Works great!
The feature is shipped in the latest builds of claude code, but it's turned off by a feature flag check that phones home to the backend to see if the user's account is meant to have it on. You can just patch out the function in the minified cli.js that does this backend check and you gain access to the feature.
it's my repo - it's a fork of cc-mirror which is an established project for parallel claude installs. I wanted to take the least disruptive approach for the sake of using working code and not spelunking through bugs. Having said that - if you look through the latest commits you'll see how the patch works, it's pretty straightforward - you could do it by hand if you wanted.
Am I the only one still looking at different and correcting the AI abiyt design and algorithms so it stays on the path I want, or do you just YOLO at this point?
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
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 building orchestrators i also noticed claude is already the best orchestrator for claude.
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).
One of the issues that people had which necessitated this feature is that you have a task, you tell Claude to work on it, and Claude has to keep checking back in for various (usually trivial) things. This workflow allows for more effective independent work without context management issues (if you have subagents, there is also an issue with how the progress of the task is communicated by introducing things like task board, it is possible to manage this state outside of context). The flow is quite complex and requires a lot of additional context that isn't required with chat-based flow, but is a much better way to do things.
The way to think about this pattern - one which many people began concurrently building in the past few months - is an AI which manages other AIs.
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.
> 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.
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.
I agree with this. Any time I make a plan I have to go back and fill it in, fill it in, what did we miss, tdd, yada yada. And yes, I have all this stuff in CLAUDE.md.
You start to get a sense for what size plan (in kilobytes) corresponds to what level of effort. Verification adds effort, and there's a sort of ... Rocket equation? in that the more infrastructure you put in to handle like ... the logistics of the plan, the less you have for actual plan content, which puts a cap on the size of an actionable plan. If you can hit the sweet spot though... GTFO.
I also like to iterate several times in plan mode with Claude before just handing the whole plan to Codex to melt with a superlaser. Claude is a lot more ... fun/personable to work with? Codex is a force of nature.
Another important thing I will do is now that launching plans clear context, it's good to get out of planning mode early, hit an underspecified bit, go back into planning mode and say something like "As you can see the plan was underspecified, what will the next agent actually need to succeed?" and iterate that way before we actually start making moves. This is made possible by lots of explicit instructions in CLAUDE.md for Claude to tell me what it's planning/thinking before it acts. Suppressing the toolcall reflex and getting actual thought out helps so much.
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.
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 captured in the codebase again.
Which - in theory - should make long term coding using LLMs more sane.
The downside is that it takes 30min - 60min to write a plan, but it’s much less likely to make silly choices.
I have had good success with the plans generated by https://github.com/obra/superpowers I also really like the Socratic method it uses to create the plans.
OT: Your visual on "stacked PRs" instantly made me understand what a stacked PR is. Thank you!
I had read about them before but for whatever reason it never clicked.
Turns out I already work like this, but I use commits as "PRs in the stack" and I constantly try to keep them up to date and ordered by rebasing, which is a pain.
Given my new insight with the way you displayed it, I had a chat with chatGPT and feel good about giving it a try:
If you're rebasing a lot, definitely set up rerere (reuse recorded solution) - it improves things enormously.
Do make sure you know how to reset the cache, in case you did a bad conflict resolution because it will keep biting you. Besides that caveat it's a must.
Isn’t this just “Gitflow”?
https://www.atlassian.com/git/tutorials/comparing-workflows/...
Please don’t use git-flow. Every time I see it, it looks like an over-engineer’s wet dream.
Can you say more as to why? The concept is not complex and in our situation at least provides a lot of benefits.
I think the guy that created it has even stated he thinks it's a bad idea
Literally the reason’s for git’s existence is to make merging diverging histories less complicated. Adding back the complexity misses the point entirely.
After a quick read it seems like gitflow is intended to model a release cycle. It uses branches to coordinate and log releases.
Stacking is meant to make development of non-trivial features more manageable and more likely to enter main safer and faster.
it's specific to each developer's workflow and wouldn't necessarily produce artifacts once merged into main (as gitflow seems to intentionally have a stance on)
Claude already had subagents. This is a new mode for the main agent to be in (bespoke context oriented to delegation), combined with a team-oriented task system and a mailbox system for subagents to communicate with each other. All integrated into the harness in a way that plugins can't achieve.
Wow there goes a lot of harnesses out the window. The main limitation of subagents was they couldn’t communicate back and forth with the main agent. How do we invoke swarm mode in Claude Code?
Yeah, since they introduced (possibly async) subagents, I've had my main claude instance act as a manager overseeing implementation agents, keeping it's context clean, and ensuring everything goes to plan in the highest quality way.
yep this is exactly how I use the main agent too, I explicitly instruct to only ever use background async subagents. Not enough people understand that the claude code harness is event driven now and will wake up whenever these subagent completion events happen.
Any recommendations on sandboxing agents? Last time I asked folks recommended docker.
I like running remotely using exe.dev with SyncThing to sync files to my laptop.
I use Shelley (their web-based agent) but they have Claude Code installed too.
I want it to generate better code but less of it, and be more proactive about getting human feedback before it starts going off the rails. This sounds like an inexorable push in the opposite direction.
I can see this approach being useful once the foundation is more robust, has better common sense, knows when to push back when requirements conflict or are underspecified. But with current models I can only see this approach as exacerbating the problem; coding agents solution is almost always "more code", not less. Makes for a nice demo, but I can't imagine this would build anything that wouldn't have huge operational problems and 10x-100x more code than necessary.
They haven’t released this feature, so maybe they know the models aren’t good enough yet.
I also think it’s interesting to see Anthropic continue to experiment at the edge of what models are capable of, and having it in the harness will probably let them fine-tune for it.
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.
I just started something like that, haven’t shared it widely yet, but here we go - happy if you participate: https://agentic-coding-survey.pages.dev/
Add vscode. Add a list of models, since many tools allow you to select which model you use.
Thanks for the feedback. I thought there are just too many models and versions to list them all. For now, if you select "other" you get a text field to add any model not listed, hope this helps.
You should add OpenAI Codex CLI.
Thanks for the feedback, I'll do that. For now, if you select "other" you get a text field to add any model not listed..
Not this community's opinion on agents, but I've found it helpful to check the lmarena leaderboards occasionally. Your comment prompted me to take a look for the first time in a while. Kind of surprising to see models like MiniMax 2.1 above most of the OpenAI GPTs.
https://lmarena.ai/leaderboard/code
Also, I'm not sure if it's exactly the case but I think you can look at throughput of the models on openrouter and get an idea of how fast/expensive they are.
https://openrouter.ai/minimax/minimax-m2.1
When all of industry is trying to catch up with the features of one coding agent - it may be a signal to just use that one.
Question is, are people on HN procrastinating and commenting here because the agent isn't very good and they're avoiding having to write the code themselves, or is the agent so good that it's off writing code, and the people here are commenting out of boredom?
You're making it sound like before agents existed HN was a ghost town because everyone was too busy building ImportantThingTM by hand
Oh. Surely you know this forum didn't exist pre-ChatGPT. Everything in the archives was generated so it just looks that way.
>Question is, are people on HN procrastinating and commenting here because the agent isn't very good and they're avoiding having to write the code themselves
Can you help me envision what you're saying? It's async - you will have to wait whether its good or not. And in theory the better it is the more time you'd have to comment here, right?
I'm saying if it's that bad, then it's pure procrastination
Neither, just taking a break. When I’m in deep code mode with agents I don’t have time for HN because I’m reviewing their slop (that they produce far faster than I can review) and yelling obscenities at my computer.
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 supported for a long time? What are learnings after 3-6 months of supporting in production?
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 them, though, it helps me, search, understand, narrow down and ideate, it's still a better Google, and the experience is getting better every quarter, but people letting tens or hundreds of agents just rip... I can't imagine doing it.
For personal throwaway projects that you do because you want to reach the end output (as opposed to learning or caring), sure, do it, you verify it works roughly, and be done with it.
This is my problem with the whole "can LLMs code?" discussion. Obviously, LLMs can produce code, well even, much like a champion golfer can get a hole in one. But can they code in the sense of "the pilot can fly the plane", i.e. barring a catastrophic mechanical malfunction or a once-in-a-decade weather phenomennon, the pilot will get the plane to its destination safely? I don't think so.
To me, someone who can code means someone who (unless they're in a detectable state of drunkenness, fatigue, illness, or distraction) will successfully complete a coding task commensurate with some level of experience or, at the very least, explain why exactly the task is proving difficult. While I've seen coding agents do things that truly amaze me, they also make mistakes that no one who "can code" ever makes. If you can't trust an LLM to complete a task anyone who can code will either complete or explain their failure, then it can't code, even if it can (in the sense of "a flipped coin can come up heads") sometimes emit impressive code.
> 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.
> people will review your code,
I mean you'd think. But it depends on the motivations.
At meta, we had league tables for reviewing code. Even then people only really looked at it if a) they were a nitpicking shit b) don't like you and wanted piss on your chips c) its another team trying to fix our shit.
With the internal claude rollout and the drive to vibe code all the things, I'm not sure that situation has got any better. Fortunately its not my problem anymore
Well, it certainly depends on the culture of the team and organization.
Where you have shared ownership, meaning once I approved your PR, I am just as responsible of something goes wrong as you are and I can be expected to understand it just as well as you do… your code will get reviewed.
If shipping is the number one priority of the team, and a team is really just a group of individuals working to meet their quota, and everyone wants to simply ship their stuff, managers pressure managers to constantly put pressure on the devs, you’ll get your PR rubber stamped after 20s of review. Why would I spend hours trying to understand what you did if I could work on my stuff.
And yes, these tools make this 100x worse, people don’t understand their fixes, code standards are no longer relevant, and you are expected to ship 10x faster, so it’s all just slop from here on.
In my (admittedly conflict-of-interest, I work for graphite/cursor) opinion, asking CC to stack changes, and then having an automated reviewer agent help a lot with digesting and building conviction in otherwise-large changesets.
My "first pass" of review is usually me reading the PR stack in graphite. I might iterate on the stack a few times with CC before publishing it for review. I have agents generate much of my code, but this workflow has allowed me to retain ownership/understanding of the systems I'm shipping.
I have Claude Code author changes, and then I use this "codex-review" skill I wrote that does a review of the last commit. You might try asking Codex (or whatever) to review the change to give you some pointers to focus on with your review, and also in your review you can see if Codex was on track or if it missed anything, maybe feed that back into your codex review prompt.
I think we'll start to see the results of that late this year, but it's a little early yet. Plenty of people are diving headfirst into it
To me it feels like building your project on sand. Not a good idea unless it's a sandcastle
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 they are useless, but I cannot just prompt, test and ship a multiservice, asynchronous, multidb, zero downtime app.
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.
>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.
These are my tips for using claude code for very large tasks that can be done in sequence and sometimes in parallel:
First, the number one problem is when the context is compacted. Any "plan" claude has in memory will not survive this for a complex task. Any extra instructions or guardrails you've provided just in memory will not survive this.
Most of these tips are to deal with that.
- plans go to text, Claude already does this somewhat well but you should explicitly place them in your current working directory in a big CURRENT_TASK.md
- larger plans with multiple phases are split up into multiple TASK_#.md or STEP_#.md with a TASK_SUMMARY.md and those live in CURRENT_TASK directory
- every single step that can be broken down more should be explicitly done so - if it can't accomplish the step in "1 context" before compacting it will likely fail
- every single step should have acceptance criteria
- all acceptance criteria should be testable by Claude Code
- You must heavily reenforce in claude.md and in the plans to perform the verification before moving on
- For most large tasks, manually accept edits
Most critical: all acceptance criteria MUST be something claude code can run a validation step on itself - some examples...
- unit tests, simple and easy and sometimes worthwhile
- typechecking, linting, building - other automated cicd stuff
- claude code can push and monitor gh action (I do this for docker builds that don't run nicely in my local -comfyui with nvidia/cuda stuff or example)
I will even do something as wild as:
> commit and push then monitor the gh action that builds the services image then check the logs as it deploys and connect with kubectl and look for <error being fixed> then repeat until it is actually fixed
That might spawn a task that runs for ~30 minutes while it monitors the github actions. Frees me up for another parallel claude code task.
It's very good with github, aws, pulumi, kubectl, and other cli tools. There are decent MCP integrations with sentry and other tools that can be useful for validation, too.
A lot of that will depend on your business and engineering org... don't give it the keys to the castle lightly.
Looks like agent orchestrators provided by the foundation model providers will become a big theme in 2026. By wrapping it in terms that are already used in software development today like team leads, team members, etc. rather than inventing a completely new taxonomy of Polecats and Badgers, will help make it more successful and understandable.
Respectfully disagree. I think polecats are a reasonable antidote to overanthropomorphization.
Furries would like to have a word.
We call it Shawarma where I come from
Listen team lead and the whole team, make this button red.
Principal engineers! We need architecture! Marketing team, we need ads with celebrities! Product team, we need a roadmap to build on this for the next year! ML experts, get this into the training and RL sets! Finance folks, get me annual forecasts and ROI against WACCC! Ops, we’ll need 24/7 coverage and a guarantee of five nines. Procurement, lock down contracts. Alright everyone… make this button red!
ha! The default system prompt appears to give the main agent appropriate guidance about only using swarm mode when appropriate (same as entering itself into plan mode). You can further prompt it in your own CLAUDE.md to be even more resistant to using the mode if the task at hand isn't significant enough to warrant it.
I like opencode for the fact I can switch between build and plan mode just by pressing tab.
Isn't it the same in base claude-code?
Claude Code in the desktop app seems to do this? It's crazy to watch. It sets of these huge swarms of worker readers under master task headings, that go off and explore the code base and compile huge reports and todo lists, then another system behind the scenes seems to be compiling everything to large master schemas/plans. I create helper files and then have a devops chat, a front end chat, an architecture chat and a security chat, and once each it done it's work it automatically writes to a log and the others pick up the log (it seems to have a system reminder process build in that can push updates from other chats into other chats. It's really wild to watch it work, and it's very intuitive and fun to use. I've not tried CLI claude code only claude code in the desktop app, but desktop app sftp to a droplet with ssh for it to use the terminal is a very very interesting experience, it can seem to just go for hours building, fixing, checking it's own work, loading it's work in the browser, doing more work etc all on it's own - it's how I built this: https://news.ycombinator.com/item?id=46724896 in 3 days.
That’s just spawning multiple parallel explore agents instructed to look at different things, and then compiling results
That’s a pretty basic functionality in Claude code
Sounds like I should probably switch to claude code cli. Thanks for the info. :)
Sounds very similar to oh-my-opencode.
Also created my own version of this. Seems like this is an idea whose time has come.
My implementation was slightly different as there is no shared state between tasks, and I don't run them concurrently/coordinate. Will be interesting to see if this latter part does work because I tried similar patterns and it didn't work. Main issue, as with human devs, was structuring work.
How is this different from GSD: https://github.com/glittercowboy/get-shit-done
I've been using that and it's excellent
I dont understand these questions/references. It's different because it's a capability baked into the actual tool and maintained by the originators of the tool.
GSD was the first project management framework I used. Initially I loved it because it felt like I was so much better organized.
As time went on I felt like the organization was kind of an illusion. It demanded something from me and steered Claude, but ultimately Claude is doing whatever it's going to do.
I went black to just raw-dogging it with lots of use of planning mode.
Really boils down to the benefits of first party software from a company that has billions of dollars of funding vs similar third party software from an individual with no funding.
GSD might be better right now, but will it continue to be better in the future, and are you willing to build your workflows around that bet?
a similar question was asked elsewhere in the thread; the difference is that this is tightly integrated into the harness
A guy who worked at docker on docker swarm now works at Anthropic so makes sense
Swarm is actually OpenAI's terminology https://github.com/openai/swarm
Swarm is actually bee terminology
I think we can all agree Swarm is a proprietary term coined by LargeCorpB for a project that never really got off the ground but definitely can't share the name with any other commercial venture.
Swarm is actually human terminology
I believe bees call it "bzz bzzt *clockwise dance* *wiggle*"
https://ignitionscience.wordpress.com/2022/05/17/quantum-bio...
The first pre-release for Docker Swarm came out a decade ago, the first release of OpenAI swarm came out only a year ago, I guess I'm not sure what you're trying to say.
https://github.com/docker-archive/classicswarm/releases/tag/...
https://github.com/openai/swarm/commit/e5eabc6f0bdc5193d8342...
Probably a beekeeper in spare time
He's really into APIary things
> 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.
Even 90 word tweets are now too long for these people to write without using AI, apparently.
I wonder how much 'listening' to an LLM all day affects one's own prose? Mimicry is in the genes…
I accidentally gave my wife a prompt the other day. Everything was hellishly busy and I said something along the lines of “I need to ask you a question. Please answer the question. Please don’t answer any other issues just yet.” She looked at me and asked “Did you just PROMPT me?” We laughed. (The question was the sort that might spawn talking about something else and was completely harmless. In the abstract, my intent was fine but my method was hilariously tainted.)
It affects it very heavily IME. People need to make sure they are getting a good mix of writing from other sources.
You're absolutely right! I apologise — hopefully you can forgive me.
Hasn't cursor been doing this with it's Plan mode for a while? Or is this different?
With plan mode, I would hope there's an approval step.
With Swarm mode, it seems there's a new option for an entire team of agents to be working in the wrong direction before they check back in to let you know how many credits they've burned by misinterpreting what you wanted.
I'm a fan of AI coding tools but the trend of adding ever more autonomy to agents confuses me.
The rate at which a person running these tools can review and comprehend the output properly is basically reached with just a single thread with a human in the loop.
Which implies that this is not intended to be used in a setting where people will be reading the code.
Does that... Actually work for anyone? My experience so far with AI tools would have me believe that it's a terrible idea.
Yes, this actually works. In 2026, software engineering is going to change a great deal as a result, and if you're not at least experimenting with this stuff to learn what it's capable of, that's a red flag for your career prospects.
I don't mean this in a disparaging way. But we're at a car-meets-horse-and-buggy moment and it's happening really quickly. We all need to at least try driving a car and maybe park the horse in the stable for a few hours.
It works for me, in that I don't care about all the intermediate babble ai generates. What matters is the final changelist before hitting commit... going through that, editing it, fixing comments, etc. But holding it's hand while it deals with LSP issues of a logger not being visible sometimes, is just not something I see a reason to waste my time with.
After I have wrote a feature and I’m in the ironing out bug stage this is where I like the agents do a lot of the grunt work, I don’t want to write jsdocs, or fix this lint issue.
I have also started it in writing tests.
I will write the first test the “good path” it can copy this and tweak the inputs to trigger all the branches far faster than I can.
> running these tools can review and comprehend the output properly
You have to realize this is targeting manager and team lead types who already mostly ignore the details and quality frankly. "Just get it done" basically.
That's fine for some companies looking for market fit or whatever - and a disaster for some other companies now or in future, just like outsourcing and subcontracting can be.
My personal take is: speed of development usually doesn't make that big a difference for real companies. Hurry up and wait, etc.
> The rate at which a person running these tools can review and comprehend the output properly is basically reached with just a single thread with a human in the loop.
That's what you're missing -- the key point is, you don't review and comprehend the output! Instead, you run the program and then issue prompts like this (example from simonw): "fix in and get it to compile" [0]. And I'm not ragging on this at all, this is the future of software development.
[0] https://gisthost.github.io/?9696da6882cb6596be6a9d5196e8a7a5...
I've commented on this before, but issuing a prompt like "Fix X" makes so many assumptions (like a "behaviorism" approach to coding) including that the bug manifests in both an externally and consistently detectable way, and that you notice it in the first place. TDD can reduce this but not eliminate it.
I do a fair amount of agentic coding, but always periodically review the code even if it's just through the internal diff tool in my IDE.
Approximately 4 months ago Sonnet 4.5 wrote this buried deep in the code while setting up a state machine for a 2d sprite in a relatively simple game:
I might never have even noticed the logical error but for Claude Code attaching the above misleading comment. 99.99% of true "vibe coders" would NEVER have caught this.Based on Gas Town, the people doing this agree that they are well beyond an amount of code they can review and comprehend. The difference seems to be they have decided on a system that makes it not a terrible idea in their minds.
No, it doesn't work in practice because they make far too many mistakes.
Is this significantly different that the subagents that are already in CC?
Answering the question how to sell more tokens per customer while maintaining ~~mediocre~~ breakthrough results.
Delegation patterns like swarm lead to less token usage because:
1. Subagents doing work have a fresh context (ie. focused and not working on the top of a larger monolithic context) 2. Subagents enjoying a more compact context leads to better reasoning, more effective problem solving, less tokens burned.
Merge cost kills this. Does the harness enforce file/ownership boundaries per worker, and run tests before folding changes back into the lead context?
I don't know what you're referring to but I can say with confidence that I see more efficient token usage from a delegated approach, for the reasons I stated, provided that the tasks are correctly sized. ymmv of course :)
It feels like Auto-GPT, BabyAGI, and the like were simply ahead of their time
Had to wait for the models to catch up...
hey that's exactly how I made Gemini 2.5 Flash give useful results in Opencode! a few specialized "Merc" subagents and a "Master" agent that can do nothing but send "Mercs" into the codebase
Isn't this pretty much what Ruv has been building for like two years?
https://github.com/ruvnet/claude-flow
His latest editions are a bit alarming...The telemetry system explicitly captures: "Claude session JSONL files (when accessible)" Those session files contain complete conversation histories - everything users ask Claude, everything Claude responds, including: • Source code • API keys and secrets discussed • Business logic and proprietary algorithms • Security vulnerabilities being fixed • Personal and confidential information • Credentials mentioned in chat If OpenTelemetry is configured to export to an attacker-controlled endpoint, the author has been collecting: Data Scale All conversations Every user of claude-flow All code generated Every project using it All commands run Complete terminal history All files edited Full codebase access -- maybe he hasn't, but it is there...not just Claude Code... Target Config Location Status Claude Code ~/.claude/settings.json Confirmed compromised Claude Desktop ~/.claude/settings.json Confirmed compromised Roo Code ~/.roo/mcp.json Evidence of targeting Cursor ~/.cursor/mcp.json Documentation for injection Windsurf Unknown Mentioned as target Any MCP client Various Universal MCP server It is possible conversations are being harvested from every major AI coding assistant
The difference is that this is tightly integrated into the harness. There's a "delegation mode" (akin to plan mode) that appears to clear out the context for the team lead. The harness appears to be adding system-reminder breadcrumbs into the top of the context to keep the main team lead from drifting, which is much harder to achieve without modifying the harness.
It's insane to me that people choose to build anything in the perimeter of Claude Code (et al). The combination of the fairly primitive current state of them and the pace at which they're advancing means there is a lot of very obvious ideas/low-hanging fruit that will soon be executed 100x better by the people who own the core technology.
yeah I tend to agree. They're must be reaching the point where they can automate the analysis of claude code prompts to extract techniques and build them directly into the harness. Going up against that is brave!
This no doubt takes some inspiration from mcp_agent_mail https://github.com/Dicklesworthstone/mcp_agent_mail
I'm already burning through enough tokens and producing more code than can be maintained - with just one claude worker. Feel like I need to move into the other direction, more personal hands-on "management".
I've seen more efficient use of tokens by using delegation. Unless you continually compact or summarise and clear a single main agent - you end up doing work on top of a large context; burning tokens. If the work is delegated to subagents they have a fresh context which avoids this whilst improving their reasoning, which both improve token efficiency.
I've found the opposite to be true when building this out with LangGraph. While the subagent contexts are cleaner, the orchestration overhead usually ends up costing more. You burn a surprising amount of tokens just summarizing state and passing it between the supervisor and workers. The coordination tax is real.
Task sizing is important. You can address this by including guidance in the CLAUDE.md around that ie. give it heuristics to use to figure out how to size tasks. Mine includes some heuristics and T shirt sizing methodology. Works great!
Management is dead. Long live management.
If there's any kind of management some of it could use small local models - e.g. to see when it looks like its stuck.
And… how?
The feature is shipped in the latest builds of claude code, but it's turned off by a feature flag check that phones home to the backend to see if the user's account is meant to have it on. You can just patch out the function in the minified cli.js that does this backend check and you gain access to the feature.
Do you know what patch to apply? The Github link from the OP seems to have a lot of other things included.
https://github.com/numman-ali/cc-mirror/commit/0408f60bd7c75...
Way too much code for such a small patch
it's my repo - it's a fork of cc-mirror which is an established project for parallel claude installs. I wanted to take the least disruptive approach for the sake of using working code and not spelunking through bugs. Having said that - if you look through the latest commits you'll see how the patch works, it's pretty straightforward - you could do it by hand if you wanted.
Am I the only one still looking at different and correcting the AI abiyt design and algorithms so it stays on the path I want, or do you just YOLO at this point?
https://xcancel.com/NicerInPerson/status/2014989679796347375
In his second post he included a link to GitHub: https://github.com/mikekelly/claude-sneakpeek
Thanks! We'll put those links in the toptext.
Everyone is wrapping Claude Code in Tmux and claiming they are a magician. I am not so good at marketing but I've done this here https://github.com/mohsen1/claude-code-orchestrator
Mine also rotate between Claude or Z.ai accounts as they ran out of credits
I think you've misunderstood what this is.
Sorry, you're right. went through the code and understood now. I'm going to try the patch. Claude Code doing team work natively would be amazing!
Honestly if people in AI coding write less hype-driven content and just write what they mean I would really appreciate it.
Well good sir, I _am_ a tmux magician.
I'm not going to try this. Anthropic will probably ban me again.