Cursor Bugbot: как настроить ревью и контролировать расходы

Мой взгляд: Bugbot стоит рассмотреть, если команде удобно переходить от замечаний в PR к исправлениям в Cursor. Сохраните одобрение человеком и действующие автоматические проверки. В Azure DevOps оценивайте именно качество ревью: Bugbot Autofix там недоступен. В GitLab и Bitbucket перед включением Autofix решите, подходит ли вам внесение исправлений прямо в ветку PR.

Что проверяет Cursor Bugbot

Bugbot ищет баги, уязвимости и проблемы с качеством кода в diff пул-реквеста — наборе изменений, предложенных к слиянию. Представьте инспектора, который принимает ремонт: он начинает с переделанных участков, а правила репозитория задают требования конкретного «здания».

Ревью можно запускать при обновлении PR или комментарием cursor review либо bugbot run. Bugbot учитывает уже оставленные комментарии к PR и отдельным строкам кода, чтобы опираться на предыдущую обратную связь. К замечаниям прилагаются объяснения, варианты исправлений и ссылки для продолжения работы в Cursor или в браузере. Как работает Bugbot.

Практическая польза — раньше обратить внимание на дефект, который иначе мог бы пройти ревью незамеченным. Количество комментариев эту пользу не измеряет. Оценивайте, указывает ли замечание на реальную ошибку, объясняет ли условия её возникновения и помогает ли исправить код. Тесты, сканирование безопасности и ревью ответственными за код остаются в силе.

Настройка Bugbot для отдельных репозиториев

Подключите сервис хранения репозиториев через раздел интеграций Cursor, затем откройте Bugbot в Automations и включите проверку нужных репозиториев. Подключение сервиса и включение репозиториев — отдельные шаги. Cursor поддерживает GitHub, GitLab, Bitbucket и Azure DevOps Services, а для первых трёх — также описанные в документации варианты развёртывания на собственных серверах. Подключение Bugbot.

GitHub

Нужны права администратора Cursor и администратора организации GitHub. В разделе Integrations нажмите Connect рядом с GitHub или Manage Connections, если подключение уже есть. Выберите All repositories или Selected repositories, завершите подключение, затем вернитесь в Cursor и включите выбранные репозитории в Bugbot. Для GitHub Enterprise Server предусмотрены отдельная вкладка настройки и рекомендации по сетевому доступу. Интеграция Cursor с GitHub.

GitLab

Для GitLab.com нужны права администратора Cursor, роль Maintainer в GitLab и платный тариф GitLab Premium или Ultimate. Cursor использует токены доступа к проекту, которых нет в GitLab Free. В Integrations выберите Connect или Manage Connections, завершите установку интеграции GitLab, затем выполните Manage → Sync Repos и только после этого включайте репозитории в Bugbot. Для установки на собственном сервере есть отдельные инструкции по подключению. Интеграция Cursor с GitLab.

Bitbucket

Интеграция с Bitbucket Cloud сейчас находится в открытой бете. Подключите свою учётную запись в Integrations и предоставьте доступ Cursor. В рабочем пространстве также должно быть установлено приложение Cursor: администратор рабочего пространства Bitbucket открывает меню управления Bitbucket в Cursor, выбирает Install Cursor app и устанавливает приложение. Затем администратор команды Cursor с доступом к этому пространству открывает Forge Apps → Cursor в настройках рабочего пространства Bitbucket, выбирает Connect to Cursor и привязывает команду. После этого включите репозитории в Bugbot. Одного подключения личной учётной записи недостаточно: оно не создаёт идентичность приложения, от имени которой публикуются комментарии ревью. Для Bitbucket Data Center предусмотрен отдельный порядок настройки. Интеграция Cursor с Bitbucket.

Azure DevOps

Для Azure DevOps Services следуйте инструкции подключения именно Bugbot. Потребуется согласие администратора тенанта Microsoft Entra. Пользователь с ролью Project Collection Administrator подключает Azure DevOps и включает Bugbot для репозитория. При этом создаётся service principal Cursor — идентичность приложения в вашей организации. Администратор проекта должен добавить её в Project Administrators каждого проекта, который будет проверяться: это даст ей возможность управлять service hooks — уведомлениями, запускающими ревью.

Изменения прав могут вступить в силу не сразу. Если при настройке возникла ошибка, устраните её и повторно включите Bugbot для репозитория. Bugbot поддерживает командные репозитории; репозитории в личной области не поддерживаются. Настройка Bugbot для Azure DevOps.

Когда и чьи PR проверять

Для каждого подключённого репозитория выберите, нужно ли проверять обновления или запускать ревью только один раз на PR. При необходимости настройте списки разрешённых и исключённых авторов. В личных настройках автор может оставить запуск только по упоминанию, ограничить проверку одним запуском на PR или включить проверку черновиков. В подключённых репозиториях Bugbot может проверять и изменения участников, которые не входят в вашу команду Cursor. Настройки репозитория и личные настройки.

В Azure DevOps для ручного запуска есть дополнительное условие: адрес входа автора комментария в Azure DevOps должен совпадать с адресом учётной записи Cursor в команде, которой принадлежит репозиторий. На автоматическое ревью это ограничение не распространяется. Запуск ревью в Azure DevOps.

Как настроить .cursor/config/bugbot.yaml

Храните настройки ревью в репозитории, если хотите проверять их изменения через код-ревью. Ниже — пример из документации Cursor по настройке репозитория:

# .cursor/config/bugbot.yaml
version: 1

triggers:
  drafts: false
  frequency: everyPush # everyPush | oncePerPr

review:
  effort: default # low | default | high | smart
  smartPrompt: ""
  incremental: true

prSummary:
  mode: comment # disabled | description | comment
  riskScore: true

autofix:
  mode: disabled # disabled | newBranch | existingBranch

Добавьте файл по указанному пути относительно корня репозитория, сделайте коммит и отправьте его в удалённый репозиторий. Bugbot читает файл из базовой ветки PR, то есть ветки, в которую вливаются изменения. Версия из исходной ветки PR не используется, поэтому предлагаемые изменения не могут поменять настройки собственной проверки. С помощью CODEOWNERS, механизма назначения ответственных за файлы, определите, кто должен проверять изменения конфигурации.

Все поля необязательны. Если поле отсутствует или содержит недопустимое значение, настройка берётся из следующего по приоритету источника; файлы размером больше 64 KB игнорируются. Приоритет такой:

1. Личные переопределения автора PR для его собственных пул-реквестов.
2. YAML-файл репозитория.
3. Настройки команды и организации в панели управления.

Этот порядок важен: по одному YAML-файлу нельзя определить, какие настройки в итоге применятся к конкретному автору. Кроме того, autofix.mode может сузить разрешения из панели управления, но не может включить Autofix, если там он отключён. Поведение настроек и их приоритет.

В примере сводка по PR публикуется комментарием; это не полный список настроек панели по умолчанию. Без такого переопределения сводка по умолчанию попадает в описание PR. Инкрементальное ревью проверяет изменения, появившиеся после предыдущей проверки Bugbot. Повышенный уровень усилий — effort — может увеличить время и расход ресурсов на поиск ошибок; в режиме Smart этот уровень определяется вашими инструкциями. Сводки, инкрементальное ревью и effort.

Правила ревью проекта в BUGBOT.md

В .cursor/BUGBOT.md опишите то, что проверяющему нужно знать о проекте. Файл в корне проекта включается всегда. Bugbot также ищет вложенные .cursor/BUGBOT.md, поднимаясь по дереву каталогов от изменённых файлов. Поэтому у бэкенда могут быть свои инструкции, отличные от инструкций фронтенда. Правила редактора Cursor из .cursor/rules/*.mdc на Bugbot не распространяются. Правила проекта для Bugbot.

Полезное правило описывает инвариант и ошибку, которую нужно искать. Например, команда платёжного сервиса может указать, что повторный запуск операции не должен приводить к повторному списанию с клиента. Команда бэкенда — перечислить переходы состояний, при которых обязательна запись в журнал аудита. Это примеры тем для правил, а не гарантия, что Bugbot обнаружит каждое нарушение.

При проверке объединяются правила команды, файлы правил проекта, правила, усвоенные в ходе обучения, и правила репозитория, заданные вручную. Чтобы работали усвоенные и ручные правила из панели управления, обучение должно быть включено и для организации, и для репозитория. Пишите по существу: каждое правило обрезается до 30,000 символов, а общий объём правил ревью ограничен 100,000 символов. Чтобы увидеть, что действительно загрузилось, оставьте комментарий bugbot run verbose=true или cursor review verbose=true. В ответе будет указано, какие правила включены, обрезаны или пропущены. Правила и ограничения.

Тарифы Bugbot: как рассчитывается оплата

Закладывайте в бюджет фактическое использование Bugbot, а расходы на Autofix учитывайте отдельно. Сейчас Cursor описывает оплату так:

Это действующие условия оплаты Bugbot. Не стоит считать, что командный лимит на работу в редакторе покрывает ревью Bugbot. Autofix расходует кредиты Cloud Agent по ставкам вашего действующего тарифа. Оплата Autofix.

Майское изменение цен применяется к действующим подпискам при ближайшем продлении после 8 июня 2026 года. Поэтому годовая подписка, оформленная ранее, может сохранять прежние условия до продления. Объявление Cursor об изменении цен.

В текущей документации Bugbot нет фиксированной цены за ревью, которую можно просто подставить в бюджет. Объём работы зависит от сложности PR, частоты проверок и уровня effort. Средняя стоимость запуска, которую приводит поставщик, — ориентир, а не гарантированная ставка для вашего репозитория.

Чтобы оценить экономический смысл, сравните расходы на ревью + расходы на Autofix + время инженеров на разбор замечаний с трудозатратами на проверку и доработки, которых команда избежала. Бюджет на ревью людьми при этом сохраняется. Решение зависит от пользы замечаний и сэкономленного внимания, а не от способности ещё одного бота писать комментарии.

Что нужно для Autofix и MCP

Autofix запускает Cloud Agent — агента, который удалённо работает с кодом, исправляет замечания Bugbot и сообщает о результате в PR. Для этого должны быть включены использование с оплатой по факту и хранение данных; Legacy Privacy Mode не соответствует требованию к хранению. Выберите поддерживаемый режим в Bugbot Automations. Требования Autofix.

Это режимы Autofix, описанные в документации Cursor. В режиме существующей ветки разрешено не более 3 попыток на PR, чтобы избежать зацикливания. Я рекомендую на старте оставить Autofix выключенным, пока команда не договорится, как проверять сгенерированные исправления. После этого команды на GitHub могут выбрать новую ветку и оценивать исправления отдельно.

MCP — протокол, который даёт ИИ-инструменту доступ к другим инструментам и контексту, — может расширить возможности ревью Bugbot. Настройте MCP-сервер и добавьте его инструменты в Bugbot через Automations. Поддержка MCP в Bugbot доступна только на тарифах Team и Enterprise. Доступность MCP.

Что выбрать: Bugbot, CodeRabbit или Greptile

Выбирайте инструмент, который вписывается в ваш процесс и предлагает понятную для вас модель расходов. Ниже приведены опубликованные цены, а не результаты сравнительного тестирования.

Источники: Cursor Bugbot, тарифы CodeRabbit, тарифы Greptile. Цены CodeRabbit при годовой оплате указаны в пересчёте на месяц. Кредиты Greptile нельзя приравнивать к единицам использования Cursor или оплате за проверенные файлы в CodeRabbit.

С точки зрения бюджета разница проста: в CodeRabbit к подписке за места могут добавляться расходы на продолжение ревью сверх лимита; Greptile сочетает оплату за места с кредитами; у Bugbot главный переменный расход — объём использования ревью. По одной лишь цене за место нельзя обоснованно назвать самый дешёвый вариант для вашей команды.

Подробное сравнение двух альтернатив — в статье Greptile или CodeRabbit. Если нужен более широкий выбор, посмотрите альтернативы CodeRabbit и лучшие ИИ-инструменты для ревью кода в небольших командах.

Где Bugbot может принести команде больше пользы

Я бы начал с процессов, в которых пропущенный дефект обходится дороже, чем внимание, потраченное на разбор замечания. Ниже — возможные сценарии в том порядке, в котором я бы их пробовал, а не измеренные результаты.

Механизмы ревью, работы с контекстом, правил и Autofix, на которых основаны эти примеры, описаны в руководстве Cursor по Bugbot. Их ценность зависит от вашего кода и тех, кто его проверяет.

Какие инструменты имеет смысл создавать вокруг Bugbot

Самая перспективная задача — помочь руководителю разработки понять стоимость и результаты ревью. Продать ещё один генератор комментариев сложнее: проверку кода уже предлагают устоявшиеся инструменты.

Учёт расходов и результатов ревью

Платформенная команда могла бы создать панель, которая связывает расходы по репозиториям с замечаниями, которые инженеры приняли, отклонили или по которым исправили код. Покупатели такого решения — руководители разработки. Цена Greptile Pro $30 за место в месяц показывает, что платный рынок инструментов ревью уже существует, но не доказывает готовность этих клиентов платить за дополнение к ним. Тарифы Greptile.

Минимально полезная версия объединяла бы замечания, данные о расходах и оценку полезности, выставленную человеком. API ревью Cursor на тарифе Enterprise предоставляет аналитику проверок, в том числе замечания и начисленную стоимость; при этом поле стоимости может не содержать суммы начислений. Для версии без Enterprise потребуется согласованный ручной ввод данных — рассчитывать на доступ к этому API нельзя. API и аналитика Bugbot.

Сложность: закрытые комментарии не всегда означают устранённые существенные баги, а при неполной привязке расходов панель может вводить в заблуждение. Я бы начал именно с этого инструмента: он отвечает на вопрос, который снова возникает при продлении подписки, — оправдывает ли такой ревьюер свою полную стоимость?

Аудит правил ревью в репозиториях

Платформенной команде мог бы пригодиться инструмент, который проверяет, соответствует ли конфигурация Bugbot утверждённым требованиям, не отсутствуют ли правила проекта и не менялись ли правила ревью без проверки. Стоимость CodeRabbit Team $60 за разработчика в месяц при помесячной оплате показывает, что организация командного ревью уже относится к категории платных продуктов. Но готовность покупать отдельный инструмент контроля правил ещё нужно проверить. Тарифы CodeRabbit.

Минимальная версия могла бы читать файлы репозиториев и готовить отчёт для ответственных. Сложность: личные настройки имеют приоритет над YAML, поэтому аудит одних файлов не может подтвердить, как ревью работает на самом деле. Явно указывайте это ограничение и включайте в проверку настройки панели управления, когда предоставленные права доступа это позволяют. Приоритет настроек Bugbot.

Явно определите условия одобрения слияния

Обязательная проверка Bugbot сама по себе не означает, что неустранённые замечания заблокируют слияние. По умолчанию замечания дают нейтральный результат. Требование статуса гарантирует запуск проверки; настройка fail-on-unresolved-issues, если она доступна вашей организации, делает результат проверки неуспешным при наличии неустранённых замечаний. Проверьте эту настройку, прежде чем полагаться на защиту ветки. Статусы проверок Bugbot.

Я рекомендую использовать Bugbot как дополнительный источник информации для ревьюера. Отчёт без замечаний не доказывает, что функция соответствует требованиям, а автоматически сгенерированный патч требует такой же тщательной проверки, как и любой другой код.

С чего начать в понедельник

Выберите репозиторий, ответственные за который могут сформулировать, какие ошибки нужно находить. Поручите администратору с нужными правами подключить сервис, включите Bugbot для этого репозитория, добавьте конфигурацию в базовую ветку и напишите конкретные правила ревью. Назначьте ответственного за бюджет, а решение об Autofix примите отдельно. Прежде чем расширять внедрение, в ходе обычных ревью фиксируйте полезные замечания, отклонённые предложения и время, потраченное на разбор тех и других.

Если вам нужны отчёты по ревью или средства контроля репозиториев, встроенные в процесс разработки и выпуска, мы поможем с ИИ-автоматизацией.