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.
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".
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.
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.
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.
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
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?
Not a direct answer to your question, but I’m recently trying to adopt the mindset of letting Claude “prove” to me with very high confidence that what they did works. The bar for this would be much higher than what I’d require for a human engineer. For example it can be near 100% test coverage, combined with advanced testing techniques like property-based tests and fuzz tests, and benchmarks if performance is a concern. I’d still have to skim through both the implementation and tests, but it doesn’t have to be a line by line review. This also forces me to establish a verifiable success criteria which is quite useful.
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.
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.
> ...like the TIOBE Index for programming languages.
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"
The only advantage this methodology has is it's extremely cheap for the surveyor to use.
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?
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.
66 comments
[ 2.6 ms ] story [ 96.2 ms ] threadIn his second post he included a link to GitHub: https://github.com/mikekelly/claude-sneakpeek
https://github.com/ruvnet/claude-flow
I've been using that and it's excellent
Mine also rotate between Claude or Z.ai accounts as they ran out of credits
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.
Even 90 word tweets are now too long for these people to write without using AI, apparently.
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?
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.
I find Claude Code to be very steerable. Ask it to make small atomic commits and it will.
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.
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:
The only advantage this methodology has is it's extremely cheap for the surveyor to use.[0] <https://www.tiobe.com/tiobe-index/programminglanguages_defin...>
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.