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 Inspection Protocol)

Перед выполнением команды git push инженер проверяет:

- [ ] Не удалил ли агент важный код в не связанных частях файла?
- [ ] Обработаны ли крайние случаи (null, undefined, пустой массив, 404)?
- [ ] Отсутствуют ли захардкоженные пароли, секреты и тестовые токены?
- [ ] Нет ли в дифе случайных изменений форматирования в 50 чужих файлах?
- [ ] Соответствуют ли названия новых сущностей принятым стандартам проекта?

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

01. Выявление коварной галлюцинации в финансовом модуле

Агент написал функцию расчета банковской комиссии и уверенно сообщил: "Логику обновлено в соответствии с правилами". Инженер включил дисциплину верификации и написал тест на передачу негативной суммы (amount: -100). Выяснилось, что функция возвращала отрицательную комиссию, что позволило бы злоумышленникам красть деньги с счетов компании. Баг был устранен до релиза.

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

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

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

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

5. Подводные камни, типовые ошибки и безопасность

1. "Diff Blindness" (Слепота просмотра): Когда диф содержит более 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. Работайте по правилу: ноль предупреждений в консоли.