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

Привет, Хабр! Меня зовут Марат Киньябулатов, я эксперт по гибким практикам и отвечаю за эффективность инженерных команд в ядре банка. В этой статье расскажу, какие гипотезы мы проверяли при внедрении ИИ, почему рост использования чатов и кодинг-агентов не равен росту скорости, какие метрики помогали отделять привычку от результата и как мы пришли к идее Agentic Engineering.

Зачем вообще внедрять ИИ в инженерные команды

Почти все организации так или иначе пробуют ИИ. В 2025 году 88% организаций внедрили хотя бы один ИИ-инструмент, но только 6% получили реальный бизнес-эффект. Это может быть эффект с точки зрения ROI, бизнес-процессов или конкретного бизнес-результата. При этом 43% ИИ-инициатив в организациях провалились или были отменены.

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

У нас этот вопрос сформулирован довольно чётко. Нам важно быстрее доставлять ценность клиенту.

В финтехе и банковской разработке это всегда заметнее. Представьте, что приходит новое legal-требование, меняется процесс, появляется новая интеграция или вводная от регулятора. Команда должна максимально быстро к этому адаптироваться. Поэтому нам близка идея Self-Driving Bank. Конечно, в большой инженерной системе это не так просто. Но чем быстрее мы можем безопасно довести изменение до клиента, тем больше ценности доставляем.

Чтобы оценивать реальное движение к этой цели, мы посмотрели на три инженерные метрики.

Lead Time — это время от момента, когда команда закоммитилась что-то сделать и взяла обязательство, до релиза клиенту. В нашем случае это ответ на вопрос, за сколько мы делаем.

Throughput показывает, сколько элементов команда доставляет за определённый период. То есть сколько мы делаем.

Defect Rate количество багов в вашей системе. Это ответ на вопрос, не ломаем ли мы качество по пути. 

Ожидание от внедрения ИИ было простым: если он действительно помогает инженерным командам, Lead Time должен снижаться или Throughput должен расти, а Defect Rate при этом не ухудшаться.

Как мы измеряли прогресс внедрения ИИ

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

MAU LLM показывает, сколько сотрудников хотя бы раз в месяц пользовались любыми LLM-инструментами.

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

MAU 10+ API показывает регулярных пользователей кодинг-агентов. Тех, кто работал с ними 10 и более рабочих дней в месяц, примерно больше 50% рабочих дней. Это сигнал, что начинает формироваться привычка.

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

Но метрики внедрения — это не метрики результата. Они показывают, что люди движутся в нужную сторону, но сами по себе ещё не доказывают, что система стала быстрее.

Изменения — это работа с людьми

ИИ-инструменты сами по себе ничего не меняют, поэтому их внедрение в первую очередь про людей. Мы исходили из того, что 70% изменений делается с людьми и только 30% — с инструментами. Поэтому без фреймворка изменений внедрять что-то довольно странно.

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

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

Кроме того, любое изменение надо продать. Поэтому мы работали через принцип WIIFM, «Что мне с того?». Конечно, продавать каждому на масштабе 500 человек не получилось бы или заняло слишком много времени. Поэтому мы действовали через руководителей, команды и большие мероприятия, которые помогают быстро вовлечь людей в процесс.

Гипотезы

У нас было три гипотезы о том, что именно должно ускорить инженерные команды. Две из них мы довольно быстро отмели.

Первая гипотеза

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

Мы довольно быстро дорастили MAU LLM до 50%. На графиках внедрения это выглядело хорошо, но по Lead Time, Throughput и Defect Rate изменений не было.

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

Поэтому первую гипотезу мы отбросили.

После этого мы подумали, что нужно растить использование кодинг-агентов.

Вторая гипотеза

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

Мы снова дорастили MAU API до 50%, но снова ничего не изменилось.

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

Из теории систем мы знаем, что скорость системы равна её самому медленному элементу. Поэтому вам не нужно мерить самую широкую часть трубы. Нужно смотреть на самую узкую часть и расширять её.

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

Поэтому мы вспомнили ещё одну теорию.

Третья гипотеза

Из теории очередей мы знаем, что большую часть времени задача ждёт перехода между этапами. В бережливом производстве это примерно 50-60% всего времени. Плохо, если задача ждёт 80% всего времени и больше.

А что, если убрать этапы передачи между людьми? Что, если агенты будут делать всё максимально самостоятельно? Мы постарались хотя бы минимизировать этапы передачи между разными сотрудниками.

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

Заключение

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

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

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

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