AI code review con Cursor Bugbot: configuración, costos y límites

Mi opinión: vale la pena considerar Bugbot si tu equipo busca conectar los hallazgos de las PR con el flujo de corrección de Cursor. Mantén la aprobación humana y las comprobaciones automáticas que ya tienes. En Azure DevOps, evalúa la herramienta por su capacidad de revisión, ya que Bugbot Autofix no está disponible. En GitLab y Bitbucket, antes de activar Autofix, decide si permitir correcciones directamente en la rama de la PR encaja con tu forma de trabajar.

AI code review con Cursor Bugbot: ¿qué revisa?

Bugbot busca errores, problemas de seguridad y fallos de calidad del código en el diff de una pull request: los cambios que se proponen para integrar. Imagina a un inspector que revisa una remodelación: empieza por la obra que se ha modificado y utiliza las reglas del repositorio como los requisitos particulares del edificio.

Las revisiones pueden ejecutarse cuando se actualiza una PR o cuando alguien comenta cursor review o bugbot run. Los comentarios generales y los vinculados a líneas de código de la PR aportan contexto para que Bugbot tenga en cuenta las observaciones anteriores. Los hallazgos incluyen explicaciones, propuestas de corrección y enlaces para continuar en Cursor o en la web. Cómo funciona Bugbot.

La ventaja práctica consiste en detectar antes un defecto que podría pasar inadvertido durante la revisión. El número de comentarios no mide esa ventaja. Evalúa si los hallazgos identifican un fallo real, explican cuándo ocurre y permiten corregirlo de forma útil. Mantén las pruebas, los análisis de seguridad y la revisión por parte de los responsables del código.

Cómo configurar Bugbot en cada repositorio

Conecta tu proveedor de control de versiones desde el panel de integraciones de Cursor. Después, abre Bugbot en Automations y activa los repositorios que quieras revisar. Conectar el proveedor y activar los repositorios son pasos distintos. La configuración de Cursor admite GitHub, GitLab, Bitbucket y Azure DevOps Services, incluidas las variantes autohospedadas documentadas de los tres primeros. Configuración de Bugbot.

GitHub

Necesitas permisos de administrador en Cursor y en la organización de GitHub. En Integrations, selecciona Connect junto a GitHub, o Manage Connections si ya está conectado. Elige All repositories o Selected repositories, completa la conexión y vuelve a Cursor para activar los repositorios elegidos en Bugbot. GitHub Enterprise Server tiene su propia pestaña de configuración e instrucciones de red. Integración de Cursor con GitHub.

GitLab

Para GitLab.com, necesitas permisos de administrador en Cursor, acceso de maintainer en GitLab y un plan de pago GitLab Premium o Ultimate. Cursor requiere tokens de acceso de proyecto, que GitLab Free no ofrece. En Integrations, selecciona Connect o Manage Connections, completa la instalación de GitLab y usa Manage → Sync Repos antes de activar los repositorios en Bugbot. Las instalaciones autohospedadas tienen instrucciones de conexión específicas. Integración de Cursor con GitLab.

Bitbucket

Bitbucket Cloud está actualmente en beta pública. Conecta tu cuenta desde Integrations y autoriza a Cursor. El espacio de trabajo también necesita la aplicación de Cursor: un administrador del espacio de trabajo de Bitbucket debe abrir el menú de gestión de Bitbucket en Cursor, elegir Install Cursor app e instalarla en ese espacio. Después, un administrador del equipo de Cursor con acceso al espacio de trabajo debe abrir Forge Apps → Cursor en la configuración del espacio de Bitbucket, seleccionar Connect to Cursor y vincular el equipo. A continuación, activa los repositorios en Bugbot. Conectar una cuenta personal no basta para establecer la identidad de la aplicación que publicará los comentarios de revisión. Bitbucket Data Center sigue un proceso de configuración distinto. Integración de Cursor con Bitbucket.

Azure DevOps

Sigue la configuración específica de Bugbot para Azure DevOps Services. Requiere el consentimiento de un administrador del tenant de Microsoft Entra. Un Project Collection Administrator conecta Azure DevOps y activa Bugbot en un repositorio; este paso crea el principal de servicio de Cursor, una identidad de aplicación dentro de tu organización. Un administrador de proyecto debe añadir esa identidad a Project Administrators en cada proyecto que se vaya a revisar, para que pueda gestionar los service hooks, las notificaciones que activan las revisiones.

Los cambios de permisos pueden tardar en propagarse. Si aparece un error de configuración, resuélvelo y vuelve a intentar activar el repositorio. Bugbot admite repositorios de equipo, pero no los de ámbito personal. Configuración de Bugbot para Azure DevOps en Cursor.

Decide cuándo y para quién se ejecutan las revisiones

En cada repositorio activado, elige si quieres revisar las actualizaciones o ejecutar la revisión una sola vez por PR, y configura las listas de autores permitidos o excluidos que necesites. La configuración personal permite que las revisiones de un autor se ejecuten solo al mencionar a Bugbot, una vez por PR o también en borradores. Bugbot puede revisar las contribuciones de personas ajenas a tu equipo de Cursor en los repositorios activados. Configuración de repositorios y preferencias personales.

Azure DevOps añade una condición para activar revisiones mediante comentarios: la dirección de inicio de sesión en Azure DevOps de quien comenta debe coincidir con una cuenta de Cursor del equipo propietario del repositorio. Esta restricción no se aplica a las revisiones automáticas. Activación de revisiones en Azure DevOps.

El archivo .cursor/config/bugbot.yaml, tal como debes guardarlo

Guarda la configuración de las revisiones en el repositorio si quieres que sus cambios también pasen por una revisión de código. Este es el ejemplo publicado en la documentación de Cursor sobre la configuración del repositorio:

# .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

Haz commit y push del archivo en esa ruta, relativa a la raíz del repositorio. Bugbot lo lee desde la rama base de la PR, es decir, la rama que recibe los cambios. No utiliza la versión de la rama de origen de la PR, de modo que un cambio propuesto no pueda modificar la configuración con la que se revisa. Usa CODEOWNERS, el mecanismo del repositorio para asignar responsables a los archivos, para controlar quién revisa los cambios de configuración.

Todos los campos son opcionales. Si un campo falta o no es válido, se recurre a la siguiente fuente de configuración; los archivos de más de 64 KB se ignoran. El orden de prioridad es:

1. Las preferencias personales del autor para sus propias PR.
2. El archivo YAML del repositorio.
3. La configuración del equipo y de la organización en el panel.

Ese orden importa: consultar solo el YAML no permite saber qué configuración recibirá un autor. Además, autofix.mode puede restringir lo que permite el panel, pero no puede activar Autofix si está desactivado en el panel. Comportamiento y prioridad de la configuración.

El ejemplo elige publicar el resumen como comentario; no enumera todos los valores predeterminados del panel. Sin esa opción, los resúmenes de las PR se añaden a la descripción de forma predeterminada. La revisión incremental examina los cambios realizados desde la revisión anterior de Bugbot. Un nivel de esfuerzo mayor puede dedicar más tiempo y consumo a buscar errores; Smart deja que tus instrucciones determinen ese nivel. Resúmenes, revisiones incrementales y esfuerzo.

Define las instrucciones de revisión en BUGBOT.md

Usa .cursor/BUGBOT.md para recoger lo que un revisor necesita saber sobre tu proyecto. El archivo de la raíz se incluye siempre. Bugbot también busca archivos .cursor/BUGBOT.md en los directorios superiores a cada archivo modificado; así, un directorio de backend puede tener instrucciones distintas de las del frontend. Las reglas del editor de Cursor en .cursor/rules/*.mdc no se aplican a Bugbot. Reglas de proyecto para Bugbot.

Una regla útil identifica una condición que siempre debe cumplirse y el fallo que hay que vigilar. Por ejemplo, un equipo de pagos podría indicar que reintentar una operación nunca debe volver a cobrar al cliente. Un equipo de backend podría explicar qué transiciones de estado requieren una entrada de auditoría. Son sugerencias para redactar reglas, no promesas de que Bugbot detectará todos los incumplimientos.

Se combinan las reglas del equipo, los archivos de reglas del proyecto, las reglas aprendidas y las reglas manuales del repositorio. Para usar las reglas aprendidas y manuales del panel, el aprendizaje debe estar activado tanto en la organización como en el repositorio. Redacta instrucciones concretas: cada regla se trunca a 30,000 caracteres, y el conjunto de reglas de revisión tiene un límite de 100,000 caracteres. Para comprobar qué se ha cargado realmente, comenta bugbot run verbose=true o cursor review verbose=true; la respuesta indica qué reglas se incluyeron, se truncaron o se omitieron. Reglas y límites.

Cómo se factura Bugbot ahora

Presupuesta Bugbot por consumo y contabiliza Autofix por separado. Estas son las condiciones que Cursor describe actualmente:

Estas son las condiciones actuales de facturación de Bugbot. No des por hecho que el uso incluido del editor de un equipo cubre las revisiones de Bugbot. Autofix consume créditos de Cloud Agent, que se cobran según las tarifas de tu plan actual. Facturación de Autofix.

El cambio de precios de mayo se aplica a las suscripciones existentes en su siguiente renovación posterior al 8 de junio de 2026. Por eso, una suscripción anual antigua puede mantener sus condiciones anteriores hasta la renovación. Anuncio de Cursor sobre el cambio de precios.

La documentación actual de Bugbot no ofrece una tarifa fija por revisión que puedas incorporar directamente al presupuesto. La complejidad de las PR, la frecuencia de revisión y el nivel de esfuerzo influyen en el trabajo que se realiza. Toma el costo medio por ejecución que publique un proveedor como referencia, no como una tarifa garantizada para tu repositorio.

Para evaluar si compensa, compara el gasto en revisiones + el gasto en Autofix + el tiempo que los ingenieros dedican a evaluar hallazgos con el trabajo de revisión y corrección que el equipo se ahorra. El presupuesto de revisión humana sigue siendo necesario. La decisión depende de los hallazgos útiles y de la atención que permiten ahorrar, no de si otro bot es capaz de publicar comentarios.

Autofix y MCP tienen requisitos distintos

Autofix inicia un Cloud Agent, un agente que trabaja con el código de forma remota, para corregir los hallazgos de Bugbot e informar del resultado en la PR. Requiere que estén activados tanto el uso bajo demanda como el almacenamiento; Legacy Privacy Mode no cumple ese requisito de almacenamiento. Elige un modo compatible en Bugbot Automations. Requisitos de Autofix.

Estos son los modos de Autofix documentados por Cursor. El modo que trabaja en la rama existente permite como máximo 3 intentos por PR para evitar bucles. Mi recomendación inicial es dejar Autofix desactivado hasta que el equipo acuerde cómo revisar las correcciones generadas. Después, los equipos que usan GitHub pueden elegir el modo de rama nueva para examinarlas por separado.

MCP, un protocolo que permite a una herramienta de IA acceder a otras herramientas y a contexto adicional, puede ampliar el proceso de revisión de Bugbot. Configura el servidor MCP y añade sus herramientas a Bugbot en Automations. La compatibilidad de Bugbot con MCP solo está disponible en los planes Team y Enterprise. Disponibilidad de MCP.

Bugbot frente a CodeRabbit y Greptile

Elige según el encaje con tu flujo de trabajo y el modelo de costos que puedas gestionar. Estos son precios publicados, no resultados de una prueba comparativa.

Fuentes: Cursor Bugbot, precios de CodeRabbit, precios de Greptile. Los importes anuales de CodeRabbit son equivalentes mensuales con facturación anual. Los créditos de Greptile no son intercambiables con el consumo de Cursor ni con los cargos por archivo revisado de CodeRabbit.

La diferencia presupuestaria es clara: CodeRabbit combina una suscripción por usuario con posibles cargos por continuar las revisiones; Greptile combina usuarios y créditos; el modelo actual de Bugbot sitúa el consumo de las revisiones como variable central. Ninguna comparación rigurosa puede determinar cuál será la opción más barata para tu equipo mirando solo el precio por usuario.

Para una comparación más directa, lee Greptile frente a CodeRabbit. Si quieres ampliar la selección, consulta alternativas a CodeRabbit y las mejores herramientas de revisión de código con IA para equipos pequeños.

En qué situaciones podría aportar más valor al equipo

Daría prioridad a los flujos en los que un defecto que pasa inadvertido cuesta más que la atención necesaria para evaluar un hallazgo. Estos son usos posibles, ordenados según por dónde empezaría, no resultados medidos.

Los mecanismos de revisión, contexto, reglas y Autofix que sustentan estos ejemplos están documentados en la guía de Bugbot de Cursor. Su valor depende de tu código y de quienes lo revisan.

Qué vale la pena desarrollar alrededor de Bugbot

La oportunidad más sólida consiste en ayudar a los responsables de ingeniería a entender el costo y los resultados de las revisiones. Resulta más difícil justificar otro generador de comentarios cuando ya existen herramientas consolidadas que revisan el código.

Un registro de costos y resultados de las revisiones

Un equipo de plataforma podría crear un panel que vincule el gasto por repositorio con los hallazgos que los ingenieros aceptaron, descartaron o corrigieron. Los compradores serían los responsables de ingeniería. El precio Pro de Greptile, de $30/usuario/mes, demuestra que existe una categoría consolidada de herramientas de revisión de pago; no demuestra que sus clientes vayan a pagar por este complemento. Precios de Greptile.

La versión mínima útil combinaría hallazgos y registros de facturación con una valoración humana de su utilidad. La API de revisión de Cursor para Enterprise ofrece analítica de las revisiones, incluidos los hallazgos y el costo facturado; el campo de costo puede no contener ningún importe facturado. Una versión para clientes sin Enterprise necesitaría datos introducidos manualmente y autorizados, en lugar de dar por hecho el acceso a esa API. API y analítica de Bugbot.

La dificultad: los comentarios resueltos no reflejan con precisión el valor de los errores detectados, y una atribución incompleta de los cargos puede hacer que el panel resulte engañoso. Empezaría por esta herramienta porque responde a la pregunta que vuelve en cada renovación: ¿el valor de este revisor justifica su costo total?

Un auditor de políticas de revisión por repositorio

Un grupo de ingeniería de plataforma podría utilizar una herramienta que compruebe si los repositorios tienen la configuración de Bugbot aprobada, si faltan reglas de proyecto y si hay cambios de políticas que no se han revisado. El precio mensual de CodeRabbit Team, de $60/desarrollador/mes, sitúa la gestión de revisiones en equipo dentro de una categoría de productos de pago; aun así, habría que validar si existe disposición a comprar una herramienta de políticas por separado. Precios de CodeRabbit.

La versión mínima podría leer los archivos de los repositorios y generar un informe para sus responsables. La dificultad: las preferencias personales tienen prioridad sobre el YAML, por lo que auditar solo los archivos no permite certificar cómo se ejecutarán realmente las revisiones. Expón esa limitación e incorpora al proceso la configuración del panel cuando el acceso autorizado lo permita. Prioridad de la configuración de Bugbot.

Exige una aprobación explícita antes de integrar el código

Que la comprobación de Bugbot sea obligatoria no significa automáticamente que los hallazgos pendientes bloqueen la integración. De forma predeterminada, los hallazgos producen un resultado neutral. Exigir ese estado garantiza que la comprobación se ejecute; cuando está disponible para tu organización, la opción de marcar la comprobación como fallida si quedan problemas sin resolver hace que los hallazgos produzcan un estado de error. Revisa ese ajuste antes de confiar en la protección de ramas. Estados de las comprobaciones de Bugbot.

Mi recomendación es usar Bugbot como una fuente adicional de información para quien revisa el código. Un informe sin hallazgos no demuestra que la funcionalidad cumpla sus requisitos, y un parche generado automáticamente necesita el mismo escrutinio que cualquier otro código.

Por dónde empezar el lunes

Elige un repositorio cuyos responsables puedan definir qué fallos quieren detectar. Pide al administrador correspondiente que complete la conexión con el proveedor, activa Bugbot para ese repositorio, incorpora la configuración a la rama base mediante un commit y redacta reglas de revisión concretas. Asigna un responsable del presupuesto y decide por separado si activar Autofix. Antes de ampliar la implantación, aprovecha las revisiones habituales para registrar los hallazgos útiles, las sugerencias descartadas y el tiempo dedicado a evaluar ambos.

Si necesitas integrar informes de revisión o controles de repositorios en tu flujo de entrega, podemos ayudarte con la automatización con IA.