Код из спецификации, а не из чата: инженерный разбор ИИ-конвейера AI-driven Digital Q

Да, ИИ-агенты научились писать код, но релизы от этого быстрее не стали. 7 октября компания «Диасофт» представила новую версию экосистемы для разработчиков на базе ИИ – AI-driven Digital Q, где код пишет лишь один из нескольких десятков агентов, а вся остальная работа, от разбора записи встречи с заказчиком до подписанного релиза, автоматизирована как единый процесс. Разбираем, как этот конвейер устроен изнутри.

Digital Q уже несколько лет помогает собирать корпоративные системы на low-code платформах, а в новой версии вокруг них выстроен сквозной конвейер ИИ-агентов, разделенный на три контура: «Обнаружение», «Замысел» и «Реализация». На вход агенту можно отдать запись встречи с заказчиком, таблицы и презентации, а на выходе получить проверенный и подписанный релиз с тестами, документацией и актуальной спецификацией. Человек при этом ставит задачу, отвечает на вопросы агентов и принимает решения в ключевых точках.

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

О концепции AI-driven Digital Q эксперты компании уже писали в своих блогах на Хабре. Здесь сосредоточимся на инженерной стороне: как конвейер управляет потоком задач и контекстом, как проверяет результат и какие его приемы можно применить в разработке, даже не используя саму платформу.

Пять «граблей» ИИ-внедрения

Прежде чем проектировать конвейер, в «Диасофт» проанализировали опыт компаний, которые внедряли ИИ в разработку раньше и масштабнее других, и решили исправить ошибки, которые повторяются у всех. Самая заметная из них – это «зоопарк» инструментов: в одной компании одновременно живут полтора десятка несвязанных ИИ-платформ, и у каждой – свой бюджет, свои условия доступа и свой способ работы с данными. Тут и обнаруживается «культурный балласт», когда лицензии на ассистента купили всем, а в истории коммитов его почти не видно, потому что процессы и привычки команды остались прежними.

Еще одна типичная ошибка состоит в том, что ИИ применяют только для написания кода. Кодинг занимает примерно треть рабочего времени инженера, и по закону Амдала даже кратное ускорение этой трети дает прирост всего процесса в пределах 10%. Многие к тому же завязывают всю стратегию на одну модель или одного поставщика, а потом обнаруживают, что смена тарифа или условий доступа ломает выстроенные процессы. Венчают картину «пилоты», которые не масштабируются: на пяти энтузиастах все работает, а на пятидесяти – разваливается.

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

Чат и конвейер: в чем разница

Конвейер решает те же задачи, что и разработчик с ассистентом, но иначе распределяет ответственность. Разницу проще всего показать в таблице.

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

Спецификация как исходный код

Самый важный сдвиг, который стоит за конвейером, проще всего объяснить через аналогию с компилятором. Никто не правит руками байт-код: если программа работает неправильно, исправляют исходник и собирают заново. В AI-driven Digital Q роль исходника играет спецификация, а код становится артефактом сборки. Если результат не устраивает, правится спецификация, и код генерируется снова. Отсюда и одно из главных свойств системы: код не обрастает заплатками, а значит, не копит техдолг.

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

• дано: заявка на закупку в статусе «Черновик»;
• когда: инициатор отправляет ее на согласование;
• тогда: статус меняется на «На согласовании», руководитель инициатора получает задачу.

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

Маршрут задачи: что передается между этапами

Конвейер разделен на три контура: «Обнаружение» (Discovery), «Замысел» (Intent) и «Реализация» (Implementation). Удобнее всего следить за ним не по агентам, а по артефактам, которые переходят с этапа на этап, ведь именно они превращают разговор с заказчиком в проверяемую цепочку решений.

Контур «Обнаружение» запускается не всегда. В самом начале конвейер проверяет, нужно ли вообще исследовать исходные данные, и если задача уже сформулирована четко, сразу переходит к сценариям. Из «Замысла» в «Реализацию» задача попадает только после того, как человек подтвердил продуктовый замысел и создал репозитории для новых сервисов. В Digital Q компоненты называются PBC (Packaged Business Capabilities), и агент продуктового замысла в первую очередь ищет, какие из существующих PBC можно переиспользовать, а уже потом решает, что придется дописать.

«Реализацию» в «Диасофт» называют «расческой»: от общего основания отходят параллельные «зубцы», по одному на каждый затронутый сервис. «Зубцы» ничего не знают друг о друге и не обмениваются сообщениями, все необходимое каждый получает из задачи и контрактов, поэтому сервисы дорабатываются одновременно. Внутри «зубца» есть необязательная точка одобрения человеком, а после того как все ветки сходятся к основанию, приемка результата на стенде уже обязательна. Только после нее изменения упаковываются по компонентам и выпускаются.

Гейты, вопросы и предохранители

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

У каждого агента есть входной и выходной гейт. Входной проверяет предусловия: агента запустили на конкретном шаге, а нужные артефакты действительно на месте и относятся именно к этой задаче. Выходной работает как постусловие и проверяет, сделал ли агент то, что от него требовалось. Если данных не хватает, агент не имеет права их придумать: он записывает вопрос в файл questions.md, и выходной гейт не пропустит задачу дальше, пока там остается хотя бы один вопрос без ответа.

Разбирает такие остановки навигатор процесса (Dq-Navigate). Его можно вызвать с любого шага, когда срабатывает гейт, и он решает, нужно ли привлекать человека и на какой шаг вернуть управление. Возврат идет туда, где ошибка возникла, а не туда, где ее заметили. Если ревьюер нашел проблему, причиной которой стала неточная дельта-спецификация, задача вернется к проектировщику, а не к агенту, который писал код. От зацикливания защищает circuit breaker: число итераций в ветке ограничено, как и расход токенов, и если агенты начинают ходить по кругу, процесс останавливается и зовет человека.

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

Между собой агенты общаются исключительно через трекер и Git и знают друг о друге ровно столько, сколько описано в их входах и выходах. По сути это та же дисциплина, что и в микросервисной архитектуре: каждый агент для оркестратора выглядит как «черный ящик» с контрактом, и его можно заменить, не трогая соседей. Оркестрацией занимается Digital Q.Agents, который запускает конвейер по номеру задачи, а поскольку все состояние лежит в трекере и репозиториях, процесс продолжает работать в корпоративном дата-центре независимо от того, включен ли ноутбук инженера.

Движок агента тоже заменяем. Сейчас на большинстве этапов используется открытый OpenCode, но его можно заменить на Claude Code, GigaCode, KiloCode или любогой другого агента, который запускается из командной строки в Unix-среде. Многие навыки «зонтичные» и содержат точки расширения, куда можно встроить собственные поднавыки под конкретную отрасль или продукт.

Инженерия контекста и экономика токенов

Токены быстро превратились в отдельную статью расходов. В июне Gartner спрогнозировала, что к 2028 году расходы на ИИ-инструменты для программирования могут превысить среднюю зарплату разработчика, а опрос Gartner Peer Insights показал, что 23% руководителей разработки уже тратят на токены от $200 до $500 на одного разработчика в месяц. Как показывает опыт компаний, которые внедряли ИИ раньше других, при бесконтрольном использовании потребление токенов вырастает кратно, в отдельных случаях – в 15 раз. Чем больше агентов работает в процессе, тем острее вопрос, поэтому экономику разработчики закладывали в архитектуру платформы с самого начала.

Главное правило звучит так: детерминированное раньше вероятностного. Digital Q – это экосистема примерно из 30 low-code платформ, которые генерируют обычный код на Java Spring и Angular или React, и для типового приложения средней сложности 70–80% кода получается из детерминированных шаблонов, которые вообще не расходуют токены. Агент-разработчик первым делом вызывает генератор, получает каркас сервиса и дописывает только ту логику, которую шаблоном не опишешь. Линтеры, валидаторы и часть проверок тоже работают без языковых моделей.

Тот же принцип и в переиспользовании кода: готовое не генерируется заново. В экосистеме – сотни сервисов, от аутентификации и API Gateway до проигрывателя BPM-процессов и сервиса для работы с Kafka, и агенту дешевле встроить существующий компонент в конфигурацию системы, чем написать аналог с нуля. Новые компоненты создавать можно, но только после того, как обвязка убедилась, что это не дубль.

Модели при этом подбираются под задачу каждого этапа. Разбор видеозаписи встречи и сбор требований прекрасно выполняет компактная open-weight модель на собственном сервере, а мощные модели подключаются там, где без них не обойтись. К тому же выводу приходит и Gartner в рекомендациях по оптимизации токенов: агенты наиболее эффективны по затратам, когда работа разбита на небольшие задачи для небольших моделей, а к мощным переходят только с ростом сложности. Вместе с дозированным контекстом и лимитами на итерации это, по оценке «Диасофт», позволяет сократить расход токенов до 70%.

У такой архитектуры есть приятный побочный эффект: от поставщика модели вы не зависите. В «Диасофт» проверяли разные модели, в основном – развернутые на собственных серверах без выхода в интернет, включая GLM, Qwen и DeepSeek, и благодаря обвязке смена модели не превращается в переписывание процесса. Нет и привязки к самому вендору: сгенерированный код остается у заказчика и работает без платформ «Диасофт», а к ручной разработке можно вернуться в любой момент, сохранив при этом полное описание системы в спецификациях.

Сколько проверок проходит одно изменение

Если код пишет модель, вопрос «а кто это проверял?» становится главным. В конвейере проверки выстроены слоями, примерно как классическая пирамида тестирования, только каждый слой обслуживает свой агент.

Первый рубеж находится прямо внутри ветки сервиса. Агент-разработчик вместе с кодом создает модульные и API-тесты и техническую документацию, а агент-ревьюер (dq-openspec-review) заходит в задачу с чистым контекстом, иногда на другой модели, и проверяет, что код компилируется, тесты проходят и покрывают изменения, архитектурные паттерны и стандарты соблюдены, уязвимостей и секретов в коде нет, а линтеры не нашли нарушений. Модель, которая перечитывает собственный код в том же контексте, склонна соглашаться сама с собой, поэтому автор и проверяющий в конвейере – всегда разные агенты.

Следующий уровень относится к задаче целиком. Отдельные агенты генерируют тест-кейсы по сценариям, сформулированным еще в контуре «Замысел», поднимают стенд со всеми задействованными сервисами, генерируют тестовые данные и прогоняют тесты (dq-cypress-pipeline). Именно здесь возникает классическая ситуация, когда каждый сервис по отдельности работает, а вместе – нет. Дальше результат на стенде принимает человек, и без его решения задача в выпуск не попадет.

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

В собственных проектах «Диасофт» такая схема обеспечивает соответствие кода требованиям более чем на 99% и покрытие тестами свыше 80% там, где это применимо. Тест-кейсы и документация выпускаются вместе с кодом, а значит, больше не зависят от того, нашлось ли у кого-то время их написать.

Результаты и новая роль инженера

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

Полная запись показа доступна на сайте digitalq.diasoft.ru.

На полном цикле, от требований до релиза, в «Диасофт» проверили этот подход на решении собственных задач. Разработка CRM-системы с нуля на 75 сервисов и 21 PBC заняла три месяца, новый бизнес-компонент «Факультативное перестрахование» на десять сервисов и два PBC появился за полтора месяца, а прототип системы управления закупками для авиакомпании, три сервиса и один PBC, собран за два дня. В целом трудозатраты на этих проектах сократились на треть.

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

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

Что можно перенять уже сейчас

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

1. Разрешите агенту спрашивать. Заведите в задаче файл с открытыми вопросами и договоритесь, что работа не считается завершенной, пока в нем остаются вопросы без ответа. Агент, которому разрешено сказать «не знаю», ошибается заметно реже агента, от которого ждут ответа любой ценой.
2. Разделите роли автора и проверяющего. Ревью стоит запускать отдельным агентом с чистым контекстом и четким списком критериев, а не просить того же агента перепроверить себя в том же диалоге.
3. Ставьте детерминированное раньше вероятностного. Генераторы каркаса, шаблоны, линтеры и статический анализ дешевле и надежнее модели. Чем больше работы они забирают на себя, тем меньше токенов и галлюцинаций.
4. Храните изменения требований рядом с кодом. Дельта-спецификация в репозитории переживет любой чат и позволит через полгода понять, почему код устроен именно так.
5. Поставьте предохранители. Ограничьте число итераций и бюджет токенов на решение задачи. Агенты, которые раз за разом переделывают одно и то же, сигнализируют о проблеме в постановке задачи, а не о нехватке попыток.
6. Чините правило, а не результат. Если агент повторяет одну и ту же ошибку, правка в навыке или инструкции окупается быстрее, чем ручные исправления в каждой задаче.

Где это уместно и как развернуть

AI-driven Digital Q рассчитана на корпоративные системы, которые живут годами и развиваются несколькими командами. Лендинг на выходные или бот для домашних задач по-прежнему быстрее собрать в диалоге с агентом, и это нормально: у каждого инструмента – свой масштаб.

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

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

Вайб-кодинг никуда не исчез

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

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

Реклама. Рекламодатель ООО «Диасофт Экосистема» ИНН 9715403607, erid: 2W5zFHRDQwk