Вайб-конфигурирование: как ИИ-агенты собирают приложения из написанных людьми блоков

Привет! Я Юрий Степанов, ведущий системный аналитик в LDM (ИТ-холдинг LANSOFT). Несколько месяцев назад мне поставили задачу ускорить сборку приложений на нашей low-code платформе с помощью ИИ. Перепробовал разные модели и подходы, собирал флоу с промптами – и в итоге методом проб и ошибок пришел к рабочей схеме: подготовил для агента структурированный слой документации по платформе с индексами и ключевыми словами, по которым он сам находит нужный раздел под конкретную задачу.

Сейчас этот подход я продолжаю развивать параллельно со сборкой самого приложения. А сам подход я назвал «вайб-конфигурирование» – о нем и поговорим: чем он принципиально отличается от вайб-кодинга, как это устроено под капотом и что из этого реально работает, а что пока нет. Погнали!

Вайб-кодинг vs вайб-конфигурирование

Для начала разберемся в понятиях. У обычного вайб-кодинга результат – исходный код: ИИ пишет его вместо программиста. У вайб-конфигурирования принцип работы другой: ИИ-агенты создают приложение, оперируя не текстом программы, а готовым low-code инструментом, который ранее уже был написан разработчиками. Выполняя свои задачи, он вызывает готовые MCP-инструменты системы (Model Context Protocol – открытый стандарт, по которому ИИ обращается к внешним системам через заранее описанные команды). Под капотом эти инструменты уже реализованы поверх REST API-платформы или скриптов, написанных программистами.

Сейчас отношение к вайб-кодингу двойственное – одни видят в нем будущее, другие предупреждают о рисках. И опасения эти обоснованны: если ИИ пишет быстрее, чем люди успевают ревьюить, в проекте накапливается масса кода, который формально прошел через репозиторий, но его никто на 100% не понимает и не проверял. Риск растет вместе с объемом, тем более что агенты пока плохо проектируют архитектуру, а код, работающий на малых нагрузках, может не выдержать больших.

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

Итак, чем отличаются два этих понятия? Если отбросить детали, разница в уровне абстракции и цене ошибки. Простыми словами: в первом случае вы доверяете ИИ писать новый текст, во втором – только заполнять бланк по правилам. Детали в таблице:

Эти подходы не конкурируют, а дополняют друг друга. Вайб-кодинг может использоваться при создании функционала, которого нет в системе, а вайб-конфигурирование может применяться, когда нужный функционал уже имеется в low-code-платформе. Разница не в том, что один способ «умнее» или «лучше» другого, а в том, что именно оказывается на выходе и что именно и кому нужно проверять. В вайб-кодинге – правильность и безопасность нового кода с помощью человека с технической квалификацией, а в вайб-конфигурировании – корректность созданных элементов системы в UI, в основе которых лежит проверенный безопасный код.

Если я ничего (или почти ничего) не понимаю в коде, смогу ли я заниматься вайб-конфигурированием?

Самый частый вопрос. Ответ – да, сможете. Но с оговоркой.

Понимание кода действительно не требуется для вайб-конфигурирования, и в этом одна из практических ценностей подхода.

Пользователь описывает намерение на естественном языке. Например: «Вид услуги сейчас вводится текстом, из-за этого в отчетах разнобой. Сделай его выбором из справочника, а право вести список значений дай администратору». То, как это должно быть сделано, берет на себя агент. И пользователю не нужно знать, какие методы нужно вызвать, какие параметры в какой последовательности передать. Ему нужно только проверить результат в UI – появилась ли нужная опция выбора вида, корректно ли она работает и если что-то не так – рассказать об ошибке.

Но это не значит, что «подойдет вообще любой человек». Пользователю все равно полезно понимать логику предметной области low-code платформы, что такое класс данных, форма, коллекция, право доступа и как они связаны между собой. То есть смысл того, что он просит, а не синтаксис того, как это реализуется. Плюс критически важный навык: тестировать результат в реальном интерфейсе и внятно описывать, что не так.

Как это устроено под капотом

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

Ключевая дисциплина – агент не доверяет ответу «успех», а перепроверяет создание объекта отдельным вызовом на чтение. Получается надежный цикл «вызов → проверка чтением», вшитый в архитектуру процесса, а не оставленный на волю случая.

Может ли агент выйти за рамки? Нет. Набор операций жестко ограничен тем, что реализовано как MCP-инструмент – он физически не способен вызвать то, чего в этом наборе нет. Он лишь выбирает нужный метод и передает параметры, а всю «тяжелую» работу выполняет уже проверенный инструмент платформы.

Вопрос безопасности

Мы разобрались, как работает вайб-конфигурирование. Но чтобы понять, насколько это безопаснее вайб-кодинга, давайте вспомним, где кроются риски классической ИИ-разработки.

Утечка ключей, невалидированный ввод, слишком широкие права – все это рождается из того, что агент пишет новый исполняемый код, в котором может быть спрятана уязвимость. В вайб‑конфигурировании этого риска просто нет – потому что нет нового кода. Модель вызывает готовый MCP‑инструмент, а тот, в свою очередь, – операцию платформы (REST-метод), в которой валидация и защита уже реализованы один раз программистами и работают одинаково для всех – и для агента, и для человека, кликающего в UI.

По правам доступа агент действует не от имени привилегированной сущности, а в рамках токена/сессии – точно так же, как если бы действия выполнял человек через интерфейс. Токен может быть ограничен по времени жизни. Худшее, что может сделать агент, – это то же самое, что мог бы сделать человек с теми же правами вручную, только быстрее. Да, это создает риск «быстрого мусора» в БД, но он изолируется через журнал аудита: видно, какие инструменты вызывались и с какими параметрами, а последствия устраняемы. И это несопоставимо с рисками захламления в коде при аналогичной нештатной ситуации.

Почему это принципиально надежнее? Сравнение тут не «чуть безопаснее» – это качественно другие риски. У агента, пишущего код с нуля, поверхность атаки растет вместе с его объемом и открыта всему классическому спектру уязвимостей. У вайб-конфигуратора, ограниченного конечным набором MCP‑инструментов, эта поверхность равна поверхности атаки самой платформы – той же самой, что существовала и до его появления, ведь эти методы уже использовались людьми через UI и интеграции.

Живой кейс: сколько времени экономит агент

Сложность запроса на естественном языке упирается не в возможности ИИ, а в ясность формулировки: чем точнее пользователь описывает намерение (опираясь, например, на ТЗ), тем увереннее агент подбирает нужные MCP-инструменты. На практике конвейер агентов-экспертов способен собрать полноценное приложение целиком – несколько связанных сущностей, формы, коллекции, права, маршруты согласования – за счет декомпозиции большой задачи на последовательность шагов, где каждый шаг выполняет узкоспециализированный агент, а не один универсальный. Качественное деление на блоки + четкие запросы позволяют решать задачи высокой сложности, снижая порог вхождения – пользователю теперь не обязательно знать техническую последовательность операций.

Возможности агента ограничены периметром платформы:
• если для операции еще нет MCP-инструмента – агент физически не может ее выполнить (это не баг, а зона, которую еще предстоит закрыть инженерно);
• если функциональность вообще не выражается через low‑code (нужна нестандартная бизнес‑логика классическим кодом) – это уже зона обычной разработки или ручной работы специалиста;
• отдельная граница – проверка результата: агент подтвердит корректность данных, но пока не может сам пройти пользовательский путь в браузере, хотя в этом направлении уже есть подвижки (автопрогон BDD‑сценариев на Gherkin, сгенерированных другим агентом).

Скорость: что изменилось?

Если сравнивать с классической low-code разработкой, где те же задачи раньше выполняли люди-консультанты, то вайб-конфигурирование дает существенный прирост производительности. Но он не линейный и не одинаковый на всех типах задач.
На типовых, многократно повторяющихся операциях (создание атрибута, формы, коллекции, выдача прав) выигрыш огромен – то, что у человека требует десятков кликов и переключений между экранами, агент делает за считанные секунды несколькими вызовами. Там же, где нужно нестандартное решение или диагностика проблемы, экономия скромнее – узкое место смещается на формулировку задачи и проверку результата человеком.

Цифры из нашего опыта: небольшое приложение из 581 объекта через UI создавалось бы примерно 5 рабочих дней. При конфигурировании через ИИ-агента было выполнено 1613 вызовов MCP-инструментов:

Чистая работа агента заняла чуть более 1 часа с учетом рассуждений. Если же считать «сухое» время непосредственно на вызовы: анализ 1613 таймстемпов показал, что 85,7% интервалов между вызовами – «плотные» (< 3 секунд), медиана задержки – 390 мс, p75 – 543 мс, среднее – 432 мс на вызов (почти 2 вызова в секунду). Итого чистого времени на вызовы – около 11–15 минут. Бутылочным горлышком остается обратная связь от человека и скорость его реакции.

При этом никто не мешает распараллелить работу агентов – это даст дополнительный прирост в скорости. То есть в нашем случае можно вести разработку не в одном окне, а сразу в нескольких. Пока один проектирует слой представления, другой может создавать политики прав доступа для слоя данных. Задачу можно декомпозировать по блокам и выполнять эти блоки одновременно.

Как обычно выглядит классический подход разработки приложений, даже на системах low-code:

С ИИ-агентами сейчас можно ускорить любой этап, кроме обследования – где‑то в десятки раз (как с конфигурированием), где‑то просто в разы. А если речь о переносе функционала с платформы на платформу, обследование часто не нужно – достаточно документации на вход, на основе которой агент выявит требования, напишет сценарии и подготовит артефакты для следующих моделей. В итоге на старте была документация, в финале тоже документация, но в процессе сконфигурировано приложение и написаны BDD‑тесты.

Что агент может, а что пока нет

Что уже реально работает. Конфигурирование приложений через готовые low‑code блоки с ИИ вместо человека дает две вещи: снижает порог входа для того, кто контролирует результат, и в разы сокращает время на операции. Агент пока может ошибаться на задачах, где нужно нестандартное решение, но с базовыми операциями справляется отлично. И с таким подходом не за горами день, когда любой менеджер без навыков программирования сможет за день собрать MVP на low‑code платформе и проверить гипотезу на рынке.

А что насчет скорости и есть ли цифры? Точных замеров парного сравнения у меня нет, но порядок величин обоснован логикой. Типовая задача (поля, валидация, привязка к справочнику, уведомления) – это ровно то, для чего вайб‑конфигурирование подходит лучше всего. Разрыв между ручным кликаньем по экранам и вызовом с параметрами максимален – достаточно вспомнить, сколько вызовов в секунду способен делать агент. Но одной фразой «сделай форму заявки с 10 полями и уведомлениями в телеграм» не обойтись: нужна четкая постановка. Как говорится, без ТЗ – результат ХЗ. ИИ-исполнитель способен додумать сам, но тогда итог может не совпасть с ожиданиями. Сегодня ИИ-помощник – это исполнитель, и если задача сформулирована плохо, то и итог будет соответствующим.

А что с масштабом? Есть один измеренный пилот (см. блок про живой кейс с табличкой), но не десятки внедрений, чтобы говорить о статистически значимом ROI. Что я могу сказать с уверенностью – на измеренном примере узким местом оказался не темп API (он пренебрежимо мал), а скорость человеческого цикла обратной связи: диагностика, тестирование, согласование. Значит, при масштабировании ROI будет определяться не тем, сколько форм в секунду собирает агент, а тем, насколько отлажен процесс ревью и тестирования человеком. Менее эффектно, чем готовая цифра, но это то, что реально наблюдалось.

А качество? Снижает ли ошибки? Да, и это можно обосновать механикой, без статистики. Агент передает значения не в свободные поля UI (где человек может опечататься, забыть обязательное поле или перепутать тип), а в строго типизированный MCP‑инструмент, который такие ошибки просто не пропустит на входе. Ошибки исключаются не потому, что «агент внимательнее», а потому, что целый класс подобных погрешностей физически не проходит через параметры инструмента. Задача инженера – подготовить качественные методы, которые снизят риск ошибки модели.

Какая метрика будет самой наглядной для бизнеса? Важна не метрика «вызовов в секунду» и не «форм в месяц на сотрудника» – это показатель скорости агента, а мы уже выяснили, что это не узкое место. Самой наглядной станет метрика времени от сформулированного требования до результата, принятого человеком, потому что она включает весь реальный цикл, а не только ту часть, где агент действительно быстр. Ведь важно не просто быстро создать 20 шаблонов, а быстро создать 20 правильных и работающих шаблонов, в которых нет ошибок.

Изменение ролей в команде

Разработчики платформы настраивают агентов: прописывают роли, системные промпты, подключают MCP‑инструменты, конвейеры передачи результатов. Это «подкапотная» работа, которую конечный пользователь не видит. Он просто открывает чат с готовым конвейером и пишет на естественном языке: «сделай коллекцию заказов со связью на клиентов» – без системных инструкций и указания, какой агент за что отвечает. Вся инженерия уже «зашита», он получает итог как в обычном диалоге.

Исчезновения ролей целиком я не вижу – вижу смещение фокуса внутри каждой:
Low-code-конфигураторы – меньше рутинных кликов по экранам, больше формулирования требований на естественном языке и тестирования итога. Знание сущностей платформы остается, но применяется через диалог с агентом, а не через UI. Порог снижается – не нужно знать «как» создается форма, достаточно знать «что» и «для чего».
Разработчики – остаются нужны там, где требуется настоящий код для low‑code-блоков, то есть за периметром low‑code возможностей платформы. Но там уже совсем другая история, движение скорее в сторону вайб‑кодинга.
QA – фокус перестраивается с ручных прогонов на отладку инструментов автотестирования и проверку результата. Если раньше тестировщик вручную проходил по сценариям и искал нестыковки, то теперь его акцент смещается в сферу передачи своих навыков ИИ-агенту, который будет сам готовить и выполнять автотесты, а также в сферу контроля за работой этого агента.

Выводы и перспективы

Ценность для бизнеса

• Снижение порога входа – меняет, кто вообще может участвовать в создании приложений. Теперь это не только сертифицированный low‑code-конфигуратор, а любой, кто способен внятно сформулировать требование и проверить итог в UI.
• Сокращение времени – превращает доступность в измеряемую бизнес‑ценность. Рутинные операции конфигурирования агент выполняет почти мгновенно по сравнению с человеком.
• Повышение безопасности – не отдельная выгода, а предпосылка, делающая первые два пункта возможными без роста риска. Если бы агент писал произвольный код, снижать планку и разгонять скорость было бы безответственно. А раз он ограничен готовыми, протестированными MCP‑инструментами – снижать порог можно, не жертвуя надежностью.

Перспектива 2–3 года

Ближайшее развитие, на мой взгляд, – не в том, чтобы «агент сам придумывал приложения», а в том, чтобы закрыть сегодняшние пробелы на границах: более полное покрытие low‑code возможностей готовыми, протестированными инструментами (в случае нашей платформы – за счет расширения набора MCP-инструментов), более глубокая автоматизация проверки результата (генерация и прогон BDD‑сценариев вместо ручного тестирования), более глубокое понимание системы по запросам пользователя.

«Агенты-архитекторы», которые проектировали бы новые low‑code блоки (писали код самой платформы), – это уже про другое. Там снова появляется новый исполняемый код, который нужно ревьюить, и вся дисциплина вайб‑конфигурирования (когда агент физически не может выйти за периметр) к этому контуру уже не относится. Это будет развиваться параллельно, но принципиально в другой зоне ответственности.

Вызовы внедрения в enterprise

• Зрелость инструментов: если их мало или они плохо спроектированы (неудобные параметры, слабая валидация на входе) – агент будет ошибаться чаще, и часть выгоды уйдет на исправления.
• Смена роли человека: специалистам, которые раньше руками кликали по конфигуратору, приходится переучиваться на новую роль: формулировать требование и тестировать результат. Для одних это естественный переход, для других – психологически сложный.
• Доверие и контроль на старте: enterprise‑заказчики закономерно спрашивают про права доступа, аудит, что происходит при ошибках и как решать нестандартные ситуации – без внятных ответов на эти вопросы внедрение просто не начнется.
• Качество запроса: агент выполняет то, что понял из запроса. Неточная формулировка оборачивается неточной конфигурацией.

Итог

Вайб‑конфигурирование – это не замена разработчиков и не очередной ИИ‑инструмент «для галочки». Это следующий слой абстракции: переход от low‑code кликов к управлению платформой через естественный язык. И ценность здесь не в том, что агент быстрее кликает, а в том, что он делает это предсказуемо, безопасно и в рамках платформы, снимая с человека рутину и оставляя за ним контроль и решения.

ИИ-агент – это не терминатор, который полностью заменяет человека, а более продвинутый инструмент, увеличивающий продуктивность. Лесоруб, умеющий использовать бензопилу, будет работать эффективнее, чем десяток дровосеков с топорами. Вот ИИ-агент – это бензопила. Но для его успешной работы все так же нужен специалист, и результат будет сильно зависеть от того, в чьих руках это решение. ИИ-помощники не смогут полностью исключить человека из процесса, но могут существенно повысить его продуктивность.