Команда внедрила Claude Code, Cursor и Copilot. Разработчики чувствуют, что стали быстрее в 2-3 раза. А релизы выходят с той же скоростью, что год назад. Если узнаёте картину - дальше три шага аудита, которые показывают, куда уходит сэкономленное время.
Симптом: команда быстрее, релизы - нет
Раньше команды тормозили на написании кода. Сейчас писать стало быстро. Читать - нет.
AI-агенты генерируют больше кода. Соответственно больше пулл-реквестов. И каждый дополнительный PR - это дополнительный прерыватель внимания у того, кто его смотрит. Узкое горлышко переехало с разработки на ревью.
Большинство команд реагирует на это тем, что закидывает в горлышко ещё AI-инструменты. Подписка на ещё один линтер, ещё один бот, ещё одно расширение для редактора. Сначала имеет смысл понять, где это горлышко в принципе, а потом покупать инструменты.
Ниже - аудит, который можно пройти за неделю. Без покупок.
Шаг 1. Считаем реальную стоимость ревью
Очевидная часть - часы ревьюеров. Senior-инженер не пишет код, потому что читает чужой. Эту строку вы и так контролируете.
Неочевидная часть - налог на переключение контекста.
Ревьюер прерывает глубокую работу, чтобы посмотреть PR. Автор тем временем переключается на следующий тикет. Через 4 часа прилетает фидбек, и автор вынужден заново грузить контекст старого PR в голову. На восстановление концентрации уходит 20-30 минут. Умножьте на пять разработчиков в команде, и получите кратные часы, которые нигде не учитываются.
По исследованиям DX/DORA, время ожидания ревью - главный фактор, определяющий cycle time, в командах от 8 инженеров. Не сложность кода. Не размер задач. Скорость, с которой PR проходит проверку.
Шаг 2. Смотрим, что ловят ваши ревьюеры
Возьмите все PR, которые команда смержила за последний год. Откройте комментарии. Что ревьюеры реально находили?
Категории обычно такие:
- именование переменных, форматирование, отступы
- мелкие edge cases, которые покрылись бы юнит-тестами
- архитектурные решения, влияющие на бизнес-логику
- ошибки, которые в продакшене стоили бы компании денег
Год данных - не "малая выборка", а паттерны, которые на 50 случайных PR попросту не видны.
Если процентов 60-70 комментариев про именование и форматирование - значит, вы тратили время senior-инженера на работу, которую делает линтер за бесплатно. Это не ревью, а театр.
Шаг 3. Двухнедельный эксперимент с AI-ревьюером
Подключите AI-ревью на каждый PR на две недели. Инструменты, которые реально работают в проде:
- CodeRabbit - подключается к GitHub/GitLab, автоматически ревьюит каждый PR, по бенчмаркам сходится с человеком на 60-80% по рутинным PR
- Claude Code в режиме review-subagent через GitHub Actions - гибче в настройке, можно дёргать по запросу, проще контролировать расход
- Greptile - знает архитектуру кодбейза, ловит проблемы, требующие понимания контекста
Через две недели сравните: что флагнул AI, что флагнули люди. Обычно две колонки совпадают по категориям. AI пропускает то, что требует продуктового или бизнес-контекста. Люди тратят время на то, что AI находит мгновенно.
Что делать с данными
Не убирайте людей из ревью полностью. Сократите их роль. Распределите PR по риску:
- внутренние тулзы без авторизации и без работы с базой - AI-ревью, человек не нужен
- платёжные операции, авторизация, всё необратимое - обязательное человеческое ревью
Человек остаётся там, где ошибка стоит реальных денег. Везде остальное - AI справляется, и обходится дешевле senior-инженера на порядок.
Контринтуитивный вывод
Часть вашего код-ревью - театр. До аудита это нельзя было сказать вслух, потому что не было данных. После - можно. Данные становятся аргументом, который оппоненты в команде вынуждены воспринимать всерьёз.
Какой из этих трёх шагов в вашей команде вскроет больше всего потерь? Если уже проходили такой аудит - расскажите в комментариях, где у вас оказалось горлышко.