Почему нынешние ИИ-агенты для кода не умеют доводить от нуля до прода — и что мы с этим сделали

Самое цитируемое обещание мультиагентных ИИ-инструментов в 2026-м: «команда агентов доводит вашу идею от нуля до прода». Откройте маркетинговые страницы Devin, Replit Agent, Factory.ai, режима агента в Cursor — все они это подразумевают. Некоторые показывают это на игрушечных проектах.

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

Мы намеренно разделили задачу на два продукта. Simple Container — открытая инфраструктурная основа. Forge — мультиагентный движок процессов, который умеет им пользоваться. Вместе они действительно дают путь от нуля до прода; по отдельности не дал бы ни один.

Что на самом деле требует «от нуля до прода»

Пройдём реалистичную поставку фичи: новый эндпоинт /api/orders поверх таблицы в Postgres, с вебхуком Stripe, задеплоенный за ai.your-domain.com. Шаги:

1. Понять требование. Объём от PM, крайние случаи, критерии приёмки.
2. Спроектировать схему и форму эндпоинта. Архитектурные решения, модель данных, контракт API.
3. Написать код. Хендлер, миграция, валидация, тесты.
4. Поднять инфраструктуру. База Postgres, секрет вебхука Stripe, сертификат ACM, DNS-запись, хранилище секретов.
5. Подключить учётные данные. Строка подключения к Postgres, ключ Stripe, ключ OpenAI, если сервис использует ИИ, — зашифрованные при хранении, расшифровываемые только на деплое.
6. Собрать и просканировать артефакт. Docker-образ, скан CVE, подпись cosign, SBOM в CycloneDX, происхождение SLSA.
7. Задеплоить с возможностью отката. Состояние в Pulumi/Terraform, blue/green или канарейка, атомарный откат к прошлой версии.
8. Проверить в проде. Постучаться в эндпоинт, посмотреть логи, поискать ошибки.
9. Закоммитить и оставить след. История git по каждому изменению, подписанные коммиты, описание изменения, кто что подтвердил.

Одноагентный CLI (Claude Code, режим агента в Cursor) спокойно делает шаги 1–3. Он рассыпается начиная с четвёртого. Попросите Claude Code «подними базу Postgres в AWS и DNS-запись в Cloudflare» — получите правдоподобный на вид Terraform, который не запускается, или, хуже, запускается и оставляет состояние испорченным, потому что его никто не отслеживал. Попросите «подключить учётные данные Stripe» — получите ключи открытым текстом, закоммиченные в .env.local, который через пять минут окажется в окне контекста LLM и вполне возможно в её следующем ответе.

Дело не в том, что Claude Code плох. Дело в том, что CLI, который умеет только работать с файловой системой, — неподходящая абстракция для шагов 4–9.

Почему мы сначала сделали Simple Container открытым

Simple Container — это основа. Он в проде уже пять лет у ряда платящих партнёров-заказчиков. Это:

• Одна декларативная модель деплоя сервиса. server.yaml для общей инфраструктуры, client.yaml для сервиса, который ею пользуется, три типа деплоя (cloud-compose, single-image, static).
• Мультиоблачность по устройству. AWS Lambda / ECS Fargate / RDS, GCP Cloud Run / GKE Autopilot / Cloud SQL, свой Kubernetes. Одно и то же описание сервиса; меняется шаблон.
• Секреты, зашифрованные при хранении, прямо в git. Шифруются вашим SSH-ключом — RSA или Ed25519, — с поддержкой нескольких ключей (каждый допущенный коллега расшифровывает своим). Модель угроз после ИИ: агенты, читающие ваш репозиторий, видят шифротекст, а не значения.
• Встроенная цепочка поставок. sc release create -s my-service -e prod прогоняет сборку → скан → подпись → SBOM → происхождение → деплой. Cosign, CycloneDX и SLSA Build L3 одной командой.
• Генерация CI/CD из блока cicd: в родительском стеке. sc cicd generate -s <stack> производит процессы GitHub Actions; вы их коммитите и забываете.
• MCP-сервер, встроенный в CLI: sc assistant mcp --port 7331 выставляет примитивы SC как инструменты Model Context Protocol.

Последний пункт и есть мост к Forge.

Что Forge добавляет сверху

Forge — движок процессов для команд ИИ-агентов. Вы описываете команду обычным языком — «мне нужны PM, архитектор, разработчик, QA и ревьюер; PM проверяет каждую передачу» — и Forge генерирует спецификацию процесса из именованных персонажей с переходами и назначенным управляющим агентом. Каждый персонаж работает на подходящем рантайме; каждая передача — коммит в ветке, ограниченной процессом; управляющий агент проверяет каждый переход вердиктом (продвинуть / обогатить / эскалировать). Страница движка →

Конкретно для задачи «от нуля до прода»:

• Шаги 1–3 всё ещё работа в форме LLM. Персонажи PM, архитектора и разработчика в Forge делают их последовательно, со структурированными передачами, а не одним агентом, всасывающим всю задачу в одно окно контекста.
• Шаги 4–6 идут через примитивы SC, с которыми Forge говорит по MCP. Персонаж-разработчик не лезет в шелл и не запускает terraform apply — он делает типизированные вызовы инструментов sc deploy, sc image scan, sc release create. Агент никогда не держит учётные данные открытым текстом в собственном адресном пространстве; исходящий прокси SC подставляет их на границе.
• Шаг 7 — это sc release create -s my-service -e prod. Состояние на Pulumi, скан + подпись + SBOM + происхождение прикреплены артефактами, откат — это pulumi stack rollback или команда сноса.
• Шаг 8 — раунд проверки — это персонаж QA в Forge, работающий по только что развёрнутому окружению с ограниченным сессионным токеном.
• Шаг 9 — аудит в git — по устройству. Передача каждого персонажа — подписанный коммит в ветке, ограниченной процессом. git log и есть аудиторский след. gh attestation verify доказывает, что сборка легитимна.

Дыра, которую мы закрыли в своей архитектуре, — не «заставить агентов писать код лучше». Это «сделать так, чтобы, когда агент говорит „я задеплоил“, действительно оказалось развёрнуто нечто проверяемое, а использованные им учётные данные не утекли».

Почему это разделение — архитектура, а не случайность

Частый вопрос от потенциальных заказчиков: «А нельзя просто вшить SC в Forge?» Можно, но это упускает суть.

Simple Container намеренно открытый и намеренно полезен без Forge. DevOps-команда, которая не хочет ИИ-агентов рядом со своим конвейером, всё равно может взять SC завтра и получить всё перечисленное — декларативные описания сервисов, зашифрованные секреты, аттестации цепочки поставок. Ценность приходит до того, как ИИ вообще станет темой разговора.

Forge намеренно только про агентов и намеренно только про Forge. Именно в нём живёт агентная оркестрация — процессы из нескольких персонажей, проверка управляющим агентом, генерация спецификации с естественного языка. Вшивать это в SC было бы неправильно, потому что большинству пользователей SC оно не нужно, а отдельная поставка агентного слоя — то, что позволяет его брать неинженерным покупателям: владельцам агентств, администраторам клиник, операторам в малом бизнесе без платформенной команды.

Разделение совпадает и с путём заказчика. SC — недорогой вход: получить инфраструктурные примитивы, зашифрованные секреты, конвейер цепочки поставок, мультиоблачную абстракцию. Forge — апсейл: теперь, когда инфраструктура описана декларативно, а секреты защищены от агентов, можно позволить агентам вести процесс. Одна архитектура, два продукта, два рынка, одна общая основа под обоими.

Что это значит, если вы нас оцениваете

Если вы в компании, которая оценивает, «могут ли ИИ-агенты действительно поставлять нам продовый софт», честный ответ в 2026-м: сами по себе — нет. Но архитектура начинает существовать:

• Нужна декларативная инфраструктурная основа. Возьмите SC или соберите связку из Terraform + Helm + Vault + Snyk + Sigstore самостоятельно. Большинство команд делает второе; это дорого и хрупко.
• Нужен процесс работы с секретами, учитывающий агентов. Секреты открытым текстом на диске небезопасны в мире, где ИИ-агенты читают файлы вашего репозитория. Подход SC с шифрованием в git — один из ответов; есть и другие (Infisical Agent Vault, AgentCore Identity).
• Нужны проверяемые артефакты. Подписи cosign, SBOM, происхождение SLSA — не потому, что требует комплаенс, а потому, что в мире, где код коммитят агенты, нужен внеполосный способ убедиться, что цепочка поставок не была скомпрометирована между запуском агента и продом.
• Нужен мультиагентный слой, умеющий всем этим пользоваться. Сюда и встаёт Forge, но тот же паттерн работал бы поверх любой достаточно декларативной основы.

Если вы уже убеждены в этих четырёх вещах и хотите попробовать SC — страница про родительский стек проходит по форме YAML, а открытый CLI лежит на GitHub .

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

Мы не меняем курс. Мы расширяем угол обзора.