Первый практический сценарий

AI‑review — это система, а не скрипт

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

Сразу после решения «добавим AI‑review» команда неизбежно начнёт обсуждать не одну интеграцию, а устройство производственного процесса:

AgentКакая модель или композиция агентов лучше находит реальные дефекты?
HarnessКакой harness, system prompt и набор навыков использовать для review?
КонтекстДавать только diff, весь модуль, историю задачи или архитектурные соглашения — и в каком объёме?
ДоступНужны ли агенту тесты, сборка, история Git и инструменты проекта, а что должно остаться read‑only?
Jira round tripКак замечание попадёт в задачу, как задать уточнение и как продолжить диалог с тем же исполнителем?
ИзмерениеКакие замечания полезны, где шум и пропуски, сколько стоит запуск и какая версия действительно лучше?
Локальный shortcut

Python → Codex → комментарий в Jira

Такой скрипт быстро демонстрирует идею, но сразу фиксирует одну модель, один harness, один промпт, один объём контекста и один маршрут ответа. Любой эксперимент становится изменением интеграционного кода; сравнивать версии и обосновывать выбор нечем. Это legacy с первой минуты создания.

Общий контур

Issue → Reviewer.Agent → execution → artifacts → Jira

В Multica агент, harness, навыки, доступ, политика контекста и маршрут возврата становятся конфигурацией и сущностями системы. У каждой попытки остаются версия, trace и метрики: варианты можно сравнивать, а разговор с исполнителем — продолжать в контексте задачи.

Multica не избыточна для одного AI‑review. Она закрывает этот сценарий без отдельного самописного интеграционного продукта и одновременно создаёт основу для следующих агентов, навыков и экспериментов. Команда получает не авторитарное «делаем так», а возможность доказать, почему конкретный пайплайн работает лучше альтернатив.