←back to thread

How to use Claude Code subagents to parallelize development

(zachwills.net)
280 points zachwills | 3 comments | 09 Sep 25 13:21 UTC | HN request time: 0s | source
Show context
skimojoe ◴[13 Sep 25 11:20 UTC] No.45231193[source]▶
I am sceptical if these persona based agents really make that much of a difference, and more "appear" to make a difference because of their talk style.

Underneath is just a system prompt, or more likely a prompt layered on top "You are a frontend engineer, competent in react and Next.js, tailwind-css" - the stack details and project layout, key information is already in the CLAUDE.md. For more stuff the model is going to call file-read tools etc.

I think its more theatre then utilty.

What I have taken to doing is having a parent folder and then frontend/ backend/ infra/ etc as children.

parent/CLAUDE.md frontend/CLAUDE.md backend/CLAUDE.md

The parent/CLAUDE.md provides a highlevel view of the stack "FastAPI backend with postgres, Next.js frontend using with tailwind, etc". The parent/CLAUDE.md also points to the childrens CLAUDE.md's which have more granular information.

I then just spawn a claude in the parent folder, set up plan mode, go back and forth on a design and then have it dump out to markdown to RFC/ and after that go to work. I find it does really well then as all changes it makes are made with a context of the other service.

replies(7): >>45231217 #>>45233133 #>>45234479 #>>45235090 #>>45237422 #>>45237827 #>>45238553 #
faangguyindia ◴[13 Sep 25 11:25 UTC] No.45231217[source]▶
You don't need subagent, I shared this on ClaudeCode sub as well https://www.reddit.com/r/ClaudeCode/s/barbpBxG78

Subagents do not work well for coding at all

replies(3): >>45231965 #>>45232649 #>>45233343 #
weird-eye-issue ◴[13 Sep 25 13:32 UTC] No.45231965[source]▶
Subagents are literally built into Claude Code via a built-in tool where it can recursively call itself
replies(1): >>45232001 #
faangguyindia ◴[13 Sep 25 13:39 UTC] No.45232001[source]▶
Yes I know, but subagent suffer from context amnesia during context handouts which is why this subagent use is flawed for purpose of coding product features. I've been using these tools a lot and installed every ai agent out there i could find.
replies(1): >>45232253 #
CuriouslyC ◴[13 Sep 25 14:16 UTC] No.45232253[source]▶
Yup, this is the killer. Subagents SEEM good when you use them on greenfield projects, you can grind out a whole first pass without burning through much of your main context, it seems magical. But when you have a complex project that handoff is the kiss of death.
replies(2): >>45232481 #>>45233037 #
catlifeonmars ◴[13 Sep 25 15:49 UTC] No.45233037[source]▶
So maybe the solution is to make all subproblems greenfield products?

By this I mean treat features as isolated plugins. I get that there are cross-cutting features that touch multiple pieces of functionality, and those probably need special treatment, but a large class of functionality can be developed in an isolated way with a common set of design tokens and APIs to tie them all together.

This might play better to coding agent strengths.

Full disclosure: this is very much an armchair view. I have all of 2 weeks of experience coding via agents (vs manually), but this thread is nerd sniping me into trying it myself.

replies(1): >>45233377 #
1. CuriouslyC ◴[13 Sep 25 16:37 UTC] No.45233377[source]▶
I do try to do this, from an architectural standpoint it starts with modular monoliths to avoid coupling, then I try to decompose problems in a way that is very sandboxed so the blast radius of an agent going of the rails is contained.
replies(1): >>45234540 #
2. ffsm8 ◴[13 Sep 25 19:12 UTC] No.45234540[source]▶
So the things people hate Java for will make a big comeback then? Hexagonal architecture with domain driven design,a big fetish for inversion of control, so the LLM never needs to figure out how the system works, it just magically does. And errors have just the right amount of stack trace, this being 500++ lines
replies(1): >>45234991 #
3. CuriouslyC ◴[13 Sep 25 20:16 UTC] No.45234991[source]▶
A lot of old school "java-ish" paradigms are going to come back with AI for the same reason people used them with Java back in the day - they put golden handcuffs on implementors, which is a bad tradeoff for competent, agile humans but a very good tradeoff for sometimes off the rails agents. This includes waterfall, spec driven development, front loaded planning, extensive automated testing suites, formal verification, etc.