Условия, в которых рождаются системы. Средовой подход для ИИ‑агентов

[AlexeyLapunov]

Руслан, спасибо. Ценно, что подход проверяется на практике, а не остаётся рассуждением о будущем.

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

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

1. Результат проверяется по критериям, зафиксированным заранее, а последствия ошибки исправляет откат кода. Здесь среда может окупиться: полное ревью заменяется выборочной проверкой, если сила проверок подтверждена.

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

3. Последствия ошибки откат не исправит: данные, деньги, действия во внешних системах. Окупается та часть, которую удаётся сделать обратимой (флаги, пробный прогон, выкатка на долю). Остальное остаётся за решением человека.

4. Изменение касается самого контроля — проверок, прав, правил среды. Здесь, как и у вас, агент готовит, а решает человек.

Тип задачи класс не определяет. Рефакторинг под проверенными тестами попадает в первый класс, тот же рефакторинг без тестов — во второй. Миграция данных даже в «некритичной» зоне — это третий. Адаптер из вашего эксперимента — задача первого класса: контракт и проверки готовы заранее. Окупаемость на нём ещё не говорит о втором и третьем классах. А если ошибка адаптера может вызвать необратимое действие во внешней системе, он сам попадает в третий.

И вопрос: смотрели ли вы AI-Disrupt PDLC Сбера? Там тоже ставка на среду, а не на модель. Как соотносите свои примитивы с их подходом — дополняют или это другой путь?

[razon]

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

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

Про AI-Disrupt PDLC Сбера я узнал совсем недавно, уже после моих первых публикаций про средовой подход. Судя по описанию — сходство существенное: они тоже делают ставку на среду работы агента со встроенными проверками и ограничениями полномочий.

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

[vovkats]

Спасибо за подход.

У меня возникли вопросы:

1. Как выявлять ошибочные законы, если формально всё работает правильно?

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

2. Что делать с долгом понимания?

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

3. Как провести онбординг?

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

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

[razon]

Спасибо! Обязательность закона для агента, естественно, не делает его правильным навсегда.

1. Условия пересмотра я бы записывал сразу вместе с обоснованием закона, до внедрения (в ADR, в котором описываем внедрение нового закона). Например, законом запретили синхронные вызовы к доставщикам ради доступности (используем только кэш), а в условия пересмотра закона добавили метрику устаревания данных и/или количество жалоб на неверные сроки доставки. Если условие сработало (какая-то из метрик превысила порог пересмотра) - возвращаемся и анализируем закон.

2. Долг понимания — реальный риск. Поэтому я бы проверял способность команды сопровождать результат: может ли дежурный на стенде разобраться в отказе и восстановить работу, в том числе без привычного ИИ-инструмента. Понятно, что при реальном инциденте ради скорости дежурный будет использовать ИИ-агента, пропитанного знаниями о коде и проекте. На основе реальных инцидентов можно потом и устраивать тренировки на понимание в том числе.

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

В том числе про условия пересмотра любых архитектурных решений подробно пишу в своей книге «Доказательная архитектура», которая скоро (надеюсь скоро) выйдет. Там же разбираю метрики и проверяемую документацию. Эти практики применимы в любом подходе )