ИИ-агенту можно поручить функцию или целый модуль. Но после генерации начинаются проверка, тестирование и поиск побочных эффектов. Если поток изменений растет быстрее, чем команда успевает их проверять, нагрузка концентрируется у опытных инженеров. Формула «минута на код, три дня на дебаггинг» — метафора, а не измеренный средний срок.

Опрос Harness среди 700 специалистов и руководителей инженерных команд в пяти странах показал: 81% респондентов сообщили об увеличении времени на ревью после внедрения ИИ-инструментов для написания кода. При этом 89% руководителей отметили рост производительности разработчиков. Оба результата могут быть верны одновременно, если считать отдельно скорость появления кода и время, необходимое для его безопасного выпуска.

Когда почти правильный код становится дорогим

ИИ редко пишет очевидную бессмыслицу в каждой строке. Сложнее обнаружить изменение, которое выглядит разумно, проходит простые тесты, но нарушает контракт с другим сервисом или открывает доступ к чужим данным. В опросе Stack Overflow 2025 года 66% ответивших на вопрос о проблемах с ИИ назвали раздражающими решения, которые «почти верны», а 45% пожаловались на трудоемкую отладку сгенерированного кода.

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

«Когда агент приносит тысячу строк за пять минут, он не передает вместе с ними тысячу строк понимания. Ответственность за совместимость, защиту данных и последствия ошибки остается у инженера. Поэтому я бы считал производительность по времени от постановки задачи до проверенного результата, а не по объему сгенерированного кода», — говорит Дмитрий Пеньков, основатель и генеральный директор «Океан Тех».

Почему быстрый агент замедляет очередь

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

Исследование DORA связывает применение ИИ с ростом размеров изменений: крупные пакеты дольше проверять. У METR в эксперименте 2025 года 16 опытных разработчиков выполняли задачи в знакомых проектах в среднем на 19% дольше с доступом к ИИ. Речь о конкретных инструментах того периода. В феврале 2026 года METR сообщила, что новые агенты, вероятно, помогают сильнее, но надежно оценить ускорение пока не удалось.

«Критический момент наступает, когда скорость генерации принимают за пропускную способность команды. Если агент создает пять изменений, а специалист способен внимательно проверить два, остальные три образуют техническую очередь. Она быстро превращается в ночные исправления и постоянное переключение внимания», — объясняет Пеньков.

Выгорание — риск, а не диагноз отрасли

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

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

Как «Океан Тех» предлагает выстроить процесс

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

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

«Хороший агент должен приносить ревьюеру не загадочный массив файлов, а небольшое изменение с объяснением, какие требования оно выполняет и какими тестами подтверждено. Мы проверяем эту схему на реальных задачах заказчика. Если проверка занимает дольше ручной работы, архитектуру и границы задания нужно менять», — говорит Пеньков.

Практический показатель — время на принятое изменение и его последствия после релиза. Стоит считать длительность ревью, возвраты, дефекты и нагрузку на дежурных инженеров. Агенту можно доверять больше задач по мере подтверждения качества, не превращая сеньоров в службу исправления ошибок.