Budowanie funkcji z rownoleglymi agentami

Twoj product manager wlasnie podzielil jeden epic na piec podzadan: nowy endpoint API, migracja bazy danych, formularz frontendowy, powiadomienia email i testy end-to-end. Tradycyjnie realizowalbys je sekwencyjnie — kazde blokujace przez poprzednie. Z worktree Codex mozesz uruchomic pieciu rownoleglych agentow, ktorzy pracuja nad wszystkimi piecioma jednoczesnie, kazdy w swojej izolowanej galezi. Przegladasz diffy, synchronizujesz wyniki i wdrazasz cala funkcje w jedno popoludnie.

Co wyniesiesz z tej lekcji

Workflow planuj-potem-zrownoleglaj, ktory rozbija funkcje na niezalezne strumienie pracy
Prompty do lokalnego planowania w rozszerzeniu IDE, po ktorym nastepuje rownolegle wykonanie w worktree
Techniki laczenia wynikow z wielu worktree w jedna galaz funkcji
Wzorzec delegowania do chmury dla dlugotrwalych zadan implementacyjnych

Workflow

Krok 1: Zaplanuj lokalnie w IDE

Zanim uruchomisz jakichkolwiek rownoleglych agentow, potrzebujesz planu, ktory rozklada prace na niezalezne czesci. Uzyj do tego rozszerzenia IDE — ma kontekst twoich otwartych plikow i szybko odpowiada na zadania planistyczne.

Gotowy prompt do dekompozycji funkcji:

I need to implement a user notification preferences feature:

- Users can choose email, SMS, or push for each notification type
- Preferences are stored in the database
- A new API endpoint manages CRUD for preferences
- The notification service reads preferences before sending
- Frontend settings page for managing preferences

Break this into independent implementation tasks that can run in parallel. For each task:
1. What files need to be created or modified
2. What the task depends on (if anything)
3. A clear "definition of done" including tests

Identify which tasks can run simultaneously and which must be sequential.

Codex zazwyczaj zidentyfikuje graf zaleznosci. Na przyklad migracja bazy danych musi wejsc pierwsza, potem endpoint API i zmiany w serwisie powiadomien moga biec rownolegle, a frontend zalezy od zdefiniowanego API. Plan pozwala ci wiedziec, ktore worktree uruchomic natychmiast, a ktore kolejkowac.

Krok 2: Zacznij od fundamentow w trybie Local

Dla zadan, od ktorych zalezy inna praca — jak migracja bazy danych — uzyj trybu Local, aby zmiany trafily bezposrednio do twojego katalogu roboczego, a kolejne worktree mogly na nich budowac.

Gotowy prompt do pracy fundamentowej:

Create a database migration for notification preferences:

- New table: notification_preferences
  - id (uuid, primary key)
  - user_id (uuid, foreign key to users, unique per notification_type)
  - notification_type (enum: order_update, marketing, security_alert, system)
  - channel (enum: email, sms, push)
  - enabled (boolean, default true)
  - created_at, updated_at timestamps

- Use Drizzle ORM schema definition matching our existing patterns
- Generate the migration file
- Add the schema to our barrel export in src/lib/db/schema.ts
- Run the migration against the dev database

Follow conventions in AGENTS.md.

Zacommituj migracje do swojej galezi funkcji. Teraz kazdy worktree, ktory utworzysz z tej galezi, bedzie zawierac nowy schemat.

Krok 3: Uruchom rownolegle watki Worktree

Teraz niezalezne czesci moga biec jednoczesnie. W Codex App utwroz nowy watek dla kazdego zadania, wybierajac tryb Worktree i wskazujac galaz funkcji (z juz zacommitowana migracja) jako punkt wyjscia.

Watek 1: Endpoint API

Implement CRUD endpoints for notification preferences:

- GET /api/users/:userId/notification-preferences
- PUT /api/users/:userId/notification-preferences/:type
- Zod validation for all inputs
- Auth middleware (user can only access their own preferences)
- Default preferences created on first GET if none exist
- Unit tests for validation, integration tests for the full endpoint

Use the notification_preferences schema from src/lib/db/schema.ts.
Run tests after implementation.

Watek 2: Aktualizacja serwisu powiadomien

Update the notification service to check user preferences before sending:

- Before sending any notification, query notification_preferences for the user
- If no preferences exist, use defaults (all channels enabled)
- If the user has disabled a channel for that notification type, skip it
- Add structured logging for skipped notifications
- Unit tests with mocked preferences
- Do not change the existing notification sending interface

Read the current notification service in src/services/notifications/ first.

Watek 3: Strona ustawien frontendowych

Create a notification preferences settings page:

- Route: /settings/notifications
- Fetch current preferences from GET /api/users/:userId/notification-preferences
- Display a grid: notification types as rows, channels as columns
- Toggle switches for each combination
- Save changes with PUT on toggle
- Loading states and error handling
- Match the existing settings page styling in src/pages/settings/

Use React and follow our component patterns. Include tests.

Wszystkie trzy watki biegna jednoczesnie w oddzielnych worktree. Mozesz obserwowac ich postep na pasku bocznym Codex App, przelaczac sie miedzy watkami i zostawiac komentarze inline, jesli zauwayzysz cos wymagajacego korekty.

Krok 4: Przejrzyj i polacz wyniki

Gdy kazdy watek zakonczy prace, przejrzyj diff w panelu recenzji. Masz dwie strategie na odzyskanie zmian:

Strategia A: Utwroz galeze i polacz przez Git. Kliknij Create branch here na kazdym watku worktree. Wypchnij kazda galaz i dolacz je do galezi funkcji po kolei, rozwiazujac ewentualne konflikty.

Strategia B: Synchronizuj do lokalnego sekwencyjnie. Uzyj Sync with local na kazdym worktree, wybierajac metode Apply, aby nalozyc kazdy zestaw zmian na lokalny checkout. To utrzymuje czystsza historie commitow, poniewaz zmiany przychodza jako patche, a nie merge commity.

Krok 5: Deleguj dlugie zadania do chmury

Dla zadan, ktore trwaja dluzej — uruchamianie pelnych zestawow testow, budowanie kontenerow lub implementowanie zlozonej logiki biznesowej — deleguj do wykonania w chmurze. Agent chmurowy ma wiecej zasobow, moze dzialac dluzej i wspiera proby best-of-N.

W Codex App wybierz ikone chmury pod edytorem i wybierz swoje srodowisko chmurowe:

Implement Milestone 1 from the plan: the notification preferences API endpoints with full test coverage. Run the complete test suite after implementation and fix any failures.

Zadania chmurowe generuja diff, ktory mozesz przejrzec i zamienic bezposrednio w PR lub pobrac lokalnie do dalszej iteracji.

Gdy cos sie nie uda

Worktree wspoldziela node_modules przez git worktree, ale nie zawsze. Jesli twoj projekt ma zaleznosci na poziomie workspace, worktree powinny je dziedziczyc. Ale jesli kazdy worktree uruchamia npm install niezaleznie, mozesz napotkac konflikty lockfile. Skonfiguruj skrypt konfiguracyjny srodowiska lokalnego, aby uzywal npm ci (ktory respektuje lockfile) zamiast npm install.

Rownolegle watki podejmuja sprzeczne decyzje architektoniczne. Jesli watek 1 decyduje, ze format odpowiedzi powinien byc { data: [...] }, a watek 2 oczekuje { preferences: [...] }, nie zintegruja sie czysto. Dlatego krok 1 jest wazny — plan powinien okreslac wspoldzielone interfejsy przed rozpoczeciem pracy rownoleglej.

Czyszczenie worktree usuwa watek, ktorego potrzebowales. Worktree kwalifikuja sie do czyszczenia po 4 dniach lub gdy przekroczysz 10 lacznie. Przypnij wazne watki lub dodaj worktree do paska bocznego, aby zapobiec automatycznemu usuwaniu. Jesli worktree zostal juz wyczyszczony, Codex zapisuje migawke, z ktorej mozesz przywrocic dane z widoku watku.

Zadanie chmurowe uzywa zlej galezi. Zadania chmurowe domyslnie korzystaja z domyslnej galezi repozytorium. Jesli twoja migracja fundamentowa jest na galezi funkcji, agent chmurowy nie zobaczy nowego schematu. Okresl galaz jawnie w ustawieniach srodowiska chmurowego lub opisz schemat w prompcie.

Co dalej

Debugowanie z Codex na roznych powierzchniach Gdy twoje rownolegle funkcje tworza nieoczekiwane interakcje, debuguj je efektywnie

Wieloagentowa rownolegla praca nad funkcjami Skaluj wzorzec rownoleglych worktree do koordynowania calych zespolow agentow