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

How to use Claude Code subagents to parallelize development

zachwills.net

Post reply on HN
Print view View original

41–50 of 131 posts

Re: How to use Claude Code subagents to parallelize development

#41

Post by muratsu »

simianwords wrote: post #12

Slightly off topic but I would really like agentic workflow that is embedded in my IDE as well as my code host provider like GitHub for pull requests. Ideally I would like to spin off multiple agents to solve multiple bugs or features. The agents have to use the ci in GitHub to get feedback on tests. And I would like to view it on IDE because I like the ability to understand code by jumping through definitions. Suppo…

Why not just use only async agents? You can fire off many tasks and check PRs locally when they complete the work. (I also work on devfleet.ai to improve this experience, any feedback is appreciated)

Re: How to use Claude Code subagents to parallelize development

#42

Post by ares623 »

alxh wrote: post #38

How do you not get lost mentally in what is exactly happening at each point in time? Just trusting the system and reviewing the final output? I feel like my cognitive constraints become the limits of this parallelized system. With a single workstream I pollute context, but feel way more secure somehow.

Just one more agent...

Re: How to use Claude Code subagents to parallelize development

#43

Post by beefcake »

What's the difference between using agents and playing the casino? Large part of the industry is a casino hidden in other clothes.

I see people who never coded in their life signing up for loveable or some other code agent and try their luck.

What cements this thought pattern in your post is this: "If the agents get it wrong, I don’t really care—I’ll just fire off another run"

Re: How to use Claude Code subagents to parallelize development

#44

Post by macrolime »

lucraft wrote: post #33
sixhobbits wrote: post #26

I often see people making these sub agents modelled on roles like product manager, back end developer, etc. I spent a few hours trying stuff like this and the results were pretty bad compared to just using CC with no agent specific instructions. Maybe I needed to push through and find a combination that works but I don't find this article convincing as the author basically says "it works" without showing examples or…

Right - don’t make subagents for the different roles, make them to manage context for token heavy tasks. A backend developer subagent is going to do the job ok, but then the supervisor agent will be missing useful context about what’s been done and will go off the rails. The ideal sub agent is one that can take a simple question, use up massive amounts of tokens answering it, and then return a simple answer, dropping…

This is my experience too.

Make agents for tasks, not roles.

I've seen this for coding agents using spec-driven development for example. You can try to divide agents into lots of different roles that roughly correspond to human job positions, like for example BMad does, or you can simply make each agent do a task and have a template for the task. Like make an implementation plan using a template for an implementation plan or make a task list, using a template for a task list. In general, I've gotten much better results with agents that has a specific task to do than trying to give a role, with a job-like description.

For code review, I don't use a code reviewer agent, instead I've defined a dozen code reviewing tasks, that each runs as separate agents (though I group some related tasks together).

Re: How to use Claude Code subagents to parallelize development

#45

Post by rufasterisco »

alxh wrote: post #38

How do you not get lost mentally in what is exactly happening at each point in time? Just trusting the system and reviewing the final output? I feel like my cognitive constraints become the limits of this parallelized system. With a single workstream I pollute context, but feel way more secure somehow.

i suppose, gradually and the suddenly? each "fix" to incorrect reasoning/solution doesn't just solve the current instance, it also ends up in a rule-based system that will be used in future

initially, being in the loop is necessary, once you find yourself "just approving" you can be relaxed and think back or, more likely, initially you need fine-grained tasks; as reliability grows, tasks can become more complex

"parallelizing" allows single (sub)agents with ad-hoc responsibilities to rely on separate "institutionalized" context/rules, .ie: architecture-agent and coder-agent can talk to each others and solve a decision-conflict based on wether one is making the decision based on concrete rules you have added, or hallucinating decisions

i have seen a friend build a rule based system and have been impressed at how well LLM work within that context

Re: How to use Claude Code subagents to parallelize development

#46

Post by stingraycharles »

CuriouslyC wrote: post #5

As someone who's built a project in this space, this is incredibly unreliable. Subagents don't get a full system prompt (including stuff like CLAUDE.md directions) so they are flying very blind in your projects, and as such will tend to get derailed by their lack of knowledge of a project and veer into mock solutions and "let me just make a simpler solution that demonstrates X." I advise people to only use subagents…

It was my understanding that the subagents have the same system prompt. How do you know that they don’t follow CLAUDE.md directions?

I’ve been using subagents since they were introduced and it has been a great way to manage context size / pollution.

Re: How to use Claude Code subagents to parallelize development

#47

Post by quijoteuniv »

CuriouslyC wrote: post #5

As someone who's built a project in this space, this is incredibly unreliable. Subagents don't get a full system prompt (including stuff like CLAUDE.md directions) so they are flying very blind in your projects, and as such will tend to get derailed by their lack of knowledge of a project and veer into mock solutions and "let me just make a simpler solution that demonstrates X." I advise people to only use subagents…

My experience so far, after trying to keep CC on track with different strategies is that it will more or less end up on the same ditch sooner or later. Even though i had defined agents, workflows, etc. now i just let it interact with github issues and the quality is pretty much the same

Re: How to use Claude Code subagents to parallelize development

#48

Post by spariev »

CuriouslyC wrote: post #13
olivermuty wrote: post #9

Earlier quoted context omitted.

This is only a problem if an agent is made in a lazy way (all of them). Chat completion sends the full prompt history on every call. I am working on my own coding agent and seeing massive improvements by rewriting history using either a smaller model or a freestanding call to the main one. It really mitigates context poisoning.

There's a large body of research on context pruning/rewriting (I know because I'm knee deep in benchmarks in release prep for my context compiler), definitely don't ad hoc this.

Care to give some pointers on what to look at? Looks like I will be doing something similar soon so that would be much appreciated

Re: How to use Claude Code subagents to parallelize development

#49

Post by rufasterisco »

ako wrote: post #24
NitpickLawyer wrote: post #21

Earlier quoted context omitted.

One key insight I have from having worked on this from the early stages of LLMs (before chatgpt came out) is that the current crop of LLM clients or "agentic clients" don't log/write/keep track of success over time. It's more of a "shoot and forget" environment right now, and that's why a lot of people are getting vastly different results. Hell, even week to week on the same tasks you get different results (see the r…

I’ve experimented with feature chats, so start a new chat for every change, just like a feature branch. At the end of a chat I’ll have it summarize the the feature chat and save it as a markdown document in the project, so the knowledge is still available for next chats. Seems to work well. You can also ask the llm at the end of a feature chat to prepare a prompt to start the next feature chat so it can determine wha…

i too have discovered that feature chats are surely a winner (as well as a pre-requirement for parallelization)

in a similar vein, i match github project issues to md files committed to repo

essentially, the github issue content is just a link to the md file in the repo also, epics are folders with links (+ a readme that gets updated after each task)

i am very happy about it too

it's also very fast and handy to reference either from claude using @ .ie: did you consider what has been done @

other major improvements that worked for me were - DOC_INDEX.md build around the concept of "read this if you are working on X (infra, db, frontend, domain, ....)" - COMMON_TASKS.md (if you need to do X read Y, if you need to add a new frontend component read HOW_TO_ADD_A_COMPONENT.md )

common tasks tend to be increase quality when they are epxpressed in a checklist format

Post reply on HN