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
If they make the LLMs more productive, it is probably explained by a less complicated phenomenon that has nothing to do with the names of the roles, or their descriptions. Adversarial techniques work well for ensuring quality, parallelism is obviously useful, important decisions should be made by stronger models, and using the weakest model for the job helps keep costs down.
For instance, if an agent only has to be concerned with one task, its context can be massively reduced. Further, the next agent can just be told the outcome, it also has reduced context load, because it doesn't need to do the inner workings, just know what the result is.
For instance, a security testing agent just needs to review code against a set of security rules, and then list the problems. The next agent then just gets a list of problems to fix, without needing a full history of working it out.
“Organizations are constrained to produce designs which are copies of the communication structures of these organizations.”
Maybe a different separation of roles would be more efficient in theory, but an LLM understands "you are a scrum master" from the get go, while "you are a zhydgry bhnklorts" needs explanation.
When you think about what an LLM is, it makes more sense. It causes a strong activation for neorons related to "code review", and so the model's output sounds more like a code review.
I came across a concept called DreamTeam, where someone was manually coordinating GPT 5.2 Max for planning, Opus 4.5 for coding, and Gemini Pro 3 for security and performance reviews. Interesting approach, but clearly not scalable without orchestration. In parallel, I was trying to do repeatable workflows like API migration, Language migration, Tech stack migration using Coding agents.
Pied-Piper is a subagent orchestration system built to solve these problems and enable repeatable SDLC workflows. It runs from a single Claude Code session, using an orchestrator plus multiple agents that hand off tasks to each other as part of a defined workflow called Playbooks: https://github.com/sathish316/pied-piper
Playbooks allow you to model both standard SDLC pipelines (Plan → Code → Review → Security Review → Merge) and more complex flows like language migration or tech stack migration (Problem Breakdown → Plan → Migrate → Integration Test → Tech Stack Expert Review → Code Review → Merge).
Ideally, it will require minimal changes once Claude Swarm and Claude Tasks become mainstream.
The previous generations of AI (AI in the academic sense) like JASON, when combined with a protocol language like BSPL, seems like the easiest way to organize agent armies in ways that "guarantee" specific outcomes.
The example above is very cool, but I'm not sure how flexible it would be (and there's the obvious cost concern). But, then again, I may be going far down the overengineering route.
I built a drag and drop UI tool that sets up a sequence of agent steps (Claude code or codex) and have created different workflows based on the task. I'll kick them off and monitor.
Here's the tool I built for myself for this: https://github.com/smogili1/circuit
Have you been able to build anything productionizable this way, or are you just using this workflow for rapid prototyping?
I've been working on something in this space too. I built https://sonars.dev specifically for orchestrating multiple Claude Code agents working in parallel on the same codebase. Each agent gets its own workspace/worktree and there's a shared context layer so they can ask each other questions about what's happening elsewhere (kind of like your Librarian role but real-time).
The "ask the architect" pattern you described is actually built into our MCP tooling: any agent can query a summary of what other agents have done/learned without needing to parse their full context.
1. Are you using a Claude Code subscription? Or are you using the Claude API? I'm a bit scared to use the subscription in OpenCode due to Anthropic's ToS change.
2. How did you choose what models to use in the different agents? Do you believe or know they are better for certain tasks?
Not a change, but enforcing terms that have been there all the time.
- I built a system where context (+ the current state + goal) is properly structured and coding agents only get the information they actually need and nothing more. You wouldn’t let your product manager develop your backend and I gave the backend dev only do the things it is supposed to and nothing more. If an agent crashes (or quota limits are reached), the agents can continue exactly where the other agents left off.
- Agents are ”fighting against” each other to some extend? The Architect tries to design while the CAB tries to reject.
- Granular control. I wouldn’t call “the manager” _a deterministic state machine that is calling probabilistic functions_ but that’s to some extent what it is? The manager has clearly defined tasks (like “if file is in 01_design —> Call Architect)
Here’s one example of an agent log after a feature has been implemented from one of the older codebases: https://pastebin.com/7ySJL5Rg
Applying distributed human team concepts to a porting task squeezes extra performance from LLMs much further up the diminishing returns curve. That matters because porting projects are actually well-suited for autonomous agents: existing code provides context, objective criteria catch more LLM-grade bugs than greenfield work, and established unit tests offer clear targets.
I guess what I'm trying to say is that the setup seems absurd because it is. Though it also carries real utility for this specific use case. Apply the same approach to running a startup or writing a paid service from scratch and you'd get very different results.
You need to have different skills at different times. This type of setup helps break those skills out.
It attracts the gamers and LARPers. Unfortunately, management is on their side until they find out after four years or so that it is all a scam.
Corporate has to die
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 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.
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.
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.
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.
Not sure how well it’s working though (my agents haven’t used 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.
You can make a template and tell Claude to make a plan that follows the template.
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 pieceDo 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.
https://www.atlassian.com/git/tutorials/comparing-workflows/...
I use Shelley (their web-based agent) but they have Claude Code installed too.
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.
For the first part of this comment, I thought "trying to reinvent Istanbul in a bash script" was meant to be a funny way to say "It was generating a lot of code" (as in generating a city's worth of code)
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. It may not work today, but it might work at the end of 2026.
Antigravity and others already ask for human feedback on their plans.
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.
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.
Why would you want a list with such godawful methodology? Here's [0] what the TIOBE folks have to say about their data analysis process:
Since there are many questions about the way the TIOBE index is assembled, a special page is devoted to its definition. Basically the calculation comes down to counting hits for the search query
+"<language> programming"
[0] <https://www.tiobe.com/tiobe-index/programminglanguages_defin...>
Also 75% darwin-arm64
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.
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?
They couldn't even be bothered to write the Tweet themselves...
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 same phrases in quick succession, even across different writings (e.g. I might not reuse some phrase in email to person A, because I just used it in email to unrelated person B, and it feels like bad style).
Perhaps that's why reading LLM output feels like reading high school essays. Those essays all look alike because they're all written independently and each is a self-contained piece where the author tries to show off their mastery of language. After reading 20 of them in a row, one too gets tired of seeing the same few constructs being used in nearly every one of them.
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.
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?
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.
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 also heard "I see the issue now" so many times because it missed or misunderstood something very simple.
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
People will ask LLM to review some slop made by LLM and they will be absolutely right!
There is no limit to lazyness.
Usually about 50% of my understanding of the domain comes from the process of building the code. I can see a scenario where large scale automated code works for a while but then quickly becomes unsupportable because the domain expertise isn't there to drive it. People are currently working off their pre-existing domain knowledge which is what allows them to rapidly and accurately express in a few sentences what an AI should do and then give decisive feedback to it.
The best counter argument is that AIs can explain the existing code and domain almost as well as they can code it to begin with. So there is a reasonable prospect that the whole system can sustain itself. However there is no arguing to me that isn't a huge experiment. Any company that is producing enormous amounts of code that nobody understands is well out over their skis and could easily find themselves a year or two down the track with huge issues.
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.
Results will vary depending on how automatically checkable a problem is, but I expect a lot of problems are amenable to some variation of this.
To me it feels like building your project on sand. Not a good idea unless it's a sandcastle
I find Claude Code to be very steerable. Ask it to make small atomic commits and it will.
It means there is no value in producing more code. Only value in producing better, clearer, safer code that can be reasoned about by humans. Which in turn makes me very sceptical about agents other than as a useful parallelisation mechanism akin to multiple developers working on separate features. But in terms of ramping up the level of automation - it's frankly kind of boring to me because if anything it make the review part harder which actually slows us down.
Even 90 word tweets are now too long for these people to write without using AI, apparently.
Agents are stateless functions with a limited heap (context window) that degrades in quality as it fills. Once you see it that way, the whole swarm paradigm is just function scoping and memory management cosplaying as an org chart:
Agent = function
Role = scope constraints
Context window = local memory
Shared state file = global state
Orchestration = control flow
The solution isn't assigning human-like roles to stateless functions. It's shared state (a markdown file) and clear constraints.
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?
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 proportional benefit, especially as models get better at long-context reasoning.
Fairly recent research (arXiv May 2025: "Single-agent or Multi-agent Systems?" - https://arxiv.org/abs/2505.18286) found that MAS benefits over single-agent diminish as LLM capabilities improve. The constraints that motivated swarm architectures are being outpaced by model improvements. I admit the field is moving fast, but the direction of travel appears to be that the better the models get, the simpler your abstractions need to be.
So yes, use roles. But maybe don't reach for a framework to orchestrate a PM handing off to an Engineer handing off to QA when a single context with scoped instructions would do.
But seems we are heading this way, from initially:
- a Senior Dev pairing with Junior Dev (2024/25)
- a tech lead/architect in charge of several Developers (2025)
- a Product Owner delegating to development teams (2026?)
---
- https://github.com/steveyegge/gastown
- https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16d...
This thread seems surreal, I see multiple flow repositories mentioned with 10k+ stars. Comprehensive doc. genAI image as a logo.
Can anyone show me one product these things have accomplished please ?
I used some frontier LLM yesterday to see if it could finally produce simple cascading style sheet fix. After a few dozens attempts and steering, a couple of hours and half a million token wasted it couldn't. So I fixed the issue myself and I went to bed.
This person is on HN for the same reasons as I am, presumably: reading about hacker stuff. Entering prompts in black boxes and watching them work so you have more time to scratch your balls is not hacker stuff, it's the latest abomination of late stage capitalism and this forum is, sadly, falling for it.
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.
That’s a pretty basic functionality in Claude code
I've been using that and it's excellent
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.
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?
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.
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.
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.
Executives/product managers/sales often only really care about getting the product working well enough to sell it.
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.
Attitudes like that, where you believe that the richeous AI pushers will be saved from the coming rapture meanwhile everyone else will be out on the streets, really make people hate the AI crowd
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 feel like software engineers are taking a lot of license with the idea that if something bad happens, they will just be able to say "oh the AI did it" and no personal responsibility or liability will attribute. But if they personally looked at the code and their name is underneath it signing off the merge request acknowledging responsibility for it - we have a very different dynamic.
Just like artists have to re-conceptualise the value of what they do around the creative part of the process, software engineers have to rethink what their value proposition is. And I'm seeing a large part of it is, you are going to take responsibility for the AI output. It won't surprise me if after the first few disasters happen, we see liability legislation that mandates human responsibility for AI errors. At that point I feel many of the people all in on agent driven workflows that are explicitly designed to minimise human oversight are going to find themselves with a big problem.
My personal approach is I'm building up a tool set that maximises productivity while ensuring human oversight. Not just that it occurs and is easy to do, but that documentation of it is recorded (inherently, in git).
It will be interesting to see how this all evolves.
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;
https://github.com/docker-archive/classicswarm/releases/tag/...
https://github.com/openai/swarm/commit/e5eabc6f0bdc5193d8342...
Looks like claude calls it just "teams" under the covers
---
function i8() {
if (Yz(process.env.CLAUDE_CODE_AGENT_SWARMS)) return !1;
return xK("tengu_brass_pebble", !1);
}
---
So, after patch
function i8(){return!0}
---
The tengu_brass_pebble flag is server-side controlled based on the particulars of your account, such as tier. If you have the right subscription, the features may already be available.
The CLAUDE_CODE_AGENT_SWARMS environment variable only works as an opt-out, not an opt-in.
This will only compound wasted time on Claude.ai, which exploits that time to train its own models.
Why time wasted? Claude’s accuracy for shell, Bash, regex, Perl, text manipulation/scripting/processing, and system-level code is effectively negligible (~5%). Such code is scarce in public repositories. For swarms or agents to function, accuracy must exceed 96%. At 5%, it is unusable.
We do also use Claude.ai and we believe it is useful, but strictly for trivial, typing-level tasks. Anything beyond that, at this current point, is a liability.
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.
“FTSChunkManager agent is still running but making good progress, let’s wait a bit more for it to complete” (it’s implementing hybrid search) plus a bunch of stack traces and json output.
Mine also rotate between Claude or Z.ai accounts as they ran out of credits
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.
In his second post he included a link to GitHub: https://github.com/mikekelly/claude-sneakpeek