| What I did was to break the development into different layers which had to be completed after another, since the functionalities build on each other. Each layer had independent work streams which run in parallel. Each work stream was one independent worktree/session in Claude code First I triggered all work streams per layer and brought them to a level of completion I was happy with. Then you merge one after another (challenge in github with the @codex the implementation and rebases when you move to the next work stream. This is roughly how it looked like: Layer 0 - Project Scaffolding Layer 1 — Core Features
Stream A — Content Pipeline
Stream B — Social Platform Providers
Stream C — Media Library
Stream D — Notification System
Stream E — Settings UI T-0.1 (Scaffolding)
│
T-0.2 (Core Models + Auth)
│
┌───────────────────┼───────────────────┬──────────────┐
│ │ │ │
Stream A Stream B Stream C Stream D
(Content) (Providers) (Media) (Notifs)
│ │ │ │
T-1A.1 Composer T-1B.1 FB/IG/LI T-1C.1 Library T-1D.1 Engine
│ T-1B.2 Others │ │
T-1A.2 Calendar │ │ Stream E
│ │ │ T-1E.1 Settings UI
T-1A.3 Publisher ◄──────┘ │
│ │
└──────────◄───────────────────────────┘
(Publisher needs providers + media processing)
Layer 2 — Collaboration & Engagement
Stream F — Approval & Client Portal
Stream G — Inbox
Stream H — Calendar & Composer Enhancements
Stream I — Client Onboarding Layer 1 complete
│
┌───────────┼───────────┬──────────────┐
│ │ │ │
Stream F Stream G Stream H Stream I
(Approval (Inbox) (Calendar+ (Onboarding)
+ Portal) Composer
│ enhance)
T-2F.1 Approval
│
T-2F.2 Portal
Thus I did run up to 4 agents in parallel, but o be honest this is the max level of parallelism my brain was able to handle, I really felt like the bottleneck here.Additionally, your token usage is very high since you are having so many agent do work at the same time, hence I very often reached my claude session token limits and had to wait for the next session to begin (I do have the 5x Max plan) |