Почему ИИ-агенту нельзя доверять проверку собственной работы: рапорт о -9 500 строках при росте на +21 489

• Расхождение рапорта и git diff: заявлено «сокращение на ~9 500 строк», по факту в коммите 206 файлов и чистый рост на +21 489 строк (+34 934 / -13 445)
• Точность фактчека книги роем: проверено ~150 фактов по 20 главам (69 293 слова), поймано 13 скрытых искажений статистики и дат
• Воронка сжатия мета-кейсбука: 11,67 ГБ сырых JSONL-сессий ужаты в 160 раз до 73,8 МБ дайджестов (147 батчей, 860 уникальных карточек)
• Оптимальная ширина параллельной волны: 8–14 субагентов одновременно (при запуске 44 воркеров волна полностью ложится на лимиты провайдера)

Когда проект обрастает «божественными объектами» (`God objects`) — вся база в одном файле, весь бот во втором, — ручной рефакторинг занимает недели. Я бросил на такую кодовую базу рой из 25 субагентов в четыре фазы: закрытие дыр безопасности, реанимация контейнеров, распил монолитов и перенос фич. Через полтора дня оркестратор выдал блестящий отчёт: `database.py` на 1 004 строки разложен на 15 файлов моделей, `report_bot.py` на 1 759 строк — на 11 модулей, написано «185+ тестов», а в коммит-месседже красовалась строка `Net reduction: ~9500 lines of code`.

Полгода спустя я решил проверить каждую цифру этого рапорта командами `git`. Выяснилось, что структурная работа выполнена безупречно, а почти все числа в отчёте живут в параллельной реальности.

Почему структурные утверждения роя сходятся до файла, а цифры строк и

часов врут?

Команда `git show --shortstat` по коммиту рефакторинга показала: 206 изменённых файлов, 34 934 вставки и 13 445 удалений — чистый рост дерева на +21 489 строк там, где агент заявил сокращение на 9 500 строк. Исходные размеры файлов тоже отличались от заявленных (`883`, `1 696` и `650` строк вместо `1 004`, `1 759` и `904`), а тестовых функций `test_*` в диффе оказалось 164, а не 185+.

При этом все структурные заявления сошлись до файла: в пакете моделей появилось ровно 15 модулей, а старый `database.py` превратился в 8-строчную обёртку обратной совместимости (`from .models import *`). Второй независимый проход роя позже нашёл и распилил ещё 9 файлов длиннее 1 000 строк, которых не было в первом списке (сегодня из 313 файлов на 98 264 строки остался лишь один модуль на 1 013 строк).

Искажение чисел возникает по трём причинам: потеря контекста при рестартах сессии, отчёт о намерении до проверки вывода инструмента и двойной счёт при агрегации. Когда при сборке кейсбука по 860 сессиям скрипт просуммировал поле `time_saved` по карточкам одного проекта (где каждая сессия оценивала экономию за весь проект в «40 часов»), получилась комическая цифра 44 683 сэкономленных часа. Любые числовые агрегаты за роем нужно пересчитывать только скриптом по первичным строкам.

Как устроен конвейер из read-only аудиторов и зачем сжимать логи

сессий в 160 раз?

Чтобы исполнитель не проверял сам себя, мы разделили роли: сначала идут 5 параллельных read-only аудиторов (безопасность, баги, качество, мёртвый код, дубли) с физически отключёнными инструментами записи и обязательным контрактом `modifications_made: false` в YAML-шапке, а следом — 3 чинильщика по их отчётам с точными номерами строк и сценариями воспроизведения (вроде гонки `row_factory` на общем соединении SQLite).

Та же схема независимой верификации на рукописи книги из 20 глав (69 293 слова) проверила 150 утверждений и поймала 13 галлюцинаций (перевёрнутую цитату «91% довольны» в «90% недовольны», названную покупкой лицензионную сделку на $2,4 млрд и прогноз рынка 2032 года в $37 млрд вместо текущих $4 млрд). А чтобы прогнать роем архив из 11,67 ГБ сырых JSONL-логов сессий, мы написали препроцессор дайджестов:

```python SKIP_TOOLS = { "Read", "Glob", "Grep", "LS", "TodoWrite", "ToolSearch", "NotebookRead", "BashOutput", "KillShell", "Monitor", "TaskOutput" }

# Оставляем только мутации (Write/Edit), команды Bash и спавн субагентов,

# а вывод инструментов обрезаем потолком TOOLRES_CAP = 250 символов. ```

Это сжало корпус в 160 раз — с 11,67 ГБ до 73,8 МБ (147 батчей по `MAXKB=900`, `MAXN=6`), позволив пайплайну со стабильными ID батчей пережить три падения по лимитам и собрать 860 карточек.

Почему сам верификатор тоже может ошибаться на свежих API и больших волнах?

Агент-верификатор — такой же вероятностный механизм и умеет ошибаться в обе стороны. При реализации 173 методов крупного Bot API (рост покрытия CLI с 19 до 163 команд, справочник на 2 977 строк) верификаторы сверяли каждый метод по 4–5 открытым SDK. Наткнувшись на свежую реальную фичу, которой ещё не было в старых библиотеках, рой единогласно объявил её «галлюцинацией разведчика» — доказывать правоту пришлось автотестами свежего форка. Попутно выяснился предел параллелизма: запуск 44 верификаторов разом положил всю волну по лимитам, тогда как пачки по 8–14 агентов идут без потерь.

Оркестратор роёв с независимой приёмкой и разделением аудиторов встроен в [Nomad AI](https://nomadnet.ai) и облачный сервис [agent.nomadnet.ai](https://agent.nomadnet.ai). Научиться управлять мультиагентными роями можно в [Hamidun Academy](https://academy.hamidun.com) (72-часовой триал), а скрипты сжатия логов и промпты ревьюеров доступны в [Vibe Club](https://hamidun.com/club).