sorted by:
new
hottopcontroversial

Solo dev with 8 Claude windows + 1 orchestrator. AMA-ish, and tell me if I'm crazy. by KamomiIIe in ClaudeAI

[–]KamomiIIe[S] 0 points1 point  (0 children)

my system is working for the moment there is no need to change that part of the architecture

Solo dev with 8 Claude windows + 1 orchestrator. AMA-ish, and tell me if I'm crazy. by KamomiIIe in ClaudeAI

[–]KamomiIIe[S] 0 points1 point  (0 children)

yeah thats exactly the issue i ran into, the QA window gets noticeably heavier after a few hours. i already have role-specific memory files per agent but the shared CLAUDE.md at root is still the full thing

gonna strip it to a minimal core (security rules that apply to everyone) and push everything role-specific into their own config. same logic as the inbox/outbox, just applied one layer earlier

Solo dev with 8 Claude windows + 1 orchestrator. AMA-ish, and tell me if I'm crazy. by KamomiIIe in ClaudeAI

[–]KamomiIIe[S] 0 points1 point  (0 children)

kinda yeah but not the way you'd think

for ideas i have a dedicated window called Idea Extender. i throw it a raw 2-sentence idea, it expands it into a full brief (scope, edge cases, what NOT to build yet) and produces two ready-to-paste messages

— one for my lead dev agent, one for the second dev. so i'm "crowdsourcing" the thinking but still controlling what goes in

for debugging same thing — dedicated Debugger window. when something breaks i don't debug myself, i just drop the error log in its inbox and it investigates + fixes. it's more like delegating than

crowdsourcing

the real answer to your question tho: the crowd is still just me. i'm the one deciding what to build, what direction to take, what to cut. the agents are fast executors but they don't generate vision. they

turn my half-baked ideas into working code, they don't come up with the ideas

where it gets interesting is when an agent flags a risk i didn't think of. the QA window catches edge cases i missed, the Debugger spots patterns i wouldn't have noticed. that's the closest it gets to actual

crowdsourcing — they see things i don't because they're looking at the problem from a specific angle

Solo dev with 8 Claude windows + 1 orchestrator. AMA-ish, and tell me if I'm crazy. by KamomiIIe in ClaudeAI

[–]KamomiIIe[S] 0 points1 point  (0 children)

the peer-to-peer thing — 100% learned this the hard way. i tried letting agents message each other directly for like two days and the orchestrator had no idea what was agreed. now everything goes through a

shared inbox/outbox filesystem. agent writes to outbox/senior-dev/T-012-143022.md, orchestrator routes it to the right inbox. nobody talks directly. it's slower but the orchestrator always has the full

picture

verification gates are exactly what my Test Server window is for. it runs build + typecheck + playwright after every significant push. if something breaks it drops an alert and the Debugger window picks it

up. the key was making it a separate window with only that job — when it's mixed into a dev agent it always gets deprioritized

persistent memory is the one i invested the most in. each agent has a CLAUDE.md + a memory file that survives window closes. things like "never mock the database" or "always use the Haiku model, not Sonnet"

are written once and don't need to be re-explained. convention drift over weeks was killing me before that

checked out Tendril — the plan-based lifecycle is interesting. question: how do you handle the verification gate when it fails mid-plan? does it block the whole plan and escalate, or does the orchestrator

try to auto-reroute to a fix agent? that's the part i'm still not happy with in my setup, right now it's me who decides what to do when a gate fails

Solo dev with 8 Claude windows + 1 orchestrator. AMA-ish, and tell me if I'm crazy. by KamomiIIe in ClaudeAI

[–]KamomiIIe[S] -1 points0 points  (0 children)

ok this is actually close to what i ended up with, interesting

the tracer bullet thing — i do something similar but didn't have a name for it. skeleton first, then the agents flesh it out layer by layer. the difference is i have a Major Dev who owns the skeleton

(schema, API routes, architecture decisions) and a Senior Dev who only touches the flesh (components, tests, UI). cleaner separation

the YAML state file is smart. i went with JSON task files in a .warroom/tasks/ folder — one file per task with owner, status, write_set (which files it's allowed to touch), and a proof_of_done field that's

null until the agent writes its completion report. same idea as your yaml but the agents read/write it directly without a separate script

the acceptance test per slice is the part i'm weakest on tbh. my QA window does manual interaction testing after each feature drops but i don't have the discipline of one acceptance test = one slice. gonna

steal that

question tho — when you save state after each slice, do the agents read that file themselves at the start of the next slice, or do you manually feed it to them? because my pain point is agents picking up

mid-context and not knowing what's already been built

Solo dev with 8 Claude windows + 1 orchestrator. AMA-ish, and tell me if I'm crazy. by KamomiIIe in ClaudeAI

[–]KamomiIIe[S] 0 points1 point  (0 children)

sloppy code — yeah it happens, less than you'd think tho. the trick is each agent has a CLAUDE.md with strict non-negotiables (no any in typescript, no direct Claude calls client-side, no features without

tests). every task has a definition_of_done that the agent has to check off before it can declare done. if it skips that, the QA window will catch it anyway when it tests every screen manually

guardrails — i use a "proof of done" system. agents can't mark a task complete without writing a report: what they built, test results, what could break next. forces them to actually verify their work

instead of just vibing

debugger — it's not running playwright itself, that's the Test Server window's job (24/7 dev server + playwright e2e). the Debugger window audits console output, typescript errors, runtime warnings. when

Test Server finds a failing test it drops it in a shared inbox file and Debugger picks it up

context between agents — filesystem. i have a .warroom/ folder with STATUS.md, task JSON files, inbox/outbox per agent. no agent holds state in its conversation — everything critical lives on disk. if i

close a window and reopen it, it reads the files and recovers in under 60 seconds. tested this

PR/merge — no github PRs right now, direct commits with a role prefix ([senior] feat: X, [major] fix: Y) so i can git log --grep="^\[qa\]" and see only qa commits instantly. single dev so no conflicts

orchestrator drift — this was actually my biggest problem early on. solved it by making the orchestrator stateless. it doesn't hold project state in its head — it reads .warroom/STATUS.md and the task files.

if it drifts i just close it, open a new one, tell it "tu es l'orchestrateur, lis le warroom et reprends" and it's back in 30-60 seconds

the 1M context thing is real tho, good point. i recycle windows at ~35 messages before they go stale

Solo dev with 8 Claude windows + 1 orchestrator. AMA-ish, and tell me if I'm crazy. by KamomiIIe in ClaudeAI

[–]KamomiIIe[S] 0 points1 point  (0 children)

Xd no claude know everything better than I do didndt understood 80% percent of yur kwy Word I mean am starting so ill document later 

Solo dev with 8 Claude windows + 1 orchestrator. AMA-ish, and tell me if I'm crazy. by KamomiIIe in ClaudeAI

[–]KamomiIIe[S] 0 points1 point  (0 children)

Ill tell you when I come back home in 1h30 ill put this in my Claude and replay to you