Что изменила команда Claude Code
15 октября 2026 года Addy Osmani, Morgan Westlee Lunt и Qing Wang описали на Claude.dev, как команда Claude Code проверяет изменения, созданные с помощью ИИ. В этом процессе автоматические проверки берут на себя большую часть первичного чтения, а инженеры сохраняют внимание для изменений, требующих человеческого решения.
По данным авторов, с июня по сентябрь число слитых pull request в репозитории Claude Code более чем удвоилось, а доля изменений, которые пришлось откатить, снизилась более чем на 40%. Это показатели самой команды: в статье не приведены абсолютные значения и подробная методика расчёта, поэтому их нельзя считать независимым бенчмарком.
Проверки начинаются до pull request
В описанном процессе Claude получает возможность выполнить проверяемое действие ещё до создания pull request: запустить тесты или сборку либо сопоставить скриншот с дизайном. Команда просит показывать результат выполнения, а не просто сообщать, что задача завершена. Затем другой агент просматривает diff с новым контекстом.
Такой порядок разделяет проверку результата и оценку самих изменений. Авторы также описывают внутренние инструменты для поиска ошибок, упрощения diff и проверки поведения кода. Автоматические слои не гарантируют обнаружение всех дефектов: каждый может найти одни проблемы и пропустить другие.
Каждый pull request получает автоматическое ревью
До того как изменения смотрит человек, pull request в процессе команды получает ревью Claude. Агент сравнивает diff со всем репозиторием и заявленной целью изменения: проверяет, решает ли код поставленную задачу, вписывается ли в систему и не ломает ли связанные части.
Для небольшого проекта такой подход можно внедрять постепенно: сначала запускать тесты и сборку перед отправкой pull request, затем добавить отдельный анализ diff. Это рекомендация по последовательности внедрения, а не гарантия, что автоматическая проверка заменит тесты или владельцев кода.
Контекст проекта задают короткими правилами
Авторы предлагают хранить в CLAUDE.md основные сведения о стеке, соглашениях, целях и нецелях проекта. По их описанию, этот файл должен оставаться коротким и направлять к дополнительной документации, чтобы ревьюер учитывал контекст репозитория, а не только текст diff.
Если автоматическое ревью регулярно отмечает одну и ту же проблему, команда предлагает устранять её источник: обновлять инструкцию, добавлять правило линтера или менять инструмент. Это позволяет превращать повторяющиеся замечания в проверяемые правила проекта.
Человеческое внимание распределяют по риску
В описанной схеме простые изменения можно проверять преимущественно автоматическими средствами, а для критических изменений сохранять обязательное участие человека. Команда отслеживает число человеческих одобрений на pull request, комментарии и время ожидания решения. Откаты и инциденты служат ограничителями: если их становится больше, автоматизация переносит нагрузку, а не сокращает её.
Результаты относятся к конкретной команде Claude Code, а правила определения риска зависят от проекта и цены ошибки. Telegram-пересказ утверждает, что ИИ найдёт все баги и уязвимости и что подход подходит любому проекту, но это не подтверждают ни описание команды, ни приведённые в нём показатели.
