Как разгрузить ревью PR

Главный тезис

Ускорение требует контроля качества

Автоматические сигналы, например отчёты о медленных запросах, могут запускать работу агентов без участия человека. Поток PR растёт, а пропускная способность ревью остаётся ограниченной.

Покок предлагает три уровня контроля. Детерминированные проверки ловят известные ошибки. Агент ревью проверяет качество решения и самих тестов. Человек оценивает подготовленное изменение с учётом риска.

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

02:55 ↗

01 / Автоматические проверки

Зелёный CI может давать ложную уверенность

Линтер, проверка типов и тесты дёшевы по сравнению с агентным и человеческим ревью. Но успех проверки ещё не доказывает корректность поведения. В докладе разобраны три примера.

Тест повторяет константу

Реализация задаёт лимит 280 символов, а тест сравнивает константу с 280. Он закрепляет внутреннее устройство кода, не проверяя применение ограничения.

05:24 ↗

Тест читает исходник вместо интерфейса

Проверка ищет строки Content Plan и Videos в файле и сравнивает их позиции. Она не отображает страницу и ничего не доказывает о порядке элементов на экране.

06:28 ↗

Тест читает исходный файл через readFileSync, находит строки с помощью indexOf и сравнивает их позиции. Визуальный порядок элементов остаётся непроверенным. 06:28 ↗

Моки скрывают реальные отказы

В примере с useAudioBoost AudioContext заменён заглушками. Ошибки настоящего браузерного API в такой модели не возникают, хотя могут проявиться в работе приложения.

07:28 ↗

Глубокий модуль упрощает содержательные тесты

Идея Джона Устерхоута: скрыть сложную реализацию за небольшим интерфейсом. Если агент проверяет поведение через этот интерфейс, тесты меньше зависят от внутренней структуры. Рефакторинг перестаёт ломать их только из-за перестановки деталей.

08:39 ↗

Покок показывает навык /improve-codebase-architecture, который предлагает места для такого преобразования. В HTML-отчёте видны исходные связи и предлагаемая структура. Навык codebase-design задаёт общий язык для обсуждения локальности изменений, границ модулей и пользы простого интерфейса.

Архитектурный отчёт «до / после»: три участка с повторяющимися условиями обращаются к общему модулю предикатов видимости. 10:08 ↗

02 / Агент ревью

Дайте проверке отдельное окно контекста

Агент реализации уже исследует репозиторий, меняет файлы и разбирается со сбоями проверок. По опыту Покока, подробные стандарты кода дополнительно перегружают эту работу.

Его схема: отдельный агент получает diff, изучает необходимый контекст и применяет стандарты команды. Требования хранятся в CODING_STANDARDS.md и читаются на этапе ревью. Покок советует не загружать весь этот набор в глобальный AGENTS.md.

11:39 ↗

Это авторская модель распределения работы, а не сравнительный эксперимент. Он связывает её с циклом red–green–refactor: сначала добиться работающего решения, затем улучшить его устройство в другом контексте.

Ревьюер должен вносить исправления

Если агент только оставляет длинные комментарии, человеку приходится разбирать их и выполнять дополнительную работу. Покок предлагает по умолчанию исправлять найденное и создавать коммиты; вопросы оставлять там, где решение неоднозначно.

15:46 ↗

Стандарты должны отражать конкретный проект и накапливаться внутри команды. По словам докладчика, универсальное ревью легко становится слишком общим и шумным либо слишком узким для чужого стека.

03 / Человеческое ревью

Глубина проверки зависит от последствий

В описании PR нужно быстро ответить на два вопроса: можно ли отменить последствия и насколько широко затронута система. Размер diff сам по себе этого не показывает.

Обратимое изменение

Изменение можно откатить, а последствия локальны. Покок предлагает тратить на такие PR меньше внимания и допускает необязательное человеческое ревью для части из них.

Необратимые последствия

Отправленное письмо нельзя «откатить» вместе с кодом. Массовая рассылка, потеря данных и дорогая миграция требуют тщательной проверки до слияния.

17:28 ↗

Покажите, что меняется и зачем

В конце PR Покок размещает краткую оценку риска слияния: обратимость и радиус последствий. Для объяснения поведения использует псевдокод, схемы последовательностей и компактные примеры изменений CLI.

Он отмечает навык show-me из репозитория HumanLayer. Схема или небольшой пример позволяют быстрее понять причину изменения и перейти к вопросам, которые действительно требуют решения.

18:48 ↗

04 / Обратная связь

Замечание должно улучшать следующий PR

«Вы не хотите писать один и тот же комментарий дважды».
Мэтт Покок · перевод фразы из доклада 20:23 ↗

Человеческое ревью проверяет и код, и процесс его создания. Если одинаковые ошибки повторяются, исправления одного PR недостаточно.

Навык /retro рассматривает сессию агента, PR вместе с сессией или несколько ревью за неделю. Он предлагает новые автоматические проверки и изменения стандартов кода.

Ретроспектива также ищет проблемы навигации, лишние расходы токенов при работе с инструментами и перегруженные файлы инструкций. Например, подсказка в AGENTS.md может сократить поиск нужного модуля в следующей задаче.

20:37 ↗

Что попробовать в своём процессе

Найдите тест, который повторяет реализацию, и сформулируйте проверяемое поведение через публичный интерфейс.
Выделите отдельный этап агентного ревью с правилами вашего проекта и исправлением однозначных проблем.
Добавьте в описание PR обратимость, радиус последствий и короткий пример изменения поведения.
Разберите повторившееся замечание: его должна предотвращать проверка, стандарт кода или более понятная инструкция.

Это практические шаги по мотивам доклада. Навык /pr в выступлении ещё описан как разрабатываемый; анонс версии 1.3 относится к моменту записи.

Навигация по видео