Как ИИ-агент собирает рабочее приложение через MCP: пошаговый разбор

ИИ-агент способен собрать внутреннее бизнес-приложение, не написав ни строчки кода интерфейса: вместо генерации React-проекта он по одному шагу вызывает готовые операции платформы — создаёт страницы, компоненты, запросы и связи с данными — и проверяет результат после каждого шага. В разборе ниже агент по текстовому брифу собрал систему управления отзывами продукции из трёх страниц: 10 таблиц, 109 стартовых строк, 28 запросов и 109 компонентов.

Два пути к «ИИ строит приложение»

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

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

Как агент собирал систему

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

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

Сборка по проверяемым фазам

Схема выглядит так: спланировать фазу, проверить её, исправить ошибки проверки, применить и убедиться в результате. Проверка отловила несколько реальных проблем: колонка в базе использовала зарезервированное слово SQL, одна привязка ссылалась на компонент до его появления, а действие адресовалось компоненту не по тому свойству. Все эти ошибки были отклонены до того, как фаза попала в приложение.

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

Почему расход токенов падал от шага к шагу

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

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

После сборки приложение остаётся обычным

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

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

Что это значит для команд

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

Собрать собственный проект по описанию и продолжить работу над ним можно в разделе «Код».

Источник материала — разбор ToolJet MCP на dev.to.