Фабрике программного обеспечения нужен более быстрый цикл проверки: дальнейшая оптимизация пути от PR до слияния

TL;DR

В AI-нативной инженерной организации генерация кода больше не является самым медленным этапом выпуска ПО. Проверка, верификация, исправление и принятие решений человеком становятся узкими местами и в конечном счёте определяют, насколько быстрее может двигаться организация. Автономные AI-инструменты для написания кода могут дать ускорение на 30–40%, но для кардинального повышения пропускной способности необходимо оптимизировать всё, что происходит после написания кода.

В нашем предыдущем посте о решении код-ревью с помощью Cosmos мы описали систему ревью, которая помогла нашей инженерной организации увеличить объём выпускаемого кода в 3 раза, сократив при этом медианное время до мерджа и сохранив качество. С тех пор мы расширили эту систему за пределы ревью на весь цикл от PR до мерджа: специализированные агенты выполняют механическую работу, проверяют корректность и обрабатывают обратную связь, в то время как люди обеспечивают экспертную оценку и передачу знаний и всегда сохраняют за собой финальное решение о мердже.

Это loop engineering: улучшение полной системы, которая превращает сгенерированный код в проверенное, понятое и готовое к мерджу изменение, а не оптимизация какого-то одного инструмента в отдельности.

Почему одного «AI-инструмента код-ревью» недостаточно

Обычный AI-инструмент код-ревью, такой как CodeRabbit или Greptile, анализирует диф и оставляет комментарии. Это полезно, но ревью — лишь один из шагов. Настоящее узкое место — цепочка передач задач между людьми:

• Восстановление замысла и архитектуры.
• Сортировка низкорисковых изменений.
• Внесение правок по итогам ревью.
• Исправление ошибок CI и конфликтов мерджа.
• Сквозная проверка поведения фичи.
• Сбор достаточного объёма доказательств для безопасного релиза.
• Повторное ревью после каждого пуша.

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

1. Обзор: построение полного цикла

прочитайте описание изображения

ALT

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

Наша исходная система разделяла анализ рисков (Risk Analyzer), построчную проверку корректности (Deep Reviewer) и дизайн-ревью с участием человека (Pair Review). Расширенная система добавляет исправление, проверку в рантайме и расширенное авто-одобрение, что ещё сильнее сокращает участие человека. Обзор Cosmos и его настраиваемых экспертов см. в нашем предыдущем посте о решении код-ревью с помощью Cosmos.

Эксперты и возможности, а не один универсальный ревьюер

Эксперт или возможность

Ответственность

Risk Analyzer

Классифицирует риск и применяет политику авто-одобрения

Deep Reviewer

Выполняет исчерпывающий построчный анализ на предмет объективных дефектов корректности

Pair Reviewer

Восстанавливает замысел, архитектуру, продуктовый контекст и компромиссы

Memory Manager

Запоминает обратную связь из PR и сессий Pair Review для улучшения будущих запусков

Verifier

<sup>

НОВОЕ

</sup>

Проверяет затронутое поведение сквозным образом в тестовом окружении (

блог о Verifier

)

PR Fixer

<sup>

НОВОЕ

</sup>

Исправляет замечания ревью, ошибки CI и конфликты мерджа

Review Dashboard

<sup>

НОВОЕ

</sup>

Наблюдает и резюмирует состояние экспертов

cosmos approve

<sup>

НОВОЕ

</sup>

Оценивает настраиваемую политику одобрения по запросу автора

Различие между Deep Reviewer и Pair Reviewer особенно важно:

• Deep Reviewer спрашивает: «Есть ли объективная ошибка в этой реализации?» Он работает автономно и проверяет PR на соответствие рекомендациям AGENTS.md или CLAUDE.md.
• Pair Reviewer спрашивает: «Имеет ли это изменение смысл в более широкой системе и какие решения требуют участия человека?» Он работает интерактивно с человеком. Человек также может поручить ему отслеживать PR после публикации комментариев ревью и одобрить от его имени, когда комментарии будут учтены.

Ранее эксперт PR Author выполнял двойную работу: писал PR и исправлял комментарии ревью, ошибки CI и другие сопутствующие задачи. В новой раздельной архитектуре PR Author останавливается на создании черновика PR, а PR Fixer берёт всё остальное на себя. Это даёт пользователям больше контроля над тем, как выполняются исправления, и поддерживает PR, созданные без PR Author.

Review Dashboard объединяет статус экспертов, проверенные коммиты, доказательства и доступные действия в едином представлении.

1. Проектирование цикла с участием человека

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

Почему люди остаются в цикле

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

• Принятия решений: Должна ли эта логика жить во фронтенде или бэкенде? Уместен ли этот компромисс для продукта? Приемлем ли этот риск сейчас?
• Передачи знаний: Ревью — один из способов, которым инженеры выстраивают общее понимание архитектуры и поведения продукта.
• Ответственности и подотчётности: Агенты не владеют ПО после его релиза; им владеют разработчики-люди и инженерные организации. Поэтому финальное решение всегда принимает человек, и именно он нажимает Merge. Ни один из этих экспертов не выполняет мердж PR.

Целевой дизайн поэтому таков:

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

Рабочий процесс автора и ревьюера: до и после

Традиционный рабочий процесс

Рабочий процесс с человеком в цикле

Вручную сортировать каждый PR и выявлять низкорисковые изменения

Позволить

Risk Analyzer

классифицировать риск и применять политику авто-одобрения организации

Читать PR построчно

Доверить

Deep Reviewer

выполнение исчерпывающего построчного анализа

Восстанавливать контекст, замысел и архитектуру из диффа

Использовать сводку

Pair Reviewer

, чтобы понять изменение и выявить вопросы, требующие суждения

Вручную разворачивать и проверять фичу

Изучать доказательства

Verifier

: скриншоты, логи, трейсы и захваченные выходные данные

Перепроверять каждое исправление с нуля

Позволить

Pair Reviewer

отслеживать, были ли учтены авторизованные комментарии

Разбирать обратную связь, вносить исправления, чинить CI, разрешать конфликты и объяснять каждое изменение

Позволить

PR Fixer

— или

PR Author

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

Искать актуальное состояние по всем комментариям и проверкам

Использовать

Review Dashboard

как точку входа

Вручную собирать доказательства ревью, владения и верификации перед запросом одобрения

Вызывать

cosmos approve

для оценки настроенной политики одобрения на основе текущих доказательств

Решать, выполнять ли мердж

По-прежнему решать, выполнять ли мердж

Экономическая логика использования нескольких экспертов

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

Одна из ключевых задач Augment — помогать организациям оптимизировать затраты. Это означает оптимизацию общей стоимости за задачу: человеческие усилия плюс стоимость токенов. Это не означает минимизацию использования токенов в ущерб успешному результату. Один эксперт, нагруженный шестью обязанностями, будет выполнять каждую из них посредственно и потребует больше вмешательства человека. Шесть специализированных экспертов могут сосредоточиться каждый на своей части PR-ревью, выдавать более качественные артефакты ревью и автономно вести большую часть процесса.

3. Стоимость и качество: оптимизация стоимости за успешный результат

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

Сегодня мы используем GPT-5.6 Sol для задач, требующих высокой степени суждения, таких как анализ рисков, глубокое и парное ревью, а также исправление кода. Ограниченные, механически проверяемые задачи, такие как агрегация данных для дашборда и мониторинг конфликтов мерджа, выполняются на GPT-5.6 Luna. Модели с более длительным TTL кэша также предпочтительны для долго работающих агентов, поскольку кэшированный ввод обычно дисконтируется на 90%.

4. Настраиваемый путь одобрения с помощью cosmos approve

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

Автор PR может оставить комментарий cosmos approve, чтобы запросить оценку в соответствии с политикой одобрения. Финальный мердж по-прежнему выполняет человек.

Организации определяют собственную политику одобрения. Наша внутренняя политика проверяет:

1. Владение: Запрос делает автор PR, и автор является фактическим CODEOWNER для каждого изменённого файла.
2. Ревью актуальной версии: Нет нерешённых замечаний Deep Reviewer, блокеров Pair Reviewer или неучтённых комментариев людей.
3. Отсутствие противоречивых данных из рантайма: Verifier не сообщил о неустранённом дефекте в текущем коммите.

5. Настраиваемость — часть архитектуры

Мы спроектировали систему экспертов так, чтобы команды могли настраивать цикл с помощью Cosmos Advisor.

• Состав экспертов: Добавляйте, удаляйте или заменяйте экспертов; выбирайте модель и промпт для каждой ответственности.
• Работа: Настраивайте триггеры, инструменты, интеграции и среды верификации.
• Контроль: Ограничивайте, кто может вызывать действия и к каким учётным данным, репозиториям и системам имеет доступ каждый эксперт.
• Политика: Определяйте правила одобрения, обязательные проверки, требования CODEOWNER и допустимые доказательства.

Операционная модель AI-нативного PR-ревью

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

Высокоэффективный цикл от PR до мерджа требует:

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

Это loop engineering в применении к жизненному циклу PR: оптимизация системы, которая создаёт проверенное, понятое и готовое к мерджу изменение, а не объёма вывода какого-то отдельного агента.

Создайте свой собственный цикл от PR до мерджа

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

Попробовать Cosmos