Paralelizm zespołu — izoluj pracę i ogranicz kolejkę

Równoległe agenty poprawiają delivery tylko wtedy, gdy zadania są niezależne, a system integracji potrafi przyjąć ich output. Celem nie jest stała liczba agentów per developer. Izoluj mutable state, definiuj ownership, ogranicz work in progress na podstawie pojemności CI i review oraz porównuj accepted throughput, jakość, konflikty i rework z baseline szeregowym.

Q14 · Paralelizm w skali zespołu Dowód na maksymalny wynik: izolowany stan, mierzony limit współbieżności, ownership integracji i limity kolejki review.

Zaprojektuj jednostkę pracy równoległej

Każde zadanie potrzebuje zaakceptowanego scope, własnych plików lub interfejsów, zależności, oczekiwanego artefaktu, checków, stop conditions i integration ownera. Preferuj vertical slices lub niepokrywające się packages; nie wysyłaj kilku agentów do tej samej centralnej abstrakcji.

1. Narysuj graf zależności. Uruchamiaj równolegle wyłącznie prawdziwie niezależne nodes.
2. Utwórz izolowany stan. Użyj osobnego git worktree lub checkout, branch, local service state, ports, caches i temporary data.
3. Ustaw ostrożny cap. Zacznij od pojemności reviewerów i CI, potem mierz queue age, konflikty, rework i accepted lead time.
4. Integruj świadomie. Zdefiniuj kolejność, ownera, rebase policy, compatibility checks i osobę rozwiązującą semantic conflicts.
5. Dostosuj na podstawie dowodów. Zwiększaj, zmniejszaj albo wyłączaj concurrency według klasy zadania; nie rób peak fan-out celem dojrzałości.

Claude Code może tworzyć izolowane worktrees przez udokumentowaną opcję worktree; Cursor wspiera parallel agents i worktrees; Codex desktop uruchamia zadania w Git worktrees. Same Git worktrees pozostają przenośnym prymitywem. Przed automatyzacją sprawdź aktualne komendy wybranego toola.

Prompty do planowania równoległego

Zbuduj graf zależności zaakceptowanego planu. Wskaż niezależne zadania, overlapping files lub contracts, kolejność integracji i zadania, które muszą pozostać szeregowe.

Dla każdego zadania zdefiniuj izolowany checkout i state, allowed paths, oczekiwany artefakt, checki, stop conditions i integration ownera. Nie uruchamiaj pracy przy nierozwiązanym overlap.

Przejrzyj ostatni parallel batch: zaakceptowane zmiany, queue age, CI time, konflikty, rework, defekty i reviewer load. Poleć kolejny concurrency cap według klasy zadania.

Dowody akceptacyjne

• Każde równoległe zadanie ma izolowane pliki i local state, w tym jawne ports oraz test data.
• Zespół potrafi bezpiecznie znaleźć i posprzątać porzucone worktrees, branches i procesy.
• Limity kolejki chronią review przed lawiną ukończonych draftów.
• Konflikty rozwiązuje się względem zaakceptowanego intent i testów, nie przez ślepy wybór diffu.
• Paralelizm pozostaje opcjonalny, gdy koszt koordynacji przewyższa wall-clock benefit.

Wzorzec awarii: fan-out bez integracji

Więcej agentów może zwiększyć unfinished work, konflikty i delay reviewerów, choć liczba PR wygląda zdrowo. Zatrzymaj dispatch po osiągnięciu cap kolejki i popraw decomposition lub integrację przed dodaniem concurrency.

Dalej: praca bez nadzoru

Gdy interaktywny paralelizm jest stabilny, użyj Przebiegów bez nadzoru dla wąskiej klasy cyklicznej oraz Automatyzacji review dla dowodów.

Q15 · Przebiegi bez nadzoru Ogranicz scheduled work przez władzę i pojemność review.

Q9 · Automatyzacja review Utrzymuj acceptance queue opartą na dowodach.