Повышение инженерной продуктивности

Т-Технологии, куда входят Т-Банк и другие компании — огромная структура, в которой работает порядка 10 тысяч инженеров, специализирующихся в разных областях разработки. Каждый процент повышения их продуктивности влияет на финансовый результат. Но как измерить эту продуктивность? Вопрос непростой.

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

Мы планируем рассказывать о проектах R&D-центра, но в этой статье хотим договориться о ключевых понятиях, которыми описывается предметная область программной инженерии, и показать какая специфика есть в Т-Банке.

Пожалуй, ключевое понятие — жизненный цикл ПО или системы (SDLC, software/system development life cycle). Названия стадий и мелкость дробления могут отличаться в разных сообществах разработчиков, но в целом переходы между фазами скорее непрерывны, а подход к разработке — гибкий. Подробнее об этом — в статье

Начнем разбираться с завершающей стадии системы — сопровождения, или maintenance. На этой стадии SRE-специалисты эксплуатируют готовое ПО. Периодически возникают сбои, с которыми мы боремся, потому что каждая минута неработоспособного ПО может стоить банку миллионы рублей упущенной выгоды.

Типичные банковские системы — десятки и сотни взаимодействующих модулей, поэтому локализовать причину сбоя не всегда легко. Чтобы упростить задачу, разработчики предлагают разные инструменты телеметрии: сборщики логов, взаимодействие модулей и технических метрик с удобными дашбордами. Один из таких инструментов — платформа мониторинга и realtime-аналитики Sage, сервис Т-Банка. Рассказ о нем — в отдельной статье

Несмотря на сервисы-помощники, данных, которые нужно анализировать для поиска причин сбоя, все равно очень много, и в них не так просто разобраться. На выручку приходят инструменты на базе ИИ, которые мы разрабатываем в R&D-центре. Например, умный суммаризатор логов, детектор аномалий в технических метриках, интеллектуальный поиск по базе данных телеметрии — и это открытый список, потому что постоянно появляются идеи, причем и в нашей компании, и в сообществе разработчиков и SRE-инженеров.

Чтобы снизить риски сбоя, ПО проходит стадию тестирования. В нее входят автоматические юнит- и UI-тесты, интеграционные тесты, фаззинг. Они могут реализовываться на компьютере отдельного разработчика или на удаленных серверах внутреннего облака — в CI/CD-пайплайнах. 

На стадии тестирования ИИ тоже может помогать: есть умные анализаторы логов падения пайплайнов, выборщики подмножества запускаемых автотестов, кодогенераторы автотестов, которые могут повысить покрытие всех возможных сценариев исполнения кода. Например, Quality Gate — система контроля качества кода, она помогает улучшать качество вносимых изменений с помощью измерения метрик на каждом этапе жизненного цикла. Это тоже разработка Т-Банка. Рассказ о ней — в отдельной статье 

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

Одно из первых применений генеративных нейросетей в области программной инженерии — автодополнение кода в интегрированной среде разработки. В Т-Банке разработали Nestor, который работает по этому принципу. Рассказываем о нем в отдельной статье.

Помимо подсказок по дополнению текущей строки и генерации многострочных сниппетов кода — функций, докстрингов, методов, классов — Nestor учится генерировать автотесты. Правда, требования к работе плагина для IDE в реальном времени ограничивают качество результата и количество сценариев генерации таких тестов в сравнении с генерацией в облачном асинхронном пайплайне.

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

Если у уязвимости есть четкий паттерн, который можно описать чем-то вроде регулярного выражения, например c помощью инструментов статического анализа кода — Semgrep и/или CodeQL, соответствующий ей фрагмент кода подсвечивается в наших CI/CD-пайплайнах. Но вот автоматически предложить качественное исправление могут уже только инструменты с ИИ.

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

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

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

Для решения почти всех прикладных задач программной инженерии с применением ИИ можно использовать одну универсальную базовую предобученную большую генеративную нейросетевую модель вроде закрытой GPT-4 или открытой Llama 3.

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

С помощью значительного дообучения наши коллеги из AI-центра Т-Банка уже создали собственное семейство базовых моделей T-Lite/T-Pro, которые на момент релиза показывали лучшие результаты в разных русскоязычных бенчмарках для задач обработки естественного языка среди конкурентов своего класса. Совместно с ними еще предстоит сделать модели более качественными для решения задач программной инженерии. 

Полезные ссылки о разработках Т-Банка: 

• AI-центр
• Новость на Хабре об открытии библиотеки инструментов для разработки приложений на базе ИИ
• Статья на Хабре о двух больших языковых моделях — T-Lite и T-Pro.

Коллеги из AI-центра уже создали LLM-платформу для разработки приложений с использованием больших генеративных нейросетей, которая может быть полезна и для задач программной инженерии. Она позволяет быстрее реализовывать разные паттерны приложений с использованием LLM вроде one-prompt application, RAG и агентных систем. На зиму 2024 года она требует некоторой достройки для большего удобства в конкретных кейсах программной инженерии, например лучшей интеграции с корпоративным поиском по коду и документации. На примерах Вселенной ассистентов Т-Банка Артур Самигуллин рассказал об основных концепциях разработки LLM-приложений. Запись выступления на ютубе

Если заглядывать в конец 2025 года и еще дальше, можно выделить несколько перспективных направлений исследований и разработки, которые лежат в области интересов и компетенций нашей команды.

Индустрия не останавливается на разработке помощников в режиме «второго пилота», а уверенно двигается в сторону создания полноценных программных агентов и даже мультиагентных систем. Их цель — более полноценно заменять определенные роли в командах или даже целые небольшие команды.

С технической точки зрения движение может означать рост значимости интеграции разных модулей через программные API c помощью генерации структурированных сообщений — например, JSON — между интеллектуальными компонентами. Еще один вариант — через графические интерфейсы, на которые «смотрят» компоненты с большими мультимодальными генеративными моделями под капотом

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

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

Возможно, весь интеллектуальный функционал, который мы разрабатываем, может в ближайшем будущем стать частью Spirit — централизованной PaaS-платформы для разработчиков, ориентированной на приложения. После определенной обкатки на инженерах Т-Банка его можно будет предлагать внешним пользователям в режиме SaaS и для on-premise-поставок. Рассказ о Spirit — в отдельной статье