Как команда Claude Code проводит код-ревью

Переосмысление назначения код-ревью

Когда агенты пишут код, количество изменений растёт стремительно. В монорепозитории Anthropic количество изменений в день увеличилось с примерно 2500 в мае до более чем 30 000 в сентябре этого года.

Claude Code находится в отдельном репозитории, отделённом от основного, но испытывает не меньшее давление. При таком темпе доставки ручное, построчное код-ревью становится невероятно сложным, если не невозможным.

Код-ревью выполняет две задачи:

1. Найти и исправить проблемы до отправки в production
2. Создать общий контекст и понимание кодовой базы в команде

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

Команда считает, что вопрос «прочитал ли человек код?» — неточный прокси для вопроса «что может пойти не так с этим изменением, и какая проверка — автоматизированная или человеческая — лучше всего это поймает?»

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

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

Дефицитный ресурс: человеческое время и внимание

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

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

Поэтому цель в том, чтобы большинство pull request в репозиториях Claude Code (CLI, десктопные и веб-приложения, мобильные приложения) мерджились с максимум одним человеком в цикле, которым может быть автор, без увеличения reverт или инцидентов. Для измерения человеческого времени отслеживаются человеческие одобрения на PR (медиана и 95-й процентиль), комментарии человека и то, как долго PR ждёт человека. Уровни reverт и инцидентов — это ограничение: если они растут, человеческое время не сэкономлено, просто перемещено.

Жизненный цикл изменения

Типичное изменение проходит через несколько уровней код-ревью: от ноутбука инженера (или сессии Claude в Slack) до пользователей.

Слой за слоем

1. Работа проверяется до того, как её посмотрит кто-то ещё

Большинство ревью теперь происходит до создания PR. Команда даёт Claude что-то, что можно запустить — например тесты, сборку или скриншот для сравнения с дизайном — и просит показать результат вместо того, чтобы просто сказать, что всё готово. Затем подагент проверяет diff со свежим контекстом. Обе эти привычки взяты из руководства лучших практик.

Перед открытием PR многие также запускают несколько внутренних навыков: один охотится за ошибками, другой упрощает diff, третий проверяет поведение конец-в-конец. UI-изменения также проверяются на соответствие дизайн-гайдлайнам.

Борис Чёрни, создатель Claude Code, назвал предоставление Claude способности проверить свою работу вероятно самым важным для получения хороших результатов. По его оценкам, это делает финальный результат в два-три раза лучше, и он пишет: «Проверка выглядит по-разному для каждой области. Это может быть просто запуск bash-команды, запуск набора тестов или тестирование приложения в браузере или симуляторе телефона.»

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

• CLAUDE.md рассказывает Claude, что такое проект: стек, соглашения, цели и не-цели. Каждое ревью его загружает, поэтому в большой кодовой базе команда держит его коротким и указывает на другие документы. Ревьюер также отмечает код, который нарушает соглашение в нём, и изменения, которые делают строку в нём устаревшей.
• REVIEW.md, написанный владельцами кода, рассказывает ревьюеру, что важно в их части кода. Отдельно проверяется, действительно ли ревьюер это следует. Хорошие из них короткие. Они говорят, как выглядит отказ в этом репозитории (для документов это «он лжёт», для конфига это «он неправильно маршрутизирует»), ограничивают нелепицы, перечисляют пути для пропуска и просят файл и строку как доказательство вместо предположения по имени. Они также просят резюме, которое начинается с подсчёта и ясно говорит, когда нечего исправлять.

2. AI-ревью для каждого pull request

Каждый pull request получает Claude-ревью прежде, чем его посмотрит человек. Он читает diff против всего репозитория и заявленной цели PR, и спрашивает: решает ли изменение свою задачу, соответствует ли системе, или что-то ломает?

На исправлении ошибки он ищет коренную причину. Публичная версия, Code Review для Claude Code, теперь доступна как GA на планах Team и Enterprise, а /code-review запускает облегченную версию локально.

Когда была запущена исследовательская версия, доля внутренних PR, получающих существенные комментарии ревью, выросла с 16% до 54%. Большинство PR более чем на 1000 строк получают выводы, а большинство маленьких приходят чистыми. Администраторы устанавливают каждый репозиторий на Quick, Standard или Deep. Deep стоит того, где один пропущенный баг стоит больше, чем дополнительное время ревью.

Выводы проверяются другими агентами перед тем, как люди их ревьюят. Несколько агентов одновременно ищут баги. Затем отдельная группа голосует за каждый вывод, и он постится только если достаточно много согласились, что это реально. Выводы, которые касаются только стиля, диагностики или очистки, отбрасываются. Команда A/B тестировала эти фильтры на своих собственных PR перед тем как их сохранить. То, что остаётся, появляется как встроенные комментарии, отсортированные по серьёзности. Каждый помечен как Important, Nit или Pre-existing, поэтому баг, который PR не представил, не выглядит как вина автора.

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

3. Проверка безопасности, которая может заблокировать

Безопасность получает своё собственное автоматизированное ревью. PR не может merge, пока есть открытые выводы из проверки ошибок или проверки безопасности. Либо исправить, либо закрыть цепочку с короткой причиной — так можно очистить ложный позитив.

Если позже коммит исправляет проблему, вывод очищается сам. Можно настроить то же самое с открытоисходным GitHub Action для проверки безопасности или командой /security-review. Setup покрыт в автоматизированных проверках безопасности в Claude Code.

4. Автоматизированные проверки, которые блокируют

Обычные: lint, проверки типов, тесты на каждой платформе и сборка. (Раньше была статья о масштабировании CI для таких объёмов.) Типичный PR CLI может запустить десятки проверок прежде, чем на него посмотрит кто-то. Шаблон PR спрашивает, как было протестировано изменение и как его отменить. Claude может это заполнить, но человек, который попросил изменение, подписывает это.

5. Человеческое одобрение, масштабируемое по риску

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

Уровень риска устанавливается изменением, не автором. Классификатор читает изменение и выбирает его уровень риска. Второй классификатор спрашивает, нужен ли этому конкретному изменению другой человек, даже когда его уровень это не требует. Некоторые пути всегда нужны люди — всё, что владельцы отметили как чувствительное и любой файл CI-workflow.

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

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

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

6. Очередь merge, флаги и постепенный релиз

Очередь merge переускраивает каждую проверку против main с применённым изменением, поэтому два PR, которые проходят отдельно, не могут объединиться в сломанный main. Новое поведение обычно отправляется за флагом сотрудникам Anthropic первыми, и их интенсивное использование часто выявляет регрессии перед пользователями. Публичные релизы идут на канал latest сначала. Канал stable отстаёт от него.

7. Быстрое обнаружение, быстрый rollback

Некоторые ошибки всё ещё проскочат, поэтому последний уровень — о быстром их поймании. Флаги отключаются без развёртывания. Claude Code имеет еженедельную ротацию on-call, и обзоры инцидентов спрашивают, какой уровень должен был поймать проблему.

Заметить плохой merge всё ещё зависит от автора и on-call, а также от панелей reverт и инцидентов. Пока нет автоматических выключателей, которые затягивают одобрение, когда эти числа движутся; инженеры здесь хотят их прежде, чем больше кода переместится на нулевые человеческие merge.

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

Как команда улучшает ревьюера

Процесс код-ревью постоянно улучшается в цикле.

Любые инциденты теперь — это eval. Команда собрала прошлые PR, которые вызвали инциденты, с их fix-forward и reverт, и попросила инженеров, которые знают этот код, подтвердить каждый баг и где он жил. Ревьюер запускается против этого набора ежедневно.

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

Шум стоит больше когда автор — агент. Человек может отмахнуться от nit в секундах. Агент это исправляет, что означает ещё один коммит и ещё один раунд ревью.

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

Когда команда запустила git blame на том, что ревьюер продолжал отмечать, примерно 59% это был код, который был там с первого прохода ревьюера. Ревьюер редко находил новые баги, он находил ещё несколько старых в каждом раунде.

Команда сделала это хуже сама. Они привыкли запускать несколько раундов по умолчанию, так как каждый проход ловит что-то новое. Это может быть стоящим на рискованном изменении, но не на каждом PR. Команда теперь отслеживает rounds-to-pass рядом с recall и изменила re-review:

• Колпак раунда. После трёх раундов, ревьюер просит автора отступить и пересмотреть подход.
• Diff-only re-review после первых нескольких проходов.
• Отметить класс бага, поэтому автор исправляет каждый экземпляр, не одну строку.
• Нет повторов выводов уже постленных.

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

Где люди остаются в цикле

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

• Должны ли мы вообще это строить? Направление, вкус и масштаб. Одна команда, которая объявила свой узкое место ревью решённым, всё ещё держала человеческое ревью для изменений извне команды, поэтому кто-то спрашивает «должны ли мы вообще это делать?»
• Рискованный код такой как биллинг, автообновитель и CI workflow.
• Архитектура которая устанавливает паттерн, который другие будут копировать.
• Чтение доказательства. Вывод теста, команда которая запустилась и что она вернула, скриншот, выводы ревьюера. Если вы не можете сказать что проверки пропустили, просите реальное ревью вместо быстрого одобрения.
• Владение результатом. Человек несёт ответственность за каждое изменение, которое отправляется, кто бы оно ни напечатал.

Совместное использование контекста в команде

Вторая задача код-ревью всегда была распространение понимания кодовой базы. Чтение diff коллеги — как вы узнаёте что изменилось и как куски подходят. Если машины читают большинство, как кто-то узнаёт код?

Команда не имеет формального процесса для этого. Никто в команде не держит полную ментальную модель Claude Code в голове, и они не думают что кто-нибудь нужен. Когда кто-то хочет понять часть кодовой базы, они просят Claude написать explainer для точно этого куска. Это берёт минуты и отражает код как он есть сегодня.

Некоторые идут дальше и имеют Claude строить маленький artifact, который визуализирует эту часть кода и учит это так как этот человек любит учиться.

Если цель — потратить человеческое внимание хорошо, это лучше чем чтение тривиального diff построчно. Одна строка копия изменение учит вас почти ничему. Explainer для модуля которую вы собираетесь изменить учит вас много. Культура команды по умолчанию работать на открытых Slack каналах помогает тоже, так как вы видите что другие строят пока они это строят.

«Ты его лендишь, ты им владеешь»

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

• Изменения маленькие, поэтому их легко ревьювать, дебажить и reverт.
• Всё обратимо. Флаги, reverт и постепенные релизы отменяют большинство ошибок в минуты.
• Blast radius устанавливает бар. Дорогостоящий код получает больше людей и больше проверок.
• Регрессии появляются быстро через telemetry и внутреннее использование.
• Это не вина. Владение исправлением означает вы имеете больше контекста; обзоры инцидентов смотрят на систему.

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

Когда направление меняется

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

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

Как вы можете принять этот процесс

Большинство кусков чтобы сделать это с вашей командой существуют сегодня.

До pull request

• Дайте вашему агенту проверки которые он может запустить, перечисленные в коротком CLAUDE.md, плюс hooks которые запускают formatters и linters.
• Запустите /code-review и /security-review локально или ревью с fresh-context subagent.
• Добавьте REVIEW.md и переместите повторённые комментарии ревью в него.

На каждом pull request

• Требуйте CI и добавьте "Testing", "Risk" и "How to revert" в ваш PR шаблон.
• Добавьте AI ревьюера (Code Review для Claude Code или Claude Code GitHub Action) на один репозиторий, настройте REVIEW.md на несколько недель, потом расширьте.
• Добавьте автоматизированное ревью безопасности и требуйте каждую цепочку ревью разрешённой до merge.
• Совместите усилие ревью с риском: быстрый проход на рутинных изменениях, глубокий где пропущенный баг дорогой (Quick, Standard или Deep в Code Review).
• Ограничьте раунды ревью; после первых нескольких, re-review только новый diff.

Одобрение

• Запишите уровни риска, устанавливаемые из изменения вместо автора; начните строго и ослабьте с доказательством.
• Держите облегченные пути одобрения для авторов которым вы доверяете.
• Используйте CODEOWNERS и branch protection поэтому auth, биллинг, CI и релиз workflow и инсталлеры всегда нужны человеку.
• Никогда не позволяйте bot одобрению заменить требуемое человеческое; отмените одобрения на новые коммиты.

Merge и после

• Используйте очередь merge, флаги функций, внутреннее использование первым, постепенные релизы и one-step rollback.
• Переверните инциденты и reverт в eval набор и переоцените ревьюера каждый раз его prompts, tools или модель меняются.
• Измеряйте человеческое время с reverт и инцидентом ставками как guardrail.

Куда это идёт

Объявление Code Review сказало одобрение pull request — ещё человеческий звонок; продукт постит выводы, не одобрения. Собственные репозитории идут дальше, позволяя владельцам решить какие низкорисковые изменения merge на автоматизированных проверках одних, и эта линия продолжает двигаться.

Когда ревью пропускает что-то, команда спрашивает что модель не имел впереди и кладёт исправление в CLAUDE.md, навык или новую проверку. Цель не изменилась: меньше человеческого времени за изменение и нет больше reverт чем раньше.

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

С благодарностью Emma Webb, Michael Segner и Amie Rotherham за их ревью.