Проверка кода Claude: проверки ИИ, одобрение человека и ограничение в три раунда

Anthropic сообщает, что Claude пишет около 90% собственного кода Claude Code. Инженерная команда задается следующим вопросом: как команде проверять изменения, если агенты создают их быстрее, чем люди успевают их прочитать?

Ответом стал многоуровневый процесс, который переносит стандартные проверки на более ранний этап, использует агентов для расследования ошибок и сохраняет внимание людей для решений с более высоким риском. Anthropic сообщает, что с июня по сентябрь количество объединенных pull request увеличилось более чем вдвое, а доля изменений, потребовавших отката, снизилась более чем на 40%.

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

Сначала определите, что может пойти не так, а затем выберите проверку

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

Это превращает проверку из единственного этапа после открытия pull request в непрерывную деятельность. Тесты, сборки и проверки агентами в новом контексте могут обнаружить проблемы до того, как потребуется прерывать работу другого инженера.

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

Отдельный монорепозиторий Anthropic вырос примерно с 2 500 ежедневно объединяемых изменений в мае до более чем 30 000 в сентябре. У Claude Code есть собственный репозиторий; эти показатели монорепозитория не следует напрямую относить к его кодовой базе.

Многоуровневые проверки с учетом риска при одобрении человеком

В представленном отчете выделены три этапа из семиуровневого процесса. Официальный материал описывает полную последовательность:

1. Проверяйте изменения до открытия pull request. Запускайте тесты, сборки и линтеры, проверяйте их результаты и используйте второго агента в новом контексте. Изменения интерфейса также требуют визуальных подтверждений.
2. Запускайте проверку кода с помощью ИИ. Несколько агентов расследуют потенциальные ошибки; отдельные проверяющие оценивают найденные проблемы до публикации комментариев.
3. Проводите отдельную проверку безопасности. Открытые проблемы, найденные автоматической проверкой, блокируют слияние до тех пор, пока они не будут исправлены или закрыты с объяснением.
4. Требуйте прохождения CI. Проверки типов, платформенные тесты, упаковка и сборка остаются обязательными условиями слияния.
5. Применяйте одобрение человека с учетом риска. Содержание изменения, чувствительные пути и уровень доверия к автору определяют необходимый маршрут одобрения.
6. Используйте очередь слияния и поэтапный выпуск. Повторно проверяйте изменение относительно текущей основной ветки, сначала показывайте его внутри команды и выпускайте постепенно.
7. Быстро обнаруживайте проблемы и восстанавливайтесь. Мониторинг, функциональные флаги и откаты ограничивают продолжительность ошибок, которые прошли предыдущие проверки.

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

До открытия PR важны доказательства, а не заявление агента о том, что задача завершена. Команда тестирования и ее результат либо скриншот, проверенный по дизайну, дают проверяющим конкретный объект для анализа. Повторяющиеся проблемы затем можно превращать в правила линтера, навыки или краткие инструкции проекта в CLAUDE.md и REVIEW.md.

Проверяющий ИИ сосредоточен на содержательных дефектах, а не на неограниченных советах по стилю. Anthropic сообщает, что доля внутренних PR с содержательными комментариями выросла с 16% до 54% в период исследовательского предварительного доступа. Существующие ранее проблемы можно отмечать отдельно, чтобы не создавать впечатление, будто каждая найденная проблема была внесена новым изменением.

Кто должен одобрять?

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

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

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

Когда два агента продолжают проверять друг друга

Один pull request, созданный через CLI, за ночь прошел более 50 циклов проверки и исправления, прежде чем владелец его остановил. Агент-автор исправлял небольшой комментарий, создавал новый коммит и запускал проверяющего, который находил следующую проблему.

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

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

Внутренние измерения Anthropic, воспроизведенные в исходном отчете.

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

Что по-прежнему делают люди

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

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

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

Часто задаваемые вопросы

Означает ли то, что Claude пишет 90% своего кода, что люди ничего не проверяют?

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

Может ли одобрение ИИ заменить обязательное одобрение человека?

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

Зачем использовать нескольких агентов для проверки?

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

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

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

Что измеряет заявленное сокращение на 40%?

Это относительное снижение доли объединенных PR Claude Code, потребовавших отката, в период с июня по сентябрь. Это не утверждение о том, что количество всех программных дефектов сократилось на 40%.

Как другой команде оценить такой подход?

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

Связанные инструменты

• Проверка кода Claude: инструменты автоматической проверки, описанные в инженерном материале.
• Проверка безопасности Claude: рекомендации по проверке безопасности в рабочих процессах Claude Code.

Связанные ссылки

• Оригинальный отчет BAAI: представленное китайское освещение темы и скриншоты процесса.
• Официальная инженерная статья: подробное объяснение правил одобрения, метрик и изменений процесса схождения.
• Документация по проверке кода: настройка продукта и принцип работы проверки.
• Лучшие практики Claude Code: практики проверки и работы с контекстом проекта, на которые ссылается команда.
• Автоматическая проверка безопасности: отдельные проверки безопасности и рекомендации по интеграции.
• Инженерный подход Anthropic к управлению исходным кодом: сведения о нагрузке отдельного монорепозитория.

Итоги

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

Автоматизация меняет то, кто читает diff; люди по-прежнему отвечают за решение и результат.