Команда Claude Code отдала чтение кода машинам

Команда Claude Code описала, как проверяет код в репозитории, где около 90% кода пишет сам Claude. Неожиданно здесь другое: с июня по сентябрь слитых pull request стало более чем вдвое больше, а доля откатов за то же время упала более чем на 40%.

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

Было → стало

• Момент ревью: раньше это был шлюз в конце пути (написал код, открыл PR, ждёшь коллегу), сейчас проверка идёт непрерывно, как проверка орфографии при наборе, и большинство изменений Claude хотя бы раз проверил и исправил до того, как позовут человека.
• Поток изменений в монорепозитории Anthropic: около 2 500 в день в мае, больше 30 000 в день в сентябре. Claude Code живёт в отдельном репозитории, но, по словам команды, давление там такое же.
• Доля внутренних PR с содержательными замечаниями ревьюера: 16% до запуска исследовательского превью Code Review, 54% после.
• Раунды повторного ревью: раньше по умолчанию гоняли несколько, сейчас после трёх раундов ревьюер просит автора остановиться и пересмотреть подход.
• Время проверки в Code Review: около 20 минут в превью, 6–10 минут для большинства PR в общедоступной версии, как мы писали 16 октября.

Причину команда называет прямо: при таком темпе ручное построчное ревью почти невозможно. Вопрос «читал ли код человек» в Anthropic считают неточной заменой другому вопросу: что может сломаться в этом изменении и какая проверка, автоматическая или человеческая, должна это поймать.

Фон известен и раньше. По данным Fortune, ещё в январе создатель Claude Code Борис Черный говорил, что весь его код пишут Claude Code и Opus 4.5, и что он слил 22 PR за день и 27 днём раньше. Там же представитель Anthropic оценивал долю ИИ-кода по компании в 70–90%. А 21 июля мы писали, что внутренний Claude Tag сводит 65% продуктовых PR команды.

Экономию человеческого времени меряют по двум сторонам: сколько уходит на ревью и сколько на починку того, что сломал плохой код. Отслеживают число человеческих одобрений на PR (медиана и 95-й перцентиль), человеческие комментарии и время, которое PR ждёт человека. Откаты и инциденты служат ограничителем: если они растут, время не сэкономили, его просто переложили в другое место.

Изменение проходит шесть слоёв проверок, под ними откат

Первый слой срабатывает до появления PR. Claude дают то, что можно запустить (тесты, сборку, скриншот для сравнения с макетом), и просят показать вывод вместо слов «готово». Затем дифф с чистым контекстом читает субагент. Многие в команде перед PR прогоняют внутренние скиллы: один ищет баги, другой упрощает дифф, третий проверяет поведение от начала до конца. Черный оценивает, что возможность проверить свою работу делает результат в два-три раза лучше; ту же мысль он повторял на Startup School, о чём мы писали 3 августа.

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

Второй слой: Claude-ревью на каждом PR. Оно читает дифф на фоне всего репозитория и заявленной цели PR, а на багфиксе ищет первопричину. Несколько агентов ищут баги параллельно, отдельная группа голосует по каждой находке, и в PR попадает только то, с чем согласилось достаточно голосов. Находки про стиль, диагностику и уборку отбрасываются; эти фильтры команда сначала проверила A/B-тестом на своих PR. Комментарии помечены как Important, Nit или Pre-existing, чтобы чужой старый баг не выглядел ошибкой автора. Большинство PR больше 1 000 строк получают находки, большинство мелких проходят чисто.

Похожая схема видна в открытом плагине. По описанию на GitHub, плагин Code Review запускает четыре агента параллельно: два проверяют соответствие CLAUDE.md, один ищет очевидные баги, один разбирает git blame и историю. Каждой находке ставится уверенность от 0 до 100, всё ниже 80 отсекается. Платная управляемая версия в превью, по данным Start Debugging, стоила 15–25 долларов за ревью сверх подписки.

Третий слой: автоматическое ревью безопасности. PR не сливается, пока открыта хоть одна находка из ревью багов или безопасности; её либо чинят, либо закрывают с короткой причиной. Четвёртый: линт, проверка типов, тесты на всех платформах и сборка, у типичного PR в CLI это десятки проверок. Шаблон PR спрашивает, как изменение тестировали и как его откатить; Claude может заполнить ответ, но подписывает его человек, попросивший изменение.

Сколько людей нужно, решает изменение, автор тут ни при чём

Пятый слой распределяет человеческие одобрения по риску:

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

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

Шестой слой: очередь слияния прогоняет все проверки на main с применённым изменением, так что два PR, прошедших порознь, не ломают main вместе. Новое поведение обычно уходит за флагом сначала сотрудникам Anthropic, публичные релизы сначала идут в канал latest, stable отстаёт. Под всем этим лежит быстрый откат: флаги выключаются без деплоя, у Claude Code еженедельное дежурство, а разбор инцидента спрашивает, какой слой должен был поймать проблему.

Один PR прошёл за ночь больше пятидесяти раундов ревью

Агент-автор и агент-ревьюер умеют занимать друг друга бесконечно. Один PR в CLI за ночь прошёл больше пятидесяти раундов ревью и правок, пока автор его не остановил. Git blame по тому, что ревьюер продолжал отмечать, показал: около 59% находок касались кода, который был на месте ещё во время первого прохода. Новых багов ревьюер почти не находил, он каждый раунд выкапывал ещё пару старых.

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

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

Чего в схеме пока нет

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

Второе открытое место касается общего понимания кода, второй задачи ревью. Формального процесса нет. Полную модель Claude Code в голове не держит никто, и в команде считают, что это не нужно: тот, кому надо разобраться в модуле, просит Claude написать пояснение ровно по этому куску. Людям оставили решения, которые машинам даются плохо: стоит ли вообще это делать, рискованный код вроде биллинга, автообновления и CI, архитектуру, которую будут копировать, чтение доказательств и ответственность за результат. Действует правило «слил, значит отвечаешь»: если небольшая правка что-то сломала, чинит обычно её автор, а разбор инцидента смотрит на систему, а не ищет виноватого.

Если хотите примерить это к своему репозиторию, начать стоит с того, что команда советует сама: подключить AI-ревьюер на одном репозитории, несколько недель настраивать REVIEW.md, ограничить раунды ревью, записать уровни риска от изменения, а не от автора, и закрыть CODEOWNERS и защитой веток авторизацию, биллинг, CI и установщики. Проверьте и одну мелочь: сбрасываются ли у вас одобрения при новых коммитах.