Коротко. AI-агент не магия, а инструмент, который начинает приносить пользу только тогда, когда инженерная система готова его принять. Пять вопросов, на которые стоит честно ответить до внедрения, а не после.
Я занимаюсь системным анализом платформы генеративного AI и вижу закономерность: команды, у которых внедрение проходит тяжело, спотыкаются не о модель. Они спотыкаются о собственные процессы, которые до появления агента как-то работали, а с ним перестали.
Логика простая. Каждый раз, когда контекст разорван, агент платит за это налог. Чем длиннее цепочка «задача → анализ → реализация → проверка → интеграция», тем выше налог. Выгода появляется там, где команда умеет его снижать.
Когда в команду приходит человек, ему рассказывают, как устроена система, где грабли, почему тут сделано именно так. Агенту обычно дают формулировку задачи и всё.
Между тем половина инженерной работы — это разобраться в контексте, которого нигде нет: найти неявные требования, понять критерии приёмки, принять компромисс, который не выводится из спецификации. Без контекста даже точная модель даёт правильный ответ на неправильный вопрос.
Проверка. Возьмите три последние задачи, которые отдавали агенту. Смог бы новый разработчик сделать их по тому же описанию, без вопросов в чат? Если нет — агент работал вслепую.
«Сделать нормально» не является критерием. Для человека это работает — он спросит или догадается по прошлому опыту. Агент не спросит.
Здесь внедрение AI вскрывает старую проблему: если требования были нечёткими всегда, команда компенсировала это разговорами в коридоре. Агент этот механизм не использует, и качество постановки становится видимым.
Проверка. Можно ли по описанию задачи написать тест, который однозначно покажет, что она сделана? Если нельзя — критериев нет.
Ключевая развилка. Если в проекте есть автотесты, линтеры, статический анализ — агент получает обратную связь без человека и может исправиться сам. Если проверка возможна только глазами ревьюера, каждая итерация упирается в человека, и весь выигрыш в скорости съедается ожиданием.
Проверка. Какая доля дефектов ловится автоматически, а какая — только на ревью? Второе число прямо ограничивает пользу от агента.
Самый пропускаемый вопрос. Команда внедряет агента, все чувствуют, что стало быстрее, а через квартал никто не может сказать, стало ли.
Минимальный набор: расход токенов, время на ревью, доля правок после ревью, частота дефектов на проде. Первое — это деньги, остальные три — качество и скорость.
Отдельно и обязательно — время на проверку за агентом. Это та величина, которая чаще всего съедает выигрыш и которую почти никто не считает.
Проверка. Есть ли у вас замер «до»? Если нет, сравнивать будет не с чем, и разговор о пользе превратится в спор ощущений.
Вопрос не технический, а про договорённости — и потому самый тяжёлый.
Когда код написал человек, ответственность понятна. Когда его написал агент, а человек посмотрел и нажал кнопку — ответственность размывается. На ревью появляется соблазн просмотреть по диагонали: выглядит аккуратно, тесты зелёные.
Это не гипотетический риск. Аккуратно выглядящий код проходит ревью легче, чем неаккуратный, независимо от того, кто его написал.
Проверка. Спросите команду прямо: изменилась ли глубина ревью после внедрения агента? Ответ обычно все знают, но вслух не проговаривают.
Ни один из пяти вопросов не про модель. Все пять — про то, как устроена работа команды.
Отсюда практический вывод: внедрение AI-агентов — это не покупка инструмента, а проверка зрелости процессов. Там, где требования чёткие, проверки автоматизированы, а ответственность распределена явно, агент даёт выигрыш почти сразу. Там, где всё держалось на устных договорённостях, он сначала обнажает проблемы и только потом начинает помогать.
Это неприятно, но полезно: инструмент, который делает видимыми слабые места процесса, стоит своих денег даже до того, как начнёт экономить время.