Как разгрузить код-ревью и сохранить понимание системы

В обзоре small-change я упоминал, что хочу разобраться, как разные команды перестраивают ревью под агентскую разработку. И вот я закончил ресёрч на эту тему.

Напомню свою исходную проблему: с применением LLM в разработке количество PR и строк в них увеличивается, их становится тяжело читать. Но при этом хочется сохранить понимание систем внутри команд, которые за них отвечают.

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

⭐️ Интересные идеи ➡️ Часть ревью можно сделать до написания кода. Инженеры Honeycomb совместно прорабатывают планы и промпты, автор разбора отмечает лучшую общую осведомлённость. Но строгий процесс оказался тяжёлым, его используют выборочно.

➡️ Обязательный approval уже убирают для части изменений. У команды Claude Code число человеческих approvals зависит от риска. Но отказ от обязательного approval работает в определённых условиях: доверенные авторы, несколько слоёв проверки, CI и процесс выпуска.

➡️ Список тест-кейсов не позволяет проверить качество самих тестов. Входные данные могут не создавать нужную ситуацию, мок — скрывать поведение, assertion — не проверять обещанное. Я изначально думал, что можно не читать тесты, но исследование меня переубедило.

Из ресёрча я пришёл к выводу, что стоит сохранить код ревью в текущем виде, но поэкспериментировать с ревью спецификаций до разработки. Это позволит немного снизить восстановление принятых решений по готовому PR (вторым фактором снижения остаётся системная аналитика).

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog

В этом посте были ссылки, но мы их удалили по правилам Сетки