Wieloagentowa równoległa praca nad funkcjami

Twoje spotkanie planistyczne kwartalne właśnie się zakończyło. Roadmapa ma pięć funkcji do dostarczenia w trzy tygodnie: preferencje powiadomień, dashboard rozliczeń, eksport użytkowników, dziennik audytu administratora i publiczne API. Każda funkcja dotyka różnych części bazy kodu. Tradycyjnie twój czteroosobowy zespół pracowałby nad nimi sekwencyjnie z pewnym nakładaniem się. Z Codex pojedynczy deweloper może koordynować pięciu równoległych agentów, z których każdy pracuje we własnym worktree, tworząc przejrzane PR-y dla każdej funkcji jednocześnie. Stajesz się architektem kierującym zespołem agentów.

Co wyniesiesz z tej lekcji

• Wzorzec koordynacji do uruchamiania 4-6 agentów Codex równolegle bez konfliktów
• Prompty do dekompozycji zestawu funkcji na niezależne strumienie pracy
• Techniki zarządzania współdzielonymi zależnościami między równoległymi worktree
• Workflow do przeglądania, testowania i łączenia wyników od wielu agentów

Workflow

Krok 1: Rozłóż na niezależne strumienie pracy

Kluczowym ograniczeniem dla równoległej pracy agentów jest niezależność. Dwóch agentów modyfikujących ten sam plik stworzy konflikty merge. Zacznij od zidentyfikowania, co może biec równolegle.

Wskazówka

Gotowy prompt do dekompozycji pracy równoległej:

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 współdzieloną infrastrukturę jako pierwszą

Analiza Codex zidentyfikuje współdzielone zależności — może wszystkie pięć funkcji potrzebuje nowego middleware, albo funkcja dziennika audytu musi przechwytywać trasy używane przez inne funkcje. Obsłuż 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 gałęzi bazowej. Teraz każdy worktree utworzony od tego momentu ma współdzieloną infrastrukturę.

Krok 3: Uruchom równoległych agentów

Otwórz Codex App i utwórz pięć wątków worktree, wszystkie oparte na gałęzi z już zmergowaną współdzieloną infrastrukturą. Każdy wątek dostaje kompleksowy prompt z jasnymi granicami.

Wątek 1: Preferencje powiadomień

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

Wątek 2: Dashboard rozliczeń (ta sama struktura, inne pliki)

Wątek 3: Eksport danych użytkowników (ta sama struktura, inne pliki)

Wątek 4: Dziennik audytu administratora (ta sama struktura, inne pliki)

Wątek 5: Publiczne API (ta sama struktura, inne pliki)

Uwaga

Krytycznym szczegółem jest sekcja “Files to MODIFY”. Gdy wielu agentów dodaje po jednej linii do tego samego pliku eksportu barrel, łączenie będzie wymagać ręcznego rozwiązywania konfliktów. Minimalizuj modyfikacje współdzielonych plików przez jawne określenie, co dokładnie każdy agent powinien dodać.

Krok 4: Monitoruj i kieruj

Z pięcioma działającymi wątkami pasek boczny Codex App staje się twoim centrum dowodzenia. Każdy wątek pokazuje swój status: uruchomiony, czekający na zatwierdzenie lub ukończony.

Podczas pracy agentów:

• Sprawdzaj postęp klikając w każdy wątek. Historia konwersacji pokazuje, co Codex zrobił i nad czym pracuje.
• Zostawiaj komentarze inline jeśli zauważysz problem w panelu recenzji. Następnie wyślij wiadomość: “Address the inline comments.”
• Wysyłaj wskazówki w trakcie zadania naciskając Enter podczas pracy Codex, aby wstrzyknąć nowe instrukcje. Naciśnij Tab, aby kolejkować kontynuację na następną turę.
• Użyj zintegrowanego terminala (Cmd + J), aby weryfikować zmiany w każdym worktree niezależnie.

Krok 5: Przejrzyj, przetestuj i zmerguj

W miarę jak każdy wątek się kończy, postępuj zgodnie z tym procesem:

1. Przejrzyj diff w panelu recenzji. Skup się na logice biznesowej, nie na formatowaniu.
2. Uruchom /review w wątku, aby uzyskać drugą opinię od modelu recenzenta.
3. Utwórz gałąź za pomocą Create branch here na worktree.
4. Wypchnij i otwórz PR bezpośrednio z App.
5. Poproś o @codex review na PR GitHub dla widocznych komentarzy recenzji zespołowej.

Kolejność mergowania ma znaczenie. Merguj funkcje z najmniejszą liczbą modyfikacji współdzielonych plików jako pierwsze. Dla konfliktów eksportu barrel rozwiązuj ręcznie:

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 pięciu gałęzi funkcji uruchom pełny zestaw testów jeszcze raz, aby wyłapać ewentualne problemy integracyjne.

Skalowanie z zadaniami chmurowymi

Dla funkcji wymagających dłuższego wykonania (złożona logika biznesowa, rozległe testowanie) deleguj do zadań chmurowych zamiast lokalnych worktree. Każde zadanie chmurowe działa niezależnie we własnym 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..." &

Każde zadanie produkuje diff i opcjonalny PR. Użyj --attempts 2 dla funkcji, gdzie jakość jest ważniejsza niż szybkość — Codex generuje dwa rozwiązania, a ty wybierasz lepsze.

Gdy coś się nie uda

Konflikty merge we współdzielonych plikach. Pomimo starannego planowania niektóre konflikty są nieuniknione. Najczęstsze: pliki barrel importów, rejestracja middleware, eksporty schematu bazy danych. Minimalizuj mówiąc każdemu agentowi, aby dodał tylko jedną lub dwie linie do współdzielonych plików, i rozwiązuj konflikty w fazie mergowania.

Implementacja jednego agenta jest niekompatybilna z implementacją drugiego. Agent 1 buduje serwis powiadomień oczekujący konkretnego formatu zdarzeń; Agent 5 buduje publiczne API emitujące inny format. Zapobiegaj temu definiując współdzielone interfejsy w fazie infrastrukturalnej. Dołącz “use the EventPayload interface defined in src/types/events.ts” w promptach obu agentów.

Osiągnięto limit worktree. Codex czyści worktree, gdy przekroczysz 10 lub gdy są starsze niż 4 dni. Przy równoległej pracy nad pięcioma funkcjami używasz natychmiast 5 worktree plus wszelkie istniejące. Archiwizuj wątki, których już nie potrzebujesz, i przypnij każdy worktree, który chcesz zachować powyżej 4 dni.

Lokalna maszyna wyczerpuje zasoby. Pięć worktree, każdy z własnymi node_modules i potencjalnie działającymi procesami, może wyczerpać CPU, pamięć lub dysk. Użyj zadań chmurowych dla najcięższych funkcji i rozłóż starty lokalnych worktree, aby nie budowały wszystkie zależności jednocześnie.

Testy przechodzą pojedynczo, ale nie łącznie. Każdy worktree testuje w izolacji. Po zmergowaniu testy mogą się nie powieść z powodu interakcji między funkcjami (konflikty portów, konflikty tabel bazy danych w testach, współdzielony stan). Uwzględnij jawną fazę testowania integracyjnego po wszystkich merge’ach.

Co dalej

Modernizacja bazy kodu na dużą skalę Zastosuj wzorce równoległych agentów do modernizacji całych baz kodu

Integracje ze Slack i Linear Koordynuj równoległą pracę z zespołem przez Slack i Linear