Как мы внедряли ИИ на 500 инженеров, а скорость не росла. Часть 2. Почему AI-first команды не делают нас быстрее

В первой части статьи ^[1] мы пришли к выводу, что само использование ИИ не ускоряет инженерную систему. Можно вырастить использование LLM-инструментов в принципе (MAU LLM), потом использование кодинг-агентов (MAU API) и всё равно не увидеть изменений в Lead Time, Throughput и Defect Rate.

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

Меня зовут Марат Киньябулатов, я эксперт по гибким практикам и отвечаю за эффективность инженерных команд в ядре банка. В этой части расскажу, как мы в подразделении растили регулярное использование кодинг-агентов, зачем понадобились хакатоны и воркшопы, чем агентизация роли отличается от AI-first команды и почему даже E2E-команда не даёт магического ускорения, если вокруг неё остаётся старая цепочка поставки.

Agentic Engineering поможет доставлять быстрее?

Это подход, при котором человек становится оркестратором, а работу выполняют агенты. Инженер приходит с идеей или спецификацией и говорит, что хочет сделать. Дальше агент идёт в таск-трекер, вики, смотрит требования, сверяет их с кодовой базой, проверяет правила и ограничения, учитывает legal framework и готовит спецификацию. Она передаётся агенту-разработчику. Он реализует решение, пишет тесты и готовит результат. Человек при этом валидирует работу между этапами (ответственность никуда не пропадает). А в совсем идеальном варианте система настроена так, что и валидировать ничего не надо.

Конечно, в реальности всё работает по-разному. SDLC может схлопываться ^[2] в greenfield, brownfield или в очень зарегулированной среде. Где-то агентам можно отдать больше, где-то меньше, но почти нигде без человека между этапами пока нельзя (особенно в нашей, высокозарегулированной сфере). Это очень напоминает мультфильм «Вовка в Тридевятом царстве», где двое из ларца за него всё неправильно делали.

Поэтому, чтобы инженер научился качественно оркестрировать агентов, нам нужно выполнить три предусловия:

• Первое — люди должны регулярно пользоваться кодинг-агентами (мы это увидим на метрике MAU 10+ API – использование кодинг-агента 10 и более рабочих дней в месяц).

• Второе — агенты должны автономно выполнять работу внутри каждого этапа. Не просто «писать код», а воспроизводимо выполнять конкретную часть процесса с нужным качеством.

• Третье — инженер должен понимать весь E2E-цикл поставки. Если человек оркестрирует агентов, ему нужно разбираться не только в своём участке, но и в том, что происходит до и после него. Хотя это пока гипотеза.

И вот только после этого можно ожидать какой-то профит. Хотя, как обычно, всё оказалось сложнее.

Как повышать использование кодинг-агентов

Использование кодинг-агентов можно растить вширь и вглубь.

Для многих людей не так-то просто настроить кодинг-агентов. Особенно если это CLI-инструменты, доступы, токены, окружение и всё такое. Поэтому сначала нужно не только объяснить человеку, зачем ему кодинг-агент, но и помочь настроить, а затем воспользоваться им для рабочей задачи.

Хакатоны

Для общего охвата аудитории хорошо работают хакатоны. Это такая «ковровая бомбардировка» вовлечением, если нужно быстро повысить MAU API и завести в инструмент много людей.

Формат простой: один-два дня, немного теории про актуальность и возможности LLM, настройка CLI-инструмента, реальный кейс для решения от бизнес-эксперта или линейного персонала, команды по 3-5 человек, призы и соревнование.

Самое важное — максимально упростить установку. Нам сильно помогли скрипты. Достаточно двойного клика, и у люди получают всё нужное для начала работы с агентом. Им нужно только ввести одну-две вещи. Иначе большая часть времени уходит не на применение ИИ, а на изнуряющую борьбу с настройками.

Потом мы вместе решаем какую-то задачу, люди в течение дня делают end-to-end решение и начинают «пробовать на вкус» агентов, чтобы погрузиться и попробовать.

Хакатоны хорошо работают именно как первая воронка. Они помогают быстро нарастить MAU API для использования кодинг-агентов. Для заражения коллег этой практикой, эффект получился заметный: 95% сотрудников, которые посетили хакатоны, в следующие два-три месяца попадали в ежемесячных пользователей и продолжали там оставаться.

А ещё сильно падала доля скептиков. Скептики есть всегда. Например, если до хакатона их было около 30%, после хакатона доля могла снижаться до 10% или даже 5%. В некоторых случаях до нуля.

Но хакатон решает только первую часть задачи. Он помогает человеку попробовать инструмент и перестать смотреть на него как на непонятную штуку. Чтобы использование стало регулярным, потребуются другие форматы.

Воркшопы

Воркшопы нужны для регулярности. Они помогают встроить инструмент в рабочую задачу и начать пользоваться чаще. Если на хакатоне могло быть 35-50 человек, то на воркшопе их обычно 12-20. Мы делили людей на мини-группы. В каждой группе участник был «за рулём», а эксперт (обычно это очень прошаренный в работе с агентами разработчик) рядом как штурман: подсказывал, куда смотреть и что делать, но сам руками задачу не решал.

Это важный момент. У человека должна сформироваться мышечная память ^[3] на своей реальной задаче. Не посмотреть, как эксперт красиво работает с агентом, а самому пройти через настройку, промпты, ошибки ^[4], уточнения и результат.

Для воркшопа мы брали реальный тикет из таск-трекера. Человек приходил не с учебной задачей из воздуха, а с тем, что ему всё равно нужно было делать в работе.

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

Мы смотрели, как это распространяется внутри команд. Когда на воркшоп приходил обычный инженер, примерно 20% команды потом попадали в ежемесячные пользователи кодинг-агентов. А когда приходил техлид, показатель вырастал до 40%. А если после этого в команде запускали регулярный обмен опытом ^[5], эффект становился ещё сильнее. Например, раз в спринт люди показывали друг другу: «Я попробовал сделать так», «А я вот так», «Вот здесь агент помог», «А вот здесь всё сломал». После такого обмена больше половины команды попадало в ежемесячные пользователи кодинг-агентов.

В командах, где техлид прошёл воркшоп и настроил обмен опытом, доля регулярных пользователей MAU 10+ API была примерно в два раза выше, чем в командах без такой практики.

Поэтому хакатоны и воркшопы решают разные задачи. Хакатоны заражают людей и растят MAU API. Воркшопы помогают довести это до регулярного использования и растят MAU 10+ API.

Два пути к Agentic Engineering

Когда регулярное использование кодинг-агентов выросло, дальше есть два пути.

Путь 1. Агентизация роли

Инженеры остаются экспертами в своей области, но учатся максимально агентизировать этап, за который отвечают. Если пользоваться аналогией из Warhammer 40000, это похоже на Adeptus Mechanicus. У инженера появляются дополнительные руки, и каждая помогает делать часть работы. Одна готовит артефакт, другая проверяет соответствие требованиям, третья помогает с тест-кейсами, четвёртая забирает ещё какую-то рутину. Человек не исчезает из процесса, а начинает этим оркестрировать.

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

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

Здесь важно не пытаться всё делать сверху. У вас никогда не хватит людей, чтобы обучить всех руками. Если в подразделении условно 60 тестировщиков, невозможно каждому отдельно провести полноценное обучение ^[6] силами одной центральной команды.

Поэтому нужно вовлекать волонтёров из самой роли. Пусть они сами продумывают флоу воркшопа, собирают примеры, проверяют артефакты и потом обучают остальных. Эти артефакты становятся базой скиллов и вкладом в Harness ^[7], то есть в ту самую обвязку, которая помогает агентам работать предсказуемо.

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

Путь 2. AI-first команда и E2E-инженеры

Здесь человек уже не просто агентизирует свой этап, а выходит за пределы роли и пытается закрывать весь E2E-цикл поставки через агентов. Похоже на обучение плаванию через «выкинули в середину озера, выплывай».

У нас был такой пилот: greenfield-проект с небольшим количеством legacy-кода. До эксперимента в команде было пять человек, ролевые передачи между этапами и классический SDLC: анализ, разработка, тестирование, выкатка. На время эксперимента выделили в отдельный юнит двух разработчиков и одного бизнес-эксперт. Ответственность стала E2E, а реализация шла через агентов. Потом людей вернули в команды.

Первый месяц ушёл на формирование привычки. Инженеры старались работать на уровне спецификаций: описывать, что нужно сделать, и кормить этим агентские фреймворки (например, BMAD/SuperPowers/GSD), где уже есть готовые роли аналитика, разработчика, тестировщика и других участников процесса.

На первом этапе команда не стала заметно быстрее по Lead Time (времени реализации). Но при меньшем составе она сделала примерно столько же работы, сколько раньше делала команда из пяти человек, а потом начала делать больше. Throughput вырос, качество при этом сохранилось.

А через пару месяцев команда смогла затащить сервис меньшим количеством человек, который раньше делался дольше!

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

Вызовы для AI-first команд

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

Системные аналитики подходят для этого лучше всего. Они понимают E2E, умеют работать с требованиями и часто неплохо держат в голове весь контекст задачи. Но даже им сложно отвечать за весь SDLC. Поэтому мы стараемся снижать когнитивную нагрузку через Harness (снабдив обвязку нужным контекстом, инструментами, логикой ^[8]). И отдельно учим команду всё делать E2E агентами, а не руками. Иначе человек не оркестрирует систему, а просто получает ещё больше работы.

Второй вызов — валидация. Агенты генерируют быстрее, чем человек успевает проверять. К тому же по статистике CodeRabbit Pull Request от агентов содержат в 1,7 раза больше уязвимостей, но человек после Pull Request на 500 строк часто просто принимает его не глядя (статистика из того же исследования). Поэтому человеку нужно оставлять только самое важное, а проверку качества встраивать в Harness: автоматические проверки, критерии качества, приёмки и контекст, который агент может сам взять в нужный момент.

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

Но надо научить агентов работать по правилам, делать работу качественно (привет, eval). Иначе AI-first команда быстро превращается в генератор артефактов, которые никто не успевает проверять.

Четвёртый вызов — изменение роли. При агентизации роли человек остаётся экспертом в своей области. А в AI-first команде он выходит за её пределы, и появляется вопрос «кем я теперь буду?». Для руководителя это звучит ещё сложнее: он сам должен пройти трансформацию, показать E2E-пример команде и поддержать структурные изменения.

Ускорить одну команду недостаточно

Сейчас у нас идёт четвёртый месяц пилотов по агентизации. 96% людей пользуются LLM-инструментами, 80% инженеров кодинг-агентами, а 63% делают это каждый второй рабочий день. Привычка начала формироваться, но системных изменений всё ещё нет.

Причина в том, что AI-first команда может ускориться внутри себя, но потом упереться в соседние команды и линейные подразделения, где интенсивность внедрения ИИ ниже. Поэтому полный E2E-цикл нужно выстраивать не только внутри IT, но и вокруг всей цепочки поставки ценности.

По статистике BCG ^[9], больше ценности получают те, кто перестраивает воркфлоу вокруг ИИ, а не просто добавляет инструменты поверх старого процесса. Но не все готовы сразу идти в AI-first команды, поэтому работать всё равно нужно индивидуально, а не навязывать всем одну структуру.

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

Дальше нужна инфраструктура: общие библиотеки агентов и скиллов, нормальная база знаний и Harness. Без этого привычка может появиться, но стабильно воспроизводимого результата на масштабе не будет.

Четыре шага для вашего контекста

Первое — поймите, ради чего вы внедряете ИИ. Это ключевая вещь, потому что без ответа на вопрос «зачем?» непонятно, как измерять успех. Можно выдать людям инструменты, получить красивые графики использования и всё равно не изменить скорость поставки.

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

Третье — экспериментируйте с продажей идеи людям. Внедрение нельзя просто всунуть в голову, оно так не работает. Нужно объяснять личную пользу, вовлекать руководителей, делать малые группы, воркшопы и давать людям пробовать инструмент на реальных задачах.

И четвёртое — будьте готовы менять гипотезы и подходы. Индустрия движется очень быстро, поэтому сегодня работает один формат, завтра появится другой. Но базовая точка не меняется: сначала нужно понять, что вы хотите изменить и ради чего внедряете ИИ. Всё остальное, от хакатонов до Agentic Engineering, должно работать на эту цель.

Больше кейсов работы с эффективностью команд и внедрения AI в жизненный цикл разработки можно почитать в моем telegram-канале. ^[10]