Сначала архитектура, потом код: зачем ИИ-агенту контрольные барьеры

Гостевая статья Станислава Румеги

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

1. Проблема: код появляется раньше объяснения

ИИ-агент способен написать код быстрее, чем успевает объяснить, что именно он собирается построить.

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

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

2. Что остаётся без контроля до реализации

Современный код окружён множеством средств контроля: компиляторами, линтерами, модульными и интеграционными тестами, оценкой покрытия, мутационным тестированием, SAST и другими анализаторами.

Роберт Мартин («Дядя Боб») недавно описал похожую стратегию работы с ИИ-агентами: вместо чтения каждой строки он окружает создаваемый ими код системой тестов, метрик и других ограничений [1].

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

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

Компиляторы давно используют промежуточные представления (intermediate representations, IR): между исходным кодом и машинными инструкциями существуют структурированные формы, каждая из которых проверяется отдельно.

В ИИ-разработке цепочка часто короче:

Требования на естественном языке → код

Предлагаемый метод добавляет два проверяемых представления до реализации.

3. SIM, FAM и три контрольных барьера

Первое представление — модель намерения системы (System Intent Model, SIM).

SIM фиксирует то, что агент считает задачей системы; устройство кода в ней не описывается. В структурированном документе он указывает:

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

SIM должна соответствовать заранее определённой схеме. Это не архитектурное эссе и не свободный план.

Контрольный барьер 1 проверяет SIM на пропущенные обязательства и известные опасные сочетания. Например: критическая команда отправляется без подтверждения, механизм дедупликации не определён, число перезапусков не ограничено или заявленный инвариант не подкреплён механизмом.

После принятия SIM агент строит формальную архитектурную модель (Formal Architecture Model, FAM). В этом контексте слово «формальная» означает только структурированную, типизированную и машиночитаемую модель; formal verification и математическое доказательство корректности остаются за рамками.

FAM описывает устройство системы:

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

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

Контрольный барьер 2 проверяет полноту FAM и её соответствие принятой SIM. Он ищет необъявленные компоненты, несовпадающие порты, неполные таблицы, потерянные требования и механизмы, для которых не определено место реализации.

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

Контрольный барьер 3 применяет к реализации существующие средства: компиляторы, тесты, линтеры, SAST и другие анализаторы. Новый статический анализатор для этого не требуется.

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

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

Для аудита нужен другой тип результата:

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

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

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

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

5. Демонстрационный пример

В репозитории показан проход для платёжного обработчика из трёх акторов: worker, supervisor и payment_gateway.

Исходные требования описывают основной сценарий, но почти ничего не говорят об отказах. Первая SIM получает статус BLOCK: платёжная команда отправляется без подтверждения, механизм дедупликации недостаточен, а число перезапусков не ограничено.

Решения и их обоснование записываются в журнал решений (decision memory). После исправления SIM проходит первую проверку.

Затем создаётся FAM. Второй барьер проверяет полноту таблиц переходов, согласованность модели с SIM и прослеживаемость архитектурных элементов до намерения.

После этого создаётся намеренно уязвимая реализация. В ней есть небезопасный запуск команд оболочки, десериализация через pickle, пустой обработчик except и бесконечный цикл ожидания. Третий барьер блокирует код; исправленная версия проходит проверку.

Каждый уровень ищет свой класс проблем:

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

6. Честный статус и границы метода

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

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

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

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

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

7. Что дальше

Следующий шаг — пилотный сравнительный эксперимент на десяти реальных задачах из GitHub. Один режим будет использовать SIM, FAM и контрольные барьеры, второй — нет.

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

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

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

Вопросы автору

Что именно можно запустить сегодня?

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

Как будет устроена ослеплённая оценка?

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

Что в методе относится именно к акторным системам, а что можно перенести на web-приложения и CRUD?

Акторная специфика текущего прототипа — проверки потери сообщений, дедупликации, надзора, перезапусков и полноты таблиц «состояние × событие».

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

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

[1] Robert C. Martin, «My current strategy is to not read any of the code written by my agents…», X, июль 2026: https://x.com/unclebobmartin/status/2080257779395154409

Полная статья, краткая версия и демонстрационный пример: https://github.com/styrumg/Architect-First-Article

Лицензия: CC BY 4.0.

Об авторе

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

Полная статья на Zenodo: 10.5281/zenodo.21544417

По теме

• Статья: Мои Codex skills: как мы собираем дисциплину для ИИ-агента
• Блог: Навык ведущего разработчика — главный скилл для работы с ИИ
• База знаний: BMAD — фреймворк агентной разработки через ИИ-персоны

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov