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

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

Ошибку такого рода не поймает ни один агент, потому что формально всё написано верно. Это и есть граница, вокруг которой у нас построена работа с Claude Code, Cursor и Codex. Мы пользуемся ими каждый день, и правило у нас одно.

Нельзя принять то, что нельзя проверить за минуты

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

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

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

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

Черновики документов: оценки, технические задания, описания задач. Слово «черновик» тут ключевое, дальше человек режет. Ни один такой текст мы не отправляли клиенту в том виде, в каком его выдал агент.

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

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

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

Что меняется в процессе

Больше времени уходит на постановку задачи. «Сделай форму заявки» даёт результат, который переписывается целиком. Описание с полями, состояниями ошибок и адресом, куда уходят данные, даёт результат, который можно принять. Разница в две минуты при постановке, разница в полдня при приёмке. Больше времени уходит и на ревью (это самая неприятная часть перемены). Читать чужой код медленнее, чем писать свой, и экономия появляется только на объёме, когда типовой работы много. На проекте из трёх экранов агент скорее мешает.

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

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

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

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

Чего я тут не знаю

У нас нет замеров, которые показали бы ускорение в процентах. Учёт часов до и после мы не вели. А ощущения в такой теме врут особенно сильно: запоминается удачный случай, средний день не запоминается вообще.

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

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