Не подключение документации и API, а система команд. Как устроен аддитивный редактор FIS Platform

Как мы учим ИИ разрабатывать на low-code платформе (ПО «FIS Platform»)— не «генерировать код», а менять саму платформу через управляемый текстовый слой, рассказывает от первого лица в новой статье Алексей Ситников, руководитель направления разработки ФИС.

Первый вариант казался достаточно логичным и перспективным. У нас была документация FIS Platform и сериализованное JSON-представление объектов системы. Современные языковые модели умеют генерировать JSON, читать документацию и исправлять ошибки. Значит, можно дать агенту описание задачи, показать формат — и попросить собрать приложение.

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

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

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

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

Так появился подход, который мы называем аддитивным редактором.

Почему генерации кода на базовых технологических стеках недостаточно

В разговорах об ИИ-разработке часто звучит тезис: если модель уже умеет писать код, зачем вообще нужны платформы, low-code, no-code и накопленная инженерная база? Достаточно описать задачу — и агент соберёт приложение.

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

Но сложная прикладная система — тем более банковская — состоит не только из кода.

Поэтому вопрос «может ли ИИ написать код» для нас вторичен. Главный вопрос звучит иначе:

Может ли ИИ провести изменение так, чтобы результат был понятен, проверяем, управляем и пригоден для дальнейшего сопровождения?

Когда человек говорит: «Сделайте систему по выдаче кредитов», внутри этой короткой формулировки скрываются сотни решений:

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

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

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

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

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

В FIS Platform уже существуют:

• модель данных;
• роли и права;
• стандартные API;
• правила публикации;
• инфраструктурные ограничения;
• эксплуатационные требования;
• механизмы проверки и миграции.

Это уменьшает объём неявного контекста, который агенту пришлось бы восстанавливать самостоятельно, и обеспечивает единообразие.

То есть ИИ ускоряет создание решения, а платформа удерживает его целостность.

От JSON к специальному интерфейсу для LLM

Когда мы разрабатывали low-code платформу, главным пользователем был человек, не обязательно профессиональный программист.

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

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

Первая версия интеграции работала напрямую с документацией и JSON-представлением системы. Это был полезный эксперимент, но неэффективный производственный интерфейс.

JSON отражал внутреннее состояние объектов, но плохо выражал намерение. Чтобы добавить индекс, изменить критерий или опубликовать REST, агенту приходилось формировать крупную структуру, учитывать множество технических полей и понимать неочевидную семантику связей.

Тогда мы пришли к нескольким выводам:

Во-первых, LLM — это прежде всего генератор и интерпретатор текста. Значит, естественным интерфейсом для неё будет цепочка компактных текстовых операций.

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

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

В-четвёртых, везде, где есть потенциально большие списки, нужны возможности поиска.

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

• что не получилось;
• какой объект вызвал проблему;
• какое правило нарушено;
• что нужно исправить.

В-шестых, нужна возможность батчинга. В зависимости от модели, текущей занятости контекста и сложности задачи за один проход LLM может формировать как 1–2 команды, так и десятки сразу. Командный интерфейс должен это поддерживать.

Так мы получили отдельный интерфейс именно для агента.

Технически это MCP-сервер, через который модель работает с объектами FIS Platform.

Возможность просмотра и генерации JSON мы не запрещали. Агент использует такой вариант, если семантики команд недостаточно, нужен нестандартный поиск или редактирование.

FIS Platform

Небольшая справка, чтобы было понятно, чем именно мы занимаемся. FIS Platform — это low-code платформа, которой уже около 15 лет и на базе которой разработан ряд фронт-офисных банковских приложений. Она внедрена в ряде крупных банков. В России банковский рынок высококонкурентный, и требования к продуктам фронт-офиса (кредитные конвейеры, управление задолженностью и так далее) часто меняются.

Платформа реализована на Java, она содержит свой язык выражений UDML и его скриптовое расширение на базе JavaScript (UDMS), встроенный движок бизнес-процессов BPMN 2.0, визуальный конструктор форм, возможность публикации пользовательских REST-, SOAP- и WSDL-сервисов, кластеризации, интеграции с брокерами сообщений и так далее.

Приложения на платформе имеют модульную структуру и представляют собой набор типизированных мета-объектов, хранящихся в базе данных и имеющих сериализованные представление в виде JSON.

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

Редактирование приложений идёт через интегрированный веб-интерфейс, который обеспечивает возможности по разработке, отладке, администрированию и мониторингу.

Команды аддитивного редактора

Повторимся, аддитивный редактор — это текстовый интерфейс, через который ИИ-агент добавляет и изменяет объекты FIS Platform управляемыми командами.

Он работает с конкретными платформенными сущностями:

• структурой приложения;
• модулями и пакетами;
• моделью данных;
• критериями и индексами;
• прикладными данными;
• пользовательскими функциями;
• процессами;
• пользовательскими REST;
• формами;
• JSON-компонентами;
• переводами;
• ролями;
• другими объектами платформы.

Например, создание прикладной структуры и части модели данных может выглядеть так:

appstructure addmodule <appUuid> <newModuleUuid> Sales "Модуль продаж"
appstructure addapppackage <moduleUuid> null <packageUuid> Types "Типы предметной области"

datamodel createtype <moduleUuid> <packageUuid> <typeUuid> Order "Заказ клиента"
datamodel editview addattribute <viewUuid> number строка
datamodel editview addattribute <viewUuid> status строка

datamodel addcriteria <viewUuid> <criteriaUuid> ByStatus "Поиск по статусу"
datamodel editcriteria addparameters <criteriaUuid> [{"name":"pStatus","type":"строка"}]
datamodel editcriteria addpredicates <criteriaUuid> [{"left":"status","operator":"EQ","right":":pStatus"}]

datamodel addindex <viewUuid> <indexUuid> idx_order_status "Индекс по статусу"
datamodel editindex addfields <indexUuid> [{"attribute":"status","direction":"ASC"}]

Работа с данными строится так же — через отдельные операции создания, чтения, изменения и удаления:

dataedit create <typeUuid> {"number":"ORD-001","status":"NEW"}
dataedit list <typeUuid>
dataedit update <typeUuid> "91" {"status":"RESERVED"}
dataedit get <typeUuid> "91"
dataedit delete <typeUuid> "91"

Есть и команды, которые позволяют получить текущий статус или проверить успешность изменений:

application.validate <appUuidRoot>
customrests list <moduleUuid>
processes list <moduleUuid>
forms list <moduleUuid>
datamodel runcriteria <criteriaUuid> {"pStatus":"RESERVED"}

Каждая команда адресована конкретному объекту и возвращает либо результат, либо понятную ошибку. Агент не угадывает внутренний формат метаданных, а работает через небольшой DSL с ограниченной семантикой.

Агентский цикл важнее безошибочной генерации

Современные агенты стали полезны не потому, что LLM перестали ошибаться. Они по-прежнему допускают ошибки и галлюцинации, иногда уверенно и на ровном месте. Их практическая ценность выросла по другой причине: модель получила возможность не только генерировать текст, но и выполнять действия, видеть результат и исправлять себя. Именно обратная связь превращает генерацию в инженерный цикл. Условный пример: если вероятность корректно написать одну независимую функцию составляет 95%, то для десяти функций вероятность получить полностью корректный набор составит около 60%, а для ста — около 0,6%, то есть примерно никогда. Реальные ошибки, конечно, не независимы, но принцип достаточно нагляден.

Обратная связь меняет ситуацию. Агент может:

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

Это тот же отладочный цикл, которым пользуется и человек.

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

Компактность

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

Валидация и fast-fail

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

В итоге рабочий цикл выглядит так:

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

Кейс: система обработки заказов

Один из внутренних сквозных примеров — система обработки заказов и складских резервов.

На вход агенту дали не трёхтомное ТЗ, а несколько абзацев бизнес-логики. Это было сделано намеренно, чтобы посмотреть, насколько хорошо LLM «чувствует» абстракции платформы и сохраняет «здравый смысл» при работе с ними.

Нужна система, которая позволяет:

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

В платформенном контуре агент разложил предметную область по модулям. Появились:

Catalog, Inventory, Partners, Procurement, Sales, Shipping, Notifications, а также отдельный слой Api.

Для них были созданы и связаны функции и REST-точки вроде:

catalog_create, inventory_list, supplies_create, supplies_execute, orders_create, orders_cancel, shipments_create, shipments_list, notifications_list, notifications_resolve, inventory_status, orders_list.

В логике заказа агент реализовал вполне прикладной сценарий.

При создании заказа система сначала резервирует товар со склада. Если наличия недостаточно — пытается добрать резерв из подходящих планируемых поставок. В зависимости от результата выставляются статусы RESERVED, PARTIAL_RESERVED, PLANNED_SUPPLY, BACKORDER.

При задержке или срыве поставки создаётся уведомление клиенту и появляется возможность частично или полностью отменить заказ.

На том же контуре агент создал тестовые данные: каталог, поставщиков, клиентов, остатки, поставки и заказы.

То есть на выходе получилось вполне работающее ядро приложения с понятными платформенными артефактами: модулями, типами, функциями, REST, данными и сценариями проверки.

Фрагмент этой логики виден на скриншоте.

Результат опубликованного REST-вызова по остаткам.

Ещё примеры

В одном эксперименте агент создал тип с тремя бинарными полями: исходный PDF, изображение водяного знака и результирующий PDF.

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

Это уже не справочники и типовая обработка данных, а прикладная задача по обработке документов внутри платформенного контура. Агент успешно справился. Результат виден на скриншоте.

Другой эксперимент был ещё интереснее.

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

Агент создал 10 типов, 32 атрибута, один классификатор и 17 поисковых методов, наполнил приложение данными и добавил функции проверки. Часть этого набора представлена на скриншоте.

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

Что уже можно делать через редактор

Для backend-приложений сейчас доступна достаточно полная функциональность. Агент может:

• собирать структуру приложения;
• создавать модули и пакеты;
• описывать модель данных на уровне типов, атрибутов и классификаторов;
• создавать поисковые методы и индексы;
• наполнять приложение данными;
• создавать пользовательские функции;
• публиковать пользовательские REST;
• собирать процессы из блоков и связей;
• работать с формами, JSON-компонентами, переводами и ролями.

Всё это выполняется прямыми операциями над объектами, а не обходными манёврами через внутренний JSON.

С фронтендом ситуация менее зрелая. Через текстовый слой уже можно работать с формами, JSON-компонентами, темами и VCM-компонентами. Однако визуальная логика, тонкая настройка поведения интерфейса и работа, где результат сильно зависит от восприятия человеком, пока требуют значительного ручного участия. Это одна из принципиальных границ текущего решения. Структурированные backend-объекты хорошо выражаются текстом. Визуальный результат сложнее свести к компактному набору команд и формальных проверок.

Как мы тестируем сам редактор

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

Мы собрали два полноценных тестовых контура:

• unittest1 — режим без ручной выдачи физических имён типов;
• unittest2 — режим с ручной выдачей физических имён таблиц и полей.

Для нашей системы это существенное различие, поскольку физические имена влияют на работу слоя данных.

В каждом контуре формальная матрица покрытия включает 11 верхнеуровневых разделов и 266 командных сигнатур: appstructure, datamodel, dataedit, processes, forms, userfunctions, customrests, jsoncomponents, udml, udms, help(root). Проверяется полный цикл CRUD и валидации для модулей, пакетов, типов, представлений, атрибутов, классификаторов, критериев, индексов, данных, процессов, форм, пользовательских функций, пользовательских REST и JSON-компонентов. Отдельно проверяются справка по разделам, синтаксис команд, реакции на неверные UUID, обязательные descriptions, валидация структуры и очистка созданных артефактов. Также добавлены негативные кейсы и проверки известных багов.

По последним полным прогонам картина такая:

Под ожидаемо негативными здесь понимаются проверки, в которых команда должна завершиться контролируемой ошибкой. Soft-check — проверки, где результат фиксируется и анализируется, но не блокирует весь прогон. Неожиданные падения тоже возникают. Для развивающегося инструмента это нормально. Тестовый контур уже не раз показал свою состоятельность. Синтаксис команд неоднократно расширялся и менялся, разделы перераспределялись, внутренние интерфейсы рефакторились. Тесты позволяли сразу видеть, где изменение редактора нарушило старое поведение.

Что показывает опытная эксплуатация

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

За наблюдаемый период редактор обработал 4 097 команд в рамках 50 MCP-сессий, запущенных 4 именованными пользователями и 2 стандартными учётными записями. Успешно завершились 3 855 команд, то есть примерно 94,1% всех вызовов. Важно правильно интерпретировать эту цифру. Это доля команд, которые редактор смог выполнить. Она не означает, что 94,1% бизнес-требований были реализованы безошибочно или что все созданные приложения готовы к промышленной эксплуатации.

При этом почти половина работы шла не одиночными командами, а скриптами: 1 854 вызова были частью многострочных сценариев, ещё 2 243 — отдельными точечными командами. Это показывает, что редактор использовался не только как консоль справки, но и как инструмент пакетных изменений.

По разделам нагрузка распределилась следующим образом:

• datamodel — 2 606 команд;
• userfunctions — 677;
• appstructure — 312;
• далее — customrests, udml и dataedit.

Среди наиболее частых операций были команды просмотра, уточнения и проверки:

Это похоже на нормальный итерационный процесс. Агент и разработчик не создают объект один раз и не забывают о нём. Они просматривают существующую структуру, меняют представления, корректируют критерии, запускают запросы, дорабатывают функции и проверяют опубликованные REST.

Пики активности приходились на дни массовых рефакторингов:

• 1 028 команд;
• 725 команд;
• 568 команд. Именно в таких сценариях пакетные операции дают наибольший эффект: изменения, которые вручную потребовали бы большого числа повторяемых действий, можно выразить как единый пакет команд.

По времени выполнения контур оставался отзывчивым (на реальном большом приложении):

• медиана — 13 мс;
• p90 — около 281 мс;
• p95 — около 704 мс.

То есть обратная связь со стороны платформы не становилась узким местом в цикле «изменил → получил ответ → исправил». Основные задержки приходились на работу самой модели.

Какие ошибки встречались

Неуспешных вызовов было 242. В основном это были не инфраструктурные сбои, а ошибки прикладного редактирования:

• проблемы в runcriteria;
• обращения к уже неактуальным UUID;
• попытки работать с типом до перезапуска приложения после изменения модели;
• отсутствие обязательного physicalName в режиме ручной физической схемы.

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

Анализ эффективности

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

Для сравнения мы прогнали тот же пример системы обработки заказов на трёх контурах: в платформенном приложении и на двух «голых» стеках. Были выбраны Java (как крайне популярная среда в банковской сфере) и Python (как стек, наиболее понятный модели; можно предположить, что именно на нём ошибок будет меньше всего, а скорость разработки станет максимальной). На Java получился проект warehouse: Spring Boot + JDBC + PostgreSQL, где пришлось отдельно собирать схему из таблиц products, inventory, supplies, supply_items, customers, customer_orders, order_items, shipments, notifications, настраивать индексы и писать контроллеры /api/products, /api/inventory, /api/orders, /api/supplies, /api/shipments, /api/notifications. На Python — warehouse_py: FastAPI + SQLAlchemy + PostgreSQL с роутерами /products, /stock, /customers, /supplies, /orders, /shipments, /notifications, отдельным seed-скриптом и проверками конкурентного overbooking-сценария. То есть сравнивалась не абстрактная «платформа против hello world», а одна и та же прикладная задача в трёх технических формах.

Мы сравнивали не пустой каркас, а стартовое развёртывание одной и той же предметной области с работающим REST.

Результаты получились такие:

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

Тем не менее он позволил увидеть характерную закономерность.

Платформа показывает себя лучше там, где у агента есть прямой объектный инструмент:

• модель данных;
• стандартные операции с объектами;
• заполнение данными;
• публикация REST поверх существующих сущностей.

Там, где требуется писать собственный нетривиальный код на UDMS и вручную доводить специфическую логику, результат может получаться медленнее, чем на базовых технологиях. Это ожидаемо. Java и Python хорошо представлены в обучающих данных моделей. Специфику FIS Platform агент осваивает через доступную справку и цикл проб и ошибок. Особенно заметно замедление в новой агентской сессии, когда нужно выполнить одну небольшую задачу. В пакетном режиме, где один контекст используется для серии связанных изменений, разница сокращается.

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

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

Поэтому наша рабочая метрика звучит не так:

Насколько быстро ИИ написал код?

А так:

Насколько быстро мы провели изменение без потери управляемости?

Почему мы смещаем фокус с промежуточного кода на артефакты

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

Артефакт — это не обязательно документ. Это любой результат, который можно предъявить, связать с требованием и проверить:

• функциональное описание;
• техническое решение;
• модель данных;
• API;
• тест-кейс;
• набор тестовых данных;
• работающий backend-блок;
• прототип интерфейса.

Для артефактов с текстовым представлением используется подход doc-as-code.

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

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

Это даёт два эффекта.

Валидация

Агент не просто «что-то сделал». Можно проверить:

• соответствует ли результат формату;
• покрыты ли требования;
• нет ли противоречий;
• проходят ли тесты;
• создан ли весь обязательный набор объектов.

Масштабирование

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

Для FIS Platform такая модель естественна. Платформа уже работает с типизированными бизнес-объектами, связями, правилами и проверками. Поэтому формализовать связь реализации с требованиями проще, чем в полностью произвольной кодовой базе.

Где проходит граница человека

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

В сложных проектах по-прежнему важны:

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

ИИ может быстро подготовить вариант, но он не знает, какой вариант допустим для конкретного клиента, если это явно не формализовано. Он может создать backend-ядро, но не принимает решение о промышленной готовности. Он может пройти цикл исправлений, но не несёт ответственности за архитектурный компромисс.

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

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

Что дальше: тестирование, профилирование, воспроизведение ошибок и обеспечение безопасности

Разработка — только часть будущего контура. Следующая задача — связать создание изменений с тестированием, профилированием, безопасностью и воспроизведением ошибок из эксплуатации.

Замыкание разработки с тестированием

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

Безопасность

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

Профилирование

Для банковской системы мало «работает на тестовом примере». Нужно понимать, укладывается ли решение в требования по скорости и масштабируемости. В целевой картине агент должен уметь не только создать изменение, но и проверить, выдерживает ли оно нужные параметры по потреблению ресурсов, а затем предложить корректировку. Модели уже знают, какие способы оптимизации существуют; поэтому задача — предоставить им лаконичный набор данных, позволяющий локализовать потребление ресурсов, выявить лимитирующий ресурс и привязать его к конкретному объекту приложения.

Воспроизведение ошибок из эксплуатации

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

Что это даёт заказчику?

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

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

Задача — не ломать всё до основания и генерировать заново, а последовательно развивать существующее.

Для нас итоговая ценность ИИ-разработки измеряется не числом сгенерированных строк и не скоростью первого прототипа. Она измеряется тем, насколько быстро можно провести изменение через требования, ограничения, проверки и приёмку — и получить результат, за который кто-то готов отвечать.

Именно для этого мы и строим аддитивный редактор FIS Platform.