Zmęczenie weryfikacją i mechaniczne zatwierdzanie

1. Przegląd koncepcji i problem systemowy

W klasycznym rozwoju oprogramowania Code Review był procesem społecznym opartym na dialogu między dwiema osobami: zmiany były lokalne, autorzy rozumieli kontekst biznesowy, a reviewer koncentrował się na ulepszaniu architektury i stylu kodu.

W 2026 roku równowaga ta została zachwiana. Modele generatywne oraz agenci są w stanie tworzyć zmiany liczące setki linii kodu w ciągu kilku sekund. Jeśli wcześniej czynnikiem limitującym było pisanie kodu, to obecnie wąskim gardłem stał się ludzki audyt. Gdy inżynier musi przeglądać siódmy z rzędu gigantyczny diff w ciągu dnia, jego krytyczne myślenie zostaje wyłączone. Pojawia się Verification Fatigue (zmęczenie weryfikacją).

Niebezpiecznym skutkiem tego stanu jest Rubber-Stamping – formalne, ślepe zatwierdzanie pull requestów. Inżynier patrzy na ładną składnię, zielony status CI/CD, widzi znajome nazwy funkcji i nieświadomie przekonuje siebie samego: „Sieć neuronowa pewnie wie, co robi”. W rezultacie do produkcji trafiają subtelne podatności, niezweryfikowane uprawnienia dostępu oraz halucynacje logiczne, których nie pokrywają trywialne testy jednostkowe.

Ewolucja zmęczenia podczas przeglądów kodu:
PR 1-2 (Rano):   [ Skrupulatna analiza każdej linii, poszukiwanie warunków brzegowych ]
PR 3-5 (Obiad):    [ Przeglądanie tylko sygnatur funkcji i testów ]
PR 6-8 (Wieczór):   [ Szybki scroll, sprawdzenie statusu CI/CD -> Akceptacja ]
PR 9+  (Noc):     [ Ślepe scalenie: „Rubber Stamp” -> Awaria na produkcji ]

2. Taksonomia architektoniczna i model mentalny

Klasyfikacja poziomów wyczerpania recenzenta:

3. Praktyczne scenariusze inżynierskie w środowisku produkcyjnym

01. Przeoczenie luki autoryzacyjnej przez zmęczenie dużym diffem

Agent realizował zadanie „Refaktoryzacja tras użytkownika pod nowy standard API”. Diff obejmował 1400 linii kodu w 28 plikach. Inżynier sprawdzał go po 7 godzinach nieprzerwanej pracy. W jednym z endpointów /api/v2/admin/billing/override agent podczas unifikacji mikro-wzorów przypadkowo zamienił dekorator @RequireRole('superadmin') na @RequireAuth(), co pozwalało każdemu zarejestrowanemu klientowi na anulowanie długów. Recenzent zmęczył się przy 15. pliku i nie zauważył różnicy między dwoma podobnymi nazwami dekoratorów.

02. Wdrożenie automatycznego limitu Diff Budget

Zespół wprowadza regułę inżynierską w pipeline GitHub Actions, aby zapobiec odporności na zmęczenie:

# .github/workflows/review-guard.yml
name: "Agent PR Budget Guard"
on: [pull_request]

jobs:
  check-diff-size:
    runs-on: ubuntu-latest
    steps:
      - name: Enforce Maximum Review Budget
        run: |
          CHANGES=$(git diff --shortstat origin/main | awk '{print $4+$6}')
          if [ "$CHANGES" -gt 250 ]; then
            echo "::error::PR size ($CHANGES lines) exceeds cognitive threshold (250 lines). Split the agent task!"
            exit 1
          fi

Jeśli agent próbuje wysłać monolityczny patch, pipeline blokuje go jeszcze zanim człowiek poświęci choćby sekundę swojej uwagi.

4. Pułapki, typowe błędy i bezpieczeństwo

1. Iluzja bezpieczeństwa wynikająca z testów automatycznych: Modele potrafią pisać testy, które weryfikują własne halucynacje (testy-pustki z expect(true).toBe(true) lub fałszywymi mockami). Zaufanie do zielonego CI bez audytu treści testu jest fatalne w skutkach.
2. Przenoszenie audytu na inny model bez zasad: Użycie drugiego AI do review pierwszego często prowadzi do „efektu zmowy” (mutual reinforcement), gdy oba modele zgadzają się na niepoprawny wzorzec.
3. Psychologiczne poczucie winy: Inżynier karze siebie za wolność działania, gdy koledzy lub agenci „stemplują” kod szybciej, i zaczyna zatwierdzać PR-y bez namysłu, by „nie hamować zespołu”.

5. Strategiczny wniosek dla inżyniera w 2026 roku

Weryfikacja kodu stała się główną linią obrony współczesnego oprogramowania. Szybkość generacji nie jest już wskaźnikiem sukcesu – prawdziwą wartość definiuje głębokość weryfikacji.

Jeśli czujesz, że przewijasz pull request bez zrozumienia każdej linii, zatrzymaj się. Zmniejszaj zakres zadań dla agentów, wymagaj matematycznie precyzyjnych kontraktów i pamiętaj: jedno nierozważne naciśnięcie przycisku „Approve” może przekreślić tygodnie pracy całej infrastruktury.