Путь к агентам в low‑code платформах. Как low‑code‑конфигураторы корпоративных систем настраивают ИИ‑агенты через MCP

Low‑code обещает формы и отчёты «без программистов». То есть как без программистов… Они никуда не делись, но зато появилась новая дорогая профессия — эксперт по настройке конфигурации (внедрению).

Многие программисты уже стали такими экспертами. Ибо кто лучше знает платформу, чем разработчик, который ее пишет (даже если она low‑code).

Часть технически более подкованных методологов, аналитиков, руководителей проектов также уже примеряет на себя эту роль.

Предлагаю поговорить о том, что меняется с приходом ИИ‑агентов.

Что на самом деле покупают, когда покупают low‑code

У low‑code (а также no‑code, zero‑code и так далее) благородная родословная. Он появился, как ответ на вечную боль энтерпрайза: разработчики дороги, их мало, а бизнес хочет менять формы и отчёты быстрее, чем открывается вакансия в штате. Идея была проста — вынести изменения из кода в настройку, и тогда делать их смогут не разработчики, а «кто‑то попроще».

У разработчиков, меньше работы не стало, потому что именно им нужно было все эти платформы и построить, и поддерживать. Разработчики по‑прежнему пишут ядра, драйверы, интеграции, сами платформы и всё то, что должно работать быстро и молча.

Low‑code не убрал инженерию, он вынес в слой изменений «под каждого заказчика», а часть разработки переехала в настройку.

А вот дальше произошло интересное. На месте «рутинного слоя изменений» выросла новая профессия — эксперт по настройке конфигурации. И очень быстро она стала стоить, … как разработчик. Для отдельных платформ даже дороже — консалтинг всегда хорошо продавался:

• SAP — классика жанра. Часть изменений делается customizing'ом через SPRO, без единой строчки ABAP. Но «знать, какие 40 галочек из десяти тысяч надо выставить и что они сломают» — это и есть экспертиза. Консультанты SAP десятилетиями были одними из самых дорогих на рынке внедрения, вокруг них выросла индустрия интеграторов.

• 1С — целая экономика франчайзи, где «аналитик 1С, знающий конфигурацию» — дефицитный и недешёвый ресурс. Код (в языке 1С) при этом никуда не исчез.

• Salesforce — декларативная настройка (Flows, щёлканье в Setup) против Apex. Рынок Salesforce‑админов и консультантов — это отдельная профессиональная вселенная со своими сертификациями и ставками.

• ServiceNow, Dynamics, Mendix, OutSystems — та же история в разных масштабах: платформа декларативна ровно настолько, чтобы возник спрос на людей, которые «знают, как в ней всё устроено».

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

Но, надо признать, типовые конфигурации стали стоить дешевле «чем просто разработка». И если бизнес процессы подходили под нее (ага, прям подходят они =)...), то внедрение было недорогим. А вот как только нужно было что‑то изменить, возвращалось классическое «работает — не трогай!» иначе нужно много денег.

И вот сейчас фокус вопроса меняется. Рынок больше не спрашивает о том, как нанять меньше разработчиков. Разработчики и не были проблемой последние лет десять. Рынок спрашивает: «Какая экспертиза нужна, чтобы менять систему, — и можно ли её перестать держать в головах двух‑трёх человек?»

Потому что настоящая уязвимость ручного low‑code — не зарплаты аналитиков, а то, что их знание не версионируется. Ушёл эксперт и вместе с ним ушли «как это было настроено», «куда нажимать», «зачем эта галочка» и «что отвалится, если тронуть вот это».

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

Как устроен конфигуратор изнутри (спойлер: это просто данные)

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

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

Внутри платформы действует правило для внесения любых изменений: «настройкой раньше кода».

Перед любой строчкой кода под новое внедрение — доказать, что это нельзя сделать настройкой и это не нужно выносить в настройки, доработав конфигуратор. Есть карта возможностей платформы, и она честно отвечает «можно/нельзя/можно, но с нюансом». Код остаётся для того, что действительно код: интеграции, сложные вычисления, нетиповые хуки.

Итог любой задачи — собранный по этой задаче пакет изменений в настройке конфигуратора + (иногда) код (отдельно бек и отдельно фронт) + (иногда) миграция БД, всё прослеживается по одной задаче.

Здесь стоит остановиться и заметить, что именно делает аналитик‑внедренец в такой системе. Он не программирует, он порождает структурированные данные: «у формы риска добавить вкладку с полями X, Y, Z; на состоянии „Согласование“ показать кнопку перехода для роли N». Плюс он всегда очень плотно работает с разработчиками.

Третья волна: конфигурацию начинает писать не человек

У ручного low‑code есть жёсткий потолок масштабирования — человеко‑часы. И вот сюда приходят LLM‑агенты. И неожиданно оказывается, что low‑code и ИИ созданы друг для друга.

Смотрите на асимметрию. LLM пока посредственно генерирует продакшен‑C# в незнакомом БОЛЬШОМ легаси‑коде, когда вроде и можно, но страшно и ревью часто (пока) дороже написания. Но LLM отлично генерируют структурированные данные по формальному описанию: JSON, таблицы, декларации. А конфигуратор, как мы выяснили выше — это и есть структурированные данные.

То есть low‑code платформа — идеальный интерфейс для ИИ‑агента. Формальный, декларативный, с валидацией на каждом шаге и сильно сложнее, чем «все сломать».

Рабочий цикл сегодня выглядит так:

1. Агент читает постановку задачи из тикет системы.

2. Если доработка типовая для платформы (а таких обычно 70–80% ), проверяет валидность описания по б‑о‑о‑о‑о‑льшому чеклисту во внутренней wiki — что для такого типа работ «должно быть доописано». И если чего‑то не хватает, то дает обратную связь аналитику, чтобы и проектное решение, и постановку в задаче актуализировал. И доуточнил у заказчика все что нужно.

3. Проверяет, решается ли она настройкой (у платформы есть отдельный внутренний ИИ инструмент «проверить возможность»). Если уже есть готовый инструмент для такого типа работ, то использует MCP.

4. Если MPC еще нет, то выполняет настройку. Сейчас теми же инструментами, что и человек, под своей учётной записью (но в задаче ставит метку для валидации).

5. Сразу верифицирует результат на стенде: аудит ссылок на карточки, статусов, отчётов — не «кажется, получилось», а проверки по чек‑листам. Плюс готовит Seed‑данные для демо аналитику.

6. Пакует изменение для переноса между стендами изменений конфигуратора (экспорт/импорт, никаких «перенесу руками, потом сверю») и все это отправляет во внутренний Git.

Роль человека не исчезла. Она переехала с «исполнителя, который знает, куда нажать» на ревьюера, который знает, что должно получиться.

И вот тут происходит главная переоценка активов. Экспертиза «куда нажимать» перестаёт стоить дорого, потому что она высвобождается из голов и переезжает в два артефакта:

• базу знаний (инструкции для агентов по работе с платформой, эталоны и чеклисты в wiki, карты возможностей платформы)

• и инструменты, в первую очередь развитие MCP, про которое дальше.

Самоирония: low‑code, как концепт, начинался, как замануха для бизнеса.

«Вы избавитесь от разработчиков» (и кто‑то даже верил...). А идет все к тому, что это отличная платформа для работы Агентов. Просто теперь вопрос не «кто кликает», а «кто отвечает за корректность» того что накликано. Будет нужно бизнесу — требования к экспертизе аналитиков повышаются.

MCP: контракт между агентом и платформой

Технически связку «агент ↔ платформенная настройка» удобнее всего строить на MCP (Model Context Protocol). Но важен не сам протокол, а дизайн операций.

Наивный путь — дать агенту REST API конфигуратора и пустить. Даже если и заработает: сотни эндпоинтов, неочевидные инварианты и агент, который «настроил» систему в состояние, которое никто не может воспроизвести.

Второй наивный путь — имитация кликов в UI. Это ещё хуже: хрупко, медленно, неверсифицируемо.

И все эти подходы возможны, но требуют валиадации. И это большая трата токенов.

Рабочий путь — семантические операции. Не «измени строку в таблице полей», а пред началом работ «проверь, можно ли это настройкой», «сделай типовую операцию передав для ее выполнения все нужные данные», «проверь что получилось». Агенту нужны смыслы уровня постановки задачи, а микроскопические детали платформа разбирает сама.

Отдельно про то, откуда берутся такие инструменты. Красивые схемы MCP‑серверов на бумаге почти всегда мертвы. Живой паттерн выглядит иначе:

пачка ручных проверок → шаги стабилизировались и проверены → упаковали в новый метод.

То есть каждый метод инструментария — это кристаллизованная, много раз повторённая руками последовательность (на десятках и сотнях типовых задач) и эта история должна быть.

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

И безопасность, без которой всё это не взлетит в энтерпрайзе:

• агент работает под персональной учётной записью, каждое его действие попадает в штатный журнал изменений конфигурации, с именем;

• операции идемпотентны, повторный запуск не плодит дублей;

• запрет изменений «на всякий случай», только минимальный осознанный пакет под конкретную задачу;

• конфликт‑политика при переносе между стендами, если исходное значение уже поменял кто‑то другой, то стоп и разбирательство, а не перезапись.

Звучит очевидно? В ERP‑мире годами жили иначе.

Перенос изменений = повторение на проде всех изменений на другом стенде (и часто даже без git — нужны отдельные механизмы валидации). Но часто был и совсем треш. «Консультант поправил в проде, потому что так быстрее», а потом попробуй что‑то восстановить из бекапа. Поэтому были сотни разных правил \ проверок \ валидаций, что «точно все доехало».

Выводы

Три волны автоматизации настройки корпоративных систем:

1. Код. Изменение = разработка. Дорого, медленно, предсказуемо.

2. Ручной low‑code. Изменение = настройка экспертом. Быстрее, но экспертиза в головах, потолок по человеко‑часам.

3. Агентная настройка. Изменение = агент + база знаний + инструменты + человек‑ревьюер.

Каждая волна перевносила исполнение изменений на более дешёвый и масштабируемый ресурс: код → клики эксперта → генерация структурированных данных.

Разработчики прошли все три волны насквозь. Теперь они пишут и платформы, и конфигураторы, и инструменты, которыми агенты настраивают системы. Плюс сложную кастомную логику и (часто) интеграции. Плюс ИМХО они стали ближе и к инфраструктуре с одной стороны, и к бизнесу с другой. Большая часть написания кода в классическом виде у нас сильно снизилась за последние 3 года.

Прогноз на ближайшие годы:

1. Умение настроить конкретную платформу будет дешеветь как навык и становиться частью самих Платформ. Эта экспертиза оцифровывается первой, потому что она формальна. ИМХО даже будут появляется внутренние ИИ‑инструменты в платформах, где написав что‑то типовое вроде «создай мне отчет такой‑то и дай доступ только мне», пользователь будет получать свой уникальный результат и\или интерфейс, который будет адаптироваться под каждого пользователя.

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

3. Рост «умности» LLM. То, что можно уже сейчас, еще год назад было бы сделать сильно тяжелее. Что будет еще через год‑два? Возможно, и low‑code подход для Агентов станет ненужным. И в потребительском сегменте (малый и средний бизнес) все станет очень грустно. Быстрее будет сделать новое для себя (или взять бесплатное, что‑то похожее на нужное тебе и доработать), чем настраивать старое.

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

Финальный парадокс: low‑code хотел сделать изменения доступными непрограммистам. И в эпоху Агентов наконец сделал платформы доступнее для Бизнеса.