Мы наняли ИИ‑агента в команду разработки. Вот что пришлось перестроить

Настоящий рабочий контекст живёт в самом процессе: как ставится задача, как её проверяют, тестируют и выкатывают в прод. Мы взяли этот процесс и пересобрали заново. На это ушёл месяц.

Файл с инструкциями мы довели до совершенства. Не хватило

Можно написать сколь угодно подробный AGENTS.md, и агент всё равно не поймёт, что в конкретной фиче значит «готово». Не будет знать, какие участки кода трогать категорически нельзя. Не сможет решить, стоит ли резать большое изменение на безопасные куски или выкатывать целиком. Не поймёт, когда нужно остановиться и спросить человека, а не чинить проблему по своему усмотрению.

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

Пять целей, с которых всё началось

Прежде чем менять хоть что‑то в работающем цикле реального бизнеса, мы договорились о целях и дальше сверяли с ними каждое решение.

Четыре из этих целей, если честно, это почти пересказ известного исследования DORA о том, как работают лучшие инженерные команды: маленькие изменения, разработка от основной ветки, быстрое восстановление после сбоев, низкая доля неудачных изменений. А вот пятая цель, про ИИ как равноправного участника, в 2026 году новая, и именно она меняет всё остальное. Если относиться к агенту как к настоящему участнику команды, старый процесс, рассчитанный только на людей, к нему просто не подходит.

Кто пишет код и кто его проверяет: разные агенты, разные контексты

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

Есть и защита от зацикливания: агенту даётся три попытки починить тест и две попытки на верификацию. После этого задача останавливается и уходит на эскалацию. Не потому что агент «чувствует», что он близко к решению, а потому что процесс не даёт пытаться бесконечно.

Сюда же относится решение, которое сначала кажется странным: тесты не считаются в лимит на размер пул‑реквеста. Мы поставили мягкий лимит в 500 строк и жёсткий в 1000, потому что на больших диффах ревью реально работает хуже. По данным одного исследования на десятках тысяч пул‑реквестов, доля найденных дефектов падает с 87% на небольших диффах до 28% на диффах больше тысячи строк. Но если считать тесты в этот лимит, агент быстро научится одному из двух: писать меньше тестов или разносить реализацию и тесты по разным PR. Оба варианта хуже того, что нужно на самом деле, то есть быстрого ревью сфокусированной реализации.

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

Что стало понятно спустя месяц

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

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

Но главный вывод не про архитектуру процесса.

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

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

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

Как понять, что внедрение работает

Время от постановки задачи до результата. Замерьте до внедрения и через месяц. Не «ощущается быстрее», а конкретно: было пять дней, стало два.

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

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

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

Стратегические выводы

Скорость больше не привязана к размеру команды. Мы тратим от $500 до $1500 в месяц на ИИ‑инструменты на одного разработчика, в зависимости от сложности задач: на простых хватает подписок, на тяжёлых сверху ложится ещё около тысячи за использование сверх лимитов. По нашей оценке, отдача на одного инженера выросла примерно втрое. Чтобы получить тот же прирост наймом, пришлось бы удвоить‑утроить штат: с зарплатами, налогами и месяцами онбординга на каждого. Даже по верхней границе инструменты выигрывают у найма на порядок. Значит, команда из десяти человек конкурирует по темпу поставки с куда большими организациями, а объём выпуска растёт без линейного роста штата. Одна оговорка: в нишах, где ручной труд стоит дёшево, эта математика может пока не сходиться. Считайте свою.

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

Самая доходная инвестиция — не модель, а постановка задачи. Час, потраченный на чёткое ТЗ, экономит дни переделок. Это самый дешёвый и самый прибыльный рычаг, и он не требует более дорогой модели.

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

Ваш процесс и стандарты — это актив; берегите его. Держите стандарты и накопленный опыт в собственном репозитории, а не в базе знаний конкретного инструмента. Иначе главный актив (организационное знание) уходит вместе со сменой сервиса/вендора.