// notes / ai‑agents
AI‑агенты в разработке: где ускоряют, а где создают иллюзию прогресса
AI‑агенты уже полезны в разработке. Но полезны не магически и не везде. Они ускоряют команды, у которых есть архитектура, тесты, правила и человек, отвечающий за смысл результата. Без этого агент просто быстрее производит код, шум и технический долг.
AI‑агент в разработке — это быстрый исполнитель, а не замена senior‑разработчика. Он может читать репозиторий, менять файлы, запускать команды и возвращаться с результатом. Чем точнее задача и крепче инженерный контур вокруг неё, тем больше пользы. Чем больше тумана, тем выше шанс получить аккуратно оформленную иллюзию прогресса.
Сначала договоримся о терминах
Я говорю не про автодополнение в редакторе и не про чат, куда разработчик копирует ошибку. AI‑агент умеет сам пройтись по проекту: прочитать файлы, найти связанные места, внести изменения, запустить тесты, посмотреть вывод, поправить себя и иногда подготовить PR.
Это уже не подсказка рядом с курсором, а отдельный исполнитель внутри рабочего процесса. Но из этого не следует, что ему можно отдать кусок продукта и уйти пить кофе. Агент работает быстро, но он не живёт внутри вашего бизнеса, не помнит старые договорённости с клиентом и не чувствует цену неудачного архитектурного решения.
Где агенты действительно помогают
Лучше всего агенты работают там, где задача уже разложена, результат можно проверить, а цена ошибки ограничена. В такой зоне они снимают с разработчика рутину и помогают быстрее пройти путь от "надо поправить" до "сборка прошла".
Механика по коду
Переименовать поле, обновить импорты, пройтись по типам, поправить очевидные несовпадения. Человеку скучно, агенту нормально.
Разведка по репозиторию
Найти входные точки, основные модули, зависимости, тесты и места, где изменение может задеть соседний код.
Тестовые черновики
Поднять первый слой unit‑тестов, выписать edge cases, собрать фикстуры. Не вместо ревью, а чтобы быстрее начать.
Документация и контракты
Описать API, собрать README для модуля, привести в порядок DTO, типы и примеры запросов, если человек проверяет смысл.
Небольшие изолированные фичи
Добавить простое поле, endpoint, адаптер или экран, когда бизнес‑правила уже понятны и есть способ проверить результат.
Параллельная проверка
Один агент смотрит тесты, второй ищет похожий код, третий читает документацию. Потом человек сводит выводы в решение.
В этих задачах агент не должен быть гением. Ему достаточно быть внимательным, быстрым и послушным. Он делает много мелких шагов, а человек проверяет направление.
Где скорость начинает обманывать
Опасная зона начинается там, где задачу нельзя проверить простым "тесты прошли". Например: улучшить архитектуру, разобраться с бизнес‑логикой, ускорить модуль, переписать старый кусок системы, сделать "как правильно".
Агент почти всегда что‑то сделает. Создаст новые файлы, вынесет функции, добавит интерфейсы, перепишет тесты, красиво назовёт сущности. На экране появляется движение. Иногда очень убедительное.
Но разработка ценится не за движение. Код должен решать нужную задачу, вписываться в архитектуру, не ломать скрытые сценарии и оставаться понятным через полгода. У агента с этим бывают проблемы. Он может улучшить форму и не попасть в смысл.
Иллюзия прогресса выглядит очень правдоподобно
Самое неприятное в AI‑агентах — плохой результат не всегда выглядит плохим. Код может быть чистым. Файлы разложены аккуратно. Названия нормальные. Комментарий к PR звучит уверенно. И всё равно задача решена мимо.
- PR большой, но после ревью всё ещё непонятно, какую проблему он закрыл;
- агент добавил абстракции, хотя задача была в одном условии;
- тесты зелёные, но проверяют не тот сценарий;
- разработчик тратит час на объяснение агенту того, что сам сделал бы за двадцать минут;
- команда обсуждает количество сгенерированного кода вместо результата для пользователя;
- задача формально закрыта, но бизнес‑логика стала менее понятной.
В обычной разработке тоже бывают такие ошибки. Разница в скорости. Агент может быстрее произвести больше поверхности для ревью. Если процесс слабый, команда получает не ускорение, а дополнительный поток решений, которые нужно разбирать, перепроверять и иногда откатывать.
Агент усиливает процесс, а не заменяет его
Если в проекте есть тесты, понятная структура, нормальные границы модулей и привычка писать задачи конкретно, агенту есть за что зацепиться. Он видит контур. Может ошибиться, но у команды есть способы поймать ошибку.
Если проект держится на памяти двух разработчиков, документации нет, тестов почти нет, а бизнес‑правила живут в переписках, агент будет уверенно гадать. Иногда удачно. Иногда дорого.
Поэтому разговор про AI‑агентов быстро упирается не в выбор инструмента, а в инженерную зрелость. Cursor, Claude Code, Codex, Devin, OpenHands и другие инструменты могут быть полезны. Но ни один из них не отменяет архитектуру, ревью, тесты и ответственность за решение.
Что нужно до внедрения
- короткие задачи с понятным ожидаемым результатом;
- архитектурные правила, которые не нужно каждый раз объяснять заново;
- тесты, линтеры, typecheck и CI;
- документация по доменной логике, а не только по запуску проекта;
- ревью человеком, который понимает продукт;
- разделение задач на безопасные и рискованные;
- логи, миграции, откаты и проверка на тестовом окружении.
Что не стоит отдавать агенту сразу
- перепроектирование ядра системы;
- изменения в правах доступа и безопасности;
- сложные миграции данных без ручного плана;
- оптимизацию производительности без метрик;
- бизнес‑логику, которую никто не описал;
- большие PR без понятной границы задачи.
Как внедрять без лишнего шума
Я бы не начинал с лозунга "теперь пишем всё агентами". Это почти гарантированно создаст хаос. Нормальный путь спокойнее: выбрать безопасные классы задач, договориться о правилах, посмотреть на экономику и только потом расширять область.
Начать с безопасной зоны
Документация, тестовые черновики, типы, простые рефакторинги, поиск по коду. Не стоит первым делом отдавать агенту ядро продукта.
Писать задачи как для исполнителя
Контекст, файлы, ограничения, критерии готовности, команды проверки. Чем меньше тумана, тем меньше правдоподобной ерунды.
Требовать доказательства
Агент должен не только изменить файлы, но и показать, что запускал тесты, сборку или хотя бы узкую проверку затронутого участка.
Считать стоимость ревью
Если проверка агентского PR занимает дольше, чем ручная реализация, это не ускорение. Это перенос работы в другое место.
Оставить архитектуру человеку
Агент может предложить варианты, но решение о границах модулей, данных, рисках и поддержке должен принимать инженер.
Роль разработчика становится важнее, а не слабее
Есть соблазн думать, что с агентами можно обойтись меньшим количеством сильных инженеров. На простых участках иногда да, нагрузка действительно снижается. Но на уровне продукта всё наоборот: чем больше кода и решений производит автоматизация, тем важнее человек, который понимает систему целиком.
Senior‑разработчик в такой модели не просто пишет код. Он формулирует задачи так, чтобы агент не уехал в сторону. Выбирает, что можно автоматизировать, а что нельзя. Смотрит на архитектуру, безопасность, данные, поддержку, стоимость ревью и будущую цену изменения.
Хороший агентный workflow похож не на замену команды, а на усиление инженерного контура. Меньше ручной рутины, больше требований к постановке задач и проверке результата.
AI‑агенты ускоряют разработку, когда у команды уже есть дисциплина: архитектура, тесты, маленькие задачи, понятные правила и ответственное ревью. В такой среде они экономят время и помогают быстрее проходить рутинные участки.
В хаотичной среде они ускоряют хаос. Производят больше кода, больше PR, больше уверенных объяснений и больше работы для тех, кто потом должен понять, что из этого действительно нужно продукту.
Если вы хотите внедрить AI‑инструменты в разработку, начинать стоит не с выбора агента, а с разбора процесса: какие задачи безопасно автоматизировать, где нужны правила, как проверять результат и кто отвечает за инженерные решения. Можно написать мне в Telegram или коротко описать задачу через форму на главной.
// related