AI ускорил написание кода, но сделал ревью главным узким местом

Агенты уже пишут значительную часть кода, который попадает в production, но проверяют этот код по-прежнему люди. Поэтому узкое место в разработке сместилось: теперь проблема не в том, как сгенерировать больше pull request, а в том, как понять, какие из них действительно опасны.

По данным опроса, приведённым в статье, команды с высоким уровнем внедрения AI в 2025 году смержили на 98% больше pull request, чем годом ранее. При этом время ревью выросло на 91%, а размер PR — на 154%. Производительность генерации растёт быстрее человеческой способности разобраться в результате.

Это плохая новость для привычного процесса «маленький PR — быстрая проверка». Агент может за один проход создать миграцию базы данных, модель, сервис и тесты. Разбивка такого изменения на несколько PR не обязательно делает его понятнее: контекст просто распределяется по разным местам, и ревьюеру сложнее увидеть общую картину.

Сначала оценивать цену ошибки

Один из предложенных подходов — смотреть не на размер изменения, а на последствия сбоя. Обновление зависимости обычно обратимо: если что-то сломалось, проблему можно обнаружить в тестах или staging и откатить. Миграция базы данных — другой класс операций: последствия могут быть серьёзными, поэтому здесь нужен обязательный человеческий контроль.

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

Rootly, например, добавила к каждому PR метку риска. Она определяется тем, что произойдёт при сбое в production: насколько велик масштаб и серьёзность воздействия. К PR также прикладывается шаблон с объяснением причины изменения, его сути, проверкой контроля доступа, логированием исключений и планом отката.

Не ускорять ревью, а удешевлять ошибку

Пытаться заставить людей ревьюить со скоростью агентов — сомнительная стратегия. Надёжнее сделать так, чтобы ошибка не превращалась в инцидент на часы.

Для этого нужны автоматические откаты, canary deployments, feature flags и CI/CD, который умеет безопасно остановить изменение. В Intercom, по данным статьи, функции отделяют деплой от релиза и могут быть отключены менее чем за минуту. Команда также ориентируется не только на состояние систем, но и на пользовательские результаты: автоматический откат срабатывает, когда после деплоя ухудшаются ключевые метрики клиентов. На этом фоне downtime из-за ломающих изменений снизился на 35%, а частота деплоев удвоилась.

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

«Кто написал промпт» — не ответственный

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

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

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

Скорость строк кода больше ничего не доказывает

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

В статье приводится показательный пример Uber: около 70% кода компании, по словам её COO, генерируется AI, но прямой связи между этой цифрой и ростом полезных функций для пользователей пока нет. Сгенерировать больше кода — не то же самое, что создать больше ценности.

Главный вывод простой: зрелая AI-разработка строится не вокруг максимальной автономности агентов. Она строится вокруг классификации риска, обратимых изменений, быстрых откатов и закреплённой ответственности. Пока эти механизмы не работают, увеличение скорости генерации лишь быстрее заполняет production кодом, который команда не успевает по-настоящему понять.

Источник: Hacker News - Newest: ""AI" "LLM""