Как команда Claude Code проводит код-ревью: семь шагов и никаких автоматических выключателей

15 октября 2026 года команда Claude Code опубликовала собственный рассказ о том, как она проверяет код, — четырнадцатиминутный инженерный пост, авторство которого приписывается Эдди Османи, Морган Уэстли Лант и Цин Ван. Фраза, объясняющая, почему кто-то вообще ищет это, появляется в начале: Claude пишет около 90 процентов собственного кода Claude Code. Этот пост — не защита этой цифры, а описание механизмов, которые должны были существовать под ней, прежде чем это стало жизнеспособным, а части, достойные внимательного чтения, — это те, которых всё ещё не хватает.

Большинство кратких обзоров останавливаются на двух главных цифрах: количество объединённых pull request'ов в кодовую базу Claude Code более чем удвоилось с июня по сентябрь 2026 года, а доля тех, которые пришлось откатить, снизилась более чем на 40 процентов. Обе цифры исходят от самой команды, и обе можно получить при нескольких разных вариантах организации работы, включая тот, который люди предполагают: что ревью тихо убрали. В посте говорится, что это не так. Они передали большую часть чтения машинам, оптимизировали процесс под человеческое время и внимание и вложились в то, чтобы ошибки можно было быстро и легко откатывать. Всё остальное — детали того, как именно.

Почему ревью вообще стало узким местом

Давление исходило не от политического решения. Оно исходило от объёма. Как сообщается в публикации, в монорепозитории Anthropic количество изменений, вносимых за день, выросло с примерно 2500 в мае до более чем 30 000 в сентябре 2026 года. Claude Code живёт в собственном репозитории, отдельном от этого монорепозитория, но и он испытывает то же давление, только в меньшем масштабе.

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

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

На что они оптимизировали и что считается неудачей

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

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

Метрики затрат на ревью легко накрутить в отрыве от контекста; ревьюер, который одобряет всё подряд, рисует красивые графики времени одобрения. Именно защитный ограничитель не даёт графику лгать.

Семь шагов, а не одни ворота

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

• Проверка ещё до появления pull request. Claude запускает тесты, сборку и линтер, а второй агент проверяет diff в новом контексте. Многие инженеры также запускают внутренние навыки: один ищет баги, другой упрощает diff, третий проверяет поведение от начала до конца. Борис Черни, создавший Claude Code, назвал предоставление Claude возможности проверять собственную работу, вероятно, самым важным для хороших результатов и оценивает, что это делает итоговый результат в два-три раза лучше.

• ИИ-ревью каждого пул-реквеста. Проверка Claude анализирует diff в контексте всего репозитория и заявленной цели пул-реквеста. Несколько агентов параллельно ищут ошибки, затем отдельная группа голосует по каждой находке, и она публикуется, только если достаточно голосов подтверждают, что она реальна. Находки, касающиеся стиля, диагностики или очистки кода, отбрасываются. То, что остаётся, появляется в виде встроенных комментариев с метками Important, Nit или Pre-existing. Когда запустилось исследовательское превью, доля внутренних пул-реквестов, получающих содержательные комментарии по ревью, выросла с 16 до 54 процентов. Администраторы устанавливают для каждого репозитория режим Quick, Standard или Deep.

• Проверка безопасности. Отдельный автоматизированный проход. Pull request не может быть объединён, пока открыто замечание, выявленное в ходе любой из проверок; вы исправляете его или закрываете обсуждение с кратким пояснением. Та же проверка доступна публично в виде GitHub Action для проверки безопасности с открытым исходным кодом или команды /security-review.

• Автоматические проверки, блокирующие слияние. Линтер, проверка типов, тесты на каждой платформе и сборка.

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

• Очередь слияния, флаги и постепенный выпуск. Очередь заново запускает все проверки для main с применённым изменением, поэтому два пулл-реквеста, каждый из которых проходит проверки, не могут вместе сломать main. Новое поведение сначала выпускается под флагом для сотрудников Anthropic, затем — в канал latest, а stable — следом.

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

Уровень задаётся изменением, а не автором.

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

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

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

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

Проверяющий обучен на своих собственных инцидентах.

Это та часть, которую большинство материалов упускает, и она объясняет, почему эта схема продолжает работать, а не постепенно разваливается.

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

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

Слой, который ещё не построен

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

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

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

Вторая задача обзора, которую пост по большей части обходит стороной

В посте прямо говорится, что код-ревью выполняет две задачи: находить и исправлять проблемы до релиза и формировать общий контекст в команде. Основное внимание уделяется первой, а затем автор возвращается ко второй с необычно честным ответом: формального процесса для этого нет, никто не держит в голове полную ментальную модель Claude Code, и они не считают, что кому-либо это нужно. Хотите понять часть кодовой базы? Попросите Claude объяснить именно этот фрагмент.

Два файла с инструкциями несут в себе тот контекст, который раньше жил в головах ревьюеров. CLAUDE.md рассказывает Claude, что это за проект, каков стек, конвенции, цели и не-цели, и намеренно держится кратким. REVIEW.md пишут владельцы кода: в нём сказано, как выглядит сбой в их части кода, какие пути пропускать, и требуется указать файл и строку, а не догадку.

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

Где маршрутизатор уместен, а где нет

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

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

Граница важна. Мы размещаем модели. Мы не размещаем Claude Code, мы не запускаем Code Review for Claude Code и не имеем доступа к конвейеру, о котором идет речь в этой статье. Code Review for Claude Code — продукт Anthropic, общедоступный на планах Team и Enterprise, а более легкая версия доступна локально как /code-review. Если вам нужен именно этот конвейер, он находится там; в версии для вашей собственной команды маршрутизатор — это решение по инфраструктуре, а не по проверке кода.

Что команда поменьше действительно может скопировать

Запишите правила ревью там, где ревьюер сможет их прочитать: короткий CLAUDE.md для проекта и REVIEW.md для каждой области, где описано, как выглядит сбой, и требуется указание файла и строки вместо догадок. Зафиксируйте уровни риска письменно, сделайте их свойством изменения, а не автора, начинайте строго и ослабляйте только при наличии доказательств. Ограничьте, что может одобрить автоматизированное ревью, и никогда не позволяйте одобрению агента считаться одобрением человека. Привяжите одобрения к коммитам. Используйте очередь слияния. Превращайте инциденты и откаты в тестовые случаи и переоценивайте ревьюера при каждом его изменении, потому что неизмеряемый ревьюер — это линтер с более удачным маркетингом.

Тогда следите за {{1}}защитным ограничителем{{/1}}, а не за временем согласования. Собственная формулировка команды даёт вам критерий для любого изменения процесса ревью, которое вы рассматриваете: сохранились ли показатели {{2}}откатов{{/2}} и инцидентов или время просто перешло от ревьюера к человеку, который потом устраняет последствия? На этот вопрос можно ответить с помощью данных, которые уже есть у большинства команд, и он позволяет отличить процесс, который стал быстрее, от процесса, который только выглядит быстрее в течение квартала.