7 октября мы провели онлайн-презентацию новой, AI-driven версии экосистемы Digital Q (посмотреть видео с показа вы можете по ссылке). Мы впервые публично показали полную схему конвейера ИИ-агентов, разобрали контур за контуром и продемонстрировали, как он проводит реальную задачу от встречи с заказчиком до подписанного релиза. А теперь обо всем подробнее.

Мы в «Диасофт» вот уже 35 лет делаем корпоративный софт для крупных компаний, а в последние годы еще и продаем платформы, на которых такой софт собирают. Наша экосистема Digital Q – это около 30 low-code платформ. Они генерируют обычный код на Java Spring, Go, Angular/React, TypeScript, SQL – так, будто его написал аккуратный программист. Этот код работает и без наших платформ: его можно забрать и развивать самостоятельно, так что привязки к вендору (vendor lock-in) нет.

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

В новой версии Digital Q все устроено иначе. Вместо ассистента каждого разработчика работает конвейер из нескольких десятков агентов, через который задача проходит целиком. На вход подается то, что обычно есть у вас в начале проекта: запись встречи с заказчиком, пара таблиц Excel, полумаркетинговая презентация в PDF, которую кто-то когда-то согласовал. Агенты первого контура («Обнаружение») извлекают из этого бизнес-потребности и превращают их в сценарии использования. Агенты второго контура («Замысел») ищут, как это можно уложить в существующую архитектуру системы, какие готовые модули можно переиспользовать, а какие создать, и раскладывают работу на задачи в трекере на каждый задействованный компонент, сервис. Третий контур («Реализация») упаковывает и подписывает релиз. На выходе получают готовые, новые или доработанные компоненты системы, упакованные для поставки заказчику, с тестами, документацией и обновленной спецификацией. Если задача была создать новую систему, это будет система, собранная из таких компонентов. Ваша роль при этом – в том, чтобы поставить задачу, ответить на вопросы агентов и принять результат.

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

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

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

Код быстрее, релизы – нет: при чем тут закон Амдала

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

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

Инженеры познают здесь действие закона Амдала. Он придуман для параллельных вычислений, но и к процессам это подходит не хуже. Смысл в том, что как ни разгоняй одну часть работы, целое ускорится не больше, чем позволяет ее доля. А вот и формула, где p – это доля кодирования, а k показывает, во сколько раз агент его ускорил:

S = \frac{1}{(1 - p) + p / k}

Подставьте сюда 15% и ускорение в десять раз: получится 1,16, то есть плюс 16% ко всему циклу. Даже если агент начнет выдавать код мгновенно, потолок ускорения у него всего 18%. А теперь вычтите лицензии, видеокарты под локальные модели (заказчики не любят, когда их данные уходят в чужое облако) и время на освоение инструмента. От экономии мало что останется.

А вот вторая проблема заметна не сразу. Даже этот выигрыш плохо переносится с одного человека на команду. Подумайте, где живет контекст, когда разработчик работает с агентом в диалоге. В его голове, в истории переписки, а иногда и вовсе за пределами корпоративного контура. Человек ушел в отпуск, и решение задачи фактически начинается заново. Большую задачу, начатую таким образом, не поделишь между несколькими людьми: целиком план есть только у одного, а у остальных появятся свои трактовки. Решение, что экран готов и API можно отдавать, тоже принимает он один. А когда у агента кончается контекстное окно, он восстанавливает сжатую версию разговора и по дороге теряет шаги. В итоге удачный результат держится на одном инженере и не повторяется у соседа.

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

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

Три идеи, которые мы превратили в продукт

Если в последний год вы читали хотя бы пару больших текстов про агентную разработку, то наверняка заметили, что лидеры индустрии при всей разнице подходов сходятся в трех вещах. Источником истины становится спецификация, а не код. Обвязка вокруг модели оказывается важнее самой модели. А вместо одного универсального агента выгоднее держать команду узкоспециализированных. В Anthropic подробно писали о том, как обвязка и разделение работы между несколькими агентами определяют результат. В OpenAI говорили, что главным артефактом разработки становится спецификация, а GitHub выложил в открытый доступ Spec Kit – набор инструментов, с помощью которых разработку ведут от спецификации, а не от кода. Если вы следите за темой, многое, о чем я скажу ниже, покажется знакомым. Разница в том, что у нас эти идеи не остались на слайдах: мы собрали из них работающий конвейер поверх своих платформ и довели его до создания продукта, который можно поставить заказчику.

Начнем с главного. В подходе Specification Driven Development (SDD) источником истины служит спецификация, а не код. Результат получился плохим? Править нужно не код, как при вайб-кодинге, а спецификацию, и код родится заново. В основе у нас – открытый фреймворк OpenSpec. Любое изменение в нем оформляется как дельта: новая задача не трогает основную спецификацию, к ней пишется дельта-спецификация, по ней создается код, а после успешного завершения дельта сливается с основой. Сценарии хранятся в формате given, when, then: дано, когда происходит это, тогда система делает вот так.

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

Следующая идея звучит почти как ересь для тех, кто следит за рейтингами моделей: обвязка важнее модели. В англоязычных текстах ее называют harness. Мы перепробовали много моделей, большинство – на собственных серверах, без выхода в интернет: GLM, Qwen, DeepSeek и другие, и каждый раз убеждались, что результат определяет не столько модель, сколько то, что вокруг нее. Откуда агент берет контекст и как его обрабатывает, какие у него входные и выходные условия, какие валидаторы и политики безопасности стоят на пути, в какой среде он исполняется. Модель уровня state of the art, разумеется, справится лучше компактной open-weight модели, развернутой на собственном «железе». Задача обвязки в том, чтобы и компактная модель выдавала результат нужного качества, а замена одной модели на другую не превращалась в переписывание процесса.

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

Схема целиком: экскурсия, которую мы еще никому не проводили

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

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

В Discovery – три агента. Первый собирает данные из всего, что ему дали: протоколы встреч, документы, письма, выгрузки, аудио- и видеозаписи, которые встроенный транскрибатор переводит в текст. Он структурирует сырой материал и приводит его к единому виду. Второй выявляет в этой россыпи фактов реальные бизнес-потребности: снимает противоречия, когда один участник встречи сказал одно, а другой – другое, и формулирует общую задачу: что именно и для кого мы хотим улучшить. Третий, агент формирования сценариев, переводит потребности на язык конкретных действий пользователя в системе. Сценарии пишутся в формате given, when, then и получаются достаточно подробными, чтобы их понял и заказчик, и машина. На выходе контура – первая точка контроля за человеком: продакт-инженер проверяет сценарии и согласует их с заказчиком, и только после этого задача идет дальше. Здесь нет нужды в самой дорогой ИИ-модели на рынке: чтобы разобрать видеозапись встречи, вполне хватает компактной open-weight модели, а сэкономленные токены достаются тем этапам, где без мощной модели действительно не обойтись.

Во втором контуре, Intent, согласованные сценарии превращаются в план изменений. Открывает его агент продуктового замысла – его мы считаем сердцем всей схемы. Он примеряет сценарии к существующей архитектуре: через каталог модулей смотрит, что у нас уже есть и похоже ли это на нужное, и составляет список кандидатов с запасом. Следующий агент детально изучает их контракты, отбрасывает лишнее и решает, какие готовые модули подойдут, что в них придется доработать, что создать заново и как изменение впишется в линейку. В Digital Q такие модули называются PBC (Packaged Business Capabilities) – из них, как из кирпичей, собираются системы. Раньше эту роль играл опытный архитектор, который внимательно изучал свежую схему от команды и подсказывал: подождите, у нас уже есть три таких компонента, их надо просто соединить. Теперь так рассуждает агент, и благодаря ему никто не пишет одно и то же в четвертый раз. Если архитектуру нужно согласовать с заказчиком, к работе подключается еще один агент и рисует ее так, чтобы картину понял человек без технического бэкграунда. Замысел проверяет продакт-инженер, и это главная точка контроля: правильно ли выбраны модули, что переиспользуется, а что действительно меняется. После этого агент декомпозиции раскладывает замысел на конкретные сервисы, новые или дорабатываемые, и прописывает все вплоть до мелочей: какие библиотеки использовать, какие методы и с какими параметрами. Каждый сервис получает контракты взаимодействия с соседями с точностью до семантики, даже если соседа еще нет в природе, поэтому в реализации ветки смогут работать параллельно. Одновременно отдельный агент пишет тестовые сценарии по задаче целиком: проверку важно придумать до реализации, чтобы потом не подгонять ее под готовый код. Заканчивается контур тем, что в рабочем трекере появляются задачи на каждый сервис, а рядом с ними – общий тестовый сценарий, по которому потом станет ясно, решена ли задача на самом деле.

Контур реализации, Implementation, мы рисуем «расческой»: от общего ствола отходят параллельные зубцы, по одному на каждый затронутый сервис. В каждом зубце – свой небольшой конвейер, работающий по тем же правилам SDD из четырех агентов. Друг с другом ветки не общаются, все нужное им уже передал продуктовый замысел.

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

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

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

Как устроен отдельный агент

Технически каждый агент – это навык, построенный по общим правилам: имя, описание, алгоритм, куда смотреть и куда обращаться. Если агенту нужен список существующих сервисов или контракт соседнего компонента, в навыке прямо написано, какой MCP-инструмент вызвать и с какими аргументами. Выдумывать контракт запрещено, его надо получить. Для каждого агента автоматически собирается карточка: что он делает, что получает на вход и что отдает на выход. Многие навыки – «зонтичные», в них есть точки расширения, куда можно встроить собственные субнавыки под другую отрасль или продукт.

У каждого агента есть входной и выходной гейт. Входной проверяет, что агента запустили вовремя и нужные артефакты на месте: если он проверяет код, то код действительно написан по этой задаче. Выходной гейт – это самопроверка: сделал ли агент то, что от него требовалось. Если агент не уверен, он задает вопрос. Технически вопрос записывается в файл questions, и гейт не пропустит задачу дальше, пока там есть хоть один неотвеченный вопрос. Такие вопросы разбирает агент-менеджер (навигатор): по встроенной детерминированной карте решений он понимает, как обрабатывать те или иные ситуации. Например, вернуть задачу на предыдущие этапы с уточненным заданием или позвать человека. Оператора зовут тогда, когда не находится четкого ответа в карте решений навигатора. Скажем, сработал лимит по токенам или итерациям: если агенты в пятый раз переспрашивают друг друга, пора вмешаться. Придумать ответ и пойти дальше агент не имеет права. Либо вопрос, либо отказ с пометкой в выходном артефакте и вариантами, как поступить.

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

На большинстве этапов движком сейчас служит OpenCode, открытый агент, и мы этого не скрываем. Ничто не мешает вынуть его и поставить Claude Code, GigaCode, KiloCode или любого другого агента, который запускается из командной строки в Unix-среде. Часть этапов вообще обходится без языковых моделей: это скрипты, линтеры и валидаторы, а детерминированный шаг, там, где он возможен, всегда дешевле и надежнее вероятностного. Агент привязан не к модели, а к своей роли.

Low-code, который должен был умереть

Наверняка у вас уже возник вопрос: зачем  low-code, если агент пишет сервис за минуты? Мы задали его себе раньше вас, и для компании, которая продает low-code платформы, вопрос был не из приятных. Логика казалась железной: платформа, генерирующая каркас, становится лишней. Мы всерьез ждали, что low-code начнет тихо умирать. Вышло наоборот, и сейчас мы считаем его фундаментом всей схемы.

Low-code в нашем понимании – это не конструктор для тех, кто не умеет программировать, а надежный каркас приложения. Платформа генерирует типовую часть компонента по правилам, которые компания вырабатывала годами, а разработчику, будь то человек или теперь агент, остается написать только ту логику, что действительно требует инженерной мысли. Все простое, вроде CRUD-операций и объектов базы данных, генерируется автоматически, а сложное, например, расчет графика платежей, пишется вручную или агентом. Для типового приложения средней сложности 70–80% кода получается из детерминированных шаблонов.

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

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

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

Здесь вы наверняка спросите: а что будет, если однажды отказаться и от конвейера, и от наших платформ? Код, который создали платформы и агенты, никуда не денется: он остается у вас и прекрасно работает без них. Агенты пишут его по нашим стандартам и используют только те сервисы, которые им велено использовать, поэтому такой код легко читать. Вернуться к полностью ручному программированию можно хоть завтра, и сделать это даже проще, чем раньше: кроме понятного кода, у вас останется  полное описание его человеческим языком, которое прежде было размазано по Confluence и памяти ведущих разработчиков.

Кто работает в команде, где код пишут агенты

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

Привычная эстафета, в которой аналитик передает задачу разработчику, а тот – тестировщику, в конвейере теряет смысл: артефакты сами переходят от агента к агенту, и передавать из рук в руки больше нечего. На смену такой эстафете приходит роль, которую мы называем продакт-инженером. Это человек, который ведет задачу через конвейер от начала до конца: ставит ее, отвечает на вопросы агентов и принимает результат. Прежние специализации при этом никуда не исчезают, а превращаются в дополнительные роли. Один продакт-инженер приходит из тестирования, другой – из системного анализа, третий – из фронтенда, четвертый – из бэкенда, и именно такое сочетание опыта делает команду сильной. Сегодня типичная команда у нас насчитывает 10–12 человек, а мы хотим прийти к пяти-шести, а затем и к трем-четырем, не потеряв при этом автономности. Компактная команда, в которой собраны все нужные компетенции, движется быстрее, поэтому к меньшему составу мы идем постепенно, по мере того как люди осваивают новые роли.

Как выглядит работа продакт-инженера, проще показать на примере. Опытный бэкенд-инженер просматривает задачи, решенные конвейером. Код работает, тесты «зеленые», но он замечает, что сервис достает документы из базы по одному в цикле, хотя мог бы взять пачку одним запросом и сэкономить на сети и разборе ответа. Раньше инженер просто поправил бы код, а теперь он его не трогает и вместо этого пишет новый навык про групповую обработку объектов одного типа, с примерами, как надо и как не надо, указывает, когда его применять, и ставит в конвейер задачу: исправь все такие места по этому правилу. Задача проходит через конвейер целиком, а инженер хотя бы в первый раз смотрит, что навык действительно «подцепился». Исправлена не одна ошибка, а целый класс ошибок, и в следующий раз агент ее не повторит.

Вокруг продуктовых команд остаются обеспечивающие. Кто-то должен следить, чтобы под каждого агента вовремя поднималась среда исполнения и работали все MCP-серверы, и кто-то разрабатывает самих агентов. При этом команда, отвечающая за конвейер, сама не должна превратиться в узкое место. Если на AI-SDLC конвейер завязано все производство, то при любой его поломке встает половина компании, а «бутылочное горлышко» просто переехало на новое место.

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

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

Практика: от поверхностного ТЗ – до прототипа за три дня

Прежде чем переходить к кейсам, посмотрите, как это выглядит вживую. В коротком ролике конвейер проводит задачу через агентов всех трех контуров, от разбора требований и проектирования до кода, тестов и результата на развернутом стенде (Видео доступно по ссылке. Полную запись трансляции показа можно запросить на сайте digitalq.diasoft.ru)

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

Заказчик собирался разрабатывать большую корпоративную систему и выбирал инструменты, в том числе агентные. Low-code его заинтересовал, когда стало понятно, что около 70% кода можно получить готовым, написанным людьми и стабилизированным за годы работы. Дальше он предложил простую проверку: вот наше ТЗ, загрузите его в ваш конвейер и покажите, какой прототип он соберет. ТЗ было, скажем мягко, поверхностным: набор Excel-файлов и базовое описание сценариев. Для конвейера это не стало препятствием: система была известного класса, и агенты дополнили скупые требования знаниями о наших компонентах и типовых сценариях. Работали два человека, причем не из разработки, а из команды внедрения: аналитик и фронтенд-разработчик. За три дня, из которых полдня ушло на то, чтобы платформенная команда передала им агентов и настроила их, получилось пять бизнес-сценариев большой корпоративной системы, 27 экранных форм и длинные BPMN-процессы на несколько экранов. Все это собралось в прототип целевой системы, который показали заказчику.

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

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

Почему мы все равно считаем это сдвигом, лучше всего объясняет проект из прошлого. Крупный клиент дал нам очень подробную спецификацию, с картинками: «нажимаю эту кнопку, в этом поле появляется вот это». Для ИИ это был бы идеальный вход. Мы писали код по сценариям и через месяц приходили показывать. Клиент смотрел и говорил: да, но кнопку надо не здесь, справочник не такой, а вот это вы описали плохо или передумали, когда увидели, что получилось. Правились картинки, и мы уходили еще на месяц. Проект длился полтора года, и большая часть этого времени ушла не на код, а на ожидание следующей итерации. Сейчас спецификацию в формате given, when, then можно разобрать вместе с клиентом, поправить, тут же запустить конвейер и посмотреть результат через часы или дни.

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

Где конвейер раскрывается в полную силу

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

Сильнее всего конвейер ускоряет работу команды, у которой уже выстроено производство: понятно, откуда приходят требования, кто их анализирует, кто отвечает за выпуск и как устроены тестирование и CI/CD. Он ускоряет тот процесс, который у вас есть, поэтому если пока все держится на договоренностях в чатах, начать стоит с порядка в процессах. Проверить себя легко: если кто-то нагенерировал 50 приложений, которые оказались не нужны, то дело не в агенте, а в том, что не было трекера, где эту работу заказали, и каталога модулей, где видно, что половина из них уже существует. Конвейер как раз держит обе эти вещи под контролем: задачи живут в трекере, а агент продуктового замысла всегда сверяется с каталогом готовых модулей.

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

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

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

Следующая остановка конвейера

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

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

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

Вместо заключения: ваша следующая задача

В самом начале мы предложили вспомнить вашу последнюю задачу и посчитать, сколько дней из нее ушло на код. Закон Амдала говорит, что, как ни разгоняй эти 10–15%, весь путь станет короче не более чем на 16–18%, сколько бы денег ни ушло на подписки. Конвейер работает с другой частью уравнения. Он ускоряет не написание кода, а все остальное, ту самую долю работы, которую раньше вообще не получалось ускорить.

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

Вайб-кодинг при этом никуда не делся. Он стоит на нашей схеме там же, где стоял: один этап из 30-ти в середине «расчески». В начале года он и у нас, как почти у всех, был единственным этапом, который умели ускорять агенты. Теперь вокруг него нет пустого места, ведь мы его заполнили.

Проверим арифметику на вашем процессе? Укажите в комментариях всего два числа: сколько дней в среднем проходит от разговора с вашим заказчиком до постановки задачи в трекере и сколько дней до выпуска релиза уходит собственно на код. Давайте сравним с нашими 10–15%.