Як підʼєднати ChatGPT до код-рев’ю

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт! Я працюю на позиції DevOps Engineer в Innovecs та маю 7+ років в IT. У цій статті хочу поділитися однією зі свіжих знахідок в галузі ШІ, яка допоможе робити код-рев’ю.

Концепція

Ви хотіли б, щоб кожен ваш pull/merge request спочатку перевіряв ChatGPT-4, а вже потім ви? Хочете моментальний фідбек про зміни в коді перед тим, як це побачать колеги? А як щодо виявлення того, хто і де вкомітив конфіденційні дані або API-ключі, з можливістю одразу тегнути «винуватця» для виправлення?


До речі, як ви використовуєте ШІ у своїй роботі? Пишіть в коментарях, буде цікаво почитати.


Ми добре знаємо, що GPT вміє непогано генерувати код... але рев’ювити його він може (як виявилось) не гірше! Тож зараз я розкажу, як можна під`єднати ШІ, який буде автоматично розглядати зміни в коді та давати вам змістовний фідбек.

Такий тулінг буде корисним і для DevSecOps-інженерів, і для всіх, хто проводить код-ревʼю. Це не замінить інженера, але допоможе з рутиною.

Одразу покажу, як ця магія працює на практиці (але вимушений заблюрити частини коду, щоб не показати зайвого).

Перший кейс — в тестовому репозиторії я додав JSON-файл із трохи зламаним форматуванням та plainext-паролями, відтворивши security leak, та створив Merge Request.

GPT-4o це просто так не пропустить:

Як бачимо, ШІ не тільки виявив senstitive information, але й замаскував її у своєму коментарі та тегнув мене, щоб я це прибрав.

Або ось так: інше ревʼю, але суть та ж сама — перевірити, як впорається ШІ з комітом sensitive information:

Набагато потужніша аналітика, аніж тули типу GitLeaks, які статично роблять простий пошук за regex та wildcards.

Другий кейс — це приклади з фронтових Merge Requests (скриншоти колеги), виділю тільки певні моменти:

Модель GPT-4o демонструє непогані знання React. Ось цей дизайн з key — його всі знають, але всі забувають.

Або ось тут, ніби книжку прочитав:

Прикладів можу навести багато, але суть в тому, що ці рекомендації мають сенс! Звісно, не всі зауваження варті уваги, але велика частина є справді корисною.

Реалізація

Викладу ідею, як за одну годину можна на Python напрограмувати собі автоматизований рев`ю процес. Я б із задоволенням поділився вже готовим кодом, але, на жаль, не можу (company complains, you must understand). Тому викладу ідею з архітектурними блоками, щоб ви могли скласти це як конструктор.

Нотатка для DevOps-інженерів — цей код варто одразу додати в CI/CD-флоу для отримання максимального ефекту та автоматизації процесу. Його ідеально загорнути в одну CI/CD-джобу і виконувати на кожному MR/PR (тільки зробіть виняток для змін від renovate/dependabot).

До справи: беремо Python та пишемо код.

1. Нам знадобиться підʼєднання до ШІ-моделі

import openai

Це може бути GPT-4o від OpenAI. Але я рекомендую Azure OpenAI, оскільки Azure обіцяє не передавати код і не тренуватися на ньому.

from openai import AzureOpenAI

Запитайте у GPT, як це зробити, якщо це у вас вперше.

2. Отримуємо зміни в коді та коментарі цих до змін

Ми використовуємо GitLab, тож на його прикладі одразу дам ендпоінти:

/api/v4/projects/{gitlab_project_id}/merge_requests/{gitlab_request_id}/changes?access_raw_diffs=true
/api/v4/projects/{gitlab_project_id}/merge_requests/{gitlab_request_id}/notes?order_by=created_at&sort=asc

де:

gitlab_request_id = os.getenv("CI_MERGE_REQUEST_IID")

gitlab_project_id = os.getenv("CI_PROJECT_ID")

Для краси JSON-відповідь від GitLab треба буде розпарсити.

3. Надсилаємо код на ШІ-рев`ю

Не забуваємо на початку додати промпт з поясненнями, що робити, і складаємо це все в один запит:

review_request=f"{prompt}\n\n{notes}\n\n{changes}"

В промпті треба ввічливо попросити ШІ проаналізувати ваші зміни в коді за критеріями: щось типу такого (дуже спрощений варіант у порівнянні з тим, що використовуємо ми):

As a Developer, I want to ask you to perform a GitLab Merge Request review. 

Consider previous comments noted below and avoid repeating similar recommendations. 

If you spot a recurring issue, skip it.

For security issues or sensitive information leaks, mention the assignee's username with @.

Make your feedback clear, concise, and actionable, with specific improvement recommendations. 

Review the code snippet below based on these criteria:

- Syntax and Style: Look for syntax errors and deviations from conventions.

- Performance Optimization: Suggest changes to improve efficiency.

- Security Practices: Check for vulnerabilities and hard-coded secrets (mask half the info).

- Error Handling: Identify unhandled exceptions or errors.

- Code Quality: Look for code smells, unnecessary complexity, or redundant code.

- Bug Detection: Find potential bugs or logical errors.

4. That’s it! Отриману відповідь просто постимо як коментар

Створіть GitLab PAT token для цього з іменем AI MR review та направте POST на MR notes API:

/api/v4/projects/{gitlab_project_id}/merge_requests/{gitlab_request_id}/notes

Висновки

Імплементація цього рішення покращить процес для:

  • DevSecOps: значно додасть security;
  • Senior+ рівня: тепер можна знаходити помилки та недоліки в MR/PR, не вчитуючись у код — це зробить за вас ШІ;
  • розробки/QA: одразу отримати на диво корисні зауваження та рекомендації;
  • бізнесу: на виході отримати трохи кращий код.

Серед недоліків інструменту — вартість. Її складно спрогнозувати. Усе буде залежати від того, як багато ви плануєте передавати на рев`ю та яка власне модель буде робити рев`ю.

Є ризик, звісно, впасти в постійне вдосконалення: ідеї для покращення такого інструменту можуть бути нескінченними. Але не завжди більше контексту означає краще ревʼю. А ітеративне тестування змін вимагає певного часу. І ми можемо стати ще більш лінивими, але лінь — це рушій прогресу, чи не так?

А ще — уявіть можливості. Це буде ваш скрипт, тому, наприклад, можна:

  • додати контекст завдання з Jira;
  • зробити самарі для PM;
  • написати release notes/release changes;
  • пошукати вразливості.

Тож робимо наш код краще, а життя простішим. Welcome to AI era, dear colleagues!

👍ПодобаєтьсяСподобалось24
До обраногоВ обраному13
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

юзал чисто для нахождени секретов, и разворачивал свою llama3. Популярные OS штуки для детекта кредов полный отстой, из 5 тулов с кучей звездочек на гитхабе ни одна не смогла в ямлике на 10 строчек найти явные пароли, но которые были внутри другой строки(немного темлейт логики). Зато просишь LLM составить таблицу с найденными секретами, и всё летает

Хоча ні. Хай ця пропозиція існує тут.
Сучасні ШІ руйнують монополію на знання.
ШІ пропонують нову схему зберігання знань.
Де зараз можна надійно і безпечно зберігати цінні знання? Наприклад — юридичні знання?
Бо якщо записи з юридичними знаннями хтось хакне — отримаємо беззаконня, свавілля.
Ну хіба ж не відповідь — децентралізовані блокчейни, у які неможливо щось додати без консенсусу?
Маємо — фронт робіт для українських IT спеціалістів.
Треба запрограмувати CRUD схему для зберігання різноманітних знань на блокчейні.
А тоді вже дивитися, хто і як порушує закони.
Дуже прозоро, дуже чесно.

А що в реальному застосуванні? Бо ці приклади краще вирішить лінтер.

Дякую автору! Доволі давно працюю над подібною системою з використанням агентів, RAG та локальних моделей. Профіль SRE. Проводив також тести доступних систем на ринку. Результати та демо є в епізодах на youtube каналі (наприклад, youtu.be/iuCc2GvTrLw та тут youtu.be/56Rez-j9PWQ). Щодо кейсів та застосування AI — в нас були прямо знатні кейси коли кодревʼю людиною призводили до падіння проду (youtu.be/ArQYOn1glcA), але в той же самий час AI-асистент детектив проблеми. Роботи ще багато, як і спеціалізовані моделі, контекст, безпека, деплой. Але подібний асистент скоро вже буде в командах і він не замінить (як писали процес навчання), а доповнить, навіть сильну сеньйорну команду. Тема дуже актуальна, питання в реалізації і сам процес доволі класно прокачує тебе як інженера. Ми скоро вийдемо на хакатон з подібною темою, та хто цікавиться слідкуйте за анонсами — запросимо вас в якості глядачів на пітчинг розробок.

Не хочу приховувати, що саме ваше відео (ось це www.youtube.com/watch?v=ArQYOn1glcA), де ви розказуєте за issue і якби між іншим кидаєте фразу «...AI задетектив це але...» породило в мені питання — якщо хтось це вже використовує і це є корисно, чому б нам не зробити щось подібне?..

Дякую за ютуб контент! Я б завітав на хакатон!

Супер — я занотую та надішлю запрошення!

Стукнув в лінкід — запрошення готове!

Денисе, привіт! Дуже класний кейс.
Радо допоможемо запостити техстаттю про це, щоб якнайбільше айтівців дізнались про створення подібного асистента.

Ми готові — наступного тижня пітчінг. То запросимо DOU та автора статті!

Azure OpenAI Services як і OpenAI мають задекларовані data privacy policy (learn.microsoft.com/...​vices/openai/data-privacy, openai.com/enterprise-privacy), якщо цього недостатньо то нічого не заважає підняти власний хост із відкритою LLM, типу Llama 3, де якість аналізу та синтезу буде не гірша за GPT-4o.

Ну і мабуть треба зазначити, що цей степ не може бути єдиний. Це допоміжний інструмент, що не виключає використання статичних аналізаторів, vulnerability сканерів і т.ін. (Sonarqube, OWASP, Trivy etc.)

Мне кажется это слишком упрощенным подходом к подобной автоматизации.

Во-первых, модели могут постоянно предлагать «улучшения» кода, даже если они не являются необходимыми. Если после ее импрувментов дать ей переписанный код на повторное ревью (со свежим контекстом), то она часто перепишет его на оригинальный вариант.

Я имею в виду, что она способна делать хорошее ревью, но она также неспособна понять (особенно модель gpt-4o, gpt-4-turbo-preview обладала большей «рефлексией»), когда оно не к месту.

Во-вторых, для хорошего ревью юзер должен сам указать ей на проблемные места. Это так же, как, к примеру, использовать ее для генерации коммит-сообщений: она опишет все изменения, но коммит-message должен отвечать на вопрос «Для чего?», а не «Что изменилось?» В то же время, описав для нее цель коммита самому, она напишет отличный message.

то мабудь ще одна автоматизація яка породжує більше питань ніж відповідей
статичногоаналізатора який йде по офіціально узгодженим стандартам було вдосталь для глибокого сканінгу

В ідеалі модель має глибоко розуміти конкретну кодову базу, конвеншени і т.ін. (доречі цього можна досягнути через fine tuning).
Використання LLM для конкретно описаного випадку дозволяє автоматизувати високорівневий аналіз ченджсету.
На диво, люди зазвичай досить добре реагують на автоматичний аналіз, бо з ним не особливо посперечаєшся 😁

Йой, а як же контекст проекту? Треба всю кодбазу закинути в ажур аі, бо інакше воно не відловить імпакт на частини не відображені в змінах. Зараз воно буде нітпік коменти плодити в основному

контексту? хіба діло у домені та тула якось скіпає етап трейдофу між командою у сторони доктриного слідуванню сьогодення

В нас спробували. Саме так воно і робить — генерує капітанські коменти. Навіть якщо дійсно щось знайде, то цього ніхто не помітить бо увесь той флуд ніхто не читатиме.

Дуже хвалю за ідею і реалізацію, але для мене все ж таки недолік те що ми «віримо» що на коді не навчають моделі і ключи не витікають.
Максимум що я зараз можу довірити такии «чатам» це англійську і пошук «як щось робити» в нових для мене технологіях, і то перевіряю особисто чи корректно вони відповідають, і з власного досвіду. На 30% вони плутають терміни, сігнатури і все на світі.
Дякую за статтю!

начебто зараз кожний популярний тул навколо гіта таке вміє, мені ші подобається у форматі сочку з контенту більше ніж скайнету який за мене ще код дописувати буде

Ви хотіли б, щоб кожен ваш pull/merge request спочатку перевіряв ChatGPT-4, а вже потім ви?

Для чого?
Для тих хто не в курсі:
Задача кодрев’ю — це розповсюдження знань. Той хто подивився ваші зміни, у разі необхідності вносити зміни у ту ж частину вже буде знайомий з кодом. Які знання ви хочете пошарити з чатГПТ і головне для чого не ясно.

Хочете моментальний фідбек про зміни в коді перед тим, як це побачать колеги? А як щодо виявлення того, хто і де вкомітив конфіденційні дані або API-ключі, з можливістю одразу тегнути «винуватця» для виправлення?

Помилки виявляють не на кодрев’ю. Закомічені ключі мають виявляти статичні аналізатори коду. В принципі чатГПТ тут може бути цікавим інструментом для поверхневої перевірки, але кожному хто розуміє як працює ЛЛМ мають бути очевидні ризики використання його як довіреного кволі ґейту.
Та і виявляти таку проблему післи коміту — це вже проблема, бо ключі «витікли»

Це все так, от тільки це не зупинить якогось довбограя з тайтлом VP в якомусь копровідділі спихнути все це лайно вниз і отримати свій бонус за іновації :) вони ж думають іншими категоріями а тільки потім якимось шерінгом знань

Для чого?

Щоб зміни у коді подивився ваш колега, а також AI.
Я не кажу, що це ревʼю замінить ревʼю від девелопера. Ні.
Це як погляд з боку, щось що може виявити очевидні речі (інколи і не дуже очевидні) одразу, зекономивши людино-години.

..Закомічені ключі мають виявляти статичні аналізатори коду...

У нас працює GitLeaks сканер, є Sonarqube. Але вони значно слабші за GPT, я перевіряв.
AI використовує «інтелект» в той час, як аналізатори базуються на regex і wildcards.

В цілому — дякую за точку зору, конструктивно )

AI використовує «інтелект» в той час, як аналізатори базуються на regex і wildcards.

Що ви включаєте в значення слова «інтелект»?

Це як погляд з боку, щось що може виявити очевидні речі (інколи і не дуже очевидні) одразу, зекономивши людино-години.

Ось тут ви вже ближче до правди, але правда буде звучати неприємно:
Ваш тул не для кодрев’ю, а для статичного аналізу __низькоякісного__ коду. Тобто він буде корисний для рев’ю якогось джуна (може навіть з тайтлом сеньйора, але по реальному рівню джуна).
Почитайте все ж що таке ШІ і як воно працює. Там немає ніякої магії ... тобто інтелекту, там пошук патернів, просто ви їх задаєте не правилами, а прикладами (які ще й можуть бути «незрозумілими» системі і вона нічого не вивчить)

До речі, а що по ціні? Які витрати на проект (опишіть ті на яких перевіряли)? Скільки грошей зекономило?

Я от так скажу

Це все звісно круто

В корпах усяких де всерйоз ставляться до SDLC й безпеки, от ето всьо вилється в такі тормоза процесні, шо команда буде не кодити а розгрібати отето всьо

Не прочеканий пойнт — фейл процесу і потенційний фейл на аудиті

Таке от майбутнє з AI, будете грьобані ексельки цілий день заповнювати й чекбоксікі ставити як ракета, щоб вистачило хоч годинку насолодитися таскою в джирі.

AI реально наше майбутнє, то чому б не використовувати ці досягнення суспільства для інноваційного створення.
Дякую за можливість поглянути на цей інструмент з технічно корисного погляду.

Як ваш Information Security ставиться до того, що робочий код відправляється в OpenAI? Чи знають про такі практики ваші клієнти?

Код зазвичай під NDA, його не можна шарити

якщо дізнаються про порушення політик конфіденційності, то звільняти будуть не стаковерфлоу, а конкретну людину.

Та хрін його знає, понавидумували усіляких там GDRP, HIPAA, PCI-DSS і чіпляються потім. Є й такі клієнти, що в офіс приходять і дивляться чи у вас на столі чисто, не те що б там код до LLM-ки відправити.

Є й такі клієнти, що в офіс приходять і дивляться чи у вас на столі чисто

Так, бувають такі.
Я таких називаю «рабовласниками».

«По можливості, уникайте таких» © ))

гарний жарт :) це цілі індустрії. Наприклад банківський домен

уникайте банківський домен. Мені вистачило одного року страданій в банку щоб наступні 15 років почувати себе людиною та ніколи не погоджуватись на банківський домен (привіт всяким Deutsche Bank та Barclays Capital). Бо там кожний стекхолдер тобі за 20 центів нестиковки у звірках готові таке отвертсвіе в сраці зробити що тиждень ходити не зможеш.

Ще один гарний жарт :) Sales завжди йдуть до девів за порадою, чи зручно нам буде працювати з тим чи іншим клієнтом. Я цілком згоден в тому, що можна шукати робоче місце, де буде працювати комфортно ... але це трохи дитячий підхід.

Як ваш Information Security ставиться до того, що робочий код відправляється в OpenAI?

Нормально ставиться.
Я в тексті зазначав що ми не відправляємо на OpenAI.
Ми використовуємо Azure OpenAI deployments. Microsoft багато разів зваляли що вони не будуть зберігати код або використовувати для навчання. Віримо :)

Взагалі це філософські питання... чи використовувати Copilot (або інших асистентів) через страх що код може бути відісланий третім компаніям? Чи використовувати взагалі AI в роботі, бо при наданні контексту ти так чи інакше передаєш інфу. Кожна компанія обирає для себе, ми не параноїмо і не відмовляємось від нових можливостей.

Чи знають про такі практики ваші клієнти?

Якщо Ви про кастомера — так, звісно! Я робив їм демо.

Але по суті «клієнти» ДевОпс-ів — це девелопери :). Їм подобається.

Взагалі це філософські питання...

Какое ж оно философское если NDA подписан, как минимум

Тоді щиро радий, що компанія підтримує ці практики. Бо в нас треба дуже багато зусиль докласти на анонімізацію всього, що відправляється в GenAI, іноді настільки треба заморочитись, що краще взагалі це не робити. Але звичайно музику тут замовляє навіть не компанія, а замовник. І у деяких замовників прямо пунктики про це є.

наш 2 місяці на лист відповідає, томи ми робимо і вже потім розбираємось по ходу діла)

робочий код + потенційно plaintext паролі

Беріть ширше:

Як ваш Information Security ставиться до того, що робочий код відправляється в

Github
Jira/Asana
Telegram/Slack/IM
Google/Stackoverflow

Github
Jira

Часто селфхост, якраз тому і популярний гітлаб замість гітхабу. З асаною ні разу не стикався.

Telegram/Slack/IM

Телеграм — ного.
Слак дає гарантії, але частіше використовують тімс у якого і контракт, і гарантія видалення даних за запитом.
До речі, мав проблеми відправки коду в середині домену через пошту, бо оутлук так налаштований, що просто не відправляє архіви де є в середині джава файли.

Google/Stackoverflow

Сюди зазвичай забороняють постити продакшн код. В одній американській фінконторі чувак мав проблеми бо стектрейс (з назвою контори в пакеті) в гугл закинув

Ага, записуєм: Слак/Аутлук/Тімс — норм, сісуріті не проти.
Оголосіть увесь список, будь ласка.

Упс: dou.ua/...​ail&utm_campaign=19072024

Хуюпс:
NullBulge стверджує, що отримала доступ до даних від інсайдера Disney і навіть назвала ім’я ймовірного співробітника.

Тут играем, тут рыбу заворачивали:

Однак чи справді хакери мали допомогу зсередини — залишається непідтвердженим

OpenAi побіжить завтра створювати конкурента того сервісу? Я думаю що через пару років в НДА буде прописано, що нічого страшного, що з кодом також буде працювати чатжпт або клауде.

Прикольна ідея, сам з чимось схожим грався нещодавно. Непогано працює додати різні мд-шки з Гітхабу з бест практиками по технології, тоді коменти виходять більш специфічними для конкретного стеку. Я ще пробував як контекст додати попередні N реквестів з їх коментами щоб AI їх використовував як приклад, але суттєвого впливу на якість генерації не побачив — може треба якісніше відібрати дата сет.

Цікава думка з md, мені подобається. Я планую у нас релізити v2.0 цієї тули, є список features які варто зробити, додам це в ліст!

Також багато чого пробував додавати в prompt, але не завжди збільшення контексту веде до покращення ревʼю...
Поки основний напрямок покращень — це виключення непотрібного із того що передається на аналіз: типу lock файлів, видалення/переміщення файлів і т.д. Методом ітеративного тестування (на однакових code changes) буду підбирати оптимальний сетап.

Ви хотіли б, щоб кожен ваш pull/merge request спочатку перевіряв ChatGPT-4, а вже потім ви?

Ні.

може тому що це в першу чергу це саме генеративний AI? Те що він не знає — придумає (як людина). Так звані галюцинації, чули?

Звісно чув! Але як каже народна мудрість «Боятись галюцинацій — AI не використовувати»

Базуючись на промті що я надаю — галюцинація AI дуже малоймовірна (хоча і можлива, я ж не можу дати гарантій), однак поки «брєд» не зустрічався.

До того ж AI review робить **коментар** в code change request, він не вносить зміни в код і не робить апрув. Що станеться якщо ви теоретично побачите в коментарі щось дивне? Це при, тому що ризик отримати шкідливу вигадку насправді дуже малий.

Підписатись на коментарі