Si usaste Bugbot, conocés el patrón: abrís un PR, esperás, te vas a hacer un café, volvés, leés los comentarios. El review funcionaba, pero la espera era real — unos cinco minutos por corrida. El 10 de junio Cursor lanzó un update que prácticamente mata la espera, y el por qué detrás es más interesante que los números en sí.
El titular: el tiempo medio de review de Bugbot bajó de ~5 minutos a ~90 segundos. Además encuentra alrededor de un 10% más de bugs por review (0.62 vs 0.56 en promedio), y cuesta ~22% menos por corrida. Son los números propios de Cursor — auto-reportados por el vendor, sin validación independiente — así que leelos como dirección, no como evangelio. Pero la dirección es empinada.
Qué cambió realmente
Las ganancias vienen de Composer 2.5, el modelo propio de Cursor, que ahora alimenta a Bugbot. Esa es la parte para detenerse un segundo — volvemos a eso.
En el plano práctico, hay una forma nueva de usarlo. Ahora podés correr un review antes de hacer push, directo desde tu agente:
/review— te pregunta qué agentes correr (Bugbot, Security Review, o ambos)/review-bugbot— corre Bugbot directamente/review-security— corre el agente de Security Review directamente
Y el detalle que te salva de laburar al pedo: /review sincroniza con Bugbot en GitHub y GitLab. Si lo corrés localmente y después abrís un PR con el mismo diff, Bugbot lo reconoce, se saltea el re-review, y deja un comentario avisando que ya revisó ese diff. No pagás dos veces, no leés los mismos comentarios dos veces.
También hay una config nueva para revisar solamente lo que es nuevo desde el último review, así el feedback se mantiene enfocado en tus últimos cambios en vez de re-litigar toda la branch.
Todo esto está en Cursor 3.7+ y en cursor.com/agents. El soporte en CLI está en camino pero todavía no llegó.
Por qué el pre-push cambia la cuenta
Acá está el cambio de workflow. El default viejo era: escribís código → push → abrís PR → esperás el review → corregís → push de nuevo. Bugbot vivía en el PR, lo que significaba que el review era un checkpoint después de que ya declaraste el trabajo “suficientemente listo para compartir”.
Corré /review antes del push y el review se mueve aguas arriba, al mismo loop donde todavía estás editando activamente. Cazás las pavadas antes de que sean públicas, antes de que se dispare la notificación de un compañero, antes de que el diff sea algo que tengas que defender. El comportamiento de sync con el PR significa que moverlo más temprano no te cuesta nada — no estás agregando un paso, estás reubicando uno.
Un review de 90 segundos es lo que hace esto viable. A cinco minutos, correr el review en cada pre-push es una fricción que vas a saltear bajo deadline. A 90 segundos es más o menos el costo de releer tu propio diff, cosa que deberías estar haciendo igual.
Dónde no encaja
Si tu equipo ya tiene un pipeline de review humano maduro y de bajo volumen — diffs chicos, turnaround rápido, reviewers que conocen el codebase de memoria — una pasada automática en pre-push agrega más ruido que señal. Y si tu organización bloquea modelos propietarios por políticas de data, tené en cuenta que Bugbot respeta las model block lists, pero la performance del titular viene específicamente de Composer 2.5; bloquealo y los números cambian. Esta es una herramienta para equipos que despachan un alto volumen de PRs donde el cuello de botella es la atención del reviewer, no para el taller de dos personas que se revisan el código en tiempo real.
La parte para los CTOs que están leyendo
Alejate un paso del feature y mirá la jugada. Cursor no hizo a Bugbot 3x más rápido tuneando prompts contra el frontier model de otro. Llegaron ahí entrenando su propio modelo — Composer 2.5 — y apuntándolo a un trabajo específico y acotado: revisar código.
Esa es la tendencia para seguir. La primera ola de herramientas de AI dev era una capa fina sobre un frontier model prestado; la diferenciación estaba en el UX. Lo que Cursor está señalando acá es la fase siguiente: vendors entrenando modelos verticales tuneados para una sola tarea — review, en este caso — donde controlan la curva de costo, la latencia y el techo de calidad en vez de alquilar los tres a un frontier lab.
Para cualquiera que esté evaluando gasto en tooling, esa es la pregunta que conviene empezar a hacerle a cada vendor: lo que estoy pagando, ¿es un wrapper, o son dueños del modelo debajo del feature que realmente uso? Porque el vendor que es dueño del modelo es el que te puede entregar un recorte de costo del 22% y un 3x de velocidad en una sola entrada de changelog — y seguir haciéndolo.