Высокорисковый релиз в высоконагруженной микросервисной системе, легаси-код, сжатые сроки и больше 8000 документов с требованиями в Confluence. QA-инженер, автор этого кейса, не стал разбирать документацию вручную: он разбил общую задачу на небольшие специализированные подзадачи и поручил каждую отдельному ИИ-агенту в рамках структурированного процесса.
Работа шла в два этапа. Сначала параллельно запускались агенты: одни искали в Confluence требования по конкретным действиям системы, другие исследовали кодовую базу. Затем последовательно прослеживались сквозные потоки, чтобы понять, какие события их запускают и как воспроизвести эти события при тестировании. Итоговый отчёт со ссылками на первоисточники прошёл проверку разработчиками и системными аналитиками и использовался как тестовое покрытие релиза.
Дальше разовый кейс превратился в переиспользуемую среду на базе Agentic AI для агентов Cursor. Она отвечает на вопросы о поведении сервисов, находит расхождения между требованиями и кодом и обновляет базу знаний. Автор называет результат прототипом: нужны тестирование и доработка, а экспертная проверка остаётся обязательной.
Проблема: 8000+ документов и один пропущенный дефект как финансовый риск
Задача звучала так: протестировать релиз, сопряжённый с высокими рисками и реализованный в высоконагруженных агломерациях микросервисов с легаси-проблемами, и всё это при сжатых сроках. Цена ошибки измерялась деньгами.
даже один пропущенный дефект мог создать существенный финансовый риск
Формально работа упиралась в документацию. В Confluence накопилось больше 8000 документов: бизнес-требования, функциональные требования, пользовательские истории и разные спецификации. Сопоставить такой объём с кодом и релизом вручную за отведённое время не получалось, а тестовое покрытие обычно и строится из требований. В микросервисной системе один сценарий проходит через несколько сервисов, поэтому разрыв в любом звене цепочки остаётся незамеченным, пока не сработает в продакшене.
Отсюда развилка: либо сокращать охват и рисковать, либо искать способ обрабатывать документацию и код машинно. Автор выбрал второе. Описание задачи и хода работ приводится в публикации на Хабре.
Решение: декомпозиция задачи и агентный подход
Решение состояло в том, чтобы разбить общую задачу на небольшие специализированные подзадачи и поручить каждую отдельному ИИ-агенту в рамках структурированного процесса. Агент здесь отличается от обычного запроса к LLM: модель не просто генерирует текст, а проходит цепочку шагов по заданным правилам, работает с подключёнными источниками и передаёт результат следующему этапу в оговорённом формате. Роль человека смещается к постановке задачи, выбору критериев и проверке результата.
Семь принципов, на которых держался процесс:
- разбивать работу на небольшие задачи с чёткими границами и одной зоной ответственности;
- задавать для каждого этапа понятные и структурированные форматы входных и выходных данных;
- передавать агенту только необходимый контекст, учитывая ограничения контекстного окна;
- запускать независимые задачи параллельно, если это повышает эффективность без снижения качества;
- выбирать модели с учётом сложности задачи, требуемой точности и стоимости;
- давать каждому агенту чёткие инструкции, ограничения и критерии успешного выполнения;
- проверять промежуточные артефакты.
Перечень принципов и логика этапов приведены в исходном разборе.
Принципы декомпозиции: границы, форматы, контекст
Границы. У подзадачи одна зона ответственности. Поиск требований в Confluence и исследование кодовой базы стали разными задачами: у них разные источники, разный объём и разные критерии готовности. Агент, которому поручили «разобраться с релизом», вернёт общие слова. Агент с формулировкой «найти в Confluence требования, связанные с публикацией в конкретный топик Kafka» выдаёт проверяемый список.
Форматы. На каждом этапе известен формат входа и выхода. Требования собираются в список со ссылками, код описывается картой реализации, потоки описываются картой ожидаемых потоков. Жёсткий формат даёт два эффекта: следующий агент получает предсказуемые данные, а ревьюер сразу видит, чего в ответе не хватает.
Контекст. Агенту передаётся только нужное, с учётом ограничений контекстного окна. Если залить в промпт всю документацию, релевантные детали тонут, а часть материала просто не помещается. Дробление на подзадачи решает и эту проблему: каждая работает со своей выборкой документов или участком кода.
Оставшиеся пункты работают поверх этих трёх: параллельно запускаются только независимые подзадачи, а промежуточные артефакты проверяются до того, как на них начнёт опираться следующий этап.
Выбор моделей: сложность, точность, стоимость
Модели выбирались с учётом сложности задачи, требуемой точности и стоимости. Конкретные названия моделей в разборе не приводятся, поэтому опираться приходится на сам критерий, а не на готовый список.
Логика простая. Механические подзадачи (найти упоминания конкретного действия в массиве документов, отфильтровать и привести к заданному формату) не требуют самой дорогой модели: справится более лёгкая и быстрая. Анализ кодовой базы, где нужно удерживать связи между сервисами и не выдумывать несуществующие вызовы, требует высокой точности, и здесь экономия на модели оборачивается ошибками, которые потом ловит человек.
Стоимость считают на весь прогон, а не на отдельный запрос. Цепочка из десятков дешёвых агентов, прочёсывающих тысячи документов, может обойтись дороже, чем несколько точных прогонов мощной модели по той же задаче. Критерий выбора стоит зафиксировать до старта: иначе каждый этап решается «на глаз», и результат не воспроизводится на следующем релизе.
Этап 1: параллельный поиск требований и исследование кодовой базы
Первый этап начинался с параллельного определения исходных точек. Нужно было найти в Confluence требования, связанные с публикацией сообщений в определённый топик Kafka: результат получил название артефакт № 1. Параллельно искали требования, связанные с изменением данных в целевой таблице SQL-базы: это артефакт № 2. Третья задача того же этапа: исследовать кодовую базу и найти участки кода, отвечающие за публикацию сообщений в топик Kafka или за изменение данных в таблице. Результат назвали артефактом № 3, картой реализации.
Kafka-топик и таблица SQL выбраны не случайно. Это конкретные наблюдаемые действия системы: сообщение уходит в топик, строка меняется в таблице. Такие точки легко проверить, и они существуют одновременно в двух мирах, в требованиях и в коде. Именно совпадение точки в документации и в реализации позволяет потом сравнить ожидаемое поведение с фактическим.
Задачи этапа независимы: поиск требований не нуждается в результатах исследования кода, а карта реализации не зависит от найденных требований. Поэтому их запускали параллельно, без потери качества и с экономией времени.
Этап 2: построение карты сквозных потоков
Второй этап шёл последовательно. Артефакты № 1 и № 2 стали исходными точками для дальнейшего поиска в Confluence: от конкретного действия агент двигался по потоку и собирал связанные требования. Результат - артефакт № 4, карта ожидаемых потоков.
Ключевой вопрос этого этапа: какие события запускают каждый из ожидаемых потоков и как их воспроизвести при тестировании. Без ответа карта требований остаётся текстом, а проверка превращается в перебор сценариев наугад.
Последовательность здесь обязательна, потому что каждый следующий шаг опирается на предыдущий. Сначала нужно знать, от какой точки стартовать, затем какие события эту точку активируют, и только потом как повторить событие в тестовой среде. Если запустить этот этап параллельно с первым, агенты будут трассировать потоки от случайных точек. Описание обоих этапов есть в разборе кейса.
Итоговый отчёт и его проверка экспертами
Результатом стал отчёт, где каждый вывод подкреплён ссылкой на первоисточник: конкретный документ в Confluence или участок кода. Автор кейса отмечает, что отчёт прошёл проверку разработчиками и системными аналитиками, а затем использовался как тестовое покрытие релиза.
Ссылки на первоисточники делают проверку быстрой. Ревьюеру не нужно верить агенту на слово: он открывает указанный документ или файл и сверяет. Вывод без ссылки считается неподтверждённым и в покрытие не попадает.
Экспертная проверка остаётся обязательным шагом. Разработчики и системные аналитики знают систему и её исторические компромиссы. Агент видит документацию и код такими, какие они есть, включая устаревшие описания и незадокументированные исключения. Похожая ситуация описана в разборе о том, как ИИ-агент для разработки стал главным помощником аналитиков: инструмент, не вытянувший боевые задачи, оказался полезен именно на исследовательских запросах к базе знаний.
Превращение процесса в переиспользуемую среду для агентов Cursor
После релиза процесс превратился в переиспользуемую среду для агентов Cursor. Из набора промптов и артефактов получился инструмент, который отвечает на вопросы о поведении сервисов, выявляет расхождения между требованиями и кодом и обновляет базу знаний. Логика та же, что и в ручном кейсе: агент ищет факты в документации и коде, а не пересказывает их по памяти.
Ценность в повторяемости. Путь от требования до участка кода описывает не только текущий релиз, но и правила, по которым работает система, поэтому следующая проверка стартует не с нуля. Как выстроить контроль качества для агентов на длинной дистанции, разбирается в отдельном материале о том, как Cursor выстраивает доверие к ИИ-агентам через верификацию, evals и жёсткие CI-проверки.
Автор называет результат прототипом, которому нужны тестирование и доработка. Это не готовый продукт, и рассчитывать на стабильную работу без сопровождения не стоит.
Ограничения подхода и что нужно доработать
- Незрелость прототипа. Среда требует тестирования и доработки; поведение на других релизах и в других командах не подтверждено.
- Экспертная проверка обязательна. Отчёт без ревью разработчиков и аналитиков нельзя использовать как покрытие.
- Зависимость от качества источников. Устаревшие или неполные документы и недокументированные исключения в коде напрямую искажают карту потоков.
- Ошибки на нечётких требованиях. Чем расплывчатее формулировка, тем выше шанс, что агент достроит смысл сам.
- Ограничения контекстного окна. Крупные сервисы и объёмная документация требуют дробления на подзадачи; чем больше подзадача, тем выше риск потерять детали.
- Неполнота публичного описания. Доступный разбор обрывается на втором этапе: детали устройства переиспользуемой среды, конкретные модели и порядок экспертной проверки не раскрыты.
Подход снимает рутину, но не отменяет роли QA-инженера: человек ставит задачу, задаёт критерии, проверяет артефакты и отвечает за итоговое покрытие. Тот же принцип работает и в разработке: агенты ускоряют одни этапы и почти не влияют на другие, что разбирается в материале о том, где AI-агенты реально ускоряют работу, а где создают иллюзию продуктивности.
Практические выводы: кому подходит и с чего начать
Схема выигрывает там, где много документации и сложная микросервисная архитектура: чем больше требований нужно свести с кодом, тем заметнее разница с ручным разбором. Для небольшого сервиса с десятком страниц описаний весь этот аппарат избыточен.
Порядок действий, если решите пробовать:
- Выберите одну задачу проверки, а не весь релиз.
- Найдите опорные точки в системе: конкретное сообщение в топике, конкретную таблицу, конкретный эндпоинт.
- Разбейте работу на подзадачи с одной зоной ответственности: поиск требований, карта реализации, карта потоков.
- Задайте форматы артефактов до запуска агентов.
- Отправьте независимые подзадачи в параллель.
- Проверьте промежуточные артефакты и отбракуйте выводы без ссылок на первоисточники.
- Покажите итог разработчикам и аналитикам, прежде чем использовать его как покрытие.
Понадобятся навыки работы с LLM и понимание архитектуры сервисов. Без второго не получится ни выбрать опорные точки, ни оценить, какой артефакт выглядит правдоподобно, но неверен. Узкое место здесь то же, что и в разработке с агентами: проектирование системы, а не генерация кода, определяет, будет ли результат воспроизводимым.