Усталость от Проверки и Слепое Утверждение

1. Обзор концепции и системная проблема

В классической разработке проверка кода (Code Review) была социальным процессом диалога между двумя людьми: изменения были локальными, авторы понимали бизнес-контекст, а рецензент концентрировался на улучшении архитектуры и стиля.

В 2026 году баланс сместился. Генеративные модели и агенты способны создавать изменения размером в сотни строк за считанные секунды. Если ранее лимитирующим фактором было написание кода, то сейчас узким горлышком стал человеческий аудит. Когда инженер вынужден просматривать седьмой подряд гигантский дифф за день, его критическое мышление отключается. Наступает Verification Fatigue (Усталость от Проверки).

Опасным последствием этого состояния является Rubber-Stamping — формальное, слепое утверждение пул-реквестов. Инженер смотрит на красивый синтаксис, зеленый статус CI/CD, видит знакомые названия функций и бессознательно убеждает себя: «Нейросеть, вероятно, знает, что делает». В результате в продакшен попадают тонкие уязвимости, непроверенные права доступа и логические галлюцинации, которые не покрыты тривиальными юнит-тестами.

ЭВОЛЮЦИЯ СТАДИЙ УСТАЛОСТИ ОТ ПРОВЕРКИ:
PR 1-2 (Утро):   [ Скрупулезный анализ каждой строки, поиск крайних условий ]
PR 3-5 (Обед):    [ Просмотр только сигнатур функций и тестов ]
PR 6-8 (Вечер):   [ Быстрый скролл, проверка статуса CI/CD -> Approve ]
PR 9+  (Ночь):     [ Слепое слияние: "Rubber Stamp" -> Авария в продакшене ]

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

Классификация уровней истощения рецензента:

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

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

01. Пропуск дыры в авторизации через усталость от большого диффа

Агент выполнял задачу «Рефакторинг роутов пользователя под новый стандарт API». Дифф составил 1400 строк кода в 28 файлах. Инженер проверял его после 7 часов непрерывной работы. В одном из эндпоинтов /api/v2/admin/billing/override агент во время унификации микро-паттернов случайно заменил декоратор @RequireRole('superadmin') на @RequireAuth(), что позволило любому зарегистрированному клиенту списывать долги. Рецензент устал на 15-м файле и не заметил разницы между двумя похожими названиями декораторов.

02. Внедрение автоматического лимита Diff Budget

Команда вводит инженерное правило в CI пайплайн GitHub Actions, чтобы предотвратить резистентность к усталости:

# .github/workflows/review-guard.yml
name: "Agent PR Budget Guard"
on: [pull_request]

jobs:
  check-diff-size:
    runs-on: ubuntu-latest
    steps:
      - name: Enforce Maximum Review Budget
        run: |
          CHANGES=$(git diff --shortstat origin/main | awk '{print $4+$6}')
          if [ "$CHANGES" -gt 250 ]; then
            echo "::error::PR size ($CHANGES lines) exceeds cognitive threshold (250 lines). Split the agent task!"
            exit 1
          fi

Если агент пытается отправить монолитный патч, пайплайн блокирует его еще до того, как человек потратит секунду своего внимания.

03. Внедрение системы ротации рецензентов

Для борьбы с усталостью от проверки команда внедряет систему ротации рецензентов, чтобы каждый инженер проверял код не более чем 2-3 раза в неделю. Это позволяет снизить нагрузку и повысить качество рецензирования.

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

1. Иллюзия безопасности от автотестов: Модели умеют писать тесты, которые тестируют собственные галлюцинации (тесты-пустышки с expect(true).toBe(true) или ложными моками). Доверие к зеленому CI без аудита тела теста фатально.
2. Перекладывание аудита на другую модель без правил: Использование второго ИИ для ревью первого часто создает «эффект заговора» (mutual reinforcement), когда обе модели соглашаются на некорректный паттерн.
3. Психологическое чувство вины: Инженер наказывает себя за медлительность, когда коллеги или агенты штампуют код быстрее, и начинает утверждать PR без размышлений, чтобы «не тормозить команду».

Стратегический вывод для инженера 2026 года

Проверка кода стала главным рубежом обороны современного программного обеспечения. Скорость генерации больше не является показателем успеха — настоящую ценность определяет глубина верификации.

Если вы чувствуете, что скроллите пул-реквест без понимания каждой строки, остановитесь. Уменьшайте размер агентских задач, требуйте математически точных контрактов и помните: одно необдуманное нажатие кнопки «Approve» может перечеркнуть недели работы всей инфраструктуры.