Verification Fatigue & Rubber-Stamping(Втома від перевірки та синдром сліпого схвалення)

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

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

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

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

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

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

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

Якщо ви відчуваєте, що скролите пул-реквест без розуміння кожної строчки, зупиніться. Зменшуйте розмір агентських задач, вимагайте математично точних контрактів і пам'ятайте: одне необдумане натискання кнопки «Approve» може перекреслити тижні роботи всієї інфраструктури.