Sztywne bramki kompilatora i lintera

1. Przegląd koncepcji i problem systemowy

Modele AI mają tendencję do generowania kodu, który wizualnie wygląda bezbłędnie, ale zawodzi podczas próby kompilacji. Jeśli programista akceptuje diff bez rygorystycznej automatycznej weryfikacji:

• W projekcie kumulują się ukryte niezgodności typów (Type Mismatches).
• Importowane są moduły usunięte trzy miesiące temu.
• Naruszane są ustalenia dotyczące czystości kodu (Dead Code, nieużywane zmienne, sprzeczne reguły formatowania).

Deterministic Linter Gates przekształcają linter i kompilator w bezwzględnego cenzora. Agentowi nie zezwala się na pozostawienie kodu w repozytorium, dopóki system weryfikacyjny nie potwierdzi exit_code == 0.

2. Taksonomia architektoniczna i model mentalny

┌─────────────────────────────────────────────────────────────┐
│                 DETERMINISTIC GATE PIPELINE                 │
├─────────────────────────────────────────────────────────────┤
│ AGENT PROPOSES PATCH                                        │
│   • Writes code directly or via unified diff                │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ TRIGGER HARNESS                  │
│   1. Format & Lint: `biome check --write`                   │
│   2. Strict Types: `tsc --noEmit --strict`                  │
│   3. Security Audit: `pnpm audit --audit-level=high`        │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                 ┌────────┴────────┐                         │
│                 ▼                 ▼                         │
│           [ EXIT CODE 0 ]   [ EXIT CODE != 0 ]              │
│                 │                 │                         │
│                 ▼                 ▼                         │
│          COMMIT & PROCEED   AUTOMATIC GIT ROLLBACK          │
│                             & FEED ERROR BACK TO AGENT      │
└─────────────────────────────────────────────────────────────┘

3. Praktyczne scenariusze inżynieryjne w środowisku produkcyjnym

01. Zakaz stosowania any i tłumienia błędów

W konfiguracji Biome / ESLint włączana jest surowa reguła:

{
  "rules": {
    "suspicious": { "noExplicitAny": "error" },
    "correctness": { "noUnusedVariables": "error" }
  }
}

Jeśli agent próbuje użyć any jako szybkiego obejścia błędu typowania, bramka natychmiast odrzuca zmianę z jasnym wymaganiem: "Podaj dokładną dyskryminowaną unię (discriminated union) zamiast any".

02. Ochrona przed uszkodzonymi ścieżkami importu

Bramka uruchamia weryfikację rozwiązywania modułów. Jeśli model halucynuje i wywołuje import { helper } from '@/lib/helpers', którego nie ma w systemie plików, kompilator wykrywa to w 40 milisekund, uniemożliwiając trafienie kodu do commitu.

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

• Powolna pętla zwrotna (Slow Feedback Loop): Jeśli weryfikacja zajmuje 45 sekund, agent będzie działał skrajnie wolno. Uruchamiaj sprawdzenie tylko dla zmienionych plików (tsc --build lub staged-files check) zamiast pełnej rekompilacji całego monorepozytorium.
• Pętla samobójcza: Jeśli linter wymaga jednego stylu formatowania, a prompt systemowy agenta instruuje go do pisania inaczej, agent i linter będą ze sobą walczyć w nieskończoność. Ustawienia formatowania muszą być pobierane wyłącznie z plików konfiguracyjnych projektu (biome.json, .prettierrc).

5. Strategiczny wniosek dla inżyniera roku 2026

Sztywne bramki kompilacyjne uwalniają człowieka od roli „żywego kompilatora”. Gdy za czystość kodu odpowiadają niezawodne narzędzia automatyczne o zerowej tolerancji na błędy, vibe coding przestaje być ryzykowną awanturą, a staje się zdyscyplinowanym procesem inżynieryjnym.