Hard Compiler & Linter Gates(Жорсткі шлюзи компілятора та лінтера)

1. Огляд концепції та системна проблема

ШІ-моделі мають схильність писати код, який візуально виглядає бездоганно, але ламається під час спроби компіляції. Якщо розробник приймає diff без жорсткої автоматичної перевірки:

• У проєкті накопичуються приховані розриви типів (Type Mismatches).
• Імпортуються модулі, які були видалені три місяці тому.
• Порушуються домовленості про чистоту коду (Dead Code, невикористані змінні, суперечливі правила форматування).

Deterministic Linter Gates перетворюють лінтер та компілятор на безжального цензора. Агенту не дозволяється залишати свій код у репозиторії, доки exit_code == 0 не буде підтверджено системою перевірки.

2. Архітектурна таксономія та ментальна модель

┌─────────────────────────────────────────────────────────────┐
│                 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. Практичні інженерні сценарії в продакшені

01. Заборона any та придушення помилок

У конфігурації Biome / ESLint вмикається суворе правило:

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

Якщо агент намагається поставити any для швидкого обходу помилки типізації, шлюз миттєво відхиляє зміну з чіткою вимогою: "Вкажи точний дискримінований союз (discriminated union) замість any".

02. Захист від зламаних шляхів імпорту

Шлюз запускає перевірку резолвінгу модулів. Якщо модель галюцинує і викликає import { helper } from '@/lib/helpers', якого не існує в файловій системі, компілятор відловлює це за 40 мілісекунд, не даючи коду потрапити в комміт.

4. Підводні камені, типові помилки та безпека

• Повільний зворотний зв'язок (Slow Feedback Loop): Якщо перевірка займає 45 секунд, агент буде працювати вкрай повільно. Запускайте перевірку лише змінених файлів (tsc --build або staged-files check) замість повного перекомпілювання всього монорепозиторію.
• Цикл самоїдства: Якщо лінтер вимагає одне форматування, а системний промпт агента інструктує писати інакше, агент і лінтер боротимуться вічно. Налаштування форматування повинні братися виключно з конфігураційних файлів проєкту (biome.json, .prettierrc).

5. Стратегічний висновок для інженера 2026 року

Жорсткі компіляторні шлюзи звільняють людину від ролі "живого компілятора". Коли за чистотою коду надійно стежать автоматичні інструменти з нульовою толерантністю до помилок, вайбкодинг перестає бути ризикованою авантюрою і стає дисциплінованим інженерним процесом.