ИИ‑фабрика: переход к автономной разработке

Что делать, когда процесс разработки с ИИ‑агентами уже устоялся, но всё ещё приходиться сидеть рядом с ними и ждать, когда они закончат очередной этап работы, чтобы запустить следующий?

У меня это выглядит так. Появилась идея новой фичи для разработки. Я запускаю /opsx:explore скил OpenSpec и обсуждаю с ИИ как будем делать эту фичу, какие нюансы и детали надо предусмотреть. Когда открытых вопросов не остаётся, перехожу к /opsx:propose, чтобы подготовить спецификации перед разработкой. Потом ревью спек с помощью команды /review-artifacts и правка найденных нестыковок. Дальше запускаю /opsx:apply-sequential для реализации в автономном режиме и чистым контекстом агента для каждой подзадачи. Потом ревью через /audit-implementation и правки после него. Архивирование изменения через /opsx:archive. И наконец‑то создание PR, финальное ревью и merge.

И так раз за разом! На простых задачах моё участие сводится к запуску команд и подтверждению предложенных решений. На задачах посложнее отвечаю на вопросы наподобие какую из альтернатив выберем. Хотя этот выбор можно сделать по критериям, зафиксированным в проекте. Это уже начинает утомлять. Пришло время автоматизировать и эту рутину. Так я начал делать свою фабрику, где ИИ‑агенты («гномы») трудятся в полностью автономном режиме. А к человеку обращаются только тогда, когда столкнулись с проблемой, которую не могут решить сами.

Требования к автономной фабрике

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

1. У меня уже есть устоявшийся процесс разработки и инструменты (GitHub, Jira, SonarQube, Jenkins, тестовые среды, и так далее), которые я для этого использую => нужно переиспользовать то, что уже есть и настроено.

2. ИИ ускоряет процесс написания документации, тестов, кода в десятки и сотни раз, но имеет и недостатки => нужно взять достоинства инструмента и закрыть его недостатки.

3. Недерменированный результат работы ИИ‑агента, а нужен надёжный стабильный результат => нужно использовать чёткую логику (программы/скрипты) везде, где можно, а нечёткую логику (ИИ) только там, где без неё не обойтись.

4. ИИ модели не следят за качеством написанного кода, так как натренерованы на выполнение задачи самым коротким путём => нужно проверять качество результата их работы на каждом этапе.

5. Сегодня один провайдер предоставляет ИИ модель лучше, чем другой. Завтра наоборот => нужна возможность использовать разные модели и провайдеров.

Список можно продолжать и дальше, но для понимания принципов этого хватит.

Архитектура фабрики

Под эти требования вырисовывается следующая архитектура.

Диаграмма архитектуры

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

Настройка конвейера фабрики

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

IDEF0/ICOM модель

IDEF0/ICOM модель с петлёй контроля качества очень хорошо подходит для этого. Вы описываете каждый этап своего процесса. Что будет входными данными для этапа, что будет выходными. Инструкции и правила, по которым вход преобразуется в выход. Инструменты, с помощью которых будет осуществляться работа. И правила контроля качества. Для фабрики описание стадий хранится в stage.yaml файлах.

Описав так этап за этапом, их можно выстроить в конвейер, зафиксировав порядок стадий в pipeline.yaml. Когда процесс разработки нужно поменять, то достаточно будет обновить конфигурацию и перезапустить фабрику.

Позови своего человека, если что‑то пошло не так

Когда гном сталкивается с проблемой, которую не может решить сам, он паркует задачу и эскалирует её человеку. Делается это через таск трекер. Фабрика помечает задачу как gnomish:needs-human и добавляет комментарий с причиной эскалации. Это может быть инфраструктурная проблема, когда не хватает прав или доступов, или вопрос, на который гному нужен ответ, чтобы продолжить свою работу.

Эскалация человеку

Человек решает проблему, оставляет гному комментарий и переводит задачу в gnomish:ready. Фабрика отслеживает это и возвращает задачу обратно в работу.

Чтобы эскалаций с вопросами было меньше, буду встраивать механизм арбитра. Арбитру можно будет описывать критерии по принятию решений. Тогда он сможет ими руководствоваться и отвечать на большинство вопросов гнома. Например, гном видит, что нужно поменять структуру данных в БД, и хочет спросить нужно ли поддержать обратную совместимость со старой структурой. В инструкциях арбитра написано, что проект сейчас находится на стадии MVP, реальных пользователей ещё нет, скорость разработки сейчас важнее. Тогда гном получит ответ от арбитра, что на обратную совместимость время тратить не будем. Или наоборот, проектом уже активно пользуются. Тогда арбитр ответит, что нужно обязательно реализовать обратную совместимость и добавить информацию об этом в документацию. В таких случаях эскалация до человека доходить не будет. Правила арбитру можно будет добавлять по мере необходимости в его md файл.

Дай погонять фабрику

Код фабрики лежит вот тут. А тут небольшой HelloWorld проект для тестирования. Можно сделать форк и погонять у себя (нужны установленные claude code, openspec, java 25, git). Можно посмотреть видео демо фабрики на три минуты.

Заключение

Когда начинал этот проект, то думал, что он будет простым. Но по мере работы всплывали неочевидные детали и сложности. Что привело к очень интересным архитектурным решениям, которыми могу поделиться.

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