Тень стратега: как AI-агент становится продолжением человека, а не его заменой

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

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

Автор допускает, что могут быть исключительные ситуации, когда у кого-то прям всё было «супер-пупер», но он считает, что это стоит принимать к сведению, но не стоит воспринимать как единственную инструкцию к действию.

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

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

AI-агент — это инструмент. Стратег обучает его, выстраивая процесс, и агент становится его тенью. Тень живёт своей жизнью, работает непрерывно, но не эволюционирует без стратега.

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

Немного истории

Эпоха созидания (было)

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

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

Эпоха синтеза (сейчас)

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

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

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

Если посмотреть назад, то можно увидеть, что история повторяется.

• корпоративные шины данных (ESB — Enterprise Service Bus)

• SOA (WS-*, SOAP, BPEL)

Почему тогда не взлетело?
Проприетарные системы, цена железа.

Почему сейчас сработало?
Есть жизнеспособные опенсорс-решения, снижение цены на железо и ресурсы. Решения стали лучше масштабироваться.

Я бы хотел, чтобы всё стремилось именно в контексте прогресса всего человечества и его экспансии, но… есть как есть.

Текущий знаменатель всех наших уравнений — это деньги. Глобально бизнесу всё равно на крутой алгоритм или теорию, если её нельзя сделать активом.

Все ЦОДы, ноуты, LLM, все хай-тек игрушки у нас есть потому, что мы можем создавать активы намного больше, чем потребляем.

Бизнес-контекст

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

Раньше это всегда был выбор ИЛИ, но AI сильно сжал эту разницу при выборе и открыл другую дверь: если не знать, что делать, то незнание генерирует хаос очень быстро, создавая иллюзию через команду агенту «исправь».

Если есть явное преимущество, которое трудно воспроизвести — никто им делиться не будет.

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

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

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

Таким образом, в нынешнем виде AI — это наша ближайшая реальность.

Почему появилась идея

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

Слепое следование хайпу AI может привести не к улучшению, а просто к увеличению техдолга и более быстрому приближению предела в развитии систем.

Т.е. AI даёт лопату и даже может копать, но он не знает, что нужно выкопать именно вам.

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

Представленная Сбером Whitepaper «AI-Disrupt PDLC» требует осмысленного подхода и ответа на вопросы: «А вы понимаете, зачем она вам? А точно ли вы сможете реализовать данное преимущество?». Автор не видит глобальных преимуществ в использовании двухпетлевого подхода в чистом виде с учётом платформы Сбера. Основная задача стратегии — показать проблему, задать сроки и предоставить «решение». Но «решение» не является полным.

«Скорость требует симметричного контроля». Если мы даём Tiny Teams свободу и скорость (в том числе за счёт AI-копилотов), мы обязаны пропорционально зажать их в тиски правил. Иначе система уйдёт в надкритический разнос.

Текущее решение от Сбера чем-то напоминает время внедрения CRM, когда говорили, что вот поставите систему и всё у вас заработает, но это не случилось. Почему?

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

Теперь вы не покупаете, а берёте подписку. Но тогда вы здесь заложник.

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

Как выглядит классический подход при разработке ПО (SDLC)

• Сбор требований: Заказчик и аналитики подробно описывают все пожелания к программе. Создаётся ТЗ.

• Проектирование: Архитекторы решают, как будет устроена система.

• Разработка: Пишут код на основе требований СА и архитектуры.

• Тестирование: Проверяют ПО на ошибки и сбои согласно требованиям.

• Внедрение и поддержка: Готовый продукт отдают пользователям, а затем исправляют мелкие неполадки.

Заказчик стремится как можно быстрее вывести фичу в прод, но…

• сбор требований идёт долго

• проектирование идёт долго

Т.е. никак не получается сделать правильно и быстро.

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

Теперь у нас есть AI-агенты, которые…

• Пишут код с учётом контекста нашей системы

• Пишут тесты на основании нашего кода

• Пишут доки на основании нашего кода

Но если нет рамок, то процесс просто генерирует хаос быстрее.

Как понять, что решение правильное? Что такое правильное? Почему сейчас можно сделать неправильно, как транзитное решение? Где гарантия, что внешняя платформа думает правильно именно в вашем контексте?

И вот мы имеем тонну одноразового кода. Как долго AI сможет верно выполнять команду «исправь»?

Поиск решения и инструментов

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

Если Cursor стал неотъемлемой частью повседневной жизни разработчика, то можно ли реализовать подобный подход, но для требований или для сложных легаси-систем?

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

Какой автор выбрал полигон

Фин организация, закрытый контур. Доступ к внешним моделям под запретом ИБ. Есть мощности под внутренние открытые модели. Используется Confluence для написания документации и Jira для управления процессами разработки. Есть Bitbucket и т.д. В общем всё по классике жанра. Почему такой полигон? Доступны все MCP.

Какие процессы были выбраны: создание бизнес требований и системная аналитика.

Какую проблему решаем

Требования должны появляться до начала разработки. Сейчас они могут появляться после разработки в 80% случаев, т.к. агентная разработка увеличила скорость создания артефактов в несколько раз, иногда на порядок. Задача для агентной разработки должна опираться не только на контекст кода, но и на требования. Чем выше качество требований и контрактов окружения, тем проще код, который нам нужно реализовать.

Считаем, что в совокупности система имеет надкритическое значение. Т.е. знаний в предметной области и способах решений более чем достаточно, что периодически приводит к дублированию реализаций/решений.

Как происходит первичный анализ?

Есть идея/задача, у этой задачи есть владелец, тот, кто понимает её суть, обычно это PO. Но PO не готов все требования детально писать сам, обычно начинается фаза исследования, в рамках которой бизнес-аналитик выполняет оцифровку требований, формируя BRD. На выходе мы получаем первичные требования (схемы), которые согласованы с методологами, другими подразделениями и архитектурой, а также утверждены заказчиком.

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

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

Есть ли возможность оптимизировать данный процесс?

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

Локализация понятия «правильно»

Что такое «правильно» в контексте требований? Полнота, непротиворечивость, проверяемость, соответствие границам.

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

Что это даст?

Правила и контекст.

Если нет процессов и качественных требований, то внедрение AI просто ускорит создание хаоса, но не даст весомых преимуществ.

Почти всегда в командах есть лидеры как носители стратегии продукта. Да, бизнес всегда стремится к снижению риска bus factor, но все люди разные: кто-то явно стремится к знаниям, и бизнес это явно поощряет, т.к. платить одному выгоднее, чем, например, пятерым. (В общем, это всегда дилемма.)

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

А что изменилось?

По сути, проблема осталась — это люди. Сам по себе агент с LLM легко поддаётся влиянию. Задача — сделать процесс как нашу тень или ИО. Наша задача — удерживать смысл и суть нашего продукта как можно компактнее и в актуальном состоянии.

Что мы будем делать?

Построим свой процесс.

Возьмём за основу DeepSeek-V4.1 Flash.

Задача — создавать профиль/«личность» нашего агента.

Внедряем процесс в существующую организацию.

Мы не строим что-то новое или уникальное, так как с точки зрения автора нет разницы, ставите вы задачу сотруднику или агенту. И тот и другой могут ошибиться, но агент работает без остановки. Агент с LLM не может заменить стратега (координатора), это его инструмент. Просто теперь не нужна куча сотрудников для апробации и реализации типовых реализаций.

Автор считает, что уровень текущих моделей сейчас недостаточен для работы с ролью стратега в закрытых контурах. Если вы общались с моделью, то заметно, что она мыслит абстрактно в рамках своего понятия «правильного», но это отличается от вашего «правильного». Даже если вы загрузите в модель все документы проекта, вы не загрузите туда ваш опыт и полностью ваше видение. Интуиция стратега — это его опыт. Там, где стратег режет углы и проверяет гипотезу, агент явно размышляет — это его плюс и минус. У агентов есть ограниченное контекстное окно. Поэтому здесь нужен человек-оркестратор. С учётом скорости удешевления ресурсов это решение видится как временное, но предположительно на дистанции 1,5–2 года будет иметь актуальность.

Составные части процесса

• локальный агент

• Confluence как платформа для описания самого процесса, а также реализация памяти и масштабирования

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

Если мы выбрали процесс, то у нас по нему могут быть какие-либо уже наработанные данные (старые системы, DDD, методологические требования, наработки по аналитике, архитектура), просто этих данных может быть достаточно много. AI позволяет посмотреть на всё и структурировать для сопоставления с нашим видением. Это даст нам возможность создать первичный skill для участников — skill-опросник, предназначенный для первичного ввода данных. Ввод данных идёт как текстовый диалог в произвольной форме.

Skill в данном подходе даёт по косвенным признакам преимущество от 10% на этапе формирования первичных требований (результаты внутренних тестовых прогонов данного подхода).

Общие встречи ведутся под запись с расшифровкой и итоговой саммаризацией.

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

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

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

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

Исходя из того, что мы строим процесс по аналогии с реальными людьми, как мы понимаем, что сотрудник сделал всё правильно? Если мы это понимаем (знаем критерии), то можем сформулировать и добавить как механизм валидации. Т.е. это агент-контролёр со своим процессом и своей памятью. Весь подход строится на том, что мы можем дообучать данные процессы и сохранять их память через артефакты на страницах Confluence как естественный процесс — результаты работы что человека, что агента.

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

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

Итоговый процесс

Процесс состоит из следующих элементов.

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

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

Расшифровка встреч. Общие встречи записываются, расшифровываются и саммаризируются.

RAG по Confluence. Все артефакты — требования, схемы, BRD, шаблоны — хранятся в Confluence. Агент использует RAG для поиска по этим данным. Это даёт контекст, который не влезает в контекстное окно модели. Владелец процесса дообучает модель через skill и RAG, обновляя мастер-версию. Существует две реализации RAG: первая — шаблон процесса, вторая — результат взаимодействия с процессом.

Агент-контролёр. Проверяет требования на полноту, непротиворечивость, проверяемость и соответствие границам. Работает по своему процессу и своей памяти. По сути, это простой процесс, который дообучают по мере фиксации ошибок.

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

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

Выводы

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

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

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

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

Чем выше качество данных и контекст, тем проще будет последующим этапам разработки, тогда у Tiny Teams будет максимальный КПД.

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

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

Что произойдёт, если мы всё бросим на полпути? Ничего, по сути, не сломается. Мы не создаём ничего экстраординарного, просто всё станет как раньше. Результаты работы агентов эквивалентны работе сотрудников, и результаты их работы зафиксированы в Confluence.

По сути, это можно назвать упрощённой версией системы семантического трекинга на доступных ресурсах для борьбы со «смысловым шумом» и «дрейфом» смысла (Semantic Drift). Также это можно использовать как компенсаторный процесс для проблемы bus factor.