Новый подход к code review в эру агентов
В далекие времена, где-то 1-2 месяца назад, когда приходил PR, я ревьюил код сам. Ревьюил агентами. Оставляя комментарии. Потом возвращался, смотрел на правки, ревьюил еще раз. И так несколько итераций. Вот пример, понадобилось 70 сообщений и 9 дней, прежде чем получилось влить.
Но кажется, что есть вариант получше: дать агенту готовый ПР и попросить переписать. Я использовал простой промпт на Astra XHigh:
Let's implement the in .
But simpler. Try to avoid unnecessary abstractions, get rid of bloated tests, simplify the logic where possible, remove code duplication, etc.
Первый эксперимент, большой ПР, задача про интеграцию VK (меньше на 51% кода):
‣ Было +3200 -60
‣ Стало +1632 -105
Второй эксперимент, средний ПР, задача про композицию тулов в скиллах (меньше на 60% кода):
‣ Было +1353 -13
‣ Стало +624 -91
Третий эксперимент, маленький ПР, фикс блокирующих друг друга Tg/VK polling (меньше на 93% кода):
‣ Было +87 -10
‣ Стало +98 -93
Все три переписанных ПР-а лучше во всех важных для меня аспектах: безопаснее, идиоматичнее, проще для понимания, исправляют review findings из основного ПР-а, значительно меньше кода.
Качество оценивал сам и просил коллегу. Экспериментов всё еще мало, но очень хотелось поделиться опытом.
Итак, резюмируя: если использовать изначальный ПР как спецификацию для нового ПР, получается и быстрее, и токенов тратится меньше в сравнении с обычным code review.
В далекие времена, где-то 1-2 месяца назад, когда приходил PR, я ревьюил код сам. Ревьюил агентами. Оставляя комментарии. Потом возвращался, смотрел на правки, ревьюил еще раз. И так несколько итераций. Вот пример, понадобилось 70 сообщений и 9 дней, прежде чем получилось влить.
Но кажется, что есть вариант получше: дать агенту готовый ПР и попросить переписать. Я использовал простой промпт на Astra XHigh:
Let's implement the in .
But simpler. Try to avoid unnecessary abstractions, get rid of bloated tests, simplify the logic where possible, remove code duplication, etc.
Первый эксперимент, большой ПР, задача про интеграцию VK (меньше на 51% кода):
‣ Было +3200 -60
‣ Стало +1632 -105
Второй эксперимент, средний ПР, задача про композицию тулов в скиллах (меньше на 60% кода):
‣ Было +1353 -13
‣ Стало +624 -91
Третий эксперимент, маленький ПР, фикс блокирующих друг друга Tg/VK polling (меньше на 93% кода):
‣ Было +87 -10
‣ Стало +98 -93
Все три переписанных ПР-а лучше во всех важных для меня аспектах: безопаснее, идиоматичнее, проще для понимания, исправляют review findings из основного ПР-а, значительно меньше кода.
Качество оценивал сам и просил коллегу. Экспериментов всё еще мало, но очень хотелось поделиться опытом.
Итак, резюмируя: если использовать изначальный ПР как спецификацию для нового ПР, получается и быстрее, и токенов тратится меньше в сравнении с обычным code review.