OpenAI розповіли, що CodeRabbit тепер використовує GPT‑6.1 Sol як основну модель свого security-агента – не для того, щоб замінити людину в review, а щоб розширити його за межі одного diff. Ідея проста: окремий pull request рідко живе у вакуумі, він торкається спільних бібліотек, залежностей і захисних механізмів в інших частинах застосунку, яких автор PR міг навіть не бачити.

Чому один diff – погана одиниця для security review

Якщо ти колись робив code review великого PR, то знаєш відчуття: дивишся на змінений файл, усе виглядає ок, апрувиш. А через два тижні виявляється, що зміна в одному сервісі тихо зламала припущення в іншому – скажімо, хтось послабив валідацію в shared-бібліотеці, і це аукнулось у зовсім іншому компоненті, який ти навіть не відкривав.

Класичні сканери добре ловлять відомі патерни вразливостей у межах файлу чи модуля. Але зв’язати «ця зміна в auth-бібліотеці впливає на три інші сервіси, які її імпортують» – задача, що вимагає контексту всього графа залежностей, а не одного diff. Саме це OpenAI описують як завдання, яке вирішує GPT‑6.1 Sol у CodeRabbit: модель допомагає з’єднувати поведінку between файлами й компонентами, щоб підсвітити потенційні проблеми, які видно тільки «згори».

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

Що саме змінилось: три рівні дослідження коду

За описом OpenAI, CodeRabbit будує security-перевірку у кілька шарів:

  • PR review – Sol аналізує зміни по мірі того, як розробник працює над кодом, одразу під час review.
  • Deep Scan – ширше дослідження репозиторію: залежності, взаємодія компонентів, не тільки те, що змінилось у цьому конкретному PR.
  • CodeRabbit Secure – виходить за межі одного репозиторію й досліджує пов’язані репо, наприклад спільну auth-бібліотеку, щоб показати, як вразливість може вплинути на ширшу систему.

Важливо: сам CodeRabbit описаний як незалежний від агента, що написав код, і такий, що доповнює вже наявні сканери – тобто це не заміна SAST-інструментів чи лінтерів, а додатковий шар, який працює паралельно з ними та з іншими frontier-моделями.

За заявою CodeRabbit (наведеною в блозі OpenAI), GPT‑6.1 Sol уже використовується для флагування security-проблем у тисячах репозиторіїв і організацій, а знахідки потрапляють прямо в ті ж PR-воркфлоу, якими розробники вже користуються – тобто не окремий dashboard, куди треба ходити, а коментарі й чеки там, де відбувається сам review.

Найцікавіша частина – зв’язок дослідження з виправленням. Для обраних користувачем знахідок CodeRabbit Secure може спробувати exploit verification в ізольованому sandbox, не торкаючись production-систем. Якщо проблема підтверджена і підпадає під підтримувані типи issues, система може скласти pull request із запропонованим фіксом – а людина вирішує, чи приймати його.

Як це виглядає на практиці: чекліст для ревʼювера

Поки конкретних деталей інтеграції (які саме типи вразливостей підтримуються, як виглядає UI знахідки) в публічному анонсі небагато, є сенс подумати, як ти взагалі оцінюватимеш подібні AI-знахідки в review, незалежно від конкретного вендора. Ось чекліст, який варто тримати в голові, коли AI-агент каже «тут можлива вразливість, і ось PR з фіксом»:

  1. Чи показано ланцюжок, а не тільки точку. Якщо агент каже «тут проблема», але не показує, які ще файли чи сервіси вона зачіпає – довіряй менше. Цінність підходу, який описує OpenAI, саме в тому, що видно граф впливу, а не ізольований рядок коду.
  2. Чи є verification, а не тільки гіпотеза. Твердження «це теоретично експлуатовне» і «ми спробували в sandbox і підтвердили» – це різні рівні довіри. Друге набагато ближче до того, що варто ескалювати негайно.
  3. Чи фікс мінімальний і зрозумілий. Автоматично згенерований PR-фікс – це чернетка для людини, а не готове рішення. Перевіряй, чи не ламає він суміжну логіку, яку модель могла не побачити повністю.
  4. Хто відповідає за мердж. Навіть якщо агент дуже впевнений, фінальне рішення – завжди за людиною-ревʼювером. Це прямо підкреслюють і в самому анонсі OpenAI.

Якщо тобі цікаво, як взагалі оцінювати якість AI code review об’єктивно, а не на слово вендора, подивись ReviewBench: AI code review нарешті міряють як code review – там про метрики, якими варто перевіряти подібні заявки. А загальний чекліст перед тим, як приймати будь-який AI-згенерований код чи фікс, є у статті Як перевіряти код від AI: чекліст перед комітом.

Trade-offs: де тут реальна цінність, а де ризик

Чесно кажучи, ідея «AI, який розуміє весь граф залежностей» звучить привабливо, але варто тримати в голові кілька обмежень:

  • False positives нікуди не діваються. Чим ширший контекст аналізує модель, тим більше шансів, що вона побачить «залежність» там, де її насправді немає, або переоцінить вплив зміни. Широкий аналіз – це більше сигналу, але й більше шуму, який треба відфільтрувати.
  • Sandbox verification – не те саме, що production-перевірка. Те, що exploit підтверджено в ізольованому середовищі, знижує невизначеність, але не гарантує, що саме та ж поведінка відтвориться в реальній інфраструктурі з її конфігами, мережевими правилами й секретами.
  • Автоматичний PR-фікс створює спокусу "просто змерджити". Коли agent сам пропонує рішення, легко втратити звичку критично його читати – особливо під дедлайн. Тут варто подивитись і на $1M Vercel Sandbox Challenge: ізоляція sandbox – це security boundary, а не галочка, яку можна вважати достатньою сама по собі.
  • Покриття підтримуваних типів issues обмежене. В анонсі прямо сказано, що автоматичний фікс доступний «для підтримуваних issues» – тобто це не універсальний інструмент на всі класи вразливостей, а розширюваний набір.

Коли це варто брати в роботу

Якщо твоя команда вже працює з кодовою базою, де PR регулярно зачіпають shared-бібліотеки чи кілька репозиторіїв – шар security review, який аналізує саме ці зв’язки, закриває реальну сліпу зону класичного per-file review. Це особливо актуально там, де вже є basic SAST/лінтери, але не вистачає контексту «а що ще це зламає».

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

У будь-якому разі головний принцип не змінюється: AI тут – ще один набір очей, а не заміна рішення людини. Знахідка, навіть підтверджена в sandbox, усе одно потребує твого «так, я розумію, чому це проблема, і погоджуюсь із фіксом» – перш ніж вона потрапить у прод.