Kolejka code review, gdy pull requesty otwierają agenci

Kolejka code review dla pull requestów otwieranych przez agentów pozostaje zdrowa, dopóki PR-y napływają nie szybciej, niż zespół jest w stanie je przejrzeć. Tech lead utrzymuje tę równowagę czterema narzędziami: limitem pracy w toku (WIP), który wstrzymuje uruchamianie agentów, budżetem rozmiaru PR, torami ryzyka decydującymi o recenzencie oraz równoważeniem obciążenia recenzentów, a wszystko mierzy czasem w review.

Twoich sześciu inżynierów prowadzi po dwóch, trzech agentów i w poniedziałek rano czekają 34 otwarte pull requesty. Każdy wygląda rozsądnie. Żaden nie jest pilny. W czwartek najstarszy czeka już cztery dni, dwie osoby po cichu zaczęły zatwierdzać bez czytania, a senior mówi ci na spotkaniu 1:1, że cały dzień robi review i nic nie buduje. To sufit review z poziomu 3 drabiny autonomii, a ta strona jest instrukcją obsługi tego sufitu.

Strona jest dla tech leada lub szefa zespołu, który odpowiada za przepływ pracy jednego zespołu. Zakłada, że agenci już otwierają pull requesty; jeśli jeszcze nie, zacznij od backlogu przygotowanego dla agentów.

Co daje zespołowi zarządzana kolejka review

Jednolinijkowy test przepustowości, który mówi, czy kolejka w tym tygodniu urośnie, czy się opróżni.
Limit WIP wyliczony z twoich własnych danych i skrypt, który wstrzymuje uruchamianie agentów, gdy kolejka jest pełna.
Budżet rozmiaru PR, którego agenci przestrzegają, a CI go egzekwuje, z furtką, którą kontrolujesz ty.
Tabelę torów ryzyka, która kieruje każdy PR do zielonego pipeline’u, automatycznego recenzenta, jednej osoby albo dwóch.
Osiem definicji metryk, które policzysz jeszcze dziś po południu za pomocą gh i jq, oraz progi, przy których trzeba coś zmienić.
Zasady zrównoważonego tempa: limity sesji, dyżury przy kolejce i sygnały, że trzeba zmniejszyć współbieżność.

Dlaczego pull requesty agentów zalewają review

Generowanie kodu się przeskalowało, czytanie nie. Raport Faros AI AI Engineering Report 2026: The Acceleration Whiplash (kwiecień 2026, telemetria z 22 000 programistów) zmierzył obie strony jednocześnie: liczba zmergowanych PR na programistę wzrosła o 16,2%, a w tym samym okresie mediana czasu w review wzrosła o 441,5%, mediana czasu do pierwszego review o 156,6%, liczba incydentów na PR o 242,7%, a pull requestów zmergowanych bez żadnego review było o 31,3% więcej. PR-y też urosły: Faros podaje wzrost rozmiaru PR o 51%, a panel DX (czerwiec 2026) odnotował wzrost mediany „from 44 lines to 72 lines per pull request between July 2025 and June 2026”.

Najbardziej niepokojąca jest liczba merge’y bez review. Tak wygląda kolejka, którą nikt nie zarządza: recenzenci nie odmawiają pracy, tylko przestają czytać i dalej zatwierdzają.

DORA nazywa środek zaradczy w swoim AI Capabilities Model. O „working in small batches” materiał DORA na blogu Google Cloud (grudzień 2025) mówi: „AI can easily generate massive blocks of code, which are hard to review and test. Enforcing the discipline of small batches counteracts this risk”. Reszta tej strony zamienia to zdanie w reguły, które da się wyegzekwować.

Sprawdź, czy twoja kolejka review może się opróżnić

Kolejka jest stabilna tylko wtedy, gdy tempo napływu jest niższe niż tempo obsługi. Zmierz oba z ostatnich czterech tygodni, a nie z pamięci:

Tempo napływu (λ): liczba PR-ów niebędących draftami, otwieranych w ciągu dnia roboczego, łącznie od agentów i ludzi.
Przepustowość review (μ): liczba PR-ów, które recenzenci są w stanie zamknąć w ciągu dnia roboczego. Policz ją jako liczbę godzin recenzenckich dziennie podzieloną przez medianę godzin review na jeden PR.

Przykład na okrągłych liczbach: czterech recenzentów chroni po 90 minut dziennie na review, czyli razem 6 godzin. Mediana review jednego PR to 30 minut, więc μ wynosi 12 PR-ów dziennie. Jeśli agenci i ludzie otwierają 18 dziennie, kolejka rośnie o sześć każdego dnia, bez końca. Żaden wysiłek recenzentów tego nie naprawi; pomoże tylko mniej PR-ów albo mniejsze PR-y.

Teoria kolejek dodaje drugie ostrzeżenie: czas oczekiwania rośnie gwałtownie, a nie liniowo, gdy wykorzystanie (λ ÷ μ) zbliża się do 1. Zespół, w którym recenzenci są obciążeni w pełni, ma długie oczekiwanie nawet wtedy, gdy arytmetyka „się zgadza”. Planuj tak, by review było zajęte mniej więcej przez trzy czwarte czasu, a wszystko powyżej traktuj jako kolejkę tuż przed zatorem.

Ustaw limit WIP, który wstrzymuje uruchamianie agentów

Prawo Little’a łączy trzy liczby, na których ci zależy: liczba elementów w kolejce = przepustowość × czas w kolejce. Wybierz docelowy czas w review, pomnóż go przez zmierzoną przepustowość i masz limit WIP. Przy μ = 12 dziennie i celu jednego dnia roboczego w review limit wynosi 12 otwartych PR-ów (bez draftów) czekających na review, w skali całego zespołu.

Limit działa tylko wtedy, gdy blokuje uruchamianie pracy, a nie tworzenie pull requestów. Agent, który skończył pracę i nie może otworzyć PR, zostawia gałąź, której nikt nie widzi — to ten sam zapas pracy, tylko schowany w gorszym miejscu. Postaw więc bramkę przed tym, co uruchamia agentów: przed workflow issue-to-PR, zaplanowaną rutyną lub automatyzacją albo poleceniem, którym inżynierowie startują agenta w tle.

#!/usr/bin/env bash
# Exit 1 when the review queue (open, non-draft, not yet approved) is at or above the WIP cap.
set -euo pipefail
CAP="${REVIEW_WIP_CAP:-12}"
open=$(gh pr list --state open --search "draft:false -review:approved" \
  --limit 200 --json number --jq 'length')
if [ "$open" -ge "$CAP" ]; then
  echo "Review queue full: $open PRs awaiting review (cap $CAP). Review before dispatching more." >&2
  exit 1
fi
echo "Review queue $open/$CAP: dispatch allowed."

Skrypt liczy dokładnie to, co definiuje limit: każdy otwarty PR, który nie jest draftem i nie ma jeszcze zatwierdzenia, zarówno od agentów, jak i od ludzi. Zatwierdzone PR-y czekające na merge nie potrzebują już recenzenta, więc się nie liczą. Trzymaj limit w jednym miejscu, w zmiennej REVIEW_WIP_CAP w ustawieniach CI, żeby jego zmiana była decyzją w jednej linijce, a nie zmianą kodu. Co dwa tygodnie porównuj limit z metrykami poniżej; wynika z przepustowości, więc zmienia się razem z nią.

Wprowadź budżet rozmiaru PR, którego agenci przestrzegają

Małe pull requesty to najtańsza przepustowość, jaką możesz kupić: szybciej się je przegląda, precyzyjniej wskazują błąd i czysto się je wycofuje. Ustal budżet na podstawie własnej historii, na przykład na rozmiarze, poniżej którego mieszczą się trzy czwarte PR-ów przeglądanych przez ludzi. Jeśli nie masz historii, zacznij od 400 zmienionych linii bez lockfile’i i snapshotów i dostrój wartość po miesiącu. Ta liczba to punkt wyjścia, a nie wynik badań.

Najpierw powiedz o tym agentom, w pliku instrukcji czytanym przez każdą sesję, żeby zaplanowały podział przed napisaniem kodu:

## Pull request budget
- One concern per pull request. Stay under 400 changed lines, excluding lockfiles and snapshots.
- If a task needs more, stop before coding and propose a split into stacked pull requests,
  each independently green and reviewable on its own.
- Never change tests, CI config or lint rules in the same pull request as the code they check.
  Open those separately with the label `oracle-change`.
- Open every pull request with `gh pr create --label agent` and put the evidence bundle
  (acceptance criteria, commands run, results) in the description.

Potem zrób z CI zabezpieczenie, bo instrukcja jest prośbą, a nieprzechodzący check jest regułą:

name: pr-size-budget
on:
  pull_request:
    types: [opened, synchronize, reopened, labeled, unlabeled]
permissions:
  contents: read
jobs:
  size:
    if: ${{ !contains(github.event.pull_request.labels.*.name, 'size-exception') }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
          persist-credentials: false
      - name: Compare changed lines with the budget
        env:
          BASE: ${{ github.event.pull_request.base.sha }}
          BUDGET: 400
        run: |
          changed=$(git diff --numstat "$BASE" HEAD -- . \
            ':(exclude,glob)**/package-lock.json' ':(exclude,glob)**/pnpm-lock.yaml' \
            ':(exclude,glob)**/*.lock' ':(exclude,glob)**/__snapshots__/**' \
            | awk '{ a += $1; d += $2 } END { print a + d + 0 }')
          echo "Changed lines: $changed (budget $BUDGET)"
          if [ "$changed" -gt "$BUDGET" ]; then
            echo "::error::Over the $BUDGET-line review budget. Split the change, or ask the tech lead for size-exception."
            exit 1
          fi

Etykieta size-exception to furtka dla zmian mechanicznych, takich jak zmiana nazwy w całej bazie kodu. Niech zasadą zespołu będzie, że nadaje ją wyłącznie tech lead. GitHub tego nie wymusza, bo etykietę może dodać każdy z uprawnieniami triage lub write, dlatego cotygodniowe metryki wymieniają każde użycie size-exception i osobę, która je nadała (z osi czasu PR), a nadużycia stają się widoczne.

Kieruj każdy pull request według ryzyka

Nie każdy PR potrzebuje tego samego czytelnika. Model review opartego na dowodach mówi, co człowiek czyta zamiast diffa; tory poniżej mówią, które PR-y w ogóle trafiają do człowieka. Spisz tabelę, zacommituj ją jako docs/review-lanes.md obok CODEOWNERS i pozwól, by o torze decydowały ścieżki plików.

Tor	Co do niego trafia	Bramka przed merge’em	Kto zatwierdza
A. Zielony pipeline	Aktualizacje zależności w wersjach patch, dokumentacja, zmiany tekstów, generowani klienci, zmiany zgodne ze wzorcem zatwierdzonym już wiele razy	Przechodzą typy, testy, lint i budżet rozmiaru; automatyczny recenzent nie zgłasza blokującego problemu	Pipeline; tech lead co tydzień sprawdza kilka losowo
B. Automat plus wyrywkowo człowiek	Zwykłe funkcje i poprawki w obrębie jednego modułu z mocnymi testami	Bramki toru A plus automatyczny recenzent; człowiek czyta pakiet dowodów, a kod tylko wtedy, gdy dowody są słabe	Jeden recenzent przydzielony według obciążenia
C. Właściciel kodu	Publiczne API, biblioteki współdzielone, fragmenty kodu krytyczne wydajnościowo, wszystko, co przekracza granice modułów	Bramki torów A i B plus zatwierdzenie właściciela kodu	Zespół-właściciel przez `CODEOWNERS`
D. Dwie osoby, kod czytany	Uwierzytelnianie i autoryzacja, pieniądze, schematy i migracje danych oraz każda zmiana `oracle-change` (testy, CI, konfiguracja lintera lub typów)	Wszystkie bramki plus dwa zatwierdzenia, w tym jedno właściciela kodu; najpierw głębokie review automatyczne	Dwie wskazane osoby; przy zmianach `oracle-change` (testy, CI, lint) — tech lead

CODEOWNERS wymusza zatwierdzenie właściciela kodu w torach C i D bez nowego narzędzia, o ile w regule ochrony gałęzi włączona jest opcja „Require review from Code Owners”:

/db/migrations/     @acme/data-owners
/src/auth/          @acme/security-reviewers
/src/billing/       @acme/security-reviewers
/.github/           @acme/tech-leads
/tests/             @acme/tech-leads
/eslint.config.js   @acme/tech-leads

Ochrona gałęzi w GitHubie ma jedną wymaganą liczbę zatwierdzeń dla całej gałęzi, co wpływa na pozostałe tory. Ustaw ją na 1, a tor A obsłuż na jeden z dwóch sposobów. Albo powiąż automatyczne zatwierdzanie z kryteriami toru A (PR Routing & Approval w Cursorze albo GitHub Action, która zatwierdza tylko ścieżki toru A; Action wymaga włączenia w repozytorium ustawienia „Allow GitHub Actions to create and approve pull requests”), albo nadaj automatyzacji scalającej tor A (aplikacji GitHub lub kontu bota) uprawnienie bypass w rulesecie gałęzi i niech merge’uje wyłącznie PR-y, których wszystkie ścieżki należą do toru A. W obu przypadkach kontrolą jest cotygodniowa wyrywkowa weryfikacja przez tech leada.

Liczba 1 oznacza też, że nic nie wymusza drugiego zatwierdzenia w torze D: CODEOWNERS wymaga jednego zatwierdzenia właściciela kodu, a nie dwóch. Daj temu drugiemu zatwierdzeniu osobną kontrolę. Albo dodaj wymagany check CI, który oblewa PR, gdy zmieniono ścieżki toru D, a zatwierdzeń jest mniej niż dwa (odczytasz je poleceniem gh pr view <numer> --json reviews), albo zostaw to jako zasadę i rozliczaj ją w cotygodniowych metrykach poniżej, gdzie wiersz Merge bez review liczy także merge’e w torze D z mniej niż dwoma zatwierdzeniami.

Tor A na początku jest pusty. Klasa zmian trafia do niego dopiero po serii merge’y bez rewertów i bez błędów, które przedostały się dalej, a wypada z niego po pierwszym takim zdarzeniu. Szczegółowo opisuje to protokół transferu zaufania.

Równoważ obciążenie recenzentów zamiast przydzielać z przyzwyczajenia

Pozostawione samym sobie prośby o review trafiają do dwóch osób, które odpowiadają najszybciej, a te stają się najpierw wąskim gardłem, a potem ofiarami wypalenia. Mechanikę naprawiają ustawienia code review zespołu w GitHubie. W Team settings › Code review zaznacz Enable auto assignment i wybierz algorytm Load balance zamiast round robin. Według dokumentacji GitHuba load balance „considers the number of outstanding reviews for each member” i dąży do tego, by każdy członek zespołu przejrzał tyle samo PR-ów w dowolnym okresie 30 dni, podczas gdy round robin rotuje „regardless of the number of outstanding reviews they currently have”.

Liczą się jeszcze dwa ustawienia. Osoby, które ustawiły w GitHubie status Busy, nie są wybierane, więc „jestem w bloku skupienia” staje się realnym stanem, a nie grzecznościową fikcją. Z kolei Never assign certain team members pozwala wyłączyć kogoś z rotacji na czas onboardingu albo tygodnia z incydentem.

Wstępne review i kierowanie PR w Claude Code, Codeksie i Cursorze

Opisane wyżej mechanizmy kolejki działają na poziomie platformy Git (np. GitHuba) i są takie same dla wszystkich trzech narzędzi. Różni się to, jak każde narzędzie przegląda zmianę, zanim zobaczy ją człowiek, i jak pomaga skierować wynik.

Zanim PR zostanie otwarty: niech agent uruchomi na własnym diffie wbudowany skill /code-review i poprawi to, co znajdzie. Dodaj --fix, żeby poprawki trafiły do tego samego przebiegu.
Na pull requeście: zarządzana usługa Code Review (research preview, plany Team i Enterprise) publikuje komentarze w linii z podziałem na Important, Nit i Pre-existing, a według Anthropic kosztuje średnio 15–25 USD za review. Jej check „always completes with a neutral conclusion so it never blocks merging” (dokumentacja Code Review, sprawdzone 2026-09-26), więc zasila tor B, ale sama nie może być bramką toru A.
Głębokie review dla toru D: uruchom w terminalu claude ultrareview 482, gdzie 482 to numer PR (w sesji: /code-review ultra). To wieloagentowe review w chmurze, które niezależnie odtwarza każde znalezisko; Anthropic podaje koszt zwykle 5–25 USD po trzech darmowych uruchomieniach w planach Pro i Max. Nie działa na Bedrocku, Google Cloud ani Foundry, a także w organizacjach z Zero Data Retention.
Podgląd floty: claude agents otwiera agent view (research preview), który pozwala „dispatch and manage many Claude Code sessions from one screen”. Dzięki temu widzisz w jednym miejscu, ile sesji równocześnie nadzorują twoi inżynierowie.

Zanim PR zostanie otwarty: uruchom codex exec review --base main w worktree agenta lub jako krok CI albo /review w sesji interaktywnej. Flag --base, --commit i --uncommitted nie da się połączyć z własnym promptem (sprawdzone w Codex CLI 0.157.1), więc własne instrukcje podaj w samym prompcie, na przykład codex exec review "Review the changes against main and check them against the lane table in docs/review-lanes.md", albo zapisz reguły w AGENTS.md.
Na pull requeście: skomentuj @codex review, żeby poprosić o review, albo włącz automatyczne review w integracji z GitHubem, a reguły review zapisz w AGENTS.md (dokumentacja integracji Codeksa, sprawdzona 2026-08-28).
Podgląd floty: codex agents pokazuje wszystkie sesje agentów na lokalnym demonie app-server (Codex CLI 0.157.1).
Auto-review w Codeksie (--approve-for-me) ocenia zgody na wyjście poza sandbox w trakcie przebiegu. Nie jest recenzentem pull requestów i nie należy do tabeli torów.

Automatyczny recenzent, który nie może zablokować merge’a, uczy ludzi przewijać jego komentarze. Zdecyduj, przy których znaleziskach może oblać build — krótka lista, na przykład sekrety, SQL sklejany ze stringów i wyłączone testy — a resztę traktuj jako komentarze. Konfigurację tej warstwy opisuje workflow review pull requestów agentów, a jej wdrożenie w całym zespole — strona o automatyzacji review PR w zespole.

Mierz kolejkę czasem w review

Liczniki przepustowości łatwo oszukać i nic nie mówią o kolejce. Śledź co tydzień tych osiem metryk, z podziałem na tory oraz na autora-agenta i autora-człowieka:

Metryka	Definicja	Reaguj, gdy
Tempo napływu	PR-y (bez draftów) otwarte w dniu roboczym	Przez dwa tygodnie z rzędu przekracza przepustowość review
Przepustowość review	PR-y zmergowane lub zamknięte po review, na dzień roboczy	Spada, choć napływ się nie zmienia
Głębokość kolejki	Otwarte PR-y (bez draftów) jeszcze bez zatwierdzenia, od agentów i ludzi (to, co liczy skrypt bramki)	Stoi na limicie WIP dłużej niż dwa dni
Czas do pierwszego review	Od otwarcia (lub oznaczenia jako gotowy) do pierwszego wysłanego review od człowieka; mediana i 90. percentyl	Mediana przekracza pół dnia roboczego
Czas w review	Od otwarcia (lub oznaczenia jako gotowy) do merge’a; mediana i 90. percentyl	90. percentyl przekracza cel o 50%
Rozmiar PR	Zmienione linie bez lockfile’i i snapshotów, mediana	Mediana rośnie dwa tygodnie z rzędu
Merge bez review	Odsetek merge’y bez wysłanego review od człowieka poza torem A oraz merge’y w torze D z mniej niż dwoma zatwierdzeniami	Pojawia się choć jeden merge bez review poza torem A albo merge w torze D z mniej niż dwoma zatwierdzeniami
Obciążenie recenzentów	Otwarte prośby o review na osobę i rozrzut między najbardziej a najmniej obciążonym	Jedna osoba ma dwa razy więcej niż mediana zespołu

Progi są punktem wyjścia do rozmowy, a nie branżowymi benchmarkami. Pierwsze cztery tygodnie dają ci punkt odniesienia; potem porównuj się z nim. Jak te metryki mają się do rodzin DORA i SPACE, opisuje strona o frameworkach metryk inżynierskich.

To polecenie eksportuje kolumny czasu, rozmiaru i zmienionych ścieżek dla ostatnich 200 zmergowanych PR-ów agentów. Uruchom je w terminalu w katalogu repozytorium, z zalogowanym gh:

gh pr list --state merged --label agent --limit 200 \
  --json number,author,createdAt,mergedAt,additions,deletions,reviews,files \
  --jq '.[] | (.createdAt | fromdateiso8601) as $o | .author.login as $me
    | [ .number, .createdAt, .mergedAt,
        (.additions + .deletions),
        (([.reviews[] | (.author.login // "") as $r
            | select($r != $me and ($r | test("\\[bot\\]$|^copilot-|^chatgpt-codex") | not))
            | .submittedAt] | min) as $f
          | if $f then ((($f | fromdateiso8601) - $o) / 3600 | floor) else "none" end),
        (((.mergedAt | fromdateiso8601) - $o) / 3600 | floor),
        ([.files[].path] | join(",")) ]
    | @tsv' > review-queue.tsv

Kolumny to numer PR, znaczniki czasu utworzenia i merge’a, liczba zmienionych linii, godziny do pierwszego review (none oznacza merge bez review), godziny w review oraz zmienione ścieżki rozdzielone przecinkami. gh pobiera najwyżej 100 pierwszych plików na PR, więc przy większym PR-ze lista ścieżek jest niepełna. Filtr pomija review od botów i od autora PR, więc kolumna pierwszego review mierzy review ludzi; bez tego automatyczni recenzenci opisani wyżej prawie zawsze byliby pierwsi. Recenzenci będący aplikacjami GitHub nie zawsze mają w tym wyniku przyrostek [bot], więc raz sprawdź to poleceniem gh pr view <numer> --json reviews --jq '.reviews[].author.login' na PR-ze, który przejrzały twoje boty, i dopisz do wzorca pokazane loginy.

Dwa zastrzeżenia. createdAt obejmuje czas spędzony jako draft, więc jeśli agenci najpierw otwierają drafty, liczby zawyżają kolejkę; gdy to zniekształcenie ma znaczenie, użyj zamiast niego zdarzenia ready_for_review z API osi czasu. Ponadto kolumna rozmiaru liczy lockfile’e, które budżet w CI pomija.

Read review-queue.tsv (columns: PR number, created at, merged at, changed lines,
hours to first review or "none", hours in review, comma-separated changed paths)
and .github/CODEOWNERS. Then:
1. Report median and p90 for hours to first review and hours in review, overall
   and split into PRs under and over 400 changed lines.
2. List every PR merged with "none" for first review, and say which CODEOWNERS
   path each touched.
3. Estimate daily arrivals from the created-at column and daily throughput from
   the merged-at column, per working day. The file holds merged agent PRs only,
   so treat the arrival figure as a lower bound and say so. Then say whether
   the queue is growing or draining.
4. Recommend one change only: the WIP cap, the size budget, or a lane move.
   Show the arithmetic. Do not recommend adding reviewers.

This branch is over our 400-line review budget. Do not change behaviour.
Propose a split into stacked pull requests, each under 400 changed lines
excluding lockfiles and snapshots, each passing the full test suite on its own,
and each with one concern a reviewer can state in a sentence. Put pure
refactors and renames first, then the behaviour change, then cleanup. Any
change to tests, CI config or lint rules goes in its own PR labelled
oracle-change. Show the plan as a numbered list with the files in each PR and
the command that proves each one green. Wait for my approval before you
create branches.

Classify this pull request into a review lane using docs/review-lanes.md and
.github/CODEOWNERS. Output: the lane (A, B, C or D), the paths that decided it,
whether the PR changes its own oracle (tests, CI, lint or type config), and the
evidence a reviewer needs that is missing from the description. If any path
falls in lane D, say so first. Post the result as a PR comment and do not
approve or merge anything.

Utrzymaj zrównoważone tempo, gdy ludzie nadzorują równoległych agentów

Kolejka ma ludzki koszt, który powyższe metryki widzą z opóźnieniem. Badanie Anthropic dotyczące własnych inżynierów (grudzień 2025) opisuje osoby, których praca przesunęła się „70%+ to being a code reviewer/reviser rather than a net-new code writer”, i nazywa „paradoks nadzoru”: nadzorowanie agentów wymaga właśnie tych umiejętności, które nadmierne delegowanie osłabia. Wcześniejszy raport Faros AI AI Productivity Paradox z 2025 roku (źródło wtórne: wyciągi z wyszukiwarki) podawał wzrost czasu review PR o około 91% w zespołach intensywnie korzystających z AI. Nadzorowanie kilku agentów naraz męczy w sposób, którego dashboard nie pokaże, dopóki ktoś nie przestanie czytać.

Przyjmij te cztery zasady jako politykę zespołu i wracaj do nich na każdej retrospektywie:

Ogranicz liczbę równoległych sesji na inżyniera do tylu, ile jest w stanie przejrzeć tego samego dnia. Dwie lub trzy to rozsądny początek. Agent, który kończy o 17:00, gdy nikt nie przeczyta wyniku, wytworzył zapas, a nie postęp.
Chroń osobno bloki na review i bloki na skupienie. Planuj review w stałych blokach, a nie jako przerywniki, i niech ludzie ustawiają w GitHubie status Busy na czas pracy w skupieniu, żeby automatyczne przydzielanie ich pomijało.
Wprowadź codzienny dyżur przy kolejce. Jedna osoba dziennie pilnuje głębokości kolejki, ponagla PR-y, które przekroczyły cel czasu do pierwszego review, i zajmuje się wyłącznie kierowaniem. Dyżur rotuje, żeby nikt nie został stałym recenzentem i żeby juniorzy widzieli, jak zachowuje się cała kolejka.
Zmniejsz współbieżność, zanim obniżysz poprzeczkę. Gdy czas do pierwszego review przez dwa tygodnie przekracza cel, gdy poza torem A pojawiają się merge’e bez review albo gdy dwie osoby w tym samym tygodniu mówią, że tylko robią review, najpierw obniż limit WIP i limit sesji na inżyniera. Luzowanie torów, żeby rozładować kolejkę, to prosta droga do obrazu z danych Faros: więcej merge’y bez review i więcej incydentów na pull request.

Co się psuje, gdy zarządzasz kolejką review

Limit WIP przenosi zapas pracy do gałęzi. Inżynierowie nie wyłączają agentów i trzymają gałęzie lokalnie, aż w kolejce zrobi się miejsce. Naprawa: w cotygodniowym przeglądzie licz otwarte gałęzie agentów, a nie tylko PR-y, i blokuj uruchamianie pracy, a nie tworzenie PR, tak jak robi to skrypt wyżej.

Agenci mieszczą się w budżecie dzięki podziałom, których nie da się przejrzeć osobno. Cztery PR-y po 390 linii, które mają sens tylko razem, to jeden PR na 1560 linii z dodatkowym narzutem. Wymagaj, żeby każdy PR ze stosu przechodził testy samodzielnie i miał jeden wyraźny cel; odrzucaj stos, który tego nie spełnia.

Tor A rośnie z przyzwyczajenia. Klasa zmian trafia do zielonego pipeline’u, bo tak było wygodniej w gorącym tygodniu. Naprawa: trzymaj przynależność do torów w zacommitowanej tabeli, którą przegląda tech lead, i cofaj klasę do toru B po każdym rewercie lub błędzie, który przedostał się dalej.

Metryki karzą za drafty albo nagradzają mikroskopijne PR-y. createdAt wlicza czas draftu, a zespół rozliczany wyłącznie z czasu w review potrafi dzielić zmiany ponad sens. Czytaj czas w review razem z rozmiarem PR, rewertami i błędami, które przedostały się dalej; nigdy nie raportuj żadnej z tych liczb osobno.

Najbardziej obciążony recenzent i tak się wypala. Równoważenie obciążenia wyrównuje liczbę próśb, a nie ich trudność, a review w torze D kosztuje dużo więcej niż w torze B. Śledź, kto dźwiga tor D, i świadomie rotuj tę rolę.

Automatyczne review staje się szumem w tle. Jeśli wszyscy przewijają komentarze bota, giną też te wartościowe. Skróć jego listę blokującą do kilku znalezisk, które uzasadniają oblany build, a resztę zamień w komentarze.

Co dalej z kolejką review

Jak pomóc zespołowi przestać czytać każdy diff Etapowy protokół przenoszenia klas zmian do toru zielonego pipeline'u.

Review pull requestów agentów Konfiguracja automatycznej warstwy review i tego, co może blokować.

Pakiet dowodów Manifest, który recenzent czyta zamiast diffa.

Automatyzacja review PR w zespole Wdrożenie automatycznego review w całym zespole i decyzja, co może blokować.

Równoległa praca zespołu Izolacja równoległej pracy i limit wynikający z przepustowości review i CI.

Jak przygotować backlog dla agentów Dziel pracę na jednostki na tyle małe, by dało się je przejrzeć.

Poziom 3: sufit review Dlaczego przepustowość review ogranicza ten szczebel — pełne liczby Faros i DX.