ИИ в масштабе: как управлять внедрением, метриками и трансформацией команды из 500+ разработчиков

За год экспериментов мы выяснили, что традиционное обучение ^[1] почти не повышает adoption, а количество пользователей ещё ничего не говорит о бизнес-эффекте. Агенты могут написать от 80 до 99% кода, а могут за 12 часов разрушить архитектуру проекта. Мини-команда из двух разработчиков и бизнес-эксперта с помощью ИИ может сделать интеграционный сервис так же быстро, как команда из пяти человек, но Lead Time при этом может остаться прежним.

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

На связи Юрий Кацер, Product Owner в Data Office операционной дирекции и автор телеграм-канала ^[2], и Вячеслав Гуч, AI Product Manager в Data Office операционной дирекции и автор телеграм-канала ^[3]. Уже больше года мы внедряем agentic engineering в банке на масштабе более пятисот разработчиков, дата-инженеров, аналитиков и инженеров сопровождения.

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

Зачем всё это

Пока вокруг ИИ в разработке спорят на уровне пилотов и красивых демо, банки уже считают эффект в P&L. У Lloyds это десятки миллионов фунтов экономии и прогноз дальнейшего роста.

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

Уже была RPA-волна, которая закончилась кладбищем ботов на поддержке, хрупкими интеграциями и падениями сервисов при первом изменении интерфейса. Но сейчас разница структурная и уходит корнями в два базовых типа задач разработки. В первом случае результат можно однозначно проверить. Контракты соблюдены, тесты зелёные, миграция прошла. Во втором задача требует суждения, накопленного опыта ^[4] и неформализованного контекста.

Большинство задач в зрелой кодовой базе относятся к первому типу. На него мы и делаем ставку. При этом LLM становятся сильнее и в задачах, которые требуют суждения. Год назад Sonnet 3.5 слабо справлялся с нетривиальными задачами, а сегодня Opus 4.8 в любом домене за 10 минут выдаёт то, на что у человека ушла бы неделя. Языки программирования создавались так, чтобы быть понятными, логичными и точными. Это сделало их идеальными для LLM. Поэтому разработка сейчас лучше всего поддаётся агентизации.

Но важно выбрать правильную ментальную модель. Не «агент вместо разработчика», а «каждый разработчик теперь тимлид». У него в CLI столько агентов-джунов, сколько нужно. Паттерны постановки задач те же, что и при работе с людьми, меняется только скорость.

Мы не стремимся автоматизировать всё подряд, по крайней мере на текущем этапе и в ближайшем будущем, а хотим прийти к парето-оптимальному состоянию, при котором 80% задач закрываются агентами, а 20% усилий дают 80% результата. ROI при этом редко измеряется напрямую в деньгах. Важнее считать прирост гибкости и скорости организации, что со временем конвертируется в продукт и конкурентоспособность.

Как измерять эффективность внедрения ИИ

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

Начали с одной метрики Daily Usage. Она оказалась слишком жёсткой. Как правило, разработчик не пишет код каждый день, потому что бывают дни с другой деятельностью: документация, встречи и аналитика.

В итоге для adoption мы перешли к четырем метрикам. Это AI penetration, Active users, W50+ и W80+. Первые две показывают долю и общее количество сотрудников, использующих AI хотя бы раз за месяц. Последние две показывают долю сотрудников, которые используют ИИ более чем в 50% и 80% рабочих дней месяца.

Почему нельзя одинаково работать с adoption во всех командах и на всех этапах

Работу с adoption мы разложили на четыре стадии, чтобы точнее попадать в разные группы (и качественнее работать над ростом Adoption) на разных этапах роста метрики. AI penetration у agile-ролей несколько месяцев назад достиг 90+%, и мы уже не особо следим за этой метрикой и Active users. Нам больше интересны метрики daily usage (W50+ и W80+).

При этом adoption мы отдельно считаем для agile-ролей и линейных сотрудников. У этих групп он растёт по-разному, поэтому и работать с ними нужно по-разному. В agile больше энтузиастов, выше готовность к экспериментам и быстрее осваиваются новые инструменты, поэтому и практическая польза от ИИ возникает раньше. Для линейных ролей порог входа выше, инструменты отличаются, а эффект от ИИ-ассистентов в формате чатов с LLM, который наиболее популярен среди линейных сотрудников, менее значителен и заметен. Но работа с линейными сотрудниками — это тема отдельной статьи, и дальше речь пойдёт только об agile-ролях.

Во время трансформации мы увидели, что базовые лекции и интро-курсы работают только на самом старте, для нулевой базы. Хотя и тут польза неоднозначна. Дальше, судя по рынку и нашему опыту, они уже не повышают adoption. Здесь начинают помогать другие форматы.

• Внутренние хакатоны (даже в рамках команд) дают массовое вовлечение и растят MAU, потому что человек хотя бы пробует инструмент.

• Практические воркшопы по ролям с разбором кейсов и задач роли повышают регулярность использования.

• На верхних стадиях нужны хорошая инфраструктура, удобные инструменты, доступ к сильным моделям и продовые кейсы.

Подробнее о том, как у нас устроены хакатоны и воркшопы, почему они решают разные задачи и как регулярное использование кодинг-агентов распространяется внутри команд, Марат Киньябулатов рассказал во второй части статьи про внедрение ИИ на 500 инженеров ^[5]. Поэтому теорию мы не даём. Статьи разработчик может прочитать и сам. Все наши мероприятия предельно практико-ориентированы и распределены по ролям. Каждая роль агентизирует свои задачи на собственных примерах. К основным форматам относятся воркшопы, мини-хакатоны, обмен best и worst practices внутри команд и межкомандное опыление.

От adoption к бизнес-результату

Конечно, adoption для нас не самоцель, а метрика процесса. Выбор метрик adoption и контроль за ними строились на предположении, что рост использования ИИ влияет на Time2Market и Cost Efficiency. До этого мы последовательно проверяли более прямые гипотезы. Сначала ждали ускорения от роста общего использования LLM, затем от распространения кодинг-агентов, но инженерные метрики не изменились. Подробно этот путь и результаты экспериментов разобрал Марат Киньябулатов в статье «Как мы внедряли ИИ на 500 инженеров, а скорость не росла. Часть 1» ^[6].

В процессе мы поняли, что путь от «инженер пользуется LLM» до «TTM сократился» слишком длинный. Поэтому ввели промежуточные proxy-метрики, чтобы отслеживать движение к целевым показателям. К тому же adoption значительно вырос, и нам понадобились метрики следующего уровня для оценки пользы LLM в SDLC.

Таким образом, мы выбрали следующие две метрики агентизации команд:

• доля AI-assisted задач;

• доля autonomously delivered задач, когда задача назначена агенту и доведена им до MR.

Кстати, мы проводили эксперимент и пытались увидеть прямое влияние доли AI-assisted задач на метрики разработчиков (Defect Rate, Cycle Time), но достаточного эффекта не увидели. Поэтому в этом году мы начали смотреть на них иначе, не как на подтверждение уже полученного бизнес-результата, а как на показатель движения к автономной разработке. Сама трансформация команд, по нашей текущей гипотезе, может влиять на Time2Market и Cost Efficiency.

При этом важно соблюдать баланс и сохранять контроль над классическими инженерными метриками. Мы постоянно измеряем Defect Rate, Cycle Time, Lead Time и Throughput. Они не должны деградировать.

Трансформация ролей и команд

Переход к агентской разработке состоит из двух шагов, которые идут параллельно, а не последовательно.

1. Агентизация и трансформация роли. Каждый инженер, и не только инженер, автоматизирует рутину в своей роли: пишет скиллы, настраивает агентов и выходит на end-to-end уровень.

2. Human+AI-команда. Инженеры учатся закрывать весь цикл end-to-end в новом эффективном сетапе команды.

Как меняются роли

Мы выделяем два направления ролей, Dev и Data.

В Dev-направлении роли разработчиков постепенно сходятся к end-to-end engineer, или, как эту роль ещё называют на рынке, Product Engineer. Для неё нужны три ключевых навыка. Это программирование и разработка ПО, системное проектирование, а также моделирование и проектирование данных.

Дата-профессии, включая дата-инженеров, дата-стюардов и другие роли, сходятся к Data Product Engineer, который работает с дата-продуктом end-to-end. Дата-сайентистов, ML-инженеров, LLM-инженеров мы пока выделяем отдельно.

Трансформация ролей и команд — общий тренд рынка, и мы считаем, что к нему рано или поздно придут все. Для нас это уже наблюдаемый паттерн внутри команд, а не прогноз.

Команды меняются через эксперименты, а не через директиву

Целевой состав определяет сам владелец команды вместе с agile-коучами, с оглядкой на чужие эксперименты. Мы не спускаем единый шаблон сверху, потому что команды слишком разные.

В одном из пилотов команда из пяти человек работала по классическому SDLC с ролевыми передачами и пилила интеграционный сервис. Из неё выделили двух разработчиков и бизнес-эксперта. Разработчики закрывали задачи end-to-end через ИИ-агентов, а бизнес-эксперт наполнял их контекстом и консультировал.

В результате мини-команда сделала тот же сервис за то же время, что и команда из пяти человек. Качество сохранилось, Throughput вырос, но Lead Time пока остался на прежнем уровне.

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

Возможно, со временем дизайн команд сойдётся к формуле «1+1». Owner отвечает за планы, бюджет, коммитменты и т. д., а Engineer за реализацию. Но идти к этому мы будем через эксперименты.

Что нужно построить, чтобы agentic engineering заработал в масштабе

Но одних изменений в ролях и составе команд недостаточно. Без технологической подготовки всё описанное выше не взлетит. Поэтому мы сформулировали четыре принципа перехода к agentic engineering. Каждый следующий опирается на предыдущий, поэтому их порядок важен.

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

Четыре столпа agentic engineering

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

На практике самыми объёмными и разрозненными слоями оказались контекст и интеграции. Без них агент не мог закрывать задачи end-to-end, особенно в защищённой среде.

Мы столкнулись с этим при разработке gateway в защищённой платёжной инфраструктуре. Агенту нельзя было дать доступ к реальным данным, поэтому мы передали ему схему и добавили прокси-анонимизатор.

В нашем случае получилось так, что архитектура вокруг ограничений работает лучше, чем попытка их снять.

Оркестраторы и наша ставка на инструменты

Верхние слои пирамиды занимают оркестрация, воркфлоу и интерфейсы, но индустрия меняется слишком быстро, поэтому гибкость важнее конкретного фреймворка. IDE, CLI, UI, BMAD и другие точки входа в кодинг остаются верхушкой пирамиды, но без нижних слоёв даже «скилл, который делает всё по красоте», не заработает.

Из оркестраторов мы дольше всего тестировали BMAD. Сейчас это одно из самых обсуждаемых решений в энтерпрайзе. Самый продолжительный эксперимент охватывал полный цикл greenfield-разработки и принёс два сюрприза.

Первый сюрприз случился, когда внутренняя модель за 12 часов разрушила архитектуру проекта. Это показало, что на задачах с architectural reasoning фронтирные и self-host-модели пока не взаимозаменяемы. Поэтому в нашем LLM Gateway доступны оба варианта, а выбор зависит от конкретного кейса и ограничений среды. Вторым сюрпризом стали лимиты токенов. Они оказались реальным операционным риском, для которого нужен готовый playbook, а не реакция ^[7] по факту.

Главный вывод из работы с BMAD заключается в том, что он усиливает спецификации, но не заменяет их. Он не превратит плохое требование в хорошее, а просто сделает плохое быстрее. Качество модели остаётся критичным для architectural reasoning, но главным ограничением BMAD оказалось качество документации.

На основе этого и других экспериментов мы разложили рынок инструментов на четыре квадранта.

Наша ставка в том, что правый нижний квадрант со временем станет правым верхним. Пользователю нужно закрывать максимум задач минимальным количеством интерфейсов, поэтому лёгкие обёртки вокруг сильных моделей смогут забрать до 80% работ разработчиков и вытеснить тяжёлые оркестраторы и узкие инструменты. Но мы не пытаемся построить один end-to-end-комбайн на весь SDLC, а фокусируемся на лучших CLI-агентах и полной автоматизации отдельных функций цикла.

Что агенты уже забирают в brownfield

Лучше всего агенты сейчас справляются с рутиной в зрелых кодовых базах. Мы проверили это на двух популярных классах задач в Java-репозиториях. Важно, что это был чистый brownfield, местами даже набор репозиториев.

В первом случае SQL-миграции, JPA entities, конвертеры и маппинги. Во втором компонентные тесты, валидация и API-аудит.

В среднем более 90% таких задач удалось автоматизировать. Нюансов и «но» осталось много, но модели хорошо справлялись с задачами независимо от зрелости репозитория и других условий. Особенно интересно, что всё это выполняли не профильные Java-разработчики, а инженеры по разработке и сопровождению.

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

Граница между этими классами смещается, и задачи, которые полгода назад требовали наблюдения, сегодня перешли в разряд «брать и делать». А разрыв между ними мы дополнительно сокращаем за счёт контекста и интеграций.

Куда сместилось узкое горлышко

После экспериментов стало понятно, что само по себе написание кода больше не узкое место. Теперь их три.

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

Отдельная проблема связана со стоимостью токенов. К ней мы подходим с трёх сторон. Выбираем инструменты с изначально низким потреблением, используем альтернативных провайдеров для некритичных задач и оптимизируем инфраструктуру через MIG ^[8], tensor parallelism ^[9] и speculative decoding ^[10].

Один из главных барьеров на пути к agentic engineering связан с контекстом. Поэтому внутри мы делаем полноценный продукт. Это агентский, а в перспективе мультиагентский поиск с единой точкой входа через UI, мессенджер и MCP.

У него три ключевых свойства.

• Единая точка входа с маршрутизацией по источникам. Агент ищет в базах знаний, системах через MCP gateway, документации по коду, чатах, аналитике, дашбордах, метаданных и бизнес-процессах.

• Зеркалирование ролевой модели. Агент видит ровно то, что доступно запустившему его сотруднику. Он привязан к токену пользователя и физически не может получить доступ туда, куда не может сам сотрудник.

• Токен-эффективность. Маршрутизатор не тащит в контекст всё подряд, а идёт только в нужный источник.

Сейчас многие размечают кодовую базу и легаси, кто-то строит графовые базы. Мы выбрали маршрутизатор поверх всех источников, который сохраняет ролевую модель и контролирует доступ каждого пользователя. Мы верим, что такой подход снимает один из главных интеграционных барьеров на пути к agentic engineering.

Вместо заключения

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

Agentic engineering не сводится к покупке ещё одного инструмента. Замеряйте adoption по стадиям и отдельно для разных типов команд. Не рассчитывайте, что классическое обучение само по себе повысит adoption. Стройте фундамент пирамиды, включая модели и токены, контекст и MCP-интеграции, прежде чем переходить к хайповым агентским воркфлоу. И давайте командам самим доэкспериментироваться до своего целевого состава, конечно, не забывая про Defect Rate, Cycle Time, Lead Time и Throughput.

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