Проблема "принципал - агент" и ИИ-агенты

Дэвид Крошоу (David Crawshaw, сооснователь exe.dev, ранее в Tailscale и Google) утверждает, что стандартный процесс код-ревью "сначала проверка, потом коммит" - зародившийся в Apache, ставший корпоративным стандартом в Google и популяризированный через GitHub PR - был несущей конструкцией для совместной работы в условиях низкого доверия, и агенты его сломали.

Исходный процесс работал, потому что ревьюер мог с минимальными затратами оценить вложенные усилия, просто глядя на предложенный код. Время, потраченное на обдумывание задачи, видно в diff'е. Именно этот сигнал делал оправданным требование к ревьюеру потратить серьёзные усилия на ответ. Агенты полностью уничтожают этот сигнал. "Контрибьютор", написавший промпт на пару предложений уровня баг-репорта и пять минут потыкавший результат, может сгенерировать внушительный PR, на разбор которого у ревьюера уйдут часы.

Это хрестоматийная проблема "принципал - агент": ревьюер (принципал) не видит реальных усилий автора изменений (агента), но вся цена нерационально потраченных усилий ложится именно на ревьюера. В OSS это выливается в "slop PRs" (мусорные PR'ы). В компаниях это приводит к очередям на ревью, где ревьюеру было бы продуктивнее самому написать промпт агенту.

Наивное решение - встроить агентов в существующий процесс по принципу "человек проверяет вывод агента, а затем отправляет его на ревью" - удваивает общий объём ревью при одновременном росте объёма изменений. Математика не сходится. Пропускная способность ревьюеров была узким местом ещё до появления агентов.

Что действительно работает, по опыту Крошоу в exe.dev (команда из девяти человек):

Человек даёт машине указание внести изменение.
Человек проверяет результат и итерирует с комментариями, пока не одобрит его.
Изменение отправляется в продакшен и развёртывается.

Сторонний ревьюер из команды исключён из цепочки. Человек, управляющий агентом, сам отвечает за развёртывание. Конфликт "принципал - агент" исчезает, поскольку принципал и есть агент. Чтобы компенсировать отсутствие ревью, они активно вкладываются в интеграционные тесты, e2e-тесты и анализ безопасности, производительности и удобства силами агентов - инфраструктуру, которая обычно появляется только на гораздо более крупных масштабах, но с агентами строится значительно дешевле.

Почему это не приживётся в BigCo:

Нужно доверять коллегам в том, что они начнут обсуждение архитектуры до того, как вносить масштабные изменения
В BigCo этому никто не доверяет
И никто в BigCo не хочет развёртывать код без код-ревью, позволяющего "размазать ответственность"

Исторический пример Крошоу - Microsoft 1990-х годов: крупная компания, но организованная как множество независимых команд с синхронизацией через QA, а не через обязательное ревью перед коммитом. "Ковбойский" подход по меркам Google после 2005 года, но именно он создал Win32 и массу долгоживущего софта. Крошоу отмечает, что об этом периоде написано мало, и просит свидетельств от непосредственных участников.

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

Связи: skill-atrophy-supervision-paradox рассматривает ту же проблему со стороны проверяющего; i-dont-want-your-prs - переосмысление для OSS (замена PR'ов промптами); no-silver-bullet-llms - скепсис относительно роста продуктивности; agentic-coding-fatigue - сторона человеческих издержек.

Продолжение от той же компании: claude-is-not-a-compiler (Josh Bleecher Snyder, июль 2026 года) - практический пример механизмов, которые Крошоу описывает здесь на концептуальном уровне. Заметка показывает, как принцип "человек, управляющий агентом, сам отвечает за результат" выглядит на реальной рабочей системе: распределённом DNS-сервере, созданном параллельными циклами агентов и проверенном через differential-spec-analysis и развёртывание в теневом режиме (shadow-mode) вместо ревью, где долговечным артефактом остаётся документ с инструкциями и набитыми шишками. Шаг 2 ("проверяет и итерирует, пока не одобрит") на практике, как выясняется, вовсе не означает чтение кода.

slicer-agents-guess-code отвечает на этот кризис инструментами вместо структуры команды: построить граф влияния, отметить, какие рёбра доказаны, а какие лишь предполагаются, и выдать ревьюеру автоматически проверенную зону поражения (blast radius), вместо того чтобы заставлять его гадать по diff'у, сколько мысли было вложено в код.

Перекрёстные ссылки: crawshaw-blog, exe-dev-blog, claude-is-not-a-compiler, vibe-engineering, skill-atrophy-supervision-paradox, i-dont-want-your-prs, agentic-coding-fatigue, no-silver-bullet-llms, contributor-poker.