Я досліджував інструменти, які роблять процес рев'ю коду більш плавним, і нещодавно відкрив для себе PR-Agent з відкритим вихідним кодом (разом з його керованою версією, Qodo Merge). Це один із найцікавіших підходів до автоматизації PR, з яким я стикався останнім часом. Він функціонує як корисний помічник зі штучним інтелектом у командному рядку прямо у вашому постачальнику Git. Що привернуло мою увагу, так це його архітектура і те, як він обробляє запити. Як це працює Коли ви коментуєте /переглядаєте або /запитуєте "який вплив цієї зміни?" на запит на пул, агент запускає розумний робочий процес: - Запит на дайджест: Спочатку він аналізує зміни коду PR (шматки) і розуміє конкретну команду, яку ви видали. - План: Виходячи з вашого запиту, він формулює план. Це включає стиснення та пріоритезацію з урахуванням токенів, що має вирішальне значення для ефективної роботи з великими PR та зосередження на тому, що має значення. - Вибір функції: Потім він інтелектуально спрямовує запит до відповідного спеціалізованого інструменту. Цей модульний підхід чудовий тим, що він виділяє певну логіку для опису, рецензування, пропозицій покращень, відповідей на запитання, створення документів тощо. Крім простого створення загального опису PR (/describe), деякі з команд є неймовірно потужними для повсякденного робочого процесу розробника: /review: Це дає регульований зворотний зв'язок, який виходить за рамки статичного аналізу. Він може коментувати потенційні проблеми та проблеми безпеки, а також оцінювати зусилля з огляду, необхідні від товариша по команді. /improve: Замість того, щоб вказувати на проблему, він надає конкретні, вбудовані пропозиції коду, які ви можете прийняти безпосередньо. Це значно скорочує кількість розмов туди-сюди. /ask: Це кардинально змінює правила гри. Ви можете задавати питання про PR у довільному тексті (наприклад, «Чому було обрано саме цю бібліотеку?» або «Поясніть логіку в my_function»). Він використовує контекст PR, щоб дати вам релевантну відповідь. Глибші інтеграції: Він також має інструменти для автоматичного оновлення md-файлу CHANGELOG (/update_changelog), генерації модульних тестів для змінених компонентів (/test) і навіть отримання відгуків про невдалі завдання CI (/ci_feedback). Це здається кроком у правильному напрямку для розробки за допомогою штучного інтелекту, не стільки про заміну розробника, скільки про розширення процесу рецензування, щоб зробити його швидшим і ретельнішим. Що для вас найбільш виснажлива частина PR-процесу?