Привет, Хабр!  Меня зовут Александр Сахаров, я Член Правления и директор по работе с технологическими партнерами компании «Диасофт».

Недавно провели Летний день для клиентов и партнеров – на нем мы представили наше видение ИИ трансформации процесса разработки ПО и провели демонстрацию новой AI Driven версии нашей Экосистемы Digital Q.

Ключевая мысль: уже этим летом любая команда разработки может скачать с сайта Экосистему Digital Q и начать выпускать ПО высочайшего качества со скоростью в 10 раз быстрее, чем сегодня.

Обо всем по порядку. С начала года все крупнейшие лидеры выпустили свое видение в части ИИ трансформации процесса разработки. Это сделали и Google, и Anthropic, а также все крупнейшие консультанты от Gartner до Bain. Вишенкой на торте стал доклад Кирилла Меньшова AI Disrupt PDLC в Сбере.

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

1.     «Зоопарк ИИ-инструментов» — много инструментов без оркестрации. Каждая команда выбрала свою связку. Через год при попытке что-то унифицировать обнаруживается, что у вас не «AI-стратегия», а пятнадцать несвязанных AI-платформ — и каждая со своим бюджетом

2.     «ИИ только в кодировании» — применяется в 25–35 % рабочего времени разработчика, а не во всех фазах SDLC. Логика тут жёсткая: кодинг — это треть инженерной работы, ещё 10–30 % уходит на поиск информации, остальное — проектирование, ревью, согласования. AI в кодинге даст вам потолок 30 % прироста в кодинге, то есть 10 % на полную работу инженера. И всё. Дальше — упёрлись.

3.     «Инерционный вендор-лок» — зависимость от одного поставщика модели или инструмента. Сбер тут, кстати, немного двусмыслен: они против лока, но при этом строят свой стек. Что не отменяет правильности самой мысли

4.     «Пилоты не масштабируются» — классика: пилот команды из 5 человек удался, попытка повторить на 50 — провалилась. Обычно вскрывается через полгода после того, как руководство уже отчиталось об успехе.

 Наиболее важные конструктивные выводы лидеров, пожалуй, лучше всего удалось подытожить Кириллу Меньшову в его отчете, они приведены ниже с небольшими корректировками на основе нашего опыта:

1.     Фреймфорк (или Harness) важнее LLM модели - 98 % против 2 %. Около двух процентов инженерной ценности агентного pipeline даёт логика принятия решений в самой модели. Остальные девяносто восемь — это детерминированная обвязка вокруг: permission gates, recovery, evals, audit, context management, tool routing, policy hooks.

2.     Скрытый технический долг от Copilot-ов - Код пишется на 35 % быстрее, но содержит на 25 % больше уязвимостей. Около четверти проблем доезжают до прода. Сложность кода растёт на 40 %. Прогноз: к 2028 году 40 % предприятий, использующих агентные инструменты, удвоят расходы на AI-кодирование — из-за пробелов в управлении. Не из-за моделей, а из-за процессов

3.     Бизнес компетенция важнее кода - Главное это бизнес-компетенция и правильность постановки бизнес задачи. Генерация всех артефактов производства это практически автоматический процесс, который оркестрируется фреймворком: код, документы, бизнес-процессы, тестирование и все остальное

4.     Стоимость токенов может съесть весь ИТ бюджет - Мульти-агентная архитектура съедает примерно в 15 раз больше токенов, чем chat-режим. Без системного контроля затраты на агентов могут составить 40–60 % всего IT-бюджета к 2027 году. Автоматический выбор оптимальной модели под задачу даёт экономию 60–70 % токенов. Кэширование системных инструкций — до 10× снижения стоимости input-tokens

Самый ключевой вывод, на нашему мнению, это появление и выделение новой двухконтурной модели работы команд, где явно выделен «Контур замысла» («Петля намерений» в терминологии Сбера) и «Контур реализации» («Петля реализации» у Сбера). При этом самое важное это то, что основой работы этой модели является оркестрирующая все IDP -  integrated Development Platform, в нашем случае Экосистема разработки Digital Q.

По нашему опыту и опыту западных лидеров появление двухконтурной модели кардинально меняет роли в команде: команда разработки сужается с 12 до 4-5 человек, будучи оснащенной правильными инструментами. Команды разработки начинаю выпускать в разы больше качественного контролируемого кода. Разработчики перестают быть «наборщиками кода» и превращаются в «продуктовых инженеров», чья основная компетенция – правильная постановка бизнес-задачи.

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

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

1.     Полный и правильный процесс производства - Экосистема/IDP представляет собой единую операционную среду, обеспечивающую лучший процесс создания ПО («золотой путь») от этапа исследования до промышленной эксплуатации. Важно что здесь в полной мере имеется в виду весь процесс производства: проектирование архитектуры, процессов, потоков, экранных форм, ролей, безопасности, формирование всех видов документации, планирование и проведение всех видов тестирование, контроль всех стандартов, поддержка РБПО, все этапы DevOps пайплайна, все виды проверок, сборок, пересборок и очень много всего того, что подразумевает под собой «золотой путь» процесса разработки.

Именно Экосистема (IDP) содержит в себе все знания и опыт, который гарантирует вам то, что вы не получите в результате «черный ящик полный галлюцинаций и уязвимостей», а также не потратите на это колоссальные деньги на токены». Как будет сказано ниже именно качество выбранной вами экосистемы (IDP) дает вам нужные показатели по скорости и качеству разработки

2.     Поддержка двухконтурной модели - Отсутствие Экосистемы/IDP приводит к деградации двухконтурной модели: агенты работают с несогласованными версиями спецификаций, контекст теряется между сессиями, а качество верификации становится непредсказуемым.

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

4.     10-кратный рост производительности - К 2028 году 90% корпоративных инженеров по разработке программного обеспечения будут использовать ИИ; конкурентное преимущество сместится в плоскость качества IDP. Команды со зрелой платформой работают в 10 раз быстрее команд, использующих разрозненные инструменты вендоров, благодаря единым маршрутам, единой библиотеке шаблонов и единой методике валидации ИИ-результатов.

5.     Радикальное сокращение затрат - Мульти-агентная архитектура съедает примерно в 15 раз больше токенов, чем chat-режим. Без системного контроля затраты на агентов могут составить 40–60 % всего IT-бюджета к 2027 году. Автоматический выбор оптимальной модели под задачу даёт экономию 60–70 % токенов. Кэширование системных инструкций — до 10× снижения стоимости input-tokens.

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

 Говоря о 10-кратном росте, мы опираемся не на гипотетические расчеты, а на реальные метрики, полученные при создании наших собственных продуктов и продуктов партнеров. Вот конкретный пример: недавно мы поставили перед командой задачу создать современную CRM-систему с нуля. Используя экосистему Digital Q и ИИ-агентов, мы прошли путь до полноценного промышленного продукта за 3 месяца. И ключевым фактором было не написание кода, а постановка задачи и плотная итеративная работа продуктовых лидеров.

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

 Таким образом, еще раз фиксируем, что ключевой фактор успеха это выбор правильной Экосистемы / IDP.

 Надо сказать, что в некоторых отчетах лидеров мы видим призыв к тому, что IDP можно собрать самостоятельно. Однако здесь мы можем поделиться собственным опытом: создание «золотого пути» разработки заняло у нас более 5 лет и это результат работы команды в составе более 50 человек. Наверное, такие расходы могу себе позволить крупные банки вроде Сбера или Яндекса, однако, мы очень сильно сомневаемся в том, что это целесообразно для кого-то кроме таких крупных компаний как приведенные выше. Этот самый «золотой путь» меняется с огромной скоростью, мы каждый квартал выпускаем несколько десятков обновлений к нему, которые является результатом большой и кропотливой работы на базе сотни параллельно ведущихся проектов. Весь наш накопленный опыт заложен в Экосистему разработки и каждый его может получить, просто скачав Экосистему с сайта. Не нужно 50 человек, которые создают этот «Золотой путь» - его можно просто начать использовать в нашей Экосистеме.

 На нашем мероприятии мы показали, как работает новая версия Экосистемы Digital Q. Ключевым документом является документ с бизнес требованиями (далее – БТ). Документ может быть просто загружен в чат Экосистемы и после этого начинаются первые этапы:

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

2)     На втором этапе происходит создание архитектуры. В соответствии со стандартами, определенными в Экосистемы определяются те модули, которые будут спроектированы заново и те модули которые будут переиспользоваться. Например, в стандартных настройках используется встроенные модуль управления ролями и профилями Q.Security, который имеет сертификат ФСТЭК, а также еще много других готовых модулей/библиотек, которые не имеет смысла пересоздавать заново.

3)     Третий этап это формирование визуальной схемы объектов, их свойств и сервисов API. На этом этапе появляются важнейшие артефакты: диаграмма объектов в 3й нормальной форме, WSDL описания всех сервисов, модель угроз и другие важные документы. Важно что в Экосистеме уже есть все необходимые инфраструктурные библиотеки и приложения для эффективной работы приложения в микросервисной архитектуре: Kubernetes, kafka, artemis, nginx, elk stack, spring, react, angular и др.

4)     На этом этапе уже начинается генерация кода, который реализует объекты и сервисы, описанные выше. В результате получается код, который жестко связан с созданной ранее моделью, а специальные ИИ агенты контролируют отсутствие расхождений и галлюцинаций. Важно, что уже на этом этапе приложение может быть собрано и проведено с весь CI/CD пайплайн, в котором огромное количество дополнительных quality gates

5)     Далее на основании созданной модели объектов и уточнений в исходном ТЗ формируется микро-фронт-енд. Делается это с помощью мастера, который проводит инженера через этапы создания UI, где происходит выбор дизайн системы и доступных принципов UI

6)     После формирование бэк-енда и фронт-енда экосистема приступает к моделированию бизнес процессов и потоков данных. На основе результатов первого этапа ИИ агенты создают диаграммы процессов и потоков в привычном виде в понятных человеку нотациях BPMN, DMN, подсвечивают в них неточности, ошибки и неоптимальности. Инженеры руками могут внес необходимые уточнения. Соответствующие BPM и ETL платформы, которые являются неотъемлемой частью экосистемы (Q.BPM, Q.DataFlows), позволяют в режиме онлайн провести различные виды тестирований и тестовых запусков. Бесшовная нативная интеграция этих инструментов с синхронными (REST) и асинхронными (Kafka, Artemis) механизмами взаимодействия с сервисами обеспечивает связность создаваемого приложения.

7)     Отдельное направление - это генерация автотестов для различных видов тестирований: регрессионное, нагрузочное, логическая связность бизнес процессов, контроль соответствия кода и визуальных схем и исходных БТ, контроль граничных условий и отдельное направления для статического и динамического контроля уязвимостей

8)     Далее экосистема оркестрирует весь CI/CD конвейер и огромное количество тестирование и контролей на этапах сборки и выведения ПО в промышленный контур. Специалисты хорошо знают насколько важно и сложно собрать эффективный пайплайн и какое количество проверок и ветвлений в нем может быть

9)     Отдельный трек – документация – ее огромное количество: для администраторов, для пользователей, просто Wiki, все необходимое с точки зрения требований регламента безопасной разработки. Иногда создать приложение намного легче, чем создать и сдать все необходимую документацию

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

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

Экосистема Digital Q это продукт компании Диасофт для ИТ компаний и для заказчиков ведущих процесс собственной или распределенной разработки. Продукт может быть скачан с сайта и полностью самостоятельно развернут для полностью самостоятельной работы. Компания выпускает обновления ежеквартально, что обеспечивает пользователю самые современные практики разработки.

Экосистема позволяет вести распределенную разработку сложнейших систем и может быть успешно использована для реализации проектов импортозамещения классических западных платформ таких, как SAP, Oracle (Siebel, APEX и др.), Microsoft (Axapta, Dynamcs и др.), Pega, Lotus и др.

Обратите внимание на ссылки на нагрузочные испытания, которые мы проводили для систем, которые получаются в результате генерации на базе Экосистемы. Системы легко выдерживают более 100тыс одновременно работающих пользователей при нагрузке 2000TPS.