Dyscyplina weryfikacji wygenerowanego kodu

1. Przegląd koncepcji i problem systemowy

Rozwój narzędzi do autogeneracji kodu stworzył krytyczną przepaść między prostotą tworzenia kodu a jego rzeczywistymi cechami niezawodności. Model może wygenerować 400 linii idealnie sformatowanego kodu z wiarygodnymi nazwami metod, który wygląda profesjonalnie, ale zawodzi w pierwszej sekundzie uruchomienia z powodu wywołania nieistniejącej metody lub niezgodności typów.

Verification Discipline (Dyscyplina Weryfikacji) to główny barier oddzielający zawodowego inżyniera oprogramowania od amatora. Jest to niezachwiane wewnętrzne nastawienie:

• Żadne słowo modelu językowego nie jest przyjmowane na wiarę.
• Każdy wygenerowany kod jest uznawany za potencjalnie uszkodzony, dopóki niezależne, deterministyczne narzędzie (kompilator, linter, runner testów) nie udowodni czegoś przeciwnego.
• Inżynier ponosi osobistą odpowiedzialność zawodową za każdy znak scalony do repozytorium.

Bez dyscypliny weryfikacji projekt osuwa się w stan „kruchej konstrukcji z kart”, gdzie każda nowa funkcja łamie dwie poprzednie, a zespół zużywa wszystkie zasoby na gaszenie nagłych pożarów w środowisku produkcyjnym.

Amatorskie podejście (Ślepe zaufanie):
[LLM: „Wszystko naprawione, kod gotowy!”] ---> [Kliknięcie „Accept All”] ---> [Commit & Push] ---> [Błąd 502 Bad Gateway na produkcji]

Inżynierska dyscyplina weryfikacji (Evidence-First):
[LLM: „Wszystko naprawione!”]
          |
          v
[Krok 1: tsc --noEmit] -----------------> [Błąd typu! Zwrot do agenta w celu dalszych poprawek]
          | (Zielone światło)
          v
[Krok 2: vitest run] -------------------> [Nieudany test! Poprawa logiki]
          | (Zielone światło)
          v
[Krok 3: git diff --cached] ------------> [Wykryto zbędne console.log oraz wygenerowaną bibliotekę]
          | (Czysto)
          v
[Krok 4: Smoke Test w przeglądarce] -----> [Fizyczne kliknięcie w formularz]
          |
          v
[Świadomy Commit na produkcję]

2. Taksonomia architektoniczna i model mentalny

Poziomy zabezpieczeń weryfikacyjnych (Model Ser Szwajcarskiego):

1. Poziom 1: Statyczna analiza składniowa i semantyczna (Compile-time):
   • Ścisły kompilator (tsc --noEmit, rustc, cargo check).
   • Lintery stylu i bezpieczeństwa (ESLint, Biome, ShellCheck).
   • Eliminuje 70% halucynacji dotyczących nieistniejących pól lub metod.
2. Poziom 2: Zautomatyzowane testowanie dynamiczne (Dynamic Verification):
   • Testy jednostkowe: weryfikacja czystych funkcji i przypadków brzegowych.
   • Testy integracyjne: weryfikacja interakcji z realną bazą danych lub cache.
   • Chroni przed błędami logicznymi i regresjami.
3. Poziom 3: Audyt zmian (Diff Hygiene):
   • Ludzka analiza różnic liniowych przez git diff.
   • Cel: wykrycie „szumu”, przypadkowo usuniętych komentarzy oraz naruszeń granic architektonicznych.
4. Poziom 4: Weryfikacja runtime (End-to-End & Observability):
   • Przejście przez realny scenariusz użytkownika przy użyciu Playwright lub ręcznie w przeglądarce/terminalu.
   • Monitorowanie logów po releasie pod kątem skoków błędów 5xx.

3. Pipeline techniczny i mechanika wewnętrzna

Automatyczny hook Git Pre-Commit do weryfikacji (Husky / Lefthook)

Człowiek może zapomnieć o sprawdzeniu kodu z powodu zmęczenia. Aby chronić system przed czynnikiem ludzkim, obwód weryfikacyjny sprzętowo blokuje commit:

# lefthook.yml — надійний та швидкий валідатор
pre-commit:
  parallel: false
  commands:
    typecheck:
      run: npx tsc --noEmit
    lint:
      run: npx @biomejs/biome check --staged --apply
    test:
      run: npx vitest run --passWithNoTests

Jeśli choćby jeden test nie przejdzie lub kompilator wykryje rozbieżność typów, próba zatwierdzenia kodu kończy się awaryjnym zatrzymaniem.

Lista kontrolna ręcznego audytu diff (Diff Inspection Protocol)

Przed wykonaniem komendy git push inżynier sprawdza:

- [ ] Czy agent nie usunął ważnego kodu w niezwiązanych częściach pliku?
- [ ] Czy obsłużono przypadki brzegowe (null, undefined, pusta tablica, 404)?
- [ ] Czy brak jest zaszytych haseł, sekretów i tokenów testowych?
- [ ] Czy w diffie nie ma losowych zmian formatowania w 50 obcych plikach?
- [ ] Czy nazwy nowych encji są zgodne ze standardami przyjętymi w projekcie?

4. Praktyczne scenariusze inżynierskie w produkcji

01. Wykrycie podstępnej halucynacji w module finansowym

Agent napisał funkcję obliczającą prowizję bankową i pewnie oznajmił: „Logika została zaktualizowana zgodnie z zasadami”. Inżynier zastosował dyscyplinę weryfikacji i napisał test dla przekazania wartości ujemnej (amount: -100). Okazało się, że funkcja zwracała ujemną prowizję, co pozwoliłoby przestępcom kraść pieniądze z kont firmowych. Błąd został usunięty przed releasem.

02. Ochrona przed cichym usunięciem komentarzy w systemie legacy

Podczas refaktoryzacji moduł zawierał ważny komentarz: // CRITICAL: do not reorder this call due to Safari bug #19284. Model uznał komentarz za zbędny i go usunął, zmieniając kolejność wywołań. Dzięki uważnej analizie git diff architekt zauważył usunięcie, zachował ochronny workaround i dodał regresyjny test E2E.

03. Pełne odtworzenie błędu w testach przed jego naprawą (Bug Repro First)

Przy zgłoszeniu awarii zdyscyplinowany inżynier zabrania agentowi dotykania kodu produkcyjnego. Najpierw pisany jest test, który dokładnie odtwarza błąd i failuje z czerwonym komunikatem (Red Phase). Dopiero po zagwarantowaniu, że błąd jest złapany przez test, agent wprowadza zmiany, aż test stanie się zielony (Green Phase).

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

1. „Diff Blindness” (Ślepota przeglądania): Gdy diff zawiera ponad 800 linii, oczy męczą się i po 2 minutach scrollowania inżynier po prostu klika „Approve”. Jeśli PR jest zbyt duży – nigdy nie zatwierdzaj go w całości. Wymagaj rozbicia zadania na atomowe części liczące maksymalnie 200 linii każda.
2. Moki, które zawsze przechodzą (Tautological Tests): Agenci często generują testy sprawdzające własne moki: mockService.get.mockReturnValue(true); expect(mockService.get()).toBe(true). Taki test zawsze jest zielony, ale nie testuje ani jednej linii realnego kodu. Zawsze sprawdzaj semantykę asercji w wygenerowanych testach.
3. Ignorowanie ostrzeżeń kompilatora (Compiler Warnings): Nawyk ignorowania żółtych ostrzeżeń lintera lub niejawne rzutowanie typów przez as unknown as Type całkowicie niszczy system bezpieczeństwa TypeScript. Pracuj według zasady: zero ostrzeżeń w konsoli.