Привет, Хабр! Я Николай Бушков, архитектор в команде 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. Методология базируется на опросах, поэтому можно применять ее не только внутри, но и вне компании, чтобы оценивать состояние индустрии в целом и составлять бенчмарк. А самое главное, благодаря продвинутым методам причинно-следственных выводов можно увидеть больше, чем простые корреляции. При создании State of AI-assisted Software Development не использовались ответы респондентов из РФ, поэтому мы решили провести аналогичное исследование «ИИ в инженерной культуре России» и приглашаем поучаствовать всех заинтересованных.

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

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

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

У нас в компании есть институт профессий с разбивкой по специализациям внутри каждой, и так сложилось, что есть неплохое соответствие профессии и стадии 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, мои коллеги выделили из большого корпуса документов банка повторяющиеся паттерны и типовые блоки: цели, гипотезы, 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/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. Для офлайн-оценки, как и для код-ревью, используем фреймворк MERA Code, который недавно выложили в открытый доступ вместе с коллегами по Альянсу ИИ. Из ключевых онлайн-оценок сейчас у этой утилиты — конверсия запусков в принятый merge-реквест с готовыми тестами около 10%. Недавно интегрировали ее в IDE как самостоятельную фичу, а следующим шагом будет ее подключение к нашему агенту в IDE и сравнение качества такой реализации с открытыми коробочными универсальными решениями.

О T-Cover Agent вместе с AI Code Review подробно рассказывали на нашей Turbo ML Conf.

• Генерация тест-кейсов на основе различной документации. Мы создали инструмент 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 под капотом любого решения (а это происходит, по текущим прикидкам, примерно раз в квартал) приводит к росту End-to-End-качества, измеряемого широким набором метрик. Но нужно делать такие обновления более надежно, учитывая вероятностную природу генерации нейросетей, чтобы простые кейсы не ломались и при этом н��чинали решаться новые и более сложные. Этот подход повышает важность систематического сбора логов и трейсов реального использования решений с 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.

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