81% - отличная статистика. Если смотреть не дальше носа
Цифра из заголовка не вымысел. К середине 2026 года несколько крупных команд, активно внедряющих AI-агентов для код-ревью и генерации фич, опубликовали внутренние метрики: в среднем 81% пул-реквестов, созданных AI-агентами, проходят ревью и мержатся. Звучит как победа. Как мечта любого продакта — разработка ускоряется, backlog тает на глазах, а разработчики занимаются архитектурой, а не правкой багов.
Но есть нюанс. За этими 81% часто прячется эффект, который я называю каскадом невидимых ошибок. AI-агент написал код, прошел CI, прошел ревью (возможно, автоматизированное или поверхностное человеческое), попал в main. А через три дня — регрессия в соседнем модуле. Еще через неделю — неработающий edge-кейс, который не покрыт тестами. И команда начинает гадать: кто это сломал? А сломал AI-агент, но в его PR все было зеленым.
Совет: не доверяйте проценту принятых PR. Смотрите на процент откатов, RTO (revert time) и количество скрытых багов, которые всплывают через неделю.
Как AI-агенты штампуют PR-ы
Современные AI-агенты для кодинга — это не просто автокомплит. Это системы, способные проанализировать репозиторий, понять задачу из issue или even описания, сгенерировать код, запустить тесты и создать пул-реквест. Инструменты вроде Devin, дополнительных фич в Cursor (версия 0.45+, обновленная в апреле 2026) и GPT-5 Coding Agent работают именно так.
Механика проста:
- Агент получает задачу (текстовое описание, issue, промпт).
- Сканирует код, dependencies, историю коммитов.
- Генерирует diff — чаще всего небольшие изменения (10-300 строк).
- Проверяет, что код компилируется и тесты проходят.
- Создает PR с описанием изменений.
Звучит логично. И на каждый такой PR можно получить красивый грин-чек. Но беда в том, что AI не понимает контекста системы целиком. Он не видит, что его маленькое изменение сломает другой микросервис или нарушит неявный интерфейс. Особенно если речь о мульти-агентных средах, где несколько AI-агентов одновременно пишут PR — начинается хаос, известный как каскад конфликтов.
Когда робот чинит баг, ломая соседний модуль
Классический сценарий ловушки: AI-агент получает issue: "Исправить NullPointerException в методе getUser()". Он смотрит код, находит проблему, добавляет проверку на null. Все тесты проходят. PR принят. А через неделю выясняется, что этот метод использовался в другом месте, где null был валидным значением, и теперь логика сломана. Но в PR об этом не написано — AI не знал контекста использования.
Вот тут и вскрывается иллюзия автономии. Высокий процент принятых PR — не показатель качества. Это показатель того, что агент умеет проходить автоматические шлюзы. Но за пределами этих шлюзов — дикая природа системной интеграции, о которой агент не догадывается.
Особенно остро это проявляется в распределенных системах. Например, как в проектах с автономными автомобилями на RL — где каждое действие агента может вызвать цепную реакцию в экосистеме. Там для предотвращения коллизий используют централизованные планировщики. В коде нужна аналогичная координация.
Ловушка под названием "она же показала зеленую галочку"
Еще один когнитивный баг разработчиков — доверие к AI. Когда команда видит, что AI-агент стабильно генерирует рабочие PR, они начинают меньше всматриваться в код. Code review становится формальностью. "А зачем тратить час на ревью, если AI уже написал тесты и CI прошел?"
Ответ: потому что AI-агент не обладает бизнес-контекстом. Он не знает, какая функция критична для пользователя, а какая — технический долг. Он не знает, что заказчик изменил требования еще неделю назад. И он не знает о грядущем рефакторинге, который сделает его код мертвым. В сравнении AI и юриста AI нашел 41 проблему в договорах против 32 у человека — но те 11, которые человек нашел, были критическими и связанными с контекстом переговоров. Так и с кодом: AI-агент найдет синтаксические ошибки и типовые баги, а контекстная ошибка останется.
Важно: Использование Explainable AI (XAI) для автономных агентов — не роскошь, а необходимость. Мы уже знаем, как XAI превращает беспилотники из черных ящиков в прозрачные системы. Аналогичный подход нужен и для AI-кодинга: агент должен объяснять не только что он сделал, но и почему, и какие альтернативы рассматривал.
Что делать? Сделать агента поднадзорным
Решение не в том, чтобы отказаться от агентов. Это путь в прошлое. Решение — ввести механизмы контролируемой автономии. Например, подход, описанный в статье про централизованный AI Kit для нескольких команд: вы строите слой оркестрации, который анализирует все PR от агентов, проверяет пересечения изменений, накладывает ограничения по контексту и передает на человеческое ревью только те, где есть конфликт интересов или неопределенность.
Также введите правило: любой PR от AI-агента должен пройти обязательное парное ревью с человеком, который знает этот модуль. Да, это снизит процент принятых PR, но спасет от каскадных ошибок. И обязательно используйте feature flags для AI-сгенерированного кода — включайте его постепенно, отслеживая метрики.
Куда катимся? К гибридному будущему
Автономные агенты не исчезнут. Они станут умнее — в GPT-5 и его аналогах уже закладываются механизмы рефлексии и верификации собственных решений. Но я прогнозирую, что к концу 2026 года стандартом станет двухуровневая архитектура: AI-агент генерирует код, а AI-оценщик (другой агент, возможно, с другой архитектурой) проводит ревью на соответствие бизнес-контексту и системной целостности. И только после этого — человек.
Совет, который на первый взгляд кажется контринтуитивным: чем умнее AI-агент, тем больше контроля ему нужно. Потому что 19% отклоненных PR — это те самые ошибки, которые вы не увидите, пока не станет поздно.
