EnglishРусский Map

Code review как проблема принципала и агента

title
Code review как проблема принципала и агента
type
concept
summary
Почему review-then-commit опирался на оценку усилий автора по diff'у, как агенты ломают этот сигнал и что это меняет для процессов ревью
tags
software-engineering, code-review, agentic-coding
created
2026-05-10
updated
2026-05-10
lang
ru
source_updated
2026-05-10
translated
2026-09-01
translator
lllm/antigravity/gemini-3.7-flash-medium

Code review (в парадигме review-then-commit - Apache 1990-х, Google 2000-х, GitHub PR 2010-х) - это механизм совместной работы с низким уровнем доверия: автор предлагает изменение, ревьюер ставит LGTM, изменение попадает в кодовую базу. Он работает в командах больше "двух пицц" и в open source по одной причине: ревьюер может дёшево оценить затраченные автором усилия, просто изучив diff. Diff служит свидетельством.

Когда автором становится агент, запущенный человеком с помощью пары предложений, этот сигнал рушится. Ревьюер больше не может понять:

  • Понимал ли автор ограничения
  • Рассматривал ли альтернативы
  • Проверял ли граничные случаи
  • Потратил он тридцать секунд или три дня

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

Очевидные проявления проблемы:

  • Поток мусорных PR'ов в OSS - агенты генерируют правдоподобные PR'ы при нулевых затратах со стороны автора; мейнтейнеры выгорают, пытаясь на них отвечать
  • Очереди на внутреннее ревью - компании с обязательным code review не могут получить прирост продуктивности от агентов, поскольку пропускная способность ревьюеров становится главным узким местом
  • Ревьюер в роли промптера - ревьюеры понимают, что быстрее заново дать промпт агенту самому, чем вычитывать результат чужого запуска

Процессные ответы, которые систематизирует crawshaw-agent-principal-agent:

  1. Небольшая команда с высоким уровнем доверия без второго ревьюера - человек пишет промпт агенту + человек проверяет + человек развёртывает. Работает, потому что принципал и есть агент. Требует вложений в инфраструктуру интеграционных, e2e- и запускаемых агентами тестов.
  2. Модель Microsoft до 2005 года - независимые команды, синхронизация через QA, никакого обязательного review-before-commit. Работала в больших масштабах, но крупные корпорации с низким доверием к ней не вернутся.
  3. Перестройка OSS - замена "пришли PR" на "пришли промпт + цикл обратной связи"; см. вариант Ciężarkiewicz'а в i-dont-want-your-prs.

Нерешённой остаётся проблема крупных компаний с низким уровнем доверия. Пока нет известного процесса, способного убрать ревью из позиции узкого горлышка в таких условиях; потолок пропускной способности ревьюеров + двойная проверка = агенты почти не дают чистого прироста продуктивности. Это часть тезиса no-silver-bullet-llms, рассмотренная под другим углом.

Рядом: contributor-poker (фреймворк Cro: ставить на автора, а не на содержимое PR'а - тоже ответ на обесценивание сигнала о затраченных усилиях), skill-atrophy-supervision-paradox (проблема со стороны проверяющего).