MCP-кодинг в агентной инженерии: декомпозируем сложные запросы в конвейер разработки

Ещё недавно работа с ИИ-агентами на Agentic Engineering Infrastructure выглядела так же, как везде: одна задача — одно сообщение. Добавь на сайт раздел новостей. Ждём. Добавь раздел документации. Ждём. Добавь кнопку авторизации. Ждём. А теперь сделай так, чтобы документация была доступна только авторизованным. Четыре отдельных запроса, четыре ожидания — и держать правильный порядок в голове приходилось вам. Сегодня это меняется: платформа для агентной инженерии принимает весь заказ целиком — длинный, неструктурированный, хоть сумбурный — и превращает его в конвейер разработки, который можно прочитать, утвердить и наблюдать в работе.

Четыре тикета превращаются в один запрос к ИИ-агентам

Вот та же работа — до и после. Раньше каждая строка была отдельным тикетом, который нужно было отправить в правильном порядке:

• Добавь на сайт раздел новостей
• Добавь в проект раздел документации
• Добавь на сайт кнопку авторизации
• Сделай документацию доступной только авторизованным пользователям

Теперь всё это говорится одним сообщением — надиктованным голосом, с опечатками, в любом порядке. Специальные MCP-инструменты и навыки агентов декомпозируют запрос по реальному состоянию сайта: раздел новостей уже существует? публичный вход уже включён? Декомпозиция детерминирована — агент проверяет проект, а не гадает. И главное: четвёртая задача («документация только для авторизованных») понимается как то, чем она является на самом деле, — зависимость, которая влечёт включение входа на сайт и ролевой доступ к разделу; план показывает это отдельной, явно помеченной строкой следствий.

Наряд-заказ до первой строчки кода

Декомпозированный запрос становится наряд-заказом — как у строительной бригады: по одной разрешённой человеческой строке на раздел («новости — видят ВСЕ — появляется в: верхнем меню, футере»), выписанные следствия и честная граница по контенту: новые страницы поднимаются замороженными заглушками, а наполнение их настоящим текстом — отдельный, более поздний запрос. Агент обязан показать вам каждую строку дословно. Два вопроса на раздел обязательны и никогда не угадываются: нужна ли разделу админ-панель и нужен ли дашборд.

1. Декомпозиция — составной запрос раскладывается в мелкие под-шаги: создать раздел → добавить страницы → настроить меню → настроить доступ.
2. Наряд-заказ — вы читаете разрешённый план построчно и правите его, пока это ещё только план.
3. Утверждение — ваше явное «да» выдаёт токен одобрения, привязанный ровно к этому плану; изменённый или неподтверждённый план запуститься не может.
4. Запуск — каждый под-шаг проходит полный жизненный цикл: открыть шаг разработки → выполнить → задеплоить → записать деплой → закрыть шаг.

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

План живёт на странице Development Steps, а не в памяти агента

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

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

Два сценария агентной инженерии: плоский MCP-кодинг и рекурсивная разработка

Плоское масштабирование — MCP-кодинг на недорогих моделях

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

Рекурсивная разработка — когда подключается агент-программист

Когда задачу нельзя завершить одним лишь MCP-кодингом — настоящий текст, настоящая функциональность, изменение существующей страницы — Гермес не притворяется. Он делегирует работу одному из доступных кодинг-агентов: Claude Code, Codex, Gemini CLI, Qwen Code или Kimi Code — тому, кто готов прямо сейчас, то есть у кого есть доступные токены или открытое окно сессии в рамках подписки. Агент-программист работает иначе: его процесс может быть рекурсивным и более креативным, на усмотрение самого агента — он углубляет декомпозицию по ходу, извлекает паттерны и порождает новые шаги прямо в полёте. А если ни один кодинг-агент сейчас не активен — это не поломка: задача спокойно сохраняется шагом разработки, к которому можно вернуться позже.

Наблюдать за работой ИИ-агентов: две живые страницы вместо молчащего чата

Пока конвейер работает, чат затихает — раньше это ощущалось как чёрный ящик. Теперь за работой можно наблюдать. На странице «Архитектура» новые маршруты, страницы и служебные компоненты появляются на живой карте приложения по мере постройки. На странице Development Steps каждый шаг несёт бейдж статуса — новый, в работе, завершён — и закрывается временем завершения с точностью до секунды. Обе страницы опрашивают файловую систему и подсвечивают только что изменившиеся узлы.

К разработке приложений в 100 раз быстрее и в 100 раз дешевле

Всё описанное служит одному направлению: превратить разработку сложных приложений в быстрый и недорогой процесс, за которым по-настоящему интересно наблюдать со стороны — где всегда понятно, что происходит и почему. Плоская MCP-сборка на дешёвых моделях делает структурную массу работы; дорогое творческое внимание тратится только там, где оно незаменимо. Уже очень скоро мы рассчитываем сказать в утвердительной форме — и показать на рабочих примерах, — что Fractera создаёт приложения до 100 раз быстрее и до 100 раз дешевле, чем традиционные системы генерации приложений и автоматизации. Мы на пороге заключительного тестирования; то, что платформа умеет уже сейчас, можно увидеть и попробовать сегодня. Оставайтесь с нами — дальше больше.

Только глупцы и мертвецы никогда не меняют своего мнения.