Почему ревью становится дороже после внедрения coding agents

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

Фаундер видит движение. CTO ожидает меньше ручной работы. Тимлид надеется, что очередь задач наконец начнет сокращаться.

Но через пару недель может проявиться другая картина: код пишется быстрее, а ревью становится тяжелее. Не потому что ревьюеры сопротивляются AI. А потому что стоимость работы переехала из написания кода в проверку смысла.

Под coding agents я имею в виду инструменты, которые уже не просто подсказывают код, а читают репозиторий, строят план, меняют файлы, запускают проверки и собирают PR.

Сильный агент может быстро принести diff. Но ревьюер должен понять не только "корректен ли код". Он должен восстановить, какую задачу агент решил, где были границы, что агент не должен был трогать и можно ли доверять проверкам.

Вот здесь и появляется дорогая часть AI-assisted development.

Что кажется происходящим

Команда дает агенту задачу:

"Поправь проблему с оформлением заказа."

Агент читает репозиторий, находит несколько связанных мест, меняет обработчик, чуть трогает UI, обновляет тест, пишет краткое описание и приносит PR.

Снаружи это выглядит как хорошая автоматизация:

- задача взята в работу;
- код появился быстро;
- проверки зеленые;
- описание PR выглядит уверенно;
- человек не писал каждую строку вручную.

Если смотреть только на скорость появления PR, все хорошо.

Но ревью начинается не с радости от скорости. Ревью начинается с вопроса: "А что именно здесь надо проверить?"

Что реально проверяет ревьюер

В обычном PR от человека ревьюер тоже проверяет смысл. Но обычно между автором и ревьюером есть живой контекст: обсуждение задачи, уточнения, история решения, понимание компромисса.

С агентским PR часть этого контекста может быть потеряна.

Ревьюер видит diff и краткое описание, но не всегда видит ход выбора:

- почему агент пошел именно в эти файлы;
- какие варианты он отбросил;
- какой сценарий считал главным;
- какие части системы решил не трогать;
- где проверка действительно связана с исходной задачей;
- что было изменено "заодно";
- какие риски агент не заметил.

В итоге ревьюер проверяет не только код. Он проверяет постановку задачи, границы, скрытые допущения, качество проверки и возможность отката.

Это уже не обычное ревью. Это расследование.

Почему это дорого для бизнеса

Для бизнеса проблема не в том, что ревью занимает на 20 минут больше.

Проблема в том, что команда может перепутать активность с поставкой результата.

PR стало больше, но каждый PR требует больше внимания. Тимлид становится узким местом. QA получает изменения, где исходная задача не до конца ясна. Product lead видит движение в задачах, но не видит уверенности, что решена нужная проблема.

Так появляется ложная скорость.

Ложная скорость выглядит так:

- backlog визуально двигается;
- в репозитории больше изменений;
- в чатах больше отчетов от агентов;
- в трекере больше задач со статусом "на ревью"; - но путь до принятого результата не стал короче.

Если ревью стало дороже, AI не ускорил delivery. Он просто сдвинул стоимость в другой участок процесса.

Какие AI PR особенно дорогие

Не каждый PR от агента проблемный. Иногда агент отлично закрывает маленькую, ограниченную задачу.

Дорогими становятся другие PR.

1. PR без понятной исходной задачи Ревьюер видит изменение, но не видит критерии готовности. Тогда он вынужден сам восстановить, что считалось успехом.

2. PR с широкими границами Задача была про один сценарий, но агент тронул соседние слои. В таком PR сложно отделить нужное изменение от лишней инициативы.

3. PR с удобной, но неполной проверкой Агент запустил тесты, которые легко было запустить, но они не доказывают исходный бизнес-сценарий.

4. PR с уверенным кратким описанием Описание звучит убедительно, но не показывает, что именно проверено. Ревьюер начинает спорить не с кодом, а с красивым пересказом результата.

5. PR без точки отката Изменение размазано по нескольким местам. Если поведение сломается в проде, откат будет сложнее, чем сама задача.

6. PR без владельца результата Все видят PR, но никто не отвечает за принятие результата. Тогда агентская скорость превращается в очередь ожидания.

Что должно быть в хорошем AI PR

Перед тем как измерять скорость coding agents, я бы сначала посмотрел на качество PR, которые они приносят.

Минимальная рамка хорошего AI PR

1. Исходная задача Что должно быть видно: какую проблему решаем и для кого. Плохой сигнал: в PR понятно, что изменилось, но непонятно, зачем.

2. Границы изменения Что должно быть видно: какие файлы, сценарии или слои системы были в работе. Плохой сигнал: агент тронул соседнее поведение без объяснения.

3. Что не трогали Что должно быть видно: какие части системы остались вне задачи. Плохой сигнал: "заодно" появилась чистка, переименование или улучшение без связи с задачей.

4. Критерии готовности Что должно быть видно: по каким условиям человек принимает результат. Плохой сигнал: готовность описана как "стало лучше" или "ошибка исправлена".

5. Проверки Что должно быть видно: какие тесты, ручные сценарии или проверки подтверждают результат. Плохой сигнал: проверка сводится к отчету самого агента.

6. Риски Что должно быть видно: где изменение может сломать соседний процесс. Плохой сигнал: агент пишет "risks are low", но не объясняет почему.

7. Точка отката Что должно быть видно: как быстро вернуть поведение назад, если агент выбрал неправильную ветку решения. Плохой сигнал: изменение выглядит маленьким, но затрагивает несколько независимых мест.

Это не бюрократия ради бюрократии.

Это способ не отдавать ревьюеру всю работу по восстановлению смысла.

Пример

Плохой AI PR:

"Checkout fixed. Payment flow updated. Green."

Проблема не в английском описании. Проблема в том, что ревьюеру все равно надо понять:

- какой именно checkout issue;
- какой payment flow; - какие тесты;
- какой сценарий был главным;
- что стало критерием готовности;
- что не должно было измениться.

Лучше:

Задача: Повторная отправка checkout form не должна создавать второй charge для одного payment_id.

Границы: Backend обработчик payment callback и idempotency check.

Не трогаем: UI checkout, тарифную модель, payment provider client.

Проверки: Тест на duplicate callback. Ручной сценарий повторной отправки формы. Проверка, что успешный платеж остается в статусе successful.

Риск: Можно случайно скрыть provider timeout как успешную оплату.

Откат: Изменение локально в idempotency path.

Такой PR все еще надо ревьюить. Но ревьюер уже не начинает с нуля.

Что смотреть вместо количества PR

Количество PR - плохая основная метрика внедрения coding agents.

Она показывает активность, но не показывает результат.

Я бы смотрел на другие сигналы:

- Время до принятого PR: не только когда PR создан, а когда он реально принят.
- Доля возвратов на доработку: сколько AI PR возвращается из-за неверной трактовки задачи.
- Стоимость ревью: сколько времени ревьюер тратит на восстановление смысла.
- Выход за границы: как часто агент трогает лишние файлы или сценарии.
- Качество следа проверки: понятно ли, что проверили и чем это подтвердили.
- Количество откатов: сколько изменений пришлось возвращать после merge.
- Доля PR без владельца результата: как часто approval зависает между людьми.

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

Она стала производить больше работы для ревью.

Где подход не работает

Эта рамка не нужна для каждой мелочи.

Если агент исправляет typo, обновляет простую строку в docs или делает очевидное механическое изменение, полный список будет тяжелее самой задачи.

Она не заменяет инженерное ревью. Рамка помогает понять, что проверять, но не доказывает, что решение технически правильно.

Она не заменяет продуктовую ясность. Если команда сама не понимает нужный результат, агентский PR будет только быстрее фиксировать эту неопределенность в коде.

Она не делает агента безопасным для любых изменений. Данные, биллинг, права доступа, безопасность и публичный API требуют отдельных точек проверки.

И она не снимает ответственность с человека. Кто-то все равно должен сказать: "Да, это решает исходную задачу, риски понятны, можно принимать".

Вывод

coding agents не обязаны удорожать ревью.

Но они легко это делают, если команда измеряет только скорость появления кода и не меняет правила приемки результата.

Хороший AI PR должен снижать нагрузку на ревьюера, а не приносить ему красивый diff без контекста.

Иначе команда получает не ускорение разработки, а новую очередь: код написан, но смысл еще надо восстановить.

Какие AI PR у вас оказывались самыми дорогими в ревью: слишком широкий diff, плохие проверки, неверная трактовка задачи или что-то другое? Интересно собрать реальные failure modes в комментариях.