Bugbot — це вбудований у Cursor ШІ-рев’юер: він читає ваш pull request на GitHub і залишає коментарі там, де побачив логічну помилку, дірку в безпеці чи проблему якості коду. Працює як другий розробник, що дивиться кожен PR ще до того, як код потрапить у головну гілку.
- Що таке Bugbot і як він рев’юїть PR
- Як підключити Bugbot до GitHub за кілька кроків
- Скільки тепер коштує Bugbot: від підписки до оплати за прогін
- Що Bugbot реально ловить — і чого не ловить
- Налаштування: BUGBOT.md, правила та рівні зусилля
- Слабкі місця та ризики: хибні спрацьовування, Ghostcommit, приватність
- Чи окупається Bugbot: рахуємо на цифрах
- Поширені запитання
Розбиратися з ним саме зараз варто з однієї практичної причини: у червні 2026 Bugbot змінив модель оплати. Раніше це була підписка $40 за місце на місяць, тепер — оплата за кожен прогін. Через це «скільки мені це коштуватиме» стало не риторичним запитанням, а розрахунком, який краще зробити заздалегідь. У цій статті розберемо, як підключити Bugbot, у скільки він реально обходиться, що ловить, де помиляється і як налаштувати його так, щоб він допомагав, а не завалював вас зайвими коментарями. Усе звірено з документацією та блогом Cursor станом на липень 2026 плюс незалежними розборами практиків.
Що таке Bugbot і як він рев’юїть PR
Bugbot — окремий продукт Cursor, але живе він не в редакторі, а у вашому репозиторії. Після підключення він рев’юїть pull request на GitHub, GitLab чи Bitbucket і знаходить три типи проблем: логічні баги, питання безпеки та слабкі місця за якістю коду.
Запускається рев’ю двома способами:
- Автоматично — на кожне оновлення pull request. Відкрили PR, дописали коміт — Bugbot проходить по дифу заново.
- Вручну — коментарем-командою прямо в PR:
cursor reviewабоbugbot run. Зручно, коли автоматичний прогін вимкнений, а конкретний PR хочеться перевірити.
Результат Bugbot публікує як звичайні коментарі до рядків коду і як CI-перевірку з назвою Cursor Bugbot. Важливий нюанс: за замовчуванням знахідки отримують статус neutral — вони не блокують мерж. Bugbot почне «валити» збірку й заважати злити PR лише тоді, коли ви явно ввімкнете опцію блокування на невиправлених проблемах. Тобто з коробки він радить, а не забороняє.
Масштаб, щоб зрозуміти, що це не експеримент: Bugbot обробляє понад 2 млн pull request на місяць (станом на квітень 2026), серед клієнтів — Rippling, Discord, Samsara, Airtable і Sierra AI.
Як підключити Bugbot до GitHub за кілька кроків
Підключення йде не з редактора, а з вебдашборду Cursor:
- Відкрийте панель Bugbot у дашборді Cursor (
cursor.com/dashboard/bugbot). - Зв’яжіть Bugbot із вашою організацією на GitHub, GitLab або Bitbucket — це встановлення GitHub App (чи аналога) з доступом до потрібних репозиторіїв.
- Увімкніть рев’ю за конкретними репозиторіями — не обов’язково на всю організацію одразу, можна почати з одного.
Далі Bugbot сам почне коментувати нові PR за ввімкненими репозиторіями. Для знайомства є 14-денний безкоштовний тріал на всіх тарифах — цього вистачає, щоб прогнати бота по десятку реальних PR і зрозуміти, чи влучає він у ваші баги, чи шумить.
Якщо ви лише придивляєтеся до Cursor загалом і Bugbot — одна з причин, спробувати редактор можна за цим посиланням: Bugbot вмикається тим самим обліковим записом, окремий акаунт заводити не потрібно.
Скільки тепер коштує Bugbot: від підписки до оплати за прогін
Це головне, що змінилося у 2026 році, і головне джерело плутанини. Звів обидві моделі в одну шкалу:Період Модель оплати Ціна До червня 2026 Підписка за місце $40/користувач/міс ($32 при річній оплаті), включено 200 PR-рев’ю на користувача на місяць, сумарно в спільний пул команди З червня 2026 Оплата за прогін (usage-based) Посівні ставки прибрані; середній прогін рев’ю — $1,00–1,50 залежно від розміру PR
Ключова деталь, на якій легко обпектися: для вже чинних клієнтів нова схема вмикається не миттєво, а з продовження після 8 червня 2026. Якщо у вас річна підписка, ви дізнаєтеся про перехід на оплату за прогін у момент продовження — і рахунок може виявитися несподіваним, якщо потік PR великий. Це варто перевірити заздалегідь, а не постфактум.
Заразом у червні 2026 Bugbot переїхав на рушій Composer 2.5: середній час рев’ю впав із кількох хвилин до ~90 секунд (90% прогонів укладаються в 3 хвилини), а вартість одного прогону знизилася приблизно на 22%. Тобто оплата за прогін з’явилася, але сам прогін подешевшав і прискорився.
Як це співвідноситься з повним набором тарифів Cursor і чи варто заради Bugbot взагалі брати платний план — докладно розбирали в огляді Cursor і його тарифів. Тут же тримаємо фокус на самому Bugbot.
Що Bugbot реально ловить — і чого не ловить
У Cursor є власна метрика якості — resolution rate: частка знайдених багів, які розробник реально виправив до мержу. Вона ж — зворотний індикатор хибних спрацьовувань: якщо знахідку виправили, значить, це був справжній баг, а не шум. За рік метрика майже подвоїлася: з 52% на релізі (липень 2025) до майже 80% станом на квітень 2026.
За власним заміром Cursor на публічних репозиторіях (50 310 PR, дані на квітень 2026) картина за інструментами така:Інструмент Resolution rate Cursor Bugbot 78,13% Greptile 63,49% CodeRabbit 48,96% GitHub Copilot 46,69% Codex 45,07% Gemini Code Assist 30,93%
Цифри варто читати з поправкою: це замір самого вендора, і він за визначенням на його користь. Але методологію розкрито (LLM-суддя на момент мержу), а порядок величин збігається з незалежним досвідом практиків.
Скільки багів припадає на один прогін: на релізі Bugbot знаходив у середньому 0,4 бага за прогін, до січня 2026 — 0,7, а після апдейту 10 червня 2026 значення за замовчуванням — 0,62 бага за прогін. Розкид цифр пояснюється тим, що це різні заміри на різних вибірках і в різні місяці, тому в єдиний тренд їх складати не можна — беремо найсвіжішу.
Що це означає на практиці — з незалежного місячного розбору (madewithlove): за місяць Bugbot спіймав близько 10 реальних багів, включно з підступною підміною двох різних списків телефонних номерів у коді — рівно той клас помилок, який людина на рев’ю пропускає через утому. За постом у LinkedIn від CPO іншого стартапу: 23 перевірені PR, 19 знахідок, дію вжито по 37,5% з них, оцінка заощадженого часу — 16 годин за місяць.
Чого Bugbot не ловить і де помиляється — той самий незалежний досвід: він помилково позначив нібито «переставлені місцями» параметри функції, які насправді переставлені не були, і був надмірно обережний із nullable-типами, вимагаючи перевірок на null навіть там, де це безпечно. Висновок тверезий: Bugbot — гарне друге око, але не заміна рев’юеру-людині.
Налаштування: BUGBOT.md, правила та рівні зусилля
Щоб Bugbot влучав у ваші баги, а не в чужі, його налаштовують під проєкт. Основний інструмент — файл .cursor/BUGBOT.md з правилами рев’ю природною мовою (можна й декларативні правила: regex-патерн → блокувальний чи неблокувальний баг). Кореневий файл вмикається завжди, а вкладені BUGBOT.md підхоплюються під час обходу вгору від змінених файлів — тобто в монорепо різні пакети можуть мати свої правила.
Правила застосовуються в зрозумілому порядку пріоритету:
- Team Rules — спільні для команди.
- Правила репозиторію — як задані вручну, так і самонавчальні (learned rules).
- Проєктний
BUGBOT.md(включно з вкладеними файлами). - User Rules — ваші особисті.
Порядок важливий при конфлікті: якщо ваше User Rule розходиться з Team Rule, виграє те, що стоїть вище за списком, — командне правило переб’є особисте. Це зручно, коли команді потрібен єдиний стандарт, який окремий розробник не зможе випадково перевизначити в себе.
Про самонавчання: Bugbot уміє виводити правила з того, як ви реагуєте на його коментарі. На момент запуску фічі (станом на квітень 2026) навчання ввімкнули понад 110 000 репозиторіїв, і він згенерував понад 44 000 таких правил. На практиці це означає, що бот з часом перестає повторювати знахідки, які ви в нього вже відхиляли.
Ще два налаштування, що прямо впливають на ціну й на шум:
- Effort Levels (рівні зусилля): Default (швидко й дешево, знахідок менше), High (довше й дорожче, багів більше), Custom (правила природною мовою). Доступно лише на оплаті за прогін.
- Incremental Review: за замовчуванням при кожному пуші рев’юїться весь диф PR; якщо ввімкнути інкрементальний режим, Bugbot дивиться лише зміни з минулого свого рев’ю — менше повторів і менше витрат.
Окремий практичний прийом: команда /review-bugbot (з Cursor 3.7+) запускає рев’ю локально ще до пушу. Якщо диф збіжиться з тим, що потім потрапить у PR (звірка йде за patch ID), рев’ю на GitHub не запуститься повторно й не буде оплачене двічі. На оплаті за прогін це пряма економія.
Є й автовиправлення — Bugbot Autofix (бета): за знайденим багом Bugbot піднімає хмарний агент, який намагається сам його полагодити й запушити фікс. У функції три режими — вимкнено, «нова гілка» і «коміт у поточну» (не більше 3 спроб). Дефолтна «нова гілка» безпечніша: автофікс не переписує мовчки вже відкритий PR, а приносить вам окрему гілку на перевірку. Врахуйте дві вимоги: Autofix працює лише на оплаті за прогін і з увімкненим зберіганням даних — у старому суворому Privacy Mode він недоступний. І ще нюанс для тих, хто автоматизує Bugbot через API: навіть «сухий» прогін без публікації коментарів (dryRun=true) все одно тарифікується як звичайний — знахідки зберігаються, а отже, й оплата йде.
Слабкі місця та ризики: хибні спрацьовування, Ghostcommit, приватність
У Bugbot є й мінуси — розберемо їх по порядку.
Цінова несподіванка. Як уже сказано, річні підписки переїжджають на оплату за прогін при продовженні після 8 червня 2026 — за великого потоку PR рахунок може вирости. Це не баг, а наслідок зміни моделі, але перевірити свій випадок варто заздалегідь.
Обхід через приховану атаку. У липні 2026 незалежні дослідники безпеки показали техніку Ghostcommit: інструкція для ШІ-агента ховається всередині PNG-картинки, доданої до pull request. В одному задокументованому тесті Bugbot не видав жодної знахідки за таким шкідливим PR (текстовий варіант тієї ж атаки, за іншим джерелом, він ловить). Практичний висновок: Bugbot — додатковий шар, а не єдина лінія захисту. Рев’ю людиною та інші перевірки безпеки він не скасовує.
Залишкові хибні спрацьовування. Навіть за resolution rate під 80% приблизно кожна п’ята знахідка — мимо. Для маленької команди це означає, що коментарі Bugbot треба читати критично, а не мержити/відкочувати за ними автоматично.
Різночитання за платформами. Документація Cursor станом на липень 2026 заявляє підтримку GitHub (включно з Enterprise Server), GitLab (включно з Self-Hosted) і Bitbucket (включно з Data Center). При цьому частина незалежних джерел описує стан «фактично лише GitHub». Розбіжність ми розв’язуємо на користь свіжих офіційних доків, але якщо у вас GitLab чи Bitbucket — перевірте актуальний статус прямо під час підключення.
За приватністю: Bugbot заявлений як підпорядкований тій самій політиці, що й решта Cursor, включно з Privacy Mode, і обробляє код так само, як інші запити редактора. Якщо вам критична приватність, зверніть увагу: функція автовиправлення (Autofix) вимагає ввімкненого зберігання й не працює в старому суворому Privacy Mode.
Чи окупається Bugbot: рахуємо на цифрах
Готової цифри «варто/не варто» ніхто не дає, тому порахуємо самі на актуальних числах. Середній прогін — $1,00–1,50, візьмемо $1,25. Знахідок за замовчуванням — 0,62 бага за прогін, з них реально виправляється до мержу близько 0,5 (це наш розрахунок: 0,62 × ~80% resolution rate).
Тоді ціна одного знайденого бага ≈ $1,25 / 0,62 ≈ $2, а ціна одного реально виправленого до мержу ≈ $1,25 / 0,5 ≈ $2,5. Порівняйте це з ціною бага, який дійшов до продакшену: година роботи розробника на розбір інциденту, відкат, хотфікс — уже десятки доларів, не рахуючи репутаційних втрат. На потоці в сотню PR на місяць Bugbot обійдеться в районі $125 і, судячи з незалежних звітів, ловить те, що людина пропускає під кінець дня.
Висновок простий: для команди, де PR-потік помітний, а ціна помилки в продакшені висока, Bugbot окупається легко. Для соло-розробника з рідкісними PR оплата за прогін, навпаки, дружніша за стару підписку — платите лише за те, що реально перевірили. А якщо ви взагалі лише опановуєте розробку з ШІ й не впевнені, чи потрібен вам окремий рев’юер, почніть із вайб-кодингу без програміста і підключайте Bugbot, коли проєкти доростуть до командної роботи.
Поширені запитання
Bugbot блокує мерж, якщо знайшов баг?
За замовчуванням ні. Його знахідки публікуються як CI-перевірка зі статусом neutral — вони видимі, але злити PR не заважають. Блокування вмикається окремою опцією «fail on unresolved issues»: тоді невиправлені проблеми ронятимуть перевірку. Це зручно для суворих команд, але за замовчуванням Bugbot лишається порадником, а не вахтером.
Чи оплатять мені одне й те саме рев’ю двічі?
Ні, якщо користуватися дедуплікацією. Якщо ви прогнали /review-bugbot локально до пушу, а потім відкрили PR з тим самим дифом, Cursor звірить їх за patch ID і не запустить платне рев’ю повторно. Подвійна оплата загрожує лише тоді, коли диф між локальним прогоном і PR реально відрізняється — тоді це вже різні перевірки.
Bugbot замінить рев’ю коду людьми?
Ні, і сам Cursor цього не обіцяє. Навіть за resolution rate близько 80% приблизно п’ята частина знахідок хибна, а задокументований обхід через Ghostcommit показує, що на безпеку покладатися на один інструмент не можна. Bugbot знімає з людей рутину й ловить неуважність, але архітектурні рішення й фінальне «мержимо» лишаються за рев’юером.
Чим налаштувати Bugbot під свій проєкт?
Головний інструмент — файл .cursor/BUGBOT.md з правилами рев’ю; у монорепо можна класти вкладені файли для окремих пакетів. Плюс самонавчальні правила (Bugbot запам’ятовує, які знахідки ви відхиляєте), рівні зусилля Default/High/Custom для балансу «ціна проти повноти» та інкрементальний режим, щоб не переплачувати за повторну перевірку незмінного коду.
Гід «Все про Cursor». Це частина великого гіда по Cursor: встановлення й перші кроки, вайб-кодинг на практиці, агенти й інтеграції, тарифи та робота в команді. повному гіді по Cursor.
