Официальные docs Cursor Bugbot: Composer 2.5, /review и governance Background Agents

Июньское обновление Bugbot от Cursor уже собирает поисковый спрос вокруг официальных Bugbot docs, background agents и governance-настроек. Релиз важен не только тем, что Bugbot — автоматический PR-review agent Cursor — теперь работает на собственной модели Composer 2.5. Важно, что его можно запускать через /review до push, а team model block list всё равно применяется. Заявленные цифры реальны: среднее время review снизилось с примерно пяти минут до девяноста секунд, стоимость одного прогона упала примерно на 22%, число багов, найденных за review, выросло с 0.56 до 0.62. Но операционный вопрос шире, чем «Bugbot стал быстрее?»: совпадают ли ваши Cursor docs, background-agent workflow и model policy в описании одного и того же пути code review.

Что произошло

Июньское обновление Bugbot 2026 года содержит три изменения, которые имеют значение:

• Composer 2.5 на критическом пути. Раньше Bugbot собирал review из набора frontier-моделей сторонних provider. Теперь он работает в основном на Composer 2.5 — собственной frontier coding-модели Cursor, которая также управляет agent-циклом в редакторе. Согласно changelog, улучшения скорости, стоимости и recall полностью объясняются продолжающейся тренировкой Composer 2.5.
• /review до push. Разработчики могут запускать Bugbot и Security Review из agent ещё до открытия PR — через /review-bugbot и /review-security. Pre-push review синхронизируется с Bugbot-check на стороне GitHub/GitLab: тот же diff распознаётся, повторный review пропускается. Cursor пишет, что этот путь доступен в Cursor 3.7+ и на cursor.com/agents, а поддержка CLI появится позже.
• Настраиваемый incremental review. Команды могут настроить Bugbot так, чтобы он смотрел только то, что изменилось с предыдущего review на этом PR, а не пересканировал весь diff на каждом push.

В тексте явно написано: «Скорость и качество зависят от вашей конфигурации». Эта фраза вместе со строчкой про block list делает реальную работу: признаётся, что часть fleet сознательно ограничит Bugbot и не пустит его на Composer 2.5. Если команда ищет в Cursor docs поведение Bugbot с background agents, относитесь к этой странице как к policy surface: docs объясняют, как запускается review, а block list решает, какая модель имеет право читать diff.

Почему это важно для инженерных AI-команд

Обновление Bugbot падает на пересечение трёх вещей, которые инженерные организации до сих пор управляли по отдельности: code review, coding agents, governance provider/моделей. Composer 2.5 сворачивает их в одно решение.

• Code review теперь — это решение про routing. До этого релиза вопрос «какая модель смотрит наши PR» большинство команд осознанно не ставили: дефолт vendor был достаточно хорош. Cursor поставил собственную модель на этот путь и явно сказал, что block list перекрывает дефолт, — выбор вернулся командам, и у него теперь прямые последствия по стоимости, latency и IP.
• In-house модели vendor выходят на критические пути. Cursor — самый заметный пример, но pattern шире: Replit Code Assist, Codeium Cascade, first-party модели GitHub Copilot, ряд китайских coding-agent, которые routинг сначала на собственные модели. Для routing-операторов это значит: модель, которая читает diff в ваших PR, может не входить в периметр наблюдаемости, биллинга и аудита вашего gateway.
• PR diff — это чувствительная нагрузка. Один Bugbot-review видит весь diff, окружающие файлы и правила проекта из .cursor/BUGBOT.md. Модель, обрабатывающая этот трафик, получает очень детальный обзор кодовой базы. Команды с требованиями к code data residency, ограничениями на видимость исходного кода клиентами или контрактными исключениями по списку допустимых provider теперь должны убедиться, что data handling Composer 2.5 совпадает с их политикой, — block list Bugbot и есть рычаг, которым этот ответ принудительно вводится в действие.

Угол router/operator

Перенос Bugbot на Composer 2.5 — удобный повод формально зафиксировать политику «модель для code review» рядом с уже существующей политикой «модель для coding agent». Несколько конкретных ходов, которые переносимы между разными vendor и конфигурациями gateway:

1. Считайте модели code review отдельным routing-классом. «Что мы разрешаем писать код» и «что мы разрешаем читать весь diff целиком» — два разных governance-вопроса. У второго должна быть своя allow-list, свои настройки retention, residency и аудита, а не молча унаследованные от дефолта редактора.
2. Решите, куда block list Bugbot встаёт в вашу существующую цепочку контроля. Block list в Cursor — per-team, настраивается в Bugbot-дашборде. Если у вас уже есть центральный allow-list одобренных provider — внутри AI gateway, внутри policy-документа или и там и там — block list Bugbot должен происходить из этого источника, а не вестись отдельным админом в отдельном UI. Выберите canonical-источник и распространяйте список вниз.
3. Спланируйте, что будет, если Composer 2.5 заблокирован. Фраза changelog про «скорость и качество зависят от конфигурации» — намёк: если ваш block list исключает Composer 2.5, Bugbot откатывается к чему-то ещё, с другой latency, стоимостью и recall. Замерьте baseline review-time и bug yield с Composer 2.5 и без него на репрезентативной выборке diff, чтобы сделать trade-off явным заранее, а не открыть его постфактум на разборе инцидента.
4. Аудитируйте data path, а не только имя модели. Composer 2.5 хостится Cursor, а не frontier API provider, под которых писалось большинство процедур. Procurement-, security- и legal-обзоры, написанные под «мы используем OpenAI и Anthropic для кода», больше не покрывают всю площадь. DPA, opt-out из training data и регион inference нужно привести в соответствие.
5. Следите за CI-статусом Bugbot. Bugbot публикует GitHub check Cursor Bugbot со статусами success, neutral или failure. По умолчанию при найденных проблемах статус — neutral, поэтому зелёный build не означает, что Bugbot подписал PR, — это значит, что находки не блокируют merge. Если вы хотите воспользоваться новым более коротким окном review и ужесточить policy, явно решите: находки Bugbot обязательны к исправлению до merge или носят рекомендательный характер.

Общий сигнал шире: vendor инструментов всё спокойнее ставят собственные модели на критический путь, и контракт с клиентами сдвигается от «мы оборачиваем frontier API» к «мы запускаем свою модель, и вы можете отказаться». Block list — это новая opt-out-поверхность. Относитесь к ней как к first-class routing primitive.

Что стоит наблюдать пользователям TheRouter

Если ваша организация работает на multi-IDE fleet — Cursor у одних команд, Claude Code или OpenAI Codex у других, плюс PR-автоматизация вроде Bugbot или CodeRabbit — централизующий вопрос один: где живёт canonical-список «одобренных моделей»? AI gateway — естественное место для этого списка, потому что он стоит между редакторами, CLI и PR-ботами и умеет атрибутировать usage по инструментам и разработчикам. По мере того как Composer 2.5 (и аналогичные модели других vendor) уносят всё больше нагрузки с frontier API, задача gateway смещается с «routинг каждого вызова» на «policy-check каждого вызова, routинг тех, что проходят через gateway, и аудит тех, что не проходят». Вторая категория и есть то, что стоит инструментировать следующим.