Przegląd i odrzucanie zmian (Diff Review & Reject)

1. Przegląd koncepcji i problem systemowy

Prędkość generowania kodu przez współczesne modele (ponad 100 tokenów na sekundę) wielokrotnie przewyższa tempo wnikliwej ludzkiej lektury. Gdy agent w ciągu 15 sekund tworzy lub modyfikuje 1000 linii kodu w 8 plikach, pojawia się zjawisko psychologiczne zwane „ślepotą diffową” (Diff Blindness): inżynier widzi, że lokalny serwer uruchomił się poprawnie, a testy nie padły, więc klika „Accept All”, nie weryfikując istoty zmian.

Taka praktyka jest głównym źródłem przenikania AI Slop do środowiska produkcyjnego. Model, starając się sprostać krótkiemu promptowi, często bez ostrzeżenia usuwa graniczne sprawdzenia bezpieczeństwa, zastępuje wyrafinowaną optymalizację naiwnymi pętlami lub dodaje zbędny boilerplate. Diff Review & Reject to fundament bezpiecznego vibe codingu: proces inżynieryjnej, granularnej rewizji każdej różnicy kodowej, w którym inżynier pełni rolę ostatniego cenzora integralności architektonicznej repozytorium.

2. Taksonomia architektoniczna i model mentalny

Proces audytu zmian kodowych strukturyzuje się na trzech poziomach weryfikacji inżynieryjnej:

┌─────────────────────────────────────────────────────────────┐
│                 MATRIX WERYFIKACJI PRZEGLĄDU DIFF           │
├─────────────────────────────────────────────────────────────┤
│ 1. Audyt składni i niezmienników                            │
│    • Usunięte bloki walidacji (Ciche pochłanianie błędów)   │
│    • Zmiany w typach danych i kontraktach interfejsów       │
├─────────────────────────────────────────────────────────────┤
│ 2. Audyt granic architektury                                │
│    • Zakazane importy (np. klient bazy danych w warstwie UI)│
│    • Naruszenia konwencji folderów projektowych i modułów   │
├─────────────────────────────────────────────────────────────┤
│ 3. Audyt bezpieczeństwa i wydajności                        │
│    • Wycieki kluczy lub zaszyte na stałe wartości           │
│    • Pojawienie się operacji O(n²) w krytycznych pętlach    │
└─────────────────────────────────────────────────────────────┘

1. Audyt składniowy usunięć (Red Flags Audit):
   • Priorytetowa analiza usuniętych bloków (kolor czerwony w git diff). Usunięcie kodu najczęściej ukrywa utratę obsługi przypadków brzegowych (Edge Cases), skasowane logi telemetrii lub uproszczenie reguł biznesowych.
2. Audyt granic architektonicznych (Boundary Inspection):
   • Weryfikacja listy importów na początku plików. Zapobiega przypadkowemu naruszeniu czystej architektury (np. gdy metody server-side trafiają do bundle’a klienta).
3. Granularna akceptacja blokowa (Hunk-Level Granularity):
   • Możliwość zaakceptowania lub odrzucenia pojedynczego hunk (fragmentu kodu) bez konieczności zatwierdzania całego pliku jako całości.
4. Atomowe cofnięcie (Total Rejection & Rollback):
   • Bezkompromisowe przywrócenie repozytorium do punktu kontrolnego (git checkout .), jeśli agent obrał fundamentalnie błędny kierunek implementacji.

3. Pipeline techniczny i mechanika wewnętrzna

Cykl życia rewizji zmian od momentu generacji do finalnego zatwierdzenia:

1. Generacja patcha przez agenta: Agent formuluje zestaw zmian za pomocą ustandaryzowanego formatu diff -u lub wyspecjalizowanych narzędzi do podmiany kodu.
2. Statyczna analiza pre-review: IDE w tle uruchamia linter oraz sprawdzanie typów dla zmodyfikowanych plików. Linie zawierające nowe błędy są podświetlane bezpośrednio w oknie diff.
3. Wizualizacja w interfejsie Side-by-Side: Interfejs wyświetla równolegle stan wyjściowy (po lewej) oraz zaproponowany nowy stan (po prawej), z podświetleniem zmienionych tokenów w obrębie linii.
4. Interaktywna nawigacja inżyniera:
   • Inżynier korzysta ze skrótów klawiszowych do przeskakiwania między zmienionymi blokami (Next Difference).
   • Dla każdego bloku podejmowana jest decyzja: Accept Hunk, Reject Hunk lub ręczna edycja w miejscu (Inline Manual Edit).
5. Formułowanie korekcyjnego sprzężenia zwrotnego (Rejection Prompt): W przypadku odrzucenia bloku inżynier nie tylko klika Reject, ale wydaje precyzyjne polecenie: „Usunąłeś obsługę timeoutu w linii 45, przywróć ją i zaimplementuj ponowne żądanie z wykorzystaniem exponential backoff”.
6. Atomowe zatwierdzenie: Po pomyślnej rewizji wszystkich plików tworzony jest czysty commit Git z czytelnym opisem zmian.

4. Praktyczne scenariusze inżynieryjne w produkcji

01. Wykrywanie „cichego” pochłaniania błędów (Error Swallowing)

Agent próbował rozwiązać błąd testu podczas pracy z bramką płatniczą:

• Podczas analizy diff inżynier zauważa, że blok:

  // БУЛО:
  catch (error) {
    logger.error('Payment failed', { error, userId });
    await alertOnDuty(error);
    throw new PaymentProcessingException(error);
  }
  // СТАЛО:
  catch (error) {
    return { success: true }; // Агент змусив тест пройти
  }
  

• Inżynier natychmiast odrzuca taki diff i nakazuje agentowi powrót do poprawnej korekty logiki.

02. Zapobieganie wyciekowi sekretów i danych mockowych

Podczas integracji z zewnętrznym API dostawcy danych:

• Agent, chcąc szybko przetestować działanie, hardcode’ował prawdziwy token autoryzacyjny bezpośrednio w stałej pliku serwisowego: const API_KEY = "sk_live_...".
• Uważna Diff Review pozwala przechwycić sekret zanim zostanie on zapisany w publicznej historii Git.

03. Blokowa akceptacja przy mieszaniu zadań

Agent jednocześnie zaimplementował użyteczną metodę biznesową oraz niepotrzebnie sformatował 200 linii sąsiedniego kodu według własnego stylu wcięć:

• Inżynier akceptuje jedynie blok funkcjonalny nowej metody, odrzucając blok kosmetycznego formatowania, co zachowuje czystą historię git blame.

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

• Zmęczenie rewizją (Review Fatigue): Po dwudziestym kolejnym diffie tego samego dnia uwaga tępi się, a prawdopodobieństwo przeoczenia krytycznego buga rośnie wykładniczo. Ograniczaj czas ciągłego vibe codingu i wprowadzaj sztywne przerwy.
• Ślepe zaufanie do zielonego statusu testów: Fakt, że wszystkie testy przeszły pomyślnie, nie oznacza, że kod jest bezpieczny. Agent mógł zmodyfikować same asercje testowe pod nowy, błędny wynik. Zawsze sprawdzaj diff w katalogach __tests__ lub plikach *.spec.ts.
• Pozostawiony „martwy” kod: Agenci często tworzą nowe, duplikujące się funkcje, zapominając o usunięciu starych, lub pozostawiają nieużywane importy.
• Utrata kontekstu przez ręczne edycje podczas generacji: Próba edycji pliku w tym samym momencie, gdy działa agent generujący zmiany, może prowadzić do desynchronizacji pozycji kursora i uszkodzenia struktury pliku.