Verification Discipline (Дисципліна верифікації згенерованого коду)(Дисципліна верифікації згенерованого коду)

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

З розвитком інструментів автогенерації виник критичний розрив між простотою створення коду та його реальними якостями надійності. Модель може згенерувати 400 рядків бездоганно відформатованого коду з правдоподібними назвами методів, який виглядає авторитетно, але падає в першу секунду запуску через виклик неіснуючого методу або невідповідність типів.

Verification Discipline (Дисципліна верифікації) — це головний демаркаційний бар'єр між професійним програмним інженером та аматором. Це непохитна внутрішня установка:

• Жодне слово мовної моделі не сприймається на віру.
• Будь-який згенерований код вважається потенційно зламаним, доки зворотне не доведено незалежним детермінованим інструментом (компілятором, лінтером, тестовим раннером).
• Інженер несе персональну професійну відповідальність за кожен символ, замерджений у репозиторій.

Без дисципліни верифікації проект скочується у стан "крихкого карточного будинку", де кожна нова фіча ламає дві попередні, а команда витрачає всі сили на гасіння раптових пожеж у продакшені.

Аматорський підхід (Сліпа довіра):
[LLM: "Я все виправив, код готовий!"] ---> [Клік "Accept All"] ---> [Commit & Push] ---> [502 Bad Gateway в продакшені]

Інженерна дисципліна верифікації (Evidence-First):
[LLM: "Я все виправив!"]
          |
          v
[Крок 1: tsc --noEmit] -----------------> [Помилка типу! Повернення агенту на доопрацювання]
          | (Зелено)
          v
[Крок 2: vitest run] -------------------> [Падіння тесту! Виправлення логіки]
          | (Зелено)
          v
[Крок 3: git diff --cached] ------------> [Виявлено зайвий console.log та галюциновану бібліотеку]
          | (Чисто)
          v
[Крок 4: Smoke Test у браузері] --------> [Фізичний клік по формі]
          |
          v
[Свідомий Production Commit]

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

Рівні захисних бар'єрів верифікації (The Swiss Cheese Model):

1. Рівень 1: Статичний синтаксичний та семантичний аналіз (Compile-time):
   • Строгий компілятор (tsc --noEmit, rustc, cargo check).
   • Лінтери стилю та безпеки (ESLint, Biome, ShellCheck).
   • Відсікає 70% галюцинацій щодо неіснуючих полів або методів.
2. Рівень 2: Автоматизоване динамічне тестування (Dynamic Verification):
   • Unit-тести: перевірка чистих функцій та граничних випадків.
   • Integration-тести: перевірка взаємодії з реальною базою даних або кешем.
   • Захищає від логічних помилок та регресій.
3. Рівень 3: Аудит змін (Diff Hygiene):
   • Людське читання різниці рядків через git diff.
   • Мета: виявити "шлак", випадково видалені коментарі, порушення архітектурних кордонів.
4. Рівень 4: Рантайм-верифікація (End-to-End & Observability):
   • Проходження реального користувацького сценарію через Playwright або вручну в браузері/терміналі.
   • Моніторинг логів після релізу на наявність сплесків 5xx помилок.

3. Технічний пайплайн та внутрішня механіка

Автоматичний Git Pre-Commit хук верифікації (Husky / Lefthook)

Людина може забути перевірити код через втому. Щоб захистити систему від людського фактора, контур верифікації апаратно блокує комміт:

# 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

Якщо хоча б один тест не проходить або компілятор бачить розбіжність типів, спроба закоммітити код завершується аварійною зупинкою.

Чекліст ручного аудиту diff (Diff Inspection Protocol)

Перед виконанням команди git push інженер перевіряє:

- [ ] Чи не видалив агент важливий код у непов'язаних частинах файлу?
- [ ] Чи оброблені крайні випадки (null, undefined, порожній масив, 404)?
- [ ] Чи відсутні захардкоджені паролі, секрети та тестові токени?
- [ ] Чи немає в diff випадкових змін форматування у 50 чужих файлах?
- [ ] Чи відповідають назви нових сутностей прийнятим стандартам проекту?

4. Практичні інженерні сценарії в продакшені

01. Виявлення підступної галюцинації у фінансовому модулі

Агент написав функцію розрахунку банківської комісії і впевнено повідомив: "Логіку оновлено відповідно до правил". Інженер увімкнув дисципліну верифікації і написав тест на передачу негативної суми (amount: -100). З'ясувалося, що функція повертала від'ємну комісію, що дозволило б зловмисникам красти гроші з рахунків компанії. Баг було усунуто до релізу.

02. Захист від тихого видалення коментарів у legacy-системі

Під час рефакторингу модуль містив важливий коментар: // CRITICAL: do not reorder this call due to Safari bug #19284. Модель вирішила, що коментар зайвий, і видалила його, змінивши послідовність викликів. Завдяки уважному перегляду git diff архітектор помітив видалення, зберіг захисний воркараунд і додав регресійний E2E-тест.

03. Повне тестове відтворення багу перед його виправленням (Bug Repro First)

При надходженні повідомлення про збій дисциплінований інженер забороняє агенту чіпати продакшен-код. Спочатку пишеться тест, який точно відтворює баг і падає з червоною помилкою (Red Phase). Лише після того, як баг гарантовано спіймано тестом, агент вносить зміни, доки тест не стане зеленим (Green Phase).

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

1. "Diff Blindness" (Сліпота перегляду): Коли diff містить понад 800 рядків, очі втомлюються, і після 2 хвилин скролінгу інженер просто натискає "Approve". Якщо PR занадто великий — ніколи не підтверджуйте його цілком. Вимагайте розбити задачу на атомарні частини до 200 рядків кожна.
2. Моки, що завжди проходять (Tautological Tests): Агенти часто генерують тести, які тестують власні моки: mockService.get.mockReturnValue(true); expect(mockService.get()).toBe(true). Такий тест завжди зелений, але не тестує жодного рядка реального коду. Завжди перевіряйте семантику assertion у згенерованих тестах.
3. Ігнорування попереджень компілятора (Compiler Warnings): Звичка ігнорувати жовті попередження лінтера або неявно приводити типи через as unknown as Type повністю руйнує систему безпеки TypeScript. Працюйте за правилом: нуль попереджень у консолі.