Un pull request que se fusiona sin problemas puede modificar lo que tu empresa debe a un marco normativo: un rol ampliado, una línea de registro eliminada, un nuevo lugar donde aterrizan datos personales. Según Cursor, el trabajo de Bugbot es señalar posibles errores y problemas de calidad de código antes de que se fusionen. El trabajo de heygrc es responder a otra pregunta: ¿qué control afecta este cambio, citando la cláusula correspondiente. Esta guía es la versión práctica de ejecutar ambos, porque uno no reemplaza al otro.
Para qué sirve cada uno
Mantén clara la división de tareas para tu equipo. Bugbot es un revisor de código: se enfoca en la corrección, la calidad y el cambio en sí. heygrc es un revisor de cumplimiento: analiza el diff frente a los marcos que has seleccionado (ISO 27001, SOC 2, GDPR, entre otros) más el contexto de tu empresa, e indica qué control afecta el cambio y por qué, como un comentario de revisión con la cláusula adjunta. No hacemos ninguna afirmación sobre lo que Bugbot detecta o pasa por alto en un cambio concreto; el punto es que responde a una pregunta diferente.
Configura el par
Bugbot se configura a través de Cursor, según la documentación propia de Cursor. heygrc es una GitHub App: instálala desde github.com/apps/heygrc en los repositorios que quieras revisar (solicita acceso de lectura a código, metadatos e issues, y acceso de escritura solo a Checks y Pull requests, nunca a tu código). Luego configúrala mediante código: un PUT a api.heygrc.com/v1/config con el perfil de tu empresa y la lista de marcos, algo que tu agente de codificación puede hacer por ti en unos tres minutos.
El orden no importa y ninguna herramienta necesita saber que la otra existe. Cada una publica su propia revisión y su propio estado de verificación en el mismo pull request.
Ajusta el volumen antes de que alguien se moleste
Dos bots comentando en cada push es donde los equipos empiezan a rechazar la idea, así que decide la cadencia de heygrc desde el primer día. Ofrece tres modos de revisión: auto (revisa cada pull request al abrirse, reabrirse o recibir un push), auto_once (solo al abrirse, no en cada commit) y mention_only (permanece en silencio hasta que alguien comente /heygrc en el PR). Si tu equipo ya está acostumbrado al ritmo de un revisor de código, auto_once es un buen punto de partida con baja fricción: una revisión de cumplimiento por PR, bajo demanda después de eso.
heygrc también publica una revisión consolidada por cada paso, agrupan los hallazgos en línea en una sola revisión en lugar de un comentario por hallazgo, así que la perspectiva de cumplimiento añade una voz al hilo, no una avalancha.
Decide qué bloquea una fusión
Por defecto, heygrc publica una verificación neutral: informa, y la decisión de fusión sigue en manos de tu equipo. Una vez que confíes en la señal, puedes hacer que la verificación de cumplimiento sea obligatoria a través de la protección de ramas de GitHub, igual que con cualquier trabajo de CI, para que un cambio relevante para un control requiera una confirmación humana explícita antes de fusionarse. La mayoría de los equipos ejecutan el modo informativo durante unas semanas primero; la guía sobre cómo hacer que el cumplimiento sea una verificación obligatoria explica los ajustes exactos.
Qué cuesta añadir esta perspectiva
heygrc factura por revisión, no por asiento: gratis para 25 revisiones de repositorios privados al mes, luego 19 USD por organización al mes con 100 revisiones incluidas y 0.49 USD por revisión adicional, con repositorios públicos siempre gratuitos y una prueba ilimitada de 14 días una vez que reclames la instalación en la consola. Si quieres comparar esto con lo que cada herramienta de revisión publica sobre su propia tarificación según tu volumen, la página de comparación de costes realiza el cálculo a partir de las tarifas publicadas por los proveedores.