Команда Claude Code описала, как проверяет код, который пишет нейросеть

Команда Claude Code в Anthropic опубликовала на claude.dev разбор того, как она проверяет код при том объёме, который выдают агенты. По словам авторов, Claude пишет около 90% кода самого Claude Code. С июня по сентябрь число слитых pull request (PR) в репозиторий Claude Code выросло более чем вдвое, а доля PR, которые пришлось откатывать, снизилась более чем на 40% (абсолютные числа не приведены). В монорепозитории Anthropic число изменений в день выросло примерно с 2500 в мае до более чем 30 000 в сентябре; сам Claude Code живёт в отдельном репозитории, но давление там тоже растёт.

Главная мысль: ревью не отменили, но большую часть чтения передали машинам. Вопрос «прочитал ли человек код?» авторы считают неточной заменой вопроса «что может пойти не так с этим изменением и какая проверка, автоматическая или человеческая, лучше всего это поймает». Поэтому проверка идёт непрерывно, как проверка орфографии во время набора текста, а не воротами в конце: большинство изменений уже просмотрены и исправлены Claude хотя бы раз, прежде чем их увидит человек. Цель сформулирована так: большинство PR в репозиториях Claude Code (CLI, десктопные и веб-приложения, мобильные приложения) сливаются максимум с одним человеком в цепочке (им может быть сам автор) без роста откатов и инцидентов. Человеческое время измеряют по числу одобрений на PR (медиана и 95-й процентиль), числу комментариев и времени ожидания PR человеком; откаты и инциденты служат ограничителем: если они растут, время не сэкономлено, а лишь перенесено.

Слои проверки. 1) До появления PR: Claude получает то, что можно запустить (тесты, сборку, скриншот для сравнения с дизайном) и должен показать результат, а не заявить «готово»; затем субагент с чистым контекстом смотрит дифф. Перед PR многие запускают внутренние навыки: поиск багов, упрощение диффа, сквозная проверка поведения; интерфейс сверяют с дизайн-гайдами. Борис Черни, создатель Claude Code, называет возможность проверить свою работу едва ли не самым важным для хорошего результата и оценивает выигрыш в 2-3 раза. Если ревьюер повторно отмечает одно и то же, это исправляют у источника: в навыке, правилом линтера или в файлах инструкций CLAUDE.md (описание проекта, загружается при каждом ревью) и REVIEW.md (что важно в данной части кода, пишут владельцы кода).

2. Автоматическое ревью каждого PR перед человеком: Claude читает дифф в контексте всего репозитория и заявленной цели PR; при исправлении бага ищет первопричину. Публичная версия, Code Review for Claude Code, теперь общедоступна на тарифах Team и Enterprise, а команда /code-review запускает облегчённый вариант локально. После запуска исследовательского превью доля внутренних PR с содержательными замечаниями выросла с 16% до 54%. Администраторы выбирают для репозитория глубину Quick, Standard или Deep. Несколько агентов ищут баги одновременно, затем отдельная группа голосует по каждой находке, и она публикуется, только если достаточно голосов за. Замечания про стиль и «уборку» отбрасываются (фильтры проверили A/B-тестом на собственных PR). Остальное приходит комментариями по строкам с пометками Important, Nit или Pre-existing. На каждое замечание нужно ответить: исправить или закрыть ветку с причиной. Отдельное автоматическое ревью безопасности работает так же; PR не сливается, пока открыта любая находка из ревью багов или безопасности.

3. Обычные проверки: линтер, типы, тесты на всех платформах, сборка; шаблон PR спрашивает, как проверялось изменение и как его откатить. 4) Уровень рисков: уровень проверки задаёт изменение, а не автор. Классификатор определяет риск, второй классификатор решает, нужен ли ещё человек, даже если по уровню не нужен. Чувствительные пути, отмеченные владельцами, и любые файлы CI-процессов всегда требуют человека. Облегчённые пути доступны только авторам из доверенного списка. Одобрение агента не засчитывается как одобрение человека. На PR, написанном агентом, человек, который им руководил, считается одним из обязательных ревьюеров. Одобрение относится к конкретному коммиту и даётся заново, если появились коммиты, за которые система поручиться не может (например, пуш агента или слияние, разрешённое вручную).

4. Очередь слияния заново прогоняет все проверки на main с применённым изменением, чтобы два PR, прошедших порознь, не сломали main вместе. Новое поведение обычно сначала включают за флагом для сотрудников Anthropic; публичные релизы идут в канал latest, stable отстаёт. Флаги выключаются без деплоя, у Claude Code есть недельное дежурство on-call, а разборы инцидентов задают вопрос, какой слой должен был поймать проблему. Авторы честно признают: замечать плохое слияние всё ещё помогают автор, дежурный и дашборды откатов и инцидентов, а автоматических «предохранителей», ужесточающих одобрение при ухудшении этих чисел, пока нет; инженеры хотят их до того, как больше кода перейдёт на слияние без людей.

Как ревью улучшается. Каждый инцидент теперь становится тестом: собрали прошлые PR, вызвавшие инциденты, с их исправлениями и откатами, инженеры подтвердили каждый баг, и ревьюер ежедневно прогоняется по этому набору. Шум измеряют по реакции людей на комментарии (исправили, сочли неверным, сказали «так задумано», решили, что неважно), а также запуская ревьюера на заведомо чистых PR. Приоритет записан так: сначала ловить реальные баги, затем сокращать число раундов ревью. Для агентов шум дороже: человек отмахнётся от мелочи за секунды, агент сделает ещё один коммит и раунд. Ревью должно сходиться: один PR для CLI за ночь прошёл более пятидесяти раундов проверки и правок, пока автор его не остановил. По git blame около 59% того, что ревьюер продолжал отмечать, составлял код, присутствовавший с первого прохода, то есть он находил не новые баги, а по несколько старых за раунд. Теперь команда следит за числом раундов до прохождения наряду с полнотой и изменила повторное ревью; агенты ревью ещё и ночью прогоняются по существующему коду.

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

Ключевые факты

• Claude пишет около 90% кода Claude Code; с июня по сентябрь слитых PR стало более чем вдвое больше, а доля откатов упала более чем на 40% (авторы приводят оба тренда рядом, без абсолютных чисел).
• Каждый PR сначала получает автоматическое ревью Claude: несколько агентов ищут баги, отдельная группа голосует за каждую находку, PR не сливается при открытых замечаниях по багам или безопасности.
• Уровень проверки задаёт риск изменения, а не автор; одобрение агента не заменяет человека, а чувствительные пути и файлы CI всегда требуют человека.
• Цель: большинство PR сливаются максимум с одним человеком в цепочке (им может быть автор); откаты и инциденты служат ограничителем. Автоматических «предохранителей» при росте этих чисел пока нет.
• Агентное ревью должно сходиться: один PR прошёл более пятидесяти раундов за ночь, а около 59% повторных замечаний относились к коду, существовавшему с первого прохода.

Почему это важно

Это редкий отчёт изнутри команды, где код в основном пишут агенты: он показывает, что на практике приходится менять в ревью, когда объём изменений растёт. Ключевая идея, что ревью не исчезает, а смещается: чтение диффа берут на себя машины, а люди оставляют себе решения, с которыми автоматика справляется плохо. Заметный сигнал: число слитых PR выросло более чем вдвое, а доля откатов упала более чем на 40%. Правда, авторы лишь приводят два тренда рядом и не утверждают, что один вызван другим.

Кому это важно

Руководителям инженерных команд и тимлидам, которые решают, как перестроить ревью под код от агентов; разработчикам, которые уже работают с Claude Code и хотят понять устройство ревью в нём; тем, кто отвечает за CI, безопасность изменений и дежурства. Описанные практики (уровни риска, голосование агентов, замеры шума) полезны и командам, использующим другие инструменты.

Как это применить

Из текста можно взять конкретные приёмы: давать агенту проверяемый результат (тесты, сборку, скриншот) и требовать показать вывод; запускать субагента для ревью диффа со свежим контекстом; держать короткие CLAUDE.md и REVIEW.md с описанием того, что для данной части кода значит «плохо»; задавать уровень проверки по риску изменения; привязывать одобрение к конкретному коммиту; превращать каждый инцидент в проверочный набор для ревьюера; считать число раундов до прохождения, чтобы ревью сходилось. Code Review for Claude Code, по словам авторов, общедоступен на тарифах Team и Enterprise, облегчённый вариант локально запускается командой /code-review. Глубину ревью (Quick, Standard, Deep) для репозитория выбирают администраторы. Цены в тексте не названы.

Можно ли доверять

Источник первичный: это пост самой команды Claude Code на claude.dev, то есть описание собственных практик и собственных цифр, без независимой проверки. Цифры роста PR и снижения откатов даны только в относительном виде, без исходных значений, а связь между ними и процессом ревью авторами не утверждается. Цифра 2500 → 30 000 изменений в день относится к монорепозиторию Anthropic, а не к Claude Code. Оценка Бориса Черни «в 2-3 раза лучше» это его личная оценка. Сам разбор подан как описание собственного процесса и местами самокритичен. Текст, по которому сделан пересказ, обрывается в конце раздела о распространении знаний о коде, поэтому списки решений, оставленных людям, и изменений в повторном ревью не вошли.

Риски и подводные камни

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

«Проверка выглядит по-разному в каждой области. Это может быть простой запуск команды bash, прогон набора тестов или проверка приложения в браузере или симуляторе телефона.»

— Борис Черни, создатель Claude Code (цитата в тексте команды Claude Code)