Sedam paralelnih AI inženjera koji rade dok spavaš

Kad sam prvi put pokrenuo sedam paralelnih Claude Code sesija preko tmux orchestration sloja, osjećaj je bio kao da gledam tvornicu koja sama sebe gradi. Svaka sesija imala je svoj OAuth token, svoj workspace, svoj kontekst. Jedna je refaktorirala backend API, druga je pisala React komponente, treća je optimizirala bazu, četvrta je generirala testove. Dok sam spavao, moj swarm je odradio 182 taska u 30 dana. Nije bilo magije. Bilo je arhitekture.

Ključna greška koju svi rade je direktno slanje naredbi u terminal. Ljudi forkaju procese, šalju send-keys u tmux panele, i čude se kad kontekst pukne. Send-keys je kao da diktiraš pisaćoj mašini koja nema papir. Orchestrator-first pristup znači da svaka Claude Code sesija komunicira isključivo preko queue/done/outputs patterna. Sesija dobije task, izvrši ga, upiše rezultat u shared output file, i tek onda se vraća po novi posao. Orchestrator ne dira terminale direktno. On samo čita queue, delegira, i validira.

OAuth autentikacija za svaku sesiju je bila prva stvar koju smo riješili, i to se isplatilo. Svaka od sedam Claude Code instanci ima svoj OAuth token, što znači da mogu paralelno pozivati API bez race conditiona. Kad orchestrator detektira da je jedna sesija završila task, on instantira novu s novim tokenom. To omogućava da swarm radi 24/7 bez potrebe za ljudskim refreshom. U praksi, to znači da dok ti piješ kavu, jedan AI inženjer već ima otvoren PR.

File-conflict avoidance je bio najveći izazov. Kad sedam AI inženjera istovremeno piše kod, kolizije su neizbježne. Rješenje je domain separation. Workspace 1 je backend — čisti FastAPI, Pydantic modeli, SQLAlchemy migracije. Workspace 2 je frontend — React, TypeScript, Tailwind. Workspace 3 je infrastruktura — Terraform, Docker Compose, CI/CD. Workspace 4 je testiranje — pytest, Playwright, load testovi. Svaki workspace ima svoj git branch, svoju bazu, svoj .env file. Orchestrator zna da W1 nikad ne dira W2 fajlove.

Broj od 182 taska u 30 dana nije impresivan sam po sebi. Impresivno je da su ti taskovi uključivali kompletne refactore, migracije baza, pisanje dokumentacije, i deployment na staging. Svaki task je bio potpuno autonomno izvršen — od analize zahtjeva do pisanja koda, testiranja, i kreiranja pull requesta. Ljudski inženjer je samo pregledao PR i mergao. To je produktivnost koju ne možeš postići s jednom Claude Code sesijom.

Tmux orchestration layer je srce cijelog sustava. Svaka sesija živi u svom tmux prozoru, s vlastitim log fileom, vlastitim environment varijablama, vlastitim historyjem. Orchestrator je napisan u Pythonu, koristi tmuxp za definiranje layouta, i ima health check koji pinga svaku sesiju svakih 30 sekundi. Ako sesija padne u deadlock ili predugo traje, orchestrator je ubija i restartira s istim kontekstom. Fallback mehanizam je ručni override preko symlinka.

Queue pattern je deceptively simple. Orchestrator čita taskove iz JSON filea koji se zove queue.json. Svaki task ima ID, workspace, prioritet, i specifikaciju. Kad sesija završi task, upisuje rezultat u done.json s timestampom, trajanjem, i output pathom. Orchestrator onda validira output, ažurira queue, i dodjeljuje sljedeći task. Ovo nije rocket science, ali je razlika između kaosa i sustava. Bez queuea, imaš sedam AI inženjera koji čekaju jedan na drugog.

Najzanimljivije je bilo gledati kako se ponašanje swarma mijenja s vremenom. U prvom tjednu, sesije su često ulazile u infinite loopove ili generirale kod koji nije prolazio linting. Nakon što smo dodali pre-commit hooks i automatsku validaciju outputa, kvaliteta je drastično porasla. Orchestrator sada ima pravilo: ako task ne prođe osnovne provjere, vraća se u queue s povećanim prioritetom. To je stvorilo self-correcting mehanizam.

Gradimo ovo svaki dan. Ako tvoja institucija troši mjesece na taj problem — razgovaraj s nama.

Domain separation se pokazala kao genijalan potez. Kad backend inženjer (W1) refaktorira API, frontend inženjer (W2) ne mora čekati. On dobije notifikaciju da se API promijenio, ali njegov workspace ima mockove i fixtureove koji mu omogućavaju da nastavi raditi. Tek kad oba workspacea završe, orchestrator pokreće integration testove. Ovo je ključno za paralelni rad. Bez domain separation, imaš blocking dependencies koje ubijaju produktivnost.

Sigurnosni aspekt OAuth tokena je često zanemaren. Svaka sesija ima token s ograničenim scopeom i expiracijom od 24 sata. Orchestrator ima dedicated token refresh servis koji mijenja tokene prije nego isteknu. Ako token pukne usred taska, sesija upisuje error u output i orchestrator joj dodjeljuje novi token. Ovo je critical za produkcijske sustave gdje sesije rade danima bez prekida.

Broj 182 nije slučajan. To je rezultat mjerenja nakon što smo optimizirali sve parametre. Prvih tjedan dana smo imali 40-50 taskova tjedno. Nakon optimizacije queuea, dodavanja prioriteta, i fine-tuninga timeouta, došli smo na 60-70 taskova tjedno. To je otprilike 7-8 taskova po sesiji po danu. Neke sesije su brže, neke sporije. Infrastrukturni taskovi (W3) su najsporiji jer uključuju deploymente koji čekaju na CI/CD.

Implementacija nije zahtijevala ništa egzotično. Običan Linux server s tmuxom, Pythonom, i Claude Code CLI-jem. Orchestrator je 400 linija koda. Queue i done fileovi su plain JSON. Logovi idu u syslog. Monitoring preko jednostavnog dashboarda koji prikazuje koliko je taskova u queueu, koliko je aktivnih sesija, i koji su failali. Sve je dizajnirano da bude transparentno i debuggable.

Paralelni rad donosi i jedan neočekivani benefit: sesije se međusobno ne natječu za kontekst. Svaka ima svoj cijeli kontekst, svoje istraživanje, svoje odluke. Kad jedna sesija zapne na problemu, druga ga možda riješi iz drugog kuta. Orchestrator ima opciju da replicira task na dvije sesije ako prioritet pređe prag. Onda uzima bolji output. To je kao da imaš dva junior inženjera koji rade na istom problemu, ali ne znaju jedan za drugog.

Ono što me najviše iznenadilo je koliko je malo ljudske intervencije bilo potrebno. Prvih tjedan dana sam provjeravao queue svakih sat vremena. Nakon dva tjedna, samo ujutro i navečer. Orchestrator je sam rješavao 95% problema. Deadlockovi, timeouti, failani testovi, konfliktni branchovi — sve je imalo pravilo. Jedino što je zahtijevalo ljudsku odluku bili su arhitekturni izbori koje orchestrator nije mogao donijeti.

Ovaj sustav nije zamjena za ljudske inženjere. On je skaliranje njihove pažnje. Dok ti spavaš, sedam AI inženjera nastavlja raditi. Dok ti radiš na kompleksnom problemu, oni čiste backlog. Dok si na sastanku, oni refaktoriraju legacy kod. Orchestrator je samo posrednik koji osigurava da se svi ti poslovi odvijaju bez kolizija i bez potrebe da ti budeš budan 24 sata dnevno.

Ako te zanima ovakva arhitektura ili gradiš nešto slično za svoju instituciju — javi se preko rinet.one.