Jak pomóc zespołowi przestać czytać każdy diff

Transfer zaufania to protokół zarządzania zmianą, który przeprowadza zespół od czytania każdego diffa agenta do zatwierdzania na podstawie dowodów, jedna pętla naraz. Każda pętla przechodzi trzy etapy: shadow review, review próbkowe i „same dowody”, a do każdego wchodzi wyłącznie na podstawie zapisanych dowodów. Jedna ucieczka na produkcję lub istotne przeoczenie cofa pętlę o etap.

Twój zespół przeczytał argumentację o czytaniu dowodów zamiast kodu i pokiwał głowami. Potem nic się nie zmieniło: dwóch seniorów dalej czyta każdą linię, na code review czeka się trzy dni, a jedyną osobę, która zatwierdziła zmianę na dowodach, w zeszłym miesiącu obwiniono za błąd. Ludzie nie wiedzą, kiedy można bezpiecznie przestać czytać, kto odpowiada, jeśli coś pójdzie źle, i na czym będzie polegać ich praca potem. Ta strona jest dla tech leada, który musi odpowiedzieć na te pytania, i dla CTO, który musi te odpowiedzi poprzeć na piśmie.

Co daje zespołowi wdrożenie transferu zaufania

• Trzyetapowy protokół dla każdej pętli z dowodami wejścia, które w większości sprawdzi skrypt, i zdarzeniami, które bez dyskusji cofają pętlę o etap.
• Zespołowy rejestr zaufania (CSV), jego cztery metryki i job w GitHub Actions, który losuje jeden pull request na pięć do pełnego przeczytania.
• Umowę zespołową, która mówi, kto za co odpowiada, oraz wprost nazwane obawy o tożsamość i odpowiedzialność, które blokują zmianę.
• Trzy prompty do skopiowania: gotowość do awansu, zamiana przeoczenia w sprawdzenie i szkic umowy zespołowej dla twojego repozytorium.

Dlaczego zespół dalej czyta każdy diff?

Obciążenie jest realne i zmierzone. Raport Faros AI Acceleration Whiplash (kwiecień 2026; telemetria od 22 000 programistów i ponad 4000 zespołów) pokazał medianę czasu w review wyższą o 441,5% i o 31,3% więcej pull requestów scalanych bez żadnego review. Ta druga liczba pokazuje, co robi przeciążony zespół bez usankcjonowanego sposobu, żeby czytać mniej: po cichu pomija review.

Nieufność też jest realna. Ankieta Sonar wśród programistów (styczeń 2026, ponad 1100 osób) wykazała, że „96% of developers do not fully trust AI-generated code, and only 48% always verify it before committing”. Mail z hasłem „przestańcie czytać diffy” zderza się z tą nieufnością czołowo i przegrywa.

Traktuj więc tę zmianę jak zarządzanie zmianą, a nie przełączenie polityki. Zaufanie zdobywa się per pętla, czyli powtarzalna klasa zmian z własnym wyzwalaczem, wyrocznią i warunkiem stopu, zgodnie z definicją z jednej mapy. Aktualizacje zależności mogą dojść do etapu „same dowody”, gdy prace nad funkcjami checkoutu są jeszcze w shadow review, i obie odpowiedzi są jednocześnie poprawne.

Jakie są trzy etapy zaufania?

Każdy etap zmienia jedną rzecz: co decyduje o merge’u i ile kodu człowiek wciąż czyta. Klasy eskalacji (uwierzytelnianie i autoryzacja, pieniądze, schematy, migracje danych, zmiany samej wyroczni i wszystko, czego nie pokrywa żadne sprawdzenie) są poza protokołem. Na każdym etapie ten kod czyta wskazana z nazwiska osoba, tak jak określa to tabela eskalacji.

Etap	Co decyduje o merge’u	Co recenzent czyta w każdym pull requeście	Czytanie kodu	Czego dowodzi etap
Shadow review	Przeczytanie kodu, jak dziś	Najpierw paczkę dowodów; recenzent zapisuje werdykt, potem czyta diff	Każdy pull request	Czy dowody wyłapałyby to, co wyłapało czytanie kodu
Review próbkowe	Dowody	Paczkę dowodów	Jeden pull request na pięć, losowany przy otwarciu	Czy dowody wytrzymują, gdy nikt nie wie, która zmiana zostanie przeczytana
Same dowody	Dowody	Paczkę dowodów	Rutynowo żadne; audyt 10 PR raz na kwartał	Że pętla działa na poziomie 4: człowiek czyta dowody, nie diffy

Shadow review i review próbkowe to droga, którą pętla z poziomu 3 zdobywa poziom 4. To zespołowa wersja osobistego dziennika zaufania ze strony o dowodach: jego etapy read-all, sampled i evidence-only odpowiadają jeden do jednego tym trzem.

Od której pętli zacząć?

Wybierz pętlę, w której błąd najtaniej znaleźć i najtaniej cofnąć. Oceń kandydatów pięcioma pytaniami poniżej i zacznij od pętli, która na wszystkie odpowiada „tak”. Typowe pierwsze pętle to aktualizacje zależności, naprawa niestabilnych testów, zmiany tekstów i tłumaczeń oraz narzędzia wewnętrzne.

Pytanie	Dlaczego ma znaczenie
Czy wyrocznia powstała przed agentem i leży poza ścieżkami, które agent może zapisywać?	Wyrocznia napisana przez agenta albo przez niego edytowalna jeszcze niczego nie dowodzi; zbuduj ją najpierw według strony o sile wyroczni
Czy pętla scala co najmniej 20 pull requestów miesięcznie?	Przy mniejszej liczbie shadow review potrzebuje kwartału na werdykt
Czy zła odpowiedź wychodzi na jaw w minuty lub godziny, a nie tygodnie?	Wolna informacja zwrotna ukrywa ucieczki do czasu po awansie
Czy każdą zmianę da się cofnąć revertem albo feature flagą?	Etap „same dowody” wymaga taniego cofnięcia
Czy pętla omija wszystkie klasy eskalacji?	Te klasy nigdy nie opuszczają „czytaj zawsze”, więc nie zademonstrują protokołu

Jakich dowodów potrzebuje pętla, żeby wejść na każdy etap?

Każde kryterium poniżej to zapis, a nie odczucie. Progi to polityka zespołu, nie wyniki badań: to wartości startowe, które rekomendujemy, spójne z osobistym dziennikiem zaufania. Obniż je dla trywialnych pętli, podnieś dla wszystkiego, co widzi klient.

Wejście do	Dowody wejścia (wszystkie)	Kto podpisuje
Shadow review	Pętla ma nazwę i właściciela w loops.yaml. Każde zadanie w pętli ma kryteria akceptacji. Każdy pull request ma paczkę dowodów, wymuszaną przez CI. Testy, CI i konfigurację lintera chroni CODEOWNERS. Istnieje 30-dniowa linia bazowa change failure rate albo odsetka revertów dla pętli.	Tech lead
Review próbkowe	Co najmniej 20 kolejnych pull requestów w shadow review, przeczytanych przez co najmniej dwóch różnych recenzentów, bez istotnego przeoczenia w ostatnich 20. Każde wcześniejsze przeoczenie zamknięte nowym sprawdzeniem w wyroczni. Kompletność dowodów 100% w oknie.	Tech lead
Same dowody	Co najmniej 30 dni w review próbkowym i co najmniej 10 przeczytań z próbki bez istotnego przeoczenia. Brak ucieczki na produkcję w pętli w oknie. Change failure rate albo odsetek revertów nie gorszy niż linia bazowa. Cofnięcie revertem lub flagą przećwiczone raz. Audyt 10 PR z jednej mapy zaliczony. Przy 20 pull requestach miesięcznie i próbce jeden na pięć licz się z około dziesięcioma tygodniami w review próbkowym.	Tech lead, CTO poinformowany

Istotne przeoczenie to błąd albo niezamówiona zmiana zachowania, którą znalazło czytanie kodu, której nie pokazały dowody i która miałaby znaczenie na produkcji. Uwaga o nazwie zmiennej nie jest przeoczeniem. Zmieniona nazwa pola w publicznym API jest.

Zapisz etap w rejestrze pętli obok poziomu, żeby był wersjonowany, a każda jego zmiana była zrecenzowanym commitem:

# loops.yaml (fragment): dodaj blok trust do każdej pętli
- loop: dependency-bumps
  owner: platform-team
  level: L3
  trust:
    stage: sampled            # shadow | sampled | evidence-only
    entered: 2026-09-15
    signed_by: anna.kowalski  # tech lead
    sample_rate: 0.2          # jeden pull request na pięć
    baseline_revert_rate_30d: 0.03
    next_stage_criteria: 30 dni i 10 czystych przeczytań z próbki, brak ucieczki, ćwiczenie revertu zrobione

Prowadź protokół tydzień po tygodniu

1. Ogłoś protokół, zanim ruszy pierwsza pętla. Opublikuj umowę zespołową (szablon niżej), tabelę etapów i listę eskalacji w jednym pull requeście, który zespół recenzuje.

2. Zacznij shadow review na jednej pętli. Recenzenci najpierw otwierają paczkę dowodów, wpisują do rejestru jednowyrazowy werdykt (approve albo reject) i dopiero potem czytają diff. Zapisują, czy czytanie kodu znalazło coś, czego nie pokazały dowody. O merge’u wciąż decyduje przeczytanie kodu, więc ryzyko produkcyjne na razie się nie zmienia.

3. Rotuj recenzentów w shadow review. Wymagaj co najmniej dwóch różnych osób w ciągu 20 pull requestów. Etap wypracowany w pojedynkę przez jednego entuzjastę to zaufanie jednej osoby, nie zespołu.

4. Zamknij każde przeoczenie sprawdzeniem, zanim zaczniesz liczyć od nowa. Istotne przeoczenie zeruje licznik czystych pull requestów, a pętla nie zbiera nowej serii, dopóki sprawdzenie, które by je wyłapało, nie trafi do wyroczni.

5. Awansuj do review próbkowego pull requestem zatwierdzonym przez tech leada. Tech lead zmienia trust.stage w loops.yaml w pull requeście, którego opis linkuje wiersze rejestru. Od tej chwili decydują dowody, a job losujący opisany niżej wybiera pull requesty do pełnego przeczytania.

6. Zrób retro po 30 dniach review próbkowego. Przejrzyj z całym zespołem cztery metryki, przeczytania z próbki i sytuacje „prawie przeoczone”. Awansuj do etapu „same dowody” tylko wtedy, gdy każde kryterium wejścia jest spełnione w zapisach.

7. Audytuj pętle na etapie „same dowody” raz na kwartał. Przeprowadź audyt 10 PR z jednej mapy. Niezaliczony audyt obniża etap pętli dokładnie tak jak ucieczka.

Losuj próbkę, zanim ktokolwiek zobaczy dowody

Próbka czegoś dowodzi tylko wtedy, gdy nikt jej nie wybiera. Recenzent, który po przeczytaniu dowodów wybiera „te, które wyglądają ryzykownie”, testuje swoją intuicję, a nie dowody. Losuj próbkę przy otwarciu pull requesta i nigdy nie losuj ponownie. Ten workflow GitHub Actions robi to dla pull requestów z tego samego repozytorium (domyślny token jest tylko do odczytu w pull requestach z forków):

.github/workflows/trust-sampling.yml

name: trust-sampling
on:
  pull_request:
    types: [opened]
permissions:
  pull-requests: write
jobs:
  draw:
    runs-on: ubuntu-latest
    steps:
      - name: Draw one pull request in five for a full code read
        env:
          GH_TOKEN: ${{ github.token }}
          PR: ${{ github.event.pull_request.number }}
          REPO: ${{ github.repository }}
        run: |
          if [ $((RANDOM % 5)) -eq 0 ]; then
            gh pr edit "$PR" --repo "$REPO" --add-label "sampled-read"
          fi

Najpierw utwórz etykietę sampled-read: gh pr edit --add-label nie tworzy brakujących etykiet. Wiersz w rejestrze zapisuje, że pełne przeczytanie się odbyło.

Losowanie ma dwa ograniczenia. Agent musi otwierać pull requesty tokenem aplikacji GitHub App albo osobistym tokenem dostępu: pull request otwarty domyślnym GITHUB_TOKEN nie uruchamia innych workflow, więc nigdy nie trafi do losowania. Poza tym job oznacza pull requesty ze wszystkich pętli, więc rejestr uwzględnia etykietę sampled-read tylko dla pętli, których trust.stage to sampled.

Prowadź zespołowy rejestr zaufania

Rejestr to jeden plik CSV na repozytorium, jeden wiersz na każdy zrecenzowany pull request w pętli, która przechodzi przez etapy. Kolumnę escaped uzupełnij, gdy incydent zostanie powiązany z pull requestem.

date,pr,loop,stage,reviewer,evidence_verdict,code_read,material_miss,miss_note,escaped
2026-09-22,412,dependency-bumps,shadow,anna,approve,full,no,,no
2026-09-23,418,dependency-bumps,shadow,piotr,approve,full,yes,lockfile pinned a yanked version,no
2026-09-29,431,dependency-bumps,sampled,marek,approve,sampled,no,,no
2026-09-30,433,dependency-bumps,sampled,anna,approve,none,n/a,,no

Wynikają z niego cztery metryki. Raportuj je per pętla i per etap, nigdy jako jedną uśrednioną liczbę; kanoniczne definicje są na stronie o frameworkach metryk.

Metryka	Definicja	Co znaczy zła wartość
Odsetek przeoczeń	Istotne przeoczenia podzielone przez pull requesty, których kod przeczytano, per pętla, per etap, w oknie	Dowody są słabsze niż czytanie kodu; zostań na etapie albo cofnij
Odsetek ucieczek per etap	Błędy produkcyjne powiązane z pull requestami zatwierdzonymi na danym etapie, podzielone przez wszystkie pull requesty zatwierdzone na tym etapie, miesięcznie	Pętla awansowała za wcześnie
Kompletność dowodów	Udział scalonych pull requestów pętli, które mają wszystkie cztery artefakty dowodowe	Zatwierdzenia znów opierają się na zaufaniu
Czas review na pull request	Mediana czasu od „gotowe do review” do zatwierdzenia, per etap	To jest zysk: powinien spadać przy każdym awansie, inaczej protokół dokłada tylko ceremonii

Jak Claude Code, Codex i Cursor wpisują się w protokół?

Protokół jest identyczny we wszystkich trzech narzędziach, bo loops.yaml, rejestr, CODEOWNERS i job losujący żyją w repozytorium. Różni się to, jak powstaje paczka dowodów i które narzędzie może zatwierdzać na etapie „same dowody”.

Claude Code

Zapisz prompt dowodowy ze strony o dowodach jako .github/prompts/evidence.md, a potem uruchom go bez interfejsu, w CI albo w terminalu. Sesje claude -p startują w trybie uprawnień Manual, więc każde polecenie powłoki spoza allowlisty jest odrzucane. Prompt uruchamia testy akceptacyjne, dlatego allowlista obok git diff i git log wymienia polecenie testów; zastąp npm test poleceniem z twojego repozytorium:

# Terminal lub CI, w katalogu głównym repozytorium (Claude Code 2.1.283)
claude -p "$(cat .github/prompts/evidence.md)" \
  --allowedTools "Read,Grep,Glob,Bash(git diff *),Bash(git log *),Bash(npm test *)" \
  --output-format text > evidence.md

Dla pull requesta z etykietą sampled-read polecenie claude ultrareview 431 uruchamia w chmurze wieloagentowe review pull requesta 431. Traktuj je jako drugiego czytelnika obok człowieka, nigdy jako samo przeczytanie z próbki. Po trzech darmowych uruchomieniach na planach Pro i Max Ultrareview jest płatne za każde uruchomienie (zwykle od 5 do 25 USD) i nie jest dostępne dla organizacji z Zero Data Retention ani na Bedrock, Google Cloud i Foundry.

Codex

Codex potrzebuje dwóch poleceń, bo codex exec review --base nie przyjmuje własnego promptu (wersja 0.157.1 odrzuca to połączenie komunikatem the argument '--base <BRANCH>' cannot be used with '[PROMPT]'). Zapisz prompt dowodowy ze strony o dowodach jako .github/prompts/evidence.md, wygeneruj paczkę zwykłym codex exec i uruchom review osobno:

# Terminal lub CI, w katalogu głównym repozytorium (Codex CLI 0.157.1)
codex exec --sandbox read-only -o evidence.md \
  "$(cat .github/prompts/evidence.md) Compare HEAD against main (git diff main...HEAD)."
codex exec review --base main -o review.md

Review bierze instrukcje z wytycznych review w AGENTS.md. Wpisz tam klasy eskalacji i nazwy pętli, żeby zarówno codex exec review, jak i @codex review na GitHubie nazywały pętlę i klasę, do której należy zmiana.

Cursor

Wklej prompt dowodowy ze strony o dowodach do agenta, zanim otworzysz pull request, a potem wklej jego wynik do opisu pull requesta.

PR Routing & Approval „can approve low-risk PRs when your criteria are met” (sprawdzone na cursor.com 2026-08-28). Włączaj to tylko dla pętli na etapie „same dowody”, z kryteriami, które blokuje każda klasa eskalacji i etykieta sampled-read. Zobacz PR Routing & Approval w Cursorze.

Prompty do skopiowania dla transferu zaufania

Prompt do skopiowania: czy ta pętla jest gotowa na kolejny etap?

Decide whether one loop is ready for its next trust stage. Do not edit any file.

Read loops.yaml and trust-ledger.csv in the repository root. For the loop
named dependency-bumps:
1. State its current trust stage, the date it entered it, and the entry
   criteria for the next stage from loops.yaml.
2. From the ledger, compute over the current stage: pull requests reviewed,
   distinct reviewers, pull requests with a full or sampled code read,
   material misses, escapes, and the current run of consecutive clean rows.
3. Check each entry criterion one by one and mark it MET, NOT MET or
   UNKNOWN (no data). Quote the ledger rows behind every verdict.
4. List every material miss in the stage and whether a check that would have
   caught it has been merged (search the git log for its pull request).

End with one verdict: PROMOTE, HOLD, or DEMOTE, and the single missing piece
of evidence that blocks promotion.

Prompt do skopiowania: zamień przeoczenie w sprawdzenie

A code read found a problem the evidence bundle missed. Ledger row:
2026-09-23,418,dependency-bumps,shadow,piotr,approve,full,yes,lockfile pinned
a yanked version,no

1. Read pull request 418's diff and its evidence bundle. Explain in two
   sentences why none of the four evidence artifacts (spec delta, acceptance
   results, oracle changes, runtime evidence) showed the problem.
2. Propose the smallest automated check that would have failed on pull
   request 418 and passes on main today: a test, a CI step, or a lint rule.
   Write it on a new branch.
3. Prove it: run the check against the pull request 418 commit and against
   main, and show both results.
4. Do not modify existing tests or CI steps. If the check needs one, stop and
   explain why instead.

Prompt do skopiowania: szkic umowy zespołowej dla tego repozytorium

Draft docs/trust-transfer.md, the team working agreement for approving agent
pull requests on evidence. Read CODEOWNERS, loops.yaml, AGENTS.md or
CLAUDE.md, and the CI configuration first.

Use the section headings of the template below, and fill each one from
this repository: the loops and their current trust stage, the escalation
classes with the CODEOWNERS paths that enforce them, and the CI job that
enforces the evidence bundle. Where a control does not exist yet (for example,
tests are not protected by CODEOWNERS), write MISSING and the one-line change
that would add it. Do not edit any file except docs/trust-transfer.md.

Kto odpowiada, gdy nikt nie przeczytał kodu?

To pytanie blokuje więcej wdrożeń niż jakiekolwiek narzędzie. Odpowiedz na nie na piśmie, zanim ruszy pierwsza pętla, i poproś CTO o podpis, bo tech lead nie może obiecać ochrony przed obwinianiem, na którą organizacja się nie zgodziła.

Wytyczne DORA do modelu AI capabilities mówią to samo o polityce w ogóle: „Ambiguity creates risk. A clear policy provides the psychological safety developers need to experiment effectively.” (Nathen Harvey i Allison Park, blog Google Cloud, 10 grudnia 2025).

Przyjmij tę umowę zespołową w takiej postaci i popraw nazwiska. Szablon zostaje po angielsku, żeby nagłówki pasowały do promptu wyżej:

# Working agreement: approving agent pull requests on evidence

## What an approver answers for
- The evidence bundle was complete: spec delta, acceptance results, oracle
  changes, runtime evidence.
- No escalation class was touched, or the named code owner read that code.
- The approval follows the loop's current trust stage in loops.yaml.

## What an approver does not answer for
- A defect that the required evidence could not show. That demotes the loop
  and adds a check. It is not raised in performance reviews.

## Who owns the stage
- The tech lead signs every promotion in loops.yaml.
- Anyone on the team may demote a loop by opening a pull request with the
  reason. Demotion needs no approval and is merged the same day.
- The CTO owns the escalation list and the risk-class policy.

## What never changes
- Authentication, money, schema, migrations and oracle changes, and any code
  no check covers, are read by a named person at every stage.
- Every merged pull request has a named human approver.

Kluczowa jest asymetria. Awans jest powolny i podpisany, degradacja szybka i każdy może ją uruchomić, więc sceptyczny senior zachowuje hamulec, który zaciąga bez pytania o zgodę.

Czego ludzie się boją i co protokół z tym robi?

Nazwij obawy głośno na spotkaniu otwierającym. Każda ma w sobie coś prawdziwego i na tę część protokół odpowiada.

Obawa	Co w niej prawdziwe	Co robi protokół
„Jeśli zatwierdzę bez czytania i coś się zepsuje, to na mnie”.	Dziś często tak jest: ktoś, kto zatwierdził przejrzany pobieżnie diff, nie ma się na co powołać.	Umowa zespołowa przenosi odpowiedzialność na dowody, które zatwierdzający sprawdził, a przeoczenie protokołu zamienia w degradację pętli, nie w osobistą porażkę.
„Moja wartość polega na tym, że znam ten kod”.	Głęboka znajomość systemu wciąż się liczy i zanika, jeśli nikt nie czyta kodu. Wewnętrzne badanie Anthropic (Saffron Huang i współpracownicy, 2 grudnia 2025) nazywa to „paradox of supervision”: nadzór wymaga umiejętności, które nadmierne delegowanie osłabia.	Seniorzy odpowiadają za klasy eskalacji, przeczytania z próbki i wyrocznię. Czytaj w całości jeden pull request tygodniowo w pętli, za którą odpowiadasz; strona o rzemiośle i karierze mówi, które umiejętności świadomie utrzymywać.
„Zostałem inżynierem, żeby budować, a nie zatwierdzać”.	To samo badanie Anthropic pokazało, że u części inżynierów praca przesunęła się w „70%+ to being a code reviewer/reviser rather than a net-new code writer”.	Protokół ma ten dryf odwrócić: mniej czasu na czytanie diffów, więcej na specyfikacje, wyrocznie i sprawdzenia. Mierz czas review na pull request, żeby to pokazać.
„Juniorzy nigdy nie poznają kodu”.	Poznają go słabiej, jeśli nikt kodu nie czyta.	Daj juniorom przeczytania w shadow review razem z seniorem; porównanie ich werdyktu z dowodów z przeczytaniem kodu to uporządkowany sposób nauki systemu. Zobacz rozwój juniorów.
„Agent sam sprawi, że jego testy przejdą”.	Może, jeśli wolno mu je edytować.	Zmiany wyroczni są klasą eskalacji na każdym etapie i wymusza to CODEOWNERS. Zobacz ochronę wyroczni.
„Tu chodzi o cięcie etatów”.	Liderzy rzadko mówią co innego, jeśli nikt nie zapyta.	CTO zapisuje w umowie zespołowej, na co pójdzie uwolniony czas review. Jeśli takiego zdania nie da się napisać uczciwie, zespół odczyta protokół jako zagrożenie i wdrożenie stanie.

Rozmowy wykraczające poza spotkanie otwierające opisuje strona o przekonywaniu sceptyków i seniorów.

Kiedy cofnąć pętlę o etap?

Obniżaj etap przy pierwszym wystąpieniu któregokolwiek zdarzenia poniżej. Nie czekaj na wzorzec; o przyczynach rozmawiacie na retro.

Zdarzenie	Cofnij do
Ucieczka na produkcję powiązana z pull requestem zatwierdzonym na bieżącym etapie	Etap niżej
Istotne przeoczenie w przeczytaniu z próbki	Shadow review
Plik wyroczni zmieniony bez zgody code ownera	Shadow review i wyjaśnienie, jak zmiana została scalona
Istotna zmiana harnessu pętli: inny model, przepisany plik reguł, nowy skill lub serwer MCP na ścieżce pętli	Pętle na etapie „same dowody” wracają do review próbkowego na kolejne 10 pull requestów. Pętle w review próbkowym zerują licznik czystych przeczytań.
Dwie degradacje tej samej pętli w jednym kwartale	Shadow review i naprawa wyroczni przed ponownym liczeniem

Pojedynczy pull request bez kompletnej paczki dowodów nie cofa pętli: przeczytaj go w całości, zapisz w rejestrze i cofnij etap dopiero, gdy zdarzy się to dwa razy w oknie.

1. Zmień trust.stage w loops.yaml w pull requeście, w którego opisie jest wiersz rejestru albo link do incydentu. Scal go tego samego dnia.

2. Poinformuj zespół na kanale, na którym odbywa się review, jednym zdaniem o zdarzeniu i nowym etapie.

3. Napisz sprawdzenie, które by to wyłapało, promptem „zamień przeoczenie w sprawdzenie”, i dołącz je do wyroczni.

4. Zacznij liczenie od zera dla kryteriów wyjścia z niższego etapu.

5. Napisz notatkę bez szukania winnych w kolumnie miss_note rejestru albo w zapisie incydentu: którego artefaktu dowodowego zabrakło lub który był słaby, a nie kto zatwierdził.

Co się psuje, gdy zespół przestaje czytać diffy?

Etapy awansują według kalendarza. Naprawa: odrzucaj pull request z awansem, który nie linkuje wierszy rejestru spełniających każde kryterium.

Próbkę wybiera się po obejrzeniu dowodów. Naprawa: etykietę sampled-read nadaje wyłącznie job losujący; każde inne przeczytanie zapisuje się jako dodatkowe.

Seniorzy dalej czytają wszystko po cichu. Shadow review nigdy się nie kończy, a kolejka nie maleje. Naprawa: ogranicz czas shadow review dla pętli (sześć tygodni to rozsądny sufit) i zapytaj na retro, jakie dowody pozwoliłyby każdemu seniorowi przestać. Odpowiedzią jest zwykle brakujące sprawdzenie.

Sukces jednej pętli uogólnia się na cały zespół. Naprawa: każda pętla wchodzi w shadow review na własnych dowodach; jedna mapa raportuje zespół jako rozkład między pętlami.

Paczka dowodów staje się parafrazą diffa. Naprawa: CI odrzuca linię akceptacji bez file:line albo bez polecenia i jego kodu wyjścia; sprawdzenie jest na stronie o paczce dowodów.

Błąd zostaje przypisany zatwierdzającemu. Jedna rozmowa o winie przekreśla miesiące budowania zaufania. Naprawa: tech lead przypomina umowę zespołową, pętla zostaje zdegradowana, a brakujące sprawdzenie pisze zespół.

Review przyspiesza, ale incydentów przybywa. Dane Faros AI z kwietnia 2026 pokazują ten wzorzec w skali branży: liczba epików ukończonych na programistę wzrosła o 66,2%, a incydentów na pull request o 242,7%. Naprawa: bramką jest odsetek ucieczek per etap. Jeśli rośnie ponad linię bazową, cofaj etap, niezależnie od tego, co pokazuje wykres czasu review.

Dokąd dalej z transferem zaufania

Czytanie dowodów zamiast kodu Warunek wstępny: cztery artefakty, które czyta recenzent, i klasy, które zawsze się czyta.

Paczka dowodów Kontrakt pull requesta i sprawdzenie w CI, które odrzuca niekompletną paczkę.

Jak silna jest twoja wyrocznia? Zbuduj wyrocznię, której pętla potrzebuje przed wejściem w shadow review.

Prowadzenie kolejki code review Utrzymaj ruch pull requestów, gdy pętle są na różnych etapach.

Rozwój juniorów Następny krok ścieżki tech leada: nauka, gdy kod piszą agenci.

Governance i autonomia Gdzie CTO raz zapisuje klasy ryzyka i listę eskalacji.