Cómo Cursor mejora su agente de AI: de guardrails a contexto dinámico

Cursor publicó un estudio detallado sobre el desarrollo y la mejora continua de su agente de IA para codificación. La conclusión principal: un único modelo de lenguaje poderoso no es suficiente. Incluso los modelos más avanzados necesitan un buen "harness" — un sistema de prompts, herramientas, gestión de contexto y métricas de evaluación. El artículo no solo habla de resultados, sino de metodología: cómo Cursor prueba hipótesis, mide la calidad y adapta la arquitectura a las nuevas capacidades de los modelos.

Evolución de la Ventana de Contexto

Cuando Cursor estaba desarrollando su primer agente de codificación a finales de 2024, los modelos de lenguaje aún no eran muy buenos eligiendo independientemente qué incluir en el contexto. Así que el equipo pasó meses desarrollando guardrails — restricciones y reglas rígidas que guiaban al agente en la dirección correcta. El enfoque antiguo se veía así:

• Después de cada edición, proporcionaba al agente errores del linter y advertencias del type-checker
• Reescribía solicitudes de archivos si el agente pedía muy pocas líneas de código
• Limitaba el número de herramientas que el agente podía llamar en un solo ciclo
• Proporcionaba mucho contexto estático — estructura de carpetas, fragmentos de código y versiones comprimidas de archivos

Era primitivo, pero funcionaba. El modelo era débil y necesitaba orientación. Pero con el rápido crecimiento de las capacidades de los modelos, Cursor abandonó gradualmente los guardrails. El enfoque moderno es completamente diferente: el agente recibe contexto estático mínimo — principalmente solo información del SO, estado de git, archivos actuales y recientemente visualizados. Todo lo demás el agente lo solicita dinámicamente, según sea necesario. Busca independientemente los archivos necesarios en la base de código, solicita documentación y analiza errores en tiempo real. Eso es lo que significa que un modelo madure.

Cómo Se Mide la Calidad Real

Determinar si una mejora realmente funciona es una tarea no trivial para un producto. Cursor utiliza un enfoque de dos niveles, combinando pruebas sintéticas y datos reales del usuario. En el primer nivel están los benchmarks públicos (como CursorBench), que proporcionan una instantánea rápida de la calidad y permiten comparaciones en el tiempo. Pero incluso los benchmarks buenos solo reflejan aproximadamente el uso real. Un agente puede pasar perfectamente una prueba en condiciones de laboratorio pero fallar en el trabajo real. Así que en el segundo nivel, Cursor ejecuta pruebas A/B en usuarios reales, comparando múltiples variantes del harness simultáneamente. Aquí es donde emergen las métricas que realmente importan:

• Latency — con qué rapidez el agente proporciona la primera respuesta
• Token efficiency — cuántos tokens se gastaron por solicitud
• Tool call count — cuántas veces llamó a herramientas
• Cache hit rate — con qué frecuencia reutilizó contexto en caché

Pero la métrica más importante es Keep Rate. Esta es la proporción de código que permanece en la base de código una semana, un mes después de que se complete la tarea. Si los usuarios frecuentemente rehacen el código generado o se ven obligados a corregir errores manualmente — Keep Rate cae. Esto señala: el agente no tuvo éxito.

Lo Que Esto Significa

El enfoque de Cursor revela 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 congelan. El contexto dinámico desbloquea el potencial de mejores modelos, permitiéndoles explorar el problema de forma independiente. La conclusión principal: no esperes al modelo perfecto. Dedica tiempo a la arquitectura del harness y a la capacidad de probar hipótesis rápidamente. Porque la calidad del agente no se determina por la velocidad de respuesta ni el volumen de tokens — se determina por si la salida de su trabajo permanece en el código a lo largo del tiempo.