Привет, Хабр! Меня зовут Николай Бушков, я работаю архитектором в команде Engineering Productivity R&D в Т-Банке (группа «Т-Технологии»). В начале лета я выступал на конференции MTS True Tech Day c докладом «Не эксперимент, а стратегия: путь к системному использованию AI в SDLC». А сейчас хочу поделиться текстовой версией описания сценариев использования искусственного интеллекта (ИИ) в программной инженерии, которые реализуются у нас в компании. Уверен, наш опыт будет полезен многим для генерации и фильтрации идей применения ИИ, а также сравнения их с положением дел в ваших рабочих процессах. В конце статьи кратко сформулирую наше видение дальнейшего развития и приглашу поучаствовать в  исследовании ИИ в инженерной культуре России.

А нужно ли вообще продвигать ИИ в разработке? 

Для ответа на вопрос, зачем мы в банке занимаемся созданием и распространением инструментов на базе генеративного ИИ для различных ИТ-специалистов, я бы предложил обоснование, которое фигурирует в названии моей команды: мы хотим повысить инженерную продуктивность. Тут важно отметить, что в условиях российского рынка труда это означает повышение числа выполненных задач без увеличения найма и с сохранением имеющихся людей. Технологический прорыв в генеративных нейросетях в последние 2–3 года задал дополнительный импульс работе по повышению продуктивности инженеров, которая, по сути, и не останавливалась со времен внедрения практик DevOps и Platform Engineering.

Измерение инженерной продуктивности — это в целом крайне глубокая и сложная тема, которой мы в компании много занимаемся. Она заслуживает отдельного материала, но, если не хотите его ждать, можно начать с просмотра выступления моего коллеги Александра Поломодова на прошлогодней конференции MTS True Tech Day 2024. Для текущего поста можно ограничиться пониманием, что инженерную продуктивность мы как-то мерить умеем. Соответственно, наш следующий шаг — оценка того, как ИИ-решения влияют на нее.

Здесь еще скажу о важных принципах измерения продуктивности:

1. Главный юнит измерения — ИТ-команда: у нас более тысячи команд, и регулярно проводится актуализация их границ. Об уровне отдельных людей и больших подразделений подумаем потом.

2. Для команд должен быть общий способ ведения тикет-трекера (у нас пока что это в основном Jira), чтобы было проще единообразно оценивать не только «выхлоп» (output) типа числа строк и закрытых задач, но и «результат» (outcome или impact) в более понятных бизнесу терминах. Есть даже попытки приводить impact сразу к общему знаменателю в виде денег, но эта методология далека от совершенства.

3. Ни в коем случае не нужно ставить KPI по любым метрикам, которые должны быть индикаторами!

Наш способ оценки инженерной продуктивности во многом опирается на наработки DORA, от авторов которой недавно вышел свежий отчет State of AI-assisted Software Development. Методология базируется на опросах, поэтому можно применять ее не только внутри, но и вне компании, чтобы оценивать состояние индустрии в целом и составлять бенчмарк. А самое главное — благодаря продвинутым методам причинно-следственным выводов можно увидеть больше, чем простые корреляции. При создании отчета, упомянутого выше, не использовались ответы респондентов из РФ, поэтому мы решили провести аналогичное исследование «ИИ в инженерной культуре России», в котором приглашаем поучаствовать всех заинтересованных.

Варианты использования ИИ в программной инженерии

Как вообще подступиться к этой теме

Если говорить о самих кейсах и сценариях, то надо начать с отступления о жизненном цикле разработки ПО (SDLC). Эта модель процессов программной инженерии предполагает пошаговое прохождение программы или ее отдельных фичей через определенные стадии. На практике переходы между этапами могут и не быть последовательными, но этот флоу должны понимать большинство участников процесса. 

Канонического разбиения, на которое можно сослаться, тут нет. Коллеги разобрали эту тему чуть шире в докладе AI в Product Development Lifecycle, но я сфокусируюсь именно на ИТ-деливери, а рассказ о копайлотах в Т-Банке для большинства не IT-сотрудников оставлю ответственным за них коллегам.

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

Рабочие группы AI в SDLC у нас собирались вокруг ИТ-лидеров, ответственных за итоговую реализацию решений и имеющих в распоряжении необходимые для этого ресурсы. А еще таким людям проще думать о кейсах применения ИИ, проходящих как бы сквозь несколько стадий SDLC — для более эффективной его трансформации. Вопросы пересечения, дедупликации и взаимодополнения сценариев решаются на дополнительных регулярных кросс-групповых синках.

Не буду давать определение сценарию использования (use case, user story, jobs-to-be-done), только упомяну, что это функциональное описание. Далее, говоря о фичах, буду использовать конструктивное описание (часть программного обеспечения, реализующая соответствующую функциональность).

Для генерации идей мы штудировали публикации по ИИ, анализировали рынок и проводили брейнштормы в группах экспертов, а для фильтрации и приоритизации применили модель типа RICE. В своей работе мы используем стандартный продуктовый подход: спрашиваем самих программных инженеров об их потребностях, но помним про Генри Форда и известную проблему: «Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь».

Список сценариев использования ИИ 

С моего выступления на True Tech Day прошло уже пять месяцев, и мой руководитель Станислав Моисеев успел выступить с отличным докладом по аналогичной теме: там можно увидеть много демонстраций, в том числе и видео. А я в своем дальнейшем повествовании сделаю фокус не только на сценариях использования, но и на технологиях для их реализации. Также опишу ключевые метрики, чтобы еще сильнее заземлить на нашу внутреннюю специфику, а кому-то дать возможность сравниться с положением дел в их компаниях. Я старался обеспечить разумную полноту описания реализуемых кейсов, отбросив сырые идеи и неудавшиеся эксперименты, чтобы можно было оценить масштаб и итоги работы за плюс-минус год в условиях компании вроде «Т-Технологии».

Платформенная часть, общая для широкого круга профессий

• Поиск информации во внутренних источниках по различным оценкам занимает более 20% рабочего времени инженеров, поэтому сделать его качественным крайне важно. Этот сценарий, разумеется, развивался у нас и до бума GenAI, но актуальность его как стартовой точки для различных RAG сильно возросла в последнее время. Здесь я бы в первую очередь отметил наши недавние успехи по сведению доступа ко всем релевантным для инженеров внутренним источникам буквально к одному бэкенду, дающему возможность гибкой фильтрации для повышения качества в специализированных сценариях.

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

• Генеративные ответы со ссылками на источники. Подробности есть в выступлении моего коллеги Алексея Болтавы.

• Чат с LLM — альтернативный вариант работы с генеративными ответами. Он уже давно реализован в составе нашей LLM-платформы. Сейчас мы активно переезжаем на Open WebUI (по ссылке можно оценить, какие примерно функции уже доступны у нас внутри).

• LLM-прокси / API Gateway — это важнейшая часть платформы, централизующая доступ всех решений и сотрудников компании как к внутренним моделям, развернутым в контуре, так и к внешним, что позволяет закрывать массу проблем — например, с безопасностью. У нас собственное решение, но для референса по функциональности можно посмотреть LiteLLM.

• Каталог MCP, в который постепенно трансформируется имеющийся реестр тулов для использования в агентах. У нас уже есть несколько готовых (как самописных, так и проверенных внешних) MCP-серверов на десятки тулов. Если интересно, как это выглядит, можно посмотреть MCP Context Forge от IBM.

• LLM-observability у нас для части решений организуют с помощью Sage, а для искушенных разработчиков есть поддерживаемый Langfuse 3.

Аналитика и проектирование

• Помощь в генерации документации и бизнес-аналитике. Задействовав LLM, мои коллеги выделили bз большого корпуса документов банка повторяющиеся паттерны и типовые блоки (цели, гипотезы, user stories & аксептанс-тесты, метрики, риски) и протестировали несколько моделей на способность писать такие блоки. Затем эта логика была реализована на n8n — основном нашем low-code-конструкторе, который хостится централизованно для создания различных внутренних решений. Сейчас идет пилот с замером более конкретных метрик качества.

• Поддержка работы дизайнеров. Мы уже протестировали на первых пользователях AI-линтер макетов, частично разгружающий дизайн-лидов от ревью, а также генератор figma2code, учитывающий дизайн-систему нашей компании (Taiga и Tramvai).

• Аудит и каталогизация процессов системного анализа. Коллеги дополнили общекорпоративный Practice Hub рекомендациями по использованию ИИ, а для некоторых практик даже сделали (полу)автоматизацию по примеру бизнес-аналитиков, но еще более простыми инструментами наподобие GPTs/Assistants, которые можно легко шэрить по ссылке.

• Ревью разрабатываемых спецификаций. Системные аналитики в отличие от бизнесовых производят более формальные и структурированные артефакты, вроде OpenAPI-спецификаций. Здесь генеративный ИИ добавляется во внутренний продукт API Governance Auditor. Для работы такого решения важно подтягивать контекст из специализированных систем вроде каталога ПО и сервисов в нашей внутренней инженерной платформе Spirit, а LLM здесь помогают с менее структурированным семантическим анализом. Сейчас заканчивается первый пилот со сбором метрик.

• Работа с данными на дата-платформе, где мы реализуем множество ИИ-фич. О Helicopter, как и о других средах разработки подробнее расскажу в следующем разделе. Из специфических для этого домена утилит стоит выделить генератор SQL-запросов с оптимизацией, поиск по таблицам и генератор их описаний (больше 20 тысяч уже готово) — использование всего этого среди целевой аудитории тут уже выше 50%.

• Ревью ADR (architecture decision records). Эффективное использование ИИ в этом сценарии возможно благодаря сравнительно высокой структурированности ADR и четкому набору критериев оценки их наполнения. Подход LLM/AI-as-a-Judge проявляет себя здесь в полную силу. Количество ADR, прошедших через этот инструмент, скоро начнет исчисляться не десятками, а сотнями.

Имплементация

• Автодополнение кода в IDE. Этим в 2025 году уже вряд ли кого-то можно удивить, но отмечу, что наш набор самописных плагинов для всех сред разработки (VSCode, JetBrains, Helicopter/Jupyter, NeoVim, Xcode) работает в том числе и благодаря кастомизированным внутренним моделям (не T-Pro: слишком большая). Он позволяет использовать полностью контролируемую нами телеметрию для дальнейшей кастомизации, ведущей к повышению acceptance rate генерируемых подсказок.
  В течение года распространение автодополнения в терминах WAU (weekly active users) перевалило далеко за 50% от достижимой внутренней аудитории (кажется, уже близко к максимуму, исходя из референсов в индустрии). С удержанием тоже все хорошо, поэтому процент сгенерированного кода от всего нового кода у нас в компании стабильно высокий и еще растет.

• AI-чат в IDE. Кроме автодополнения кода в IDE есть еще ряд AI-фич (например, инплейс-редактирование) с меньшими метриками использования. Сейчас они прикопаны в различных контекстных меню, поэтому у нас есть гипотеза, что они по-настоящему раскроются при вызове через чат.
  C WAU у чата в IDE в целом тоже все хорошо, особенно после переезда на развернутые в контуре большие модели Qwen3-Coder, что позволило значительно подтянуть качество. В базовом сценарии чат может использоваться как замена Stackoverflow без переключения окна, но в продвинутых случаях это уже точка вызова агентских пайплайнов.

• Агентский режим, который мы тестировали с лета и масштабировали в сентябре, работает тоже за счет самописных обвязок (больше всего тут нас вдохновляли Cline для VSCode и Koog для JetBrains), способствующих максимизации наблюдаемости решений. Сейчас агентский режим потребляет для своей работы видеокарт, пожалуй, больше, чем любая другая AI-фича, и это немного ограничивает его дальнейшее масштабирование. Зато открывается простор для экспериментов с внешними LLM в тех проектах, где это возможно с точки зрения информационной безопасности и регуляторики.

• Миграция кодовых баз: наиболее приоритетны для нас обновления между версиями Java (+Spring), перевод Scala2Java, миграция CI/CD-пайплайнов, а также конвертация BPMN-подобных процедур внутреннего движка. Используемые для этого методы вроде автофикса билдов SWE-агентами, генерации докстрингов и процессинга рецептов OpenRewrite выглядят подходящими и для более широкого набора сценариев. В этом направлении пока рано говорить о массовых историях успеха, но в отдельных проектах уже получилась сравнительно быстрая миграция силами малопогруженного разработчика с ИИ в роли помощника.

• Ревью всего нового кода в веб-интерфейсе git-форджа. Здесь мы тоже подключаем GenAI, собирая свое решение по мотивам работы исследователей из ByteDance и GitLab Duo. В среднем каждый день генерируется нескольких сотен комментариев со стабильным лайк-рейтом около 30%.
  Здесь мы пока не приоритезируем сценарий код-ревью прямо в IDE, чтобы сохранять разделение ответственности и наблюдаемость. Недавно добавленные код-саджесты для мелких исправлений прямо в веб-интерфейсе генерируются не так часто, как просто комментарии, поэтому репортировать acceptance rate по ним пока рано.

Тестирование, безопасность и эксплуатация

• Генерация юнит-тестов. Она у нас реализована в T-Cover Agent, о котором мы вместе с описанным выше AI Code Review подробно рассказывали на нашей Turbo ML Conf. Для офлайн-оценки, как и для код-ревью, используем в частности фреймворк, который недавно выложили в открытый доступ вместе с коллегами по Альянсу ИИ. Из ключевых онлайн-оценок сейчас у этой утилиты — конверсия запусков в принятый merge-реквест с готовыми тестами около 10%. Недавно интегрировали ее в IDE как самостоятельную фичу, а следующим шагом будет подключение ее к нашему агенту в IDE и сравнение качества такого реализации с открытыми коробочными универсальными решениями.

• Генерация тест-кейсов на основе различной документации. Мы создали инструмент T-Weaver, который уже интегрирован с нашей TestOps-платформой на базе Allure и работает сравнительно неплохо (сотни экспортированных тест-кейсов в месяц). Тест-кейсы генерируются как для ручных прогонов, так и для последующей автоматизации, но вот AI-генерация кода более сложных автотестов (интеграционных и e2e c Playwright) еще пока не масштабирована на широкую аудиторию.

• Ускорения тестирования изменений при merge-реквестах в мобильных приложениях с помощью AI-выборщиков тестов. Об этом у нас даже готова отдельная публикация, и мы презентовали ее на ICSME 2025. Ключевой результат: в сравнении с детерминированным бейзлайном у нас время на дневные тесты уменьшилось на 30% без значимого влияния на результаты ночных полных прогонов.

• Обеспечение качества документации. Здесь с помощью GenAI мы уже исправляем 80% ошибок без привлечения технических писателей. Запуск этого сценария интегрируется в наш AI Code Review вместе с ревью качества тестов всех типов.

• Обеспечение безопасности. Это отдельное достаточно обширное наплавление — например, AI SAST или Security-агенты. Отсылаю к выступлениям коллег, чтобы не перегружать статью.

• Повышение надежности эксплуатации: у нас есть как небольшие AI-фичи внутри Sage, например помощник в генерации MageQL-запросов, так и целые продукты, такие как SRE-ассистент. Он дополняет нашу платформу инцидент-менеджмента и является единой точкой доступа к широкому набору сценариев от простого получения релевантной информации до root-cause аналитики, генерации постанализа, поиска аномалий и анализа логов для группировки подозрений и инцидентов.

• Ассистент внутренней ИТ-поддержки формирует верные подсказки на основе базы знаний более чем в половине запросов, обрабатывает тысячи обращений в месяц, уменьшая среднее время на тикет в два с лишним раза и сводит процент возобновления практически к нулю.

Взгляд на будущее этого направления и наши планами по развитию его в Т-Банке

Описанным выше сценариям в первую очередь нужно повышать качество. Для этого можно использовать разные методы: от training-free инженерии контекста (развившейся из промпт-инжиниринга) до дообучения различной степени. Кажется, с инженерией контекста с множеством вариаций RAG, tool use / function calling, structured output в последние пару лет уже многие в индустрии достаточно поэкспериментировали, но там еще есть что допиливать напильником. 

Однако мы помним про «горький урок» Рича Саттона и думаем в сторону дообучения LLM (дополняющего, а не альтернативного!), благо у нас в Т-Банке есть достаточные вычислительные ресурсы. Мы уже выкладывали в открытый доступ несколько версий моделей T-lite/T-Pro, дообученных для работы на русском языке и показывающих на нем в среднем лучший результат, чем базовый опенсорс, но нужны следующие шаги специализации.

Специализация LLM для программной инженерии

У сценариев в области программной инженерии есть своя специфика, толкающая нас к созданию domain-specific LLM (DSLLM). По сути Composer, все модели от Antropic, Codex-1 от OpenAI и даже отечественные аналоги — это уже шаги в направлении Software Engineering DSLLM. При этом остается еще немало простора для большей специализации, учитывающей, например, техстек и собственные закрытые наработки компании.

Обновление версии LLM под капотом любого решения (а это происходит по текущим прикидкам примерно раз в квартал) приводит к росту end2end-качества, измеряемого широким набором метрик. Но нужно делать такие обновления более надежно, учитывая вероятностную природу генерации нейросетей, чтобы простые кейсы не ломались и при этом начинали решаться новые и более сложные. Этот подход повышает важность систематического сбора логов и трейсов реального использования решений с LLM под капотом. Их можно применять не просто для создания тестов, но и для дообучения используемой нейросети, чтобы при будущих обновлениях решение не генерировало обнаруженных ранее ошибок.

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

Оптимизация инференса

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

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

Кроме того, интересным направлением оптимизации использования ограниченного контекстного окна моделей выглядит подход с кодированием текста визуальными токенами, который к тому же открывает возможность работы с мультимодальными данными, вроде архитектурных диаграмм. По нашему опыту подобные алгоритмические оптимизации тяжело дотянуть до продакшена без эффективного инференса с помощью решений вроде vLLM/SGLang. К счастью, у нас есть команда, занимающаяся и такими низкоуровневыми вещами (вплоть до подбора нужного железа под инференс для конкретных сценариев).

Мультиагентные системы

Построение DSLLM, даже на архитектурах Mixture-of-Experts, хотя и выглядит необходимым в среднесрок, само по себе не обеспечит максимальной адаптации и (что более важно) гибкости для разработки решений в краткосрок. Чтобы ML-команда не становилась бутылочным горлышком в этом процессе, нужно давать разным командам в компании возможность осуществлять адаптацию LLM под свои конкретные кейсы на другом уровне — и здесь речь в первую очередь про декомпозицию задач. Для построения каждого из LLM-агентов актуальна все та же инженерия контекста, а для оптимизации топологии мультиагентных систем команды могут использовать свое пониманием домена, в котором исторически задачи делились по профессиям и ролям внутри них.

Надеемся, что в следующем году мультиагентные системы начнут работать с качеством, достаточным для более массового их распространения, а не как сейчас. Мы сами, помимо внутреннего SRE-ассистента, рассматриваем применение мультиагентного подхода для DeepResearch-систем на внутренних данных, а также data science агентов как вариант развития и так использующегося в компании AutoML. Последнее может быть актуально с учетом того, что на вход в SDLC иногда поступают гипотезы, рожденные в ходе анализа данных. Их важно максимально качественно проверять до начала попыток имплементации, чтобы меньше фичей уходило в корзину, а инженерная продуктивность повышалась при выполнении действительно нужных задач.

Безопасность

Закончить хочу словами о стыке ИИ, информационной безопасности (ИБ) и обучения. О применении первого для улучшения второго я уже написал выше, и тут мы не планируем сбавлять обороты. Но важно понимать, что при таком изменении парадигмы разработки ПО возникают и принципиально новые угрозы, с которыми нужно учиться работать. И обучение нужно не только ИБ-командам, но и всем сотрудникам компании. 

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

За последние месяцы такой активной работы в Т-Банке мы вырастили много классных AI-инженеров, и кажется, что из обычных бэкендеров, фронтендеров и фулстеков такие ИИ-специалисты получаются даже лучше, чем из людей с бэкграундом в ML и Data Science.

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