ИИ-агенты в разработке: что реально ускоряют, а где мешают

Мы используем ИИ-агентов в ежедневной работе: Claude Code, Cursor и Codex. Продукт, над которым сейчас идёт работа, был собран силами четырёх человек с помощью таких инструментов, и это ровно тот случай, где польза видна на цифрах: страница предзаказа в магазине приложений дала 1071 просмотр и 26 предзаказов за период с 25 августа по 16 сентября 2026 без всякого продвижения.

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

Где выигрыш очевиден

Типовой код. Компоненты по образцу, формы, таблицы, миграции, обвязка вокруг API. Работа, где правильный результат легко узнать, и где раньше уходило время на механический набор.

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

Тесты. Особенно на существующий код: агент хорошо пишет проверки для того, что уже работает, и это ровно та работа, которую люди откладывают.

Черновики документов. Оценки, технические задания, описания задач. Здесь важно, что это именно черновик, который человек потом режет.

Где мы теряли время

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

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

Задачи с неявными требованиями. Если заказчик сам не сформулировал, что должно получиться, агент выдаст уверенный вариант, который придётся переделывать. Ускорение здесь мнимое: вы быстро получаете не то.

Правило, которым мы пользуемся

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

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

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

Что меняется в процессе, а не в коде

Больше времени уходит на постановку задачи. Формулировка «сделай форму заявки» даёт результат, который придётся переписывать, а формулировка с указанием полей, состояний ошибок и того, куда уходят данные, даёт результат, который можно принять.

Больше времени уходит на ревью. Это неприятная часть: читать чужой код всегда медленнее, чем писать свой. Экономия появляется только на объёме, когда типовой работы много.

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

Что стоит сделать до того, как звать агентов в проект

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

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

И договориться внутри команды, кто отвечает за принятый код. Ответ «его написал агент» не работает ни в одном известном нам договоре.

Обсудить процесс разработки