Wieloagentowa rownolegla praca nad funkcjami

Twoje spotkanie planistyczne kwartalne wlasnie sie zakonczylo. Roadmapa ma piec funkcji do dostarczenia w trzy tygodnie: preferencje powiadomien, dashboard rozliczen, eksport uzytkownikow, dziennik audytu administratora i publiczne API. Kazda funkcja dotyka roznych czesci bazy kodu. Tradycyjnie twoj czteroosobowy zespol pracowalby nad nimi sekwencyjnie z pewnym nakladaniem sie. Z Codex pojedynczy deweloper moze koordynowac pieciu rownoleglych agentow, z ktorych kazdy pracuje we wlasnym worktree, tworzac przejrzane PR-y dla kazdej funkcji jednoczesnie. Stajesz sie architektem kierujacym zespolem agentow.

Co wyniesiesz z tej lekcji

• Wzorzec koordynacji do uruchamiania 4-6 agentow Codex rownolegle bez konfliktow
• Prompty do dekompozycji zestawu funkcji na niezalezne strumienie pracy
• Techniki zarzadzania wspoldzielonymi zaleznosciami miedzy rownoleglymi worktree
• Workflow do przegladania, testowania i laczenia wynikow od wielu agentow

Workflow

Krok 1: Rozloz na niezalezne strumienie pracy

Kluczowym ograniczeniem dla rownoleglej pracy agentow jest niezaleznosc. Dwoch agentow modyfikujacych ten sam plik stworzy konflikty merge. Zacznij od zidentyfikowania, co moze biec rownolegle.

Wskazówka

Gotowy prompt do dekompozycji pracy rownoleglej:

I need to implement these five features:
1. Notification preferences (new API endpoints, database table, settings page)
2. Billing dashboard (new queries, charts page, PDF export)
3. User data export (background job, download endpoint, email notification)
4. Admin audit log (middleware, admin panel page, log viewer)
5. Public API (versioned routes, API key auth, rate limiting, docs)

Analyze the codebase and identify:
1. Which files each feature needs to create (new files = no conflict risk)
2. Which existing files each feature needs to modify
3. Shared files that multiple features would touch (these are conflict risks)
4. The dependency order: which features depend on shared infrastructure

Propose a parallel execution plan:
- Phase 1: Shared infrastructure changes (sequential, in Local mode)
- Phase 2: Independent features (parallel, in Worktree mode)
- Phase 3: Integration testing (sequential, after all merges)

Krok 2: Zbuduj wspoldzielona infrastrukture jako pierwsza

Analiza Codex zidentyfikuje wspoldzielone zaleznosci — moze wszystkie piec funkcji potrzebuje nowego middleware, albo funkcja dziennika audytu musi przechwytywac trasy uzywane przez inne funkcje. Obsluz je w trybie Local jako pierwsze.

Implement the shared infrastructure needed before parallel feature work:

1. Add the audit logging middleware that wraps route handlers (features 4 and 5 need this)
2. Update the database connection pool configuration to handle increased query load
3. Add the background job queue system (features 3 and 2 need this for PDF export and data export)
4. Create the shared pagination utility (features 1, 2, and 5 all need paginated list endpoints)

Commit each piece as a separate commit on the feature/q1-infrastructure branch.
Run the full test suite after each commit.

Zmerguj to do galezi bazowej. Teraz kazdy worktree utworzony od tego momentu ma wspoldzielona infrastrukture.

Krok 3: Uruchom rownoleglych agentow

Otworz Codex App i utwroz piec watkow worktree, wszystkie oparte na galezi z juz zmergowana wspoldzielona infrastruktura. Kazdy watek dostaje kompleksowy prompt z jasnymi granicami.

Watek 1: Preferencje powiadomien

Implement the notification preferences feature:

Files to CREATE (no conflicts):
- src/routes/notifications/preferences.ts
- src/services/notifications/preferences.ts
- src/lib/db/queries/notificationPreferences.ts
- src/lib/db/schema/notificationPreferences.ts
- src/pages/settings/notifications.tsx
- tests/unit/services/notificationPreferences.test.ts
- tests/integration/routes/notificationPreferences.test.ts
- drizzle/migrations/XXXX_notification_preferences.sql

Files to MODIFY (coordinate carefully):
- src/routes/index.ts (add route import -- add one line only)
- src/lib/db/schema/index.ts (add schema export -- add one line only)

Constraints:
- Use the shared pagination utility for list endpoints
- Follow existing patterns in src/routes/ for handler structure
- Run the full test suite after implementation

Watek 2: Dashboard rozliczen (ta sama struktura, inne pliki)

Watek 3: Eksport danych uzytkownikow (ta sama struktura, inne pliki)

Watek 4: Dziennik audytu administratora (ta sama struktura, inne pliki)

Watek 5: Publiczne API (ta sama struktura, inne pliki)

Uwaga

Krytycznym szczegolem jest sekcja “Files to MODIFY”. Gdy wielu agentow dodaje po jednej linii do tego samego pliku eksportu barrel, laczenie bedzie wymagac recznego rozwiazywania konfliktow. Minimalizuj modyfikacje wspoldzielonych plikow przez jawne okreslenie, co dokladnie kazdy agent powinien dodac.

Krok 4: Monitoruj i kieruj

Z piecioma dzialajacymi watkami pasek boczny Codex App staje sie twoim centrum dowodzenia. Kazdy watek pokazuje swoj status: uruchomiony, czekajacy na zatwierdzenie lub ukonczony.

Podczas pracy agentow:

• Sprawdzaj postep klikajac w kazdy watek. Historia konwersacji pokazuje, co Codex zrobil i nad czym pracuje.
• Zostawiaj komentarze inline jesli zauwayzysz problem w panelu recenzji. Nastepnie wyslij wiadomosc: “Address the inline comments.”
• Wysylaj wskazowki w trakcie zadania naciskajac Enter podczas pracy Codex, aby wstrzyknac nowe instrukcje. Nacisnij Tab, aby kolejkowac kontynuacje na nastepna ture.
• Uzyj zintegrowanego terminala (Cmd + J), aby weryfikowac zmiany w kazdym worktree niezaleznie.

Krok 5: Przejrzyj, przetestuj i zmerguj

W miare jak kazdy watek sie konczy, postepuj zgodnie z tym procesem:

1. Przejrzyj diff w panelu recenzji. Skup sie na logice biznesowej, nie na formatowaniu.
2. Uruchom /review w watku, aby uzyskac druga opinie od modelu recenzenta.
3. Utwroz galaz za pomoca Create branch here na worktree.
4. Wypchnij i otworz PR bezposrednio z App.
5. Popros o @codex review na PR GitHub dla widocznych komentarzy recenzji zespolowej.

Kolejnosc mergowania ma znaczenie. Merguj funkcje z najmniejsza liczba modyfikacji wspoldzielonych plikow jako pierwsze. Dla konfliktow eksportu barrel rozwiazuj recznie:

git checkout feature/notification-preferences
git merge feature/billing-dashboard
# Resolve conflict in src/routes/index.ts (add both import lines)
git add src/routes/index.ts
git commit -m "Merge billing dashboard into notification preferences branch"

Po zmergowaniu wszystkich pieciu galezi funkcji uruchom pelny zestaw testow jeszcze raz, aby wylapac ewentualne problemy integracyjne.

Skalowanie z zadaniami chmurowymi

Dla funkcji wymagajacych dluzszego wykonania (zlozona logika biznesowa, rozlegle testowanie) deleguj do zadan chmurowych zamiast lokalnych worktree. Kazde zadanie chmurowe dziala niezaleznie we wlasnym kontenerze.

# Launch three features as cloud tasks in parallel
codex cloud exec --env my-env "Implement the billing dashboard feature..." &
codex cloud exec --env my-env "Implement the user data export feature..." &
codex cloud exec --env my-env "Implement the public API feature..." &

Kazde zadanie produkuje diff i opcjonalny PR. Uzyj --attempts 2 dla funkcji, gdzie jakosc jest wazniejsza niz szybkosc — Codex generuje dwa rozwiazania, a ty wybierasz lepsze.

Gdy cos sie nie uda

Konflikty merge we wspoldzielonych plikach. Pomimo starannego planowania niektore konflikty sa nieuniknione. Najczestsze: pliki barrel importow, rejestracja middleware, eksporty schematu bazy danych. Minimalizuj mowiac kazdemu agentowi, aby dodal tylko jedna lub dwie linie do wspoldzielonych plikow, i rozwiazuj konflikty w fazie mergowania.

Implementacja jednego agenta jest niekompatybilna z implementacja drugiego. Agent 1 buduje serwis powiadomien oczekujacy konkretnego formatu zdarzen; Agent 5 buduje publiczne API emitujace inny format. Zapobiegaj temu definiujac wspoldzielone interfejsy w fazie infrastrukturalnej. Dolacz “use the EventPayload interface defined in src/types/events.ts” w promptach obu agentow.

Osiagnieto limit worktree. Codex czysci worktree, gdy przekroczysz 10 lub gdy sa starsze niz 4 dni. Przy rownoleglej pracy nad piecioma funkcjami uzywasz natychmiast 5 worktree plus wszelkie istniejace. Archiwizuj watki, ktorych juz nie potrzebujesz, i przypnij kazdy worktree, ktory chcesz zachowac powyzej 4 dni.

Lokalna maszyna wyczerpuje zasoby. Piec worktree, kazdy z wlasnymi node_modules i potencjalnie dzialajacymi procesami, moze wyczerpac CPU, pamiec lub dysk. Uzyj zadan chmurowych dla najciezszych funkcji i rozloz starty lokalnych worktree, aby nie budowaly wszystkie zaleznosci jednoczesnie.

Testy przechodza pojedynczo, ale nie lacznie. Kazdy worktree testuje w izolacji. Po zmergowaniu testy moga sie nie powiesc z powodu interakcji miedzy funkcjami (konflikty portow, konflikty tabel bazy danych w testach, wspoldzielony stan). Uwzglednij jawna faze testowania integracyjnego po wszystkich merge’ach.

Co dalej

Modernizacja bazy kodu na duza skale Zastosuj wzorce rownoleglych agentow do modernizacji calych baz kodu

Integracje ze Slack i Linear Koordynuj rownolegla prace z zespolem przez Slack i Linear