Cómo Cursor mejora su agente de IA: de los guardrails al contexto dinámico

Cursor ha publicado un estudio detallado sobre cómo desarrolla y mejora de forma continua su agente de IA para programar. La conclusión principal: un único modelo de lenguaje potente no basta. Incluso los modelos más avanzados necesitan un buen «armazón» (harness): un sistema de prompts, herramientas, gestión del contexto y métricas de evaluación. El artículo no habla solo de resultados, sino de metodología: cómo prueba Cursor sus hipótesis, mide la calidad y adapta la arquitectura a las nuevas capacidades de los modelos.

La evolución de la ventana de contexto

Cuando Cursor desarrolló su primer agente de programación, a finales de 2024, los modelos de lenguaje aún no eran muy buenos eligiendo por sí solos qué incluir en el contexto. Por eso el equipo dedicó meses a desarrollar guardrails: restricciones y reglas rígidas que encauzaban al agente.

El enfoque antiguo era así:

• Tras cada edición, le pasaba al agente los errores del linter y del type-checker
• Reescribía las solicitudes de archivos si el agente pedía muy pocas líneas de código
• Limitaba la cantidad de herramientas que el agente podía invocar en un ciclo
• Aportaba una gran cantidad de contexto estático: estructura de carpetas, fragmentos y versiones comprimidas de archivos

Era rudimentario, pero funcionaba. El modelo era débil y necesitaba guía. Sin embargo, a medida que las capacidades de los modelos crecían con rapidez, Cursor fue abandonando los guardrails.

El enfoque actual es muy distinto: el agente recibe un mínimo de contexto estático, básicamente información del sistema operativo, el estado de git y los archivos actuales y vistos recientemente. Todo lo demás lo solicita de forma dinámica, según lo necesite. Busca por sí mismo los archivos que le hacen falta en el código base, consulta la documentación y analiza los errores en tiempo real. Eso es lo que significa que un modelo haya madurado.

Cómo se mide la calidad real

Determinar si una mejora funciona de verdad no es trivial para un producto. Cursor usa un enfoque de dos niveles que combina pruebas sintéticas y datos reales de usuarios.

El primer nivel son los benchmarks públicos (como CursorBench), que ofrecen una instantánea rápida de la calidad y permiten comparar resultados a lo largo del tiempo. Pero incluso los buenos benchmarks solo reflejan de forma aproximada el uso real. Un agente puede superar una prueba en el laboratorio y fallar en el trabajo real.

Por eso, en el segundo nivel, Cursor lanza pruebas A/B con usuarios reales, comparando varias variantes del harness a la vez. Aquí aparecen las métricas que de verdad importan:

• Latency: lo rápido que el agente da la primera respuesta
• Token efficiency: cuántos tokens gastó en una sola solicitud
• Tool call count: cuántas veces recurrió a herramientas
• Cache hit rate: con qué frecuencia reutilizó contexto en caché

Pero la métrica más importante es Keep Rate. Es la proporción de código que permanece en el código base una semana o un mes después de completar la tarea. Si el usuario rehace con frecuencia el código generado o se ve obligado a corregir errores a mano, el Keep Rate baja. Es una señal: el agente no lo hizo bien.

Qué significa esto

El enfoque de Cursor muestra una verdad importante: la calidad de un agente de IA depende no solo del modelo, sino de la arquitectura que lo rodea. Los guardrails rígidos ayudan a los modelos débiles, pero los frenan. El contexto dinámico libera el potencial de los mejores modelos al permitirles explorar el problema por sí mismos.

La conclusión principal: no esperes al modelo perfecto. Dedica tiempo a la arquitectura del harness y a la capacidad de probar hipótesis con rapidez. Porque la calidad de un agente no la determinan ni la velocidad de respuesta ni el volumen de tokens, sino si el resultado de su trabajo sigue en el código con el paso del tiempo.