Архитектура AI Dark Factory: сквозная автономная разработка и деплой кода через изолированные валидаторы

Архитектура AI Dark Factory: сквозная автономная разработка и деплой кода через изолированные валидаторы

В промышленном производстве термин «темная фабрика» (Dark Factory) описывает полностью автоматизированное предприятие, работающее без физического присутствия людей и без освещения в цехах. Применительно к программной инженерии эта концепция задает архитектуру автономного репозитория: систему, в которой кодовая база самостоятельно принимает требования к продукту, планирует изменения, запускает специализированных ИИ-агентов, независимо проверяет результат и доводит проверенный код до продакшн-сервера.

Интерактивное использование кодинг-ассистентов закрывает лишь базовые уровни автоматизации. В шкале делегирования задач (от L0 до L5) автодополнение строк (L0) и парное диалоговое программирование (L1–L2) требуют непрерывного внимания человека к каждому фрагменту. Уровень L3 оставляет за инженером роль архитектора, проверяющего каждый шаг. Архитектура AI Dark Factory переводит разработку на уровни L4–L5: репозиторий становится автономным конвейером, где человек формулирует цели верхнего уровня и сохраняет аварийный контроль.

Подход уже опробован на реальных сервисах — например, веб-приложении chat.dynamous.ai, которое поддерживается в автономном режиме. Чтобы система оставалась стабильной, архитектура опирается на пять несущих компонентов.

Пять несущих компонентов автономного конвейера

1. Workflow-репозиторий и headless-раннеры. Задачи исполняются автономными агентами в фоновом неинтерактивном режиме (headless mode) через интерфейс командной строки (CLI). На разных этапах можно задействовать Claude Code, Aider, Cline, Pi или Amp. Движок рабочих процессов — например, открытый оркестратор Archon — связывает в YAML-сценарий вызовы нейросетей, системные команды, тесты и операции Git в изолированных рабочих деревьях (worktrees).
2. Очередь задач и конечный автомат. Фоновый процесс раз в 30 минут опрашивает трекер задач GitHub Issues. Задачи проходят строгую цепочку состояний: сортировка (triaged), принятие в работу (accepted), разработка (in-progress), независимое тестирование (needs-review) и доработка дефектов (needs-fix). Очередь соблюдает жесткий приоритет: сначала исправление багов (needs-fix), затем независимая валидация (needs-review), далее исполнение принятых задач (accepted) и лишь затем разбор новых обращений.
3. Непрерывный Blue-Green деплой. Без доставки кода на рабочий сервер система остается лишь генератором пул-реквестов. В схеме Dark Factory развертывание идет через два идентичных контура: действующий (Blue) и резервный (Green). Новая версия приложения развертывается на неактивном сервере, проходит проверку доступности (health checks), после чего маршрутизатор бесшовно переключает рабочий трафик.
4. Трехфайловый уровень правил (Guidance Layer). Поведение агентов регламентируют три конфигурационных файла:
   • global-rules: общие правила репозитория, стандарты форматирования и соглашения о типах;
   • factory-rules: ограничения автономного режима — запрет на масштабные одновременные переработки, дробление изменений на компактные блоки (bite-sized tasks) и лимиты параллелизма;
   • mission.md: цели проекта и явные границы нецелевых задач (non-goals) из продуктовой спецификации (PRD), позволяющие отклонять нерелевантные тикеты.
5. Изолированный контур валидации (Validation Harness). Разделение ролей агента-строителя (Builder) и агента-валидатора (Validator).

Двухконтурная валидация: как избежать предвзятости строителя

Главный фактор деградации автономного кода — предвзятость строителя (Builder Bias). Если один и тот же агент пишет код и сам же создает для него проверки, модель неизбежно оптимизирует тесты под собственную реализацию или пропускает логические ошибки.

В AI Dark Factory действует информационный барьер:

• Агент-строитель (Builder) получает задачу, пишет код и создает локальные модульные и интеграционные тесты (unit and integration tests) в изолированной ветке.
• Агент-валидатор (Validator) подключается на этапе needs-review. Он не видит план реализации строителя и прогоняет отдельный набор скрытых сценариев (holdout scenarios). Эти сценарии формулируются до начала кодинга и описывают наблюдаемое поведение системы с точки зрения пользователя.

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

Уровень управления: роль mission.md и защита от зацикливания

Автономный агент без жестких ограничений склонен раздувать кодовую базу или браться за задачи, ломающие смежные компоненты. Файл mission.md служит постоянным фильтром требований.

При поступлении нового запроса сортировочный агент сверяет его с mission.md. Если задача требует функционала, помеченного как non-goal, тикет аргументированно отклоняется (reject issue). Это защищает очередь от противоречивых задач. Кроме того, правила factory-rules запрещают менять архитектуру целиком за один запуск: изменения декомпозируются на небольшие шаги, каждый из которых проходит полный цикл до деплоя.

Пошаговый цикл обработки задачи: от Issue до релиза

1. Постановка и сортировка. Сортировочный агент сверяет тикет с mission.md и переводит его в статус accepted либо отклоняет.
2. Изолированная разработка. Свободный headless-раннер переводит задачу в in-progress, создает изолированное рабочее дерево (Git worktree), пишет код и прогоняет локальные тесты.
3. Независимая верификация. Задача переходит в needs-review, где изолированный валидатор прогоняет holdout scenarios на собранном артефакте.
4. Слияние и предрелиз. При успешной проверке ветка сливается в main, запуская пайплайн непрерывной интеграции (CI).
5. Blue-Green деплой. Код развертывается в неактивный контур (Green), проходит прогрев и проверку доступности, после чего трафик переключается на обновленный сервер.

Практический регламент подключения и настройки навыков

Для развертывания контура Dark Factory в существующем репозитории используется официальный набор навыков Cole's AI Skills.

Порядок развертывания:

1. Подготовка спецификации. Формируется документ требований (PRD) с явным разделением целевых функций и ограничений (non-goals), например через навык plan-create-prd.
2. Установка пакета навыков. В Claude Code CLI подключение выполняется командами:

   /plugin marketplace add coleam00/skills
   /plugin install skills@cole-medin
   

   Для прямой установки файлов навыка через Node.js выполняется команда:

   npx skills add coleam00/skills --skill build-dark-factory
   

3. Генерация структуры фабрики. Агент запускает команду /build-dark-factory, передавая подготовленный PRD. Навык создает структуру каталогов, файлы global-rules, factory-rules, mission.md и конфигурации рабочих процессов.
4. Предстартовая верификация. До включения автоматического триггера раз в 30 минут инженер вручную проверяет созданные правила, подтверждает изоляцию тестов и настраивает секреты.
5. Безопасность. Токены доступа к API, SSH-ключи и пароли к базам данных запрещено помещать в правила или PRD. Они передаются исключительно через переменные окружения и защищенные хранилища CI/CD.

Инженерные барьеры: бюджеты, миграции данных и аварийный контроль

Автономная фабрика требует строгих инженерных предохранителей:

• Ограничение бюджета токенов. В конфигурации обязательно задаются предельное число попыток исправления на тикет и суточный лимит расходов API.
• Миграции баз данных. Изменения схем данных должны быть обратно совместимы с обеими версиями приложения (Blue и Green), иначе переключение трафика приведет к сбою.
• Аварийный стоп-кран. При повторных ошибках валидатора задача эскалируется человеку с блокировкой автоматического деплоя.

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