A medida que los agentes de código se volvían más capaces, empezamos a dedicar más tiempo a la revisión. Para solucionarlo, creamos Bugbot, un agente de revisión de código que analiza pull requests en busca de errores de lógica, problemas de rendimiento y vulnerabilidades de seguridad antes de que lleguen a producción. Para el verano pasado, funcionaba tan bien que decidimos lanzarlo a los usuarios.

El proceso de creación de Bugbot comenzó con evaluaciones cualitativas y fue evolucionando gradualmente hacia un enfoque más sistemático, usando una métrica personalizada basada en IA para optimizar de forma iterativa la calidad.

Desde el lanzamiento, hemos ejecutado 40 experimentos importantes que han aumentado la tasa de resolución de Bugbot del 52% a más del 70%, al mismo tiempo que elevaban el número promedio de errores señalados por ejecución de 0,4 a 0,7. Esto significa que el número de errores resueltos por PR se ha más que duplicado, pasando de aproximadamente 0,2 a alrededor de 0,5.

#Humildes comienzos

Cuando intentamos por primera vez crear un agente de revisión de código, los modelos no eran lo suficientemente capaces como para que las revisiones fueran útiles. Pero a medida que mejoraron los modelos base, nos dimos cuenta de que teníamos varias formas de aumentar la calidad de los informes de errores.

Experimentamos con diferentes configuraciones de modelos, pipelines, filtros y estrategias inteligentes de gestión de contexto, encuestando a los ingenieros internamente durante el proceso. Si parecía que una configuración tenía menos falsos positivos, la adoptábamos.

Una de las mejoras de calidad más efectivas que encontramos al principio fue ejecutar múltiples pases de búsqueda de errores en paralelo y combinar sus resultados con votación por mayoría. Cada pase recibía un orden diferente del diff, lo que orientaba al modelo hacia distintas líneas de razonamiento. Cuando varios pases marcaban de forma independiente el mismo problema, lo tratábamos como una señal más sólida de que el error era real.

Tras semanas de iteraciones cualitativas internas, llegamos a una versión de Bugbot que superó a otras herramientas de revisión de código del mercado y nos dio la confianza para lanzarlo. Usaba este flujo:

1. Ejecutar ocho pases en paralelo con orden aleatorio del diff
2. Combinar errores similares en un solo grupo
3. Votación por mayoría para filtrar errores encontrados solo en un pase
4. Unir cada grupo en una única descripción clara
5. Filtrar categorías no deseadas (como advertencias del compilador o errores de documentación)
6. Pasar los resultados por un modelo validador para detectar falsos positivos
7. Eliminar duplicados respecto a errores reportados en ejecuciones anteriores

#Del prototipo a producción

Para que Bugbot fuera realmente útil en la práctica, tuvimos que invertir en un conjunto de sistemas fundamentales junto con la lógica principal de revisión. Eso incluyó hacer que el acceso al repositorio fuera rápido y confiable al reconstruir nuestra integración con Git en Rust y minimizar la cantidad de datos que obteníamos, además de agregar monitoreo de límites de frecuencia, agrupación de solicitudes e infraestructura basada en proxies para operar dentro de las restricciones de GitHub.

A medida que crecía la adopción, los equipos también necesitaban una forma de codificar invariantes específicos de la base de código, como migraciones inseguras o uso incorrecto de APIs internas. En respuesta, agregamos reglas de Bugbot para permitir esas comprobaciones sin codificarlas de forma rígida en el sistema.

En conjunto, estas piezas hicieron que Bugbot fuera práctico de ejecutar y adaptable a bases de código reales. Pero no nos indicaban si la calidad realmente estaba mejorando. Sin una métrica para medir el progreso, no podíamos evaluar cuantitativamente el rendimiento de Bugbot en entornos reales, y eso imponía un límite a hasta dónde podíamos llevarlo.

#Midiendo lo que importa

Para resolver este problema, ideamos una métrica llamada tasa de resolución. Usa IA para determinar, en el momento de fusionar la PR, qué errores fueron realmente resueltos por el autor en el código final. Al desarrollar esta métrica, revisamos manualmente cada ejemplo internamente con el autor de la PR y descubrimos que el LLM clasificó correctamente casi todos como resueltos o no.

Los equipos a menudo nos preguntan cómo evaluar el impacto que Bugbot tiene para ellos, por lo que mostramos esta métrica de forma destacada en el dashboard. Para los equipos que evalúan la efectividad, es una señal mucho más clara que los comentarios anecdóticos o las reacciones en los comentarios. La tasa de resolución responde directamente a si Bugbot está encontrando problemas reales que los ingenieros corrigen.

#Ascenso de colina

Definir la tasa de resolución cambió cómo construimos Bugbot. Por primera vez, podíamos optimizar mediante hill-climbing basándonos en señales reales, en lugar de solo en la intuición. Empezamos a evaluar cambios en línea usando tasas de resolución reales y fuera de línea usando BugBench, un conjunto de pruebas (benchmark) curado de diffs de código reales con errores anotados por humanos.

Ejecutamos docenas de experimentos con diferentes modelos, prompts, números de iteraciones, validadores, gestión de contexto, filtrado por categorías y diseños de agentes. Muchos cambios, sorprendentemente, empeoraron nuestras métricas. Resultó que muchos de nuestros juicios iniciales a partir de los primeros análisis cualitativos eran correctos.

#Arquitectura basada en agentes

Observamos las mayores mejoras cuando, este otoño, cambiamos Bugbot a un diseño completamente basado en agentes. El agente podía razonar sobre el diff, invocar herramientas y decidir dónde profundizar en lugar de seguir una secuencia fija de iteraciones.

El bucle basado en agentes nos obligó a replantear el prompting. Con las primeras versiones de Bugbot necesitábamos restringir los modelos para minimizar los falsos positivos. Pero con el enfoque basado en agentes nos encontramos con el problema opuesto: era demasiado cauteloso. Pasamos a prompts agresivos que animaban al agente a investigar cada patrón sospechoso y a pecar por exceso a la hora de señalar posibles problemas.

Además, la arquitectura basada en agentes abrió un espacio mucho más rico para la experimentación. Pudimos trasladar más información fuera del contexto estático y al contexto dinámico, variando cuánta información de contexto inicial recibía el modelo y observando cómo se adaptaba. El modelo incorporaba sistemáticamente el contexto adicional que necesitaba en tiempo de ejecución, sin requerir que todo se le proporcionara por adelantado.

La misma configuración nos permite iterar directamente sobre el propio conjunto de herramientas. Como el comportamiento del modelo está determinado por las herramientas a las que puede llamar, incluso pequeños cambios en el diseño o la disponibilidad de las herramientas tenían un impacto desproporcionado en los resultados. A través de múltiples rondas de iteración, ajustamos y perfeccionamos esa interfaz hasta que el comportamiento del modelo se alineó de forma consistente con nuestras expectativas.

#Próximos pasos

Hoy, Bugbot revisa más de dos millones de PR al mes para clientes como Rippling, Discord, Samsara, Airtable y Sierra AI. También ejecutamos Bugbot en todo el código interno de Cursor.

De cara al futuro, esperamos que nuevos modelos lleguen de forma regular con diferentes fortalezas y debilidades, tanto de otros proveedores como de nuestros propios esfuerzos de entrenamiento. El progreso continuo requiere encontrar la combinación adecuada de modelos, diseño del harness y estructura de revisión. El Bugbot de hoy es varias veces mejor que el Bugbot de su lanzamiento inicial. En unos meses esperamos que vuelva a mejorar de forma significativa.

Ya estamos construyendo hacia ese futuro. Acabamos de lanzar Bugbot Autofix en Beta, que inicia automáticamente un Cloud Agent para corregir errores encontrados durante las revisiones de PR. Las próximas capacidades importantes incluyen permitir que Bugbot ejecute código para comprobar sus propios informes de errores y habilitar análisis en profundidad cuando se encuentra con problemas complejos. También estamos experimentando con una versión siempre activa que escanea continuamente tu base de código en lugar de esperar a las PR.

Hasta ahora hemos logrado grandes avances que no habrían sido posibles sin las contribuciones de algunos miembros clave del equipo, incluidos Lee Danilek, Vincent Marti, Rohan Varma, Yuri Volkov, Jack Pertschuk, Michiel De Jong, Federico Cassano, Ravi Rahman y Josh Ma. Juntos, nuestro objetivo sigue siendo ayudar a tus equipos a mantener la calidad del código a medida que tus flujos de trabajo de desarrollo con IA escalan.

Leer la documentación o prueba Bugbot hoy.