Уилл Ларсон (которого я очень люблю читать) в последнее время пишет статьи про построение агентной разработки. На днях он выложил статью о модели ускорения код-ревью для маленьких изменений.
Imprint столкнулись с той же проблемой, что и вся индустрия: значительный рост количества PR (средний инженер мержит в 4! раза больше PR, чем 2 года назад). При этом медианное время ревью выросло с 33 до 77 минут. Поэтому они решили ускорить проверку небольших изменений.
Интересные идеи
Часть изменений автоматически помечаются как small-change. Условия:
- PR меньше 1000 строк;
- ai-code-review не нашел ничего критичного;
- автор замержил 10+ PR в этот сервис или директории;
- влияние ограничено N сервисами;
- общие библиотеки и утилиты исключены;
- отдельные пути можно запретить.
small-change проходят ревью отдельным скиллом. Этот скилл не комментирует, а только ставит аппрув или оставляет PR без действия.
Ожидание: если что-то по результатам мержа small-change упало, то проблема заключается в системе. По результатам такого падения нужно улучшать harness, CI/CD, механизмы верификации и т. д.
Для шаринга знаний у них есть второй скилл — review-pr-cluster. Он разбирает группы PR и предлагает общие темы для обсуждения и новые проверки.
Ларсон честно признаётся, что текущих результатов пока недостаточно для того, чтобы делать какие-то далеко идущие выводы. Сейчас всего около 10% PR помечаются как small-change — он характеризует это как признак того, что сама концепция работает, но её ещё нужно допиливать.
Для меня эта статья важна тем, что показывает, что я не одинок в своей борьбе с ботлнеком в код-ревью. Мне нравится, что Уилл Ларсон рассматривает изменения в процессе через призму функций самого код-ревью и старается их не потерять. Меня тоже беспокоит вопрос того, как не потерять полезные функции чтения кода (например, шаринг знаний внутри команды).
small-change — это не фундаментальный ответ, а скорее эксперимент конкретной компании. Мне здесь интересен сам подход: выделить ограниченный класс изменений для быстрого ревью и отдельно продумать, как сохранить обмен знаниями в команде.
Я сейчас разбираюсь, как разные команды перестраивают код-ревью под агентскую разработку, и планирую собрать из этого отдельный ресёрч.