Claude Code team reviews 30 000 changes a day — по одному ревьюеру на каждый слой кода
One reviewer per layer: splitting code review by the way code is read
В монорепозитории Claude Code число мержей выросло с 2 500 в день в мае до более 30 000 в сентябре, а доля откатов упала более чем на 40%. Вместо построчного чтения команда выстроила конвейер из шести стадий, где ИИ-ревьюер проверяет изменения. Автор предлагает разбить проверку не по этапам, а по слоям смысла кода: форма, локальная логика, связи, рантайм и использование. Каждый слой получает отдельного агента с узким контекстом, а информация передаётся вверх в виде контрактов, а не сырого кода.
Мы следуем этому правилу в коде, а потом нарушаем его в промптах: кладём диф, окружающие файлы и все уровни абстракции в одно контекстное окно и надеемся, что модель сама разберётся.
- visarga
Думаю, для этого года это хороший подход, но он упускает кое-что важное: откуда вы знаете, что код по-прежнему отражает ваши намерения после недель и месяцев управления, через множество сессий? Сообщения текут в сессии и выходят из поля зрения, а при компакциях/новых сессиях они забываются. Чтобы решить это, я записываю каждое сообщение пользователя в чат-лог и время от времени просматриваю его, чтобы вычленить последнюю форму намерения пользователя.
Ещё один вид ревью, не упомянутый здесь или в статье Anthropic, — это ревью плана. Я генерирую план для некоторого отрезка работы, затем отдаю план (сохранённый как файл) на ревью одному или нескольким агентам. Это проверяет план на соответствие ограничениям проекта перед его выполнением.
Если мы сможем решить тестирование, то кодинг почти полностью автоматизирован. Единственной оставшейся проблемой всегда было доверие: почему мы должны доверять этому коду? Если читать его вручную, это как вести мотоцикл. Если не читать, нужен какой-то способ снизить риски. Вокруг много идей о том, как это сделать; OP и Anthropic показали свои варианты. Но, думаю, подход зависит от проекта, общего метода нет.
- jwpapi
Моя проблема сейчас в том, что любой процесс ревью добавляет ненужную сложность, которая позже замедляет вашу гибкость, увеличивает затраты и ухудшает производительность.
Если у вас есть фича и над ней проходятся 6 разных ревьюеров, логика легко разрастается. Интересно, как с этим справляются другие? Я всеми руками за, и хочу, чтобы это работало, но это моё текущее ограничение.
Я часто получаю плохие предложения от ревью-мониторов, потому что они что-то понимают неправильно. Иногда попадаются хорошие, очень хорошие, но некоторые плохие. Так что я всегда готов посмотреть ревью о багах, но я бы боялся, что после 6 ревьюеров это просто куча текста, которая меня путает, и в итоге результат хуже, чем если бы я сам просматривал действительно критичные вещи. Мой контекст тоже ограничен, и полностью без ручного вмешательства недостаточно надёжно...
Как вы, ребята, это делаете?
- zomtorg
Интересно, увидим ли мы, как больше инженерных команд переходят с git на Sapling. Нам действительно нужно обновить подход к ревью и выпуску кода.
Я знаю, что GH недавно выпустил stacked PRs, но, судя по всему, ещё далеко до того, что есть внутри у Meta и, вероятно, у Anthropic, как с точки зрения удобства, так и надёжности.