Cursor acaba de lanzar Composer 1.5, su nuevo modelo agentic para código, y lo hace con un dato que no es puro marketing: 20 veces más pasos de aprendizaje por refuerzo (RL) que la versión anterior. No es un número puesto al azar para impresionar, sino una declaración bastante clara de hacia dónde quieren llevar la herramienta.
En ese sentido, Composer 1.5 está claramente orientado a desarrolladores profesionales y a equipos que buscan automatizar generación de código, razonamiento y tareas de mantenimiento con la menor fricción posible, sin convertir cada interacción en una microbatalla contra el asistente.
Cursor, de hecho, lo posiciona como herramienta de uso diario, no como un “experimento”. Y ese matiz importa, porque el listón real no es que escriba código correcto en abstracto, sino que te ahorre tiempo sin colarte bugs sutiles a traición.
El mensaje de fondo de Composer 1.5 es bastante claro: el equipo de Cursor está apostando fuerte por aplicar aprendizaje por refuerzo a gran escala en modelos de código para conseguir mejoras que no sean anecdóticas, sino continuas y, sobre todo, predecibles.
Cuando hablan de “20x más pasos de RL”, están apuntando a una estrategia de entrenamiento en la que el modelo no solo aprende por imitación —lo clásico: copiar lo que ve en el dataset—, sino que optimiza su comportamiento en función de objetivos claros y evaluables.
La diferencia es importante, porque ya no se trata solo de que escriba código que “parece correcto”, sino de que aprenda a llegar a soluciones más robustas en tareas largas, con decisiones intermedias, dependencias reales entre archivos y consecuencias que se arrastran durante varios pasos.
Ahora bien, el RL aplicado al código tiene trampa. Si optimizas mal, puedes acabar entrenando modelos que aparentan resolver problemas pero toman atajos peligrosos, o que se vuelven excesivamente lentos porque sobrepiensan absolutamente todo.
Por eso Cursor insiste tanto en el equilibrio: respuestas rápidas para tareas simples y razonamiento más profundo solo cuando el problema realmente lo exige, especialmente en esos marrones de varias fases que nadie quiere hacer dos veces.
Una de las novedades técnicas más llamativas de Composer 1.5 es su nuevo sistema de thinking tokens, diseñado para permitir que el modelo planifique y razone de forma más estructurada durante la resolución de un problema.
En programación, el salto de calidad no está en autocompletar una línea más rápido. Está en entender el objetivo, explorar alternativas, elegir un enfoque razonable y ejecutarlo sin romper media base de código por el camino.
Los thinking tokens funcionan precisamente como ese mecanismo intermedio que convierte el “razonamiento” en un proceso más ordenado, en lugar de una respuesta impulsiva al prompt más reciente.
La duda lógica aparece rápido: ¿esto significa que vamos a ver cadenas eternas de razonamiento para cualquier cosa? En teoría, no. La promesa es que el modelo piense cuando toca, no cuando le pides algo trivial como renombrar variables o ajustar un import mal colocado.
De hecho, según los primeros comentarios de usuarios en foros de desarrolladores, se percibe una mejora tanto en velocidad como en la capacidad de manejar escenarios más intrincados sin perder coherencia.
Y esto es clave, porque si el modelo piensa mejor pero tarda el doble, está muerto en cuestión de días. En herramientas de uso diario, la latencia manda mucho más de lo que solemos admitir.
Composer 1.5 también incorpora una capacidad avanzada de autorresumen recursivo, pensada para gestionar contextos largos condensando su propio proceso de trabajo.
La situación es conocida por cualquiera que haya usado asistentes de código: empiezas con un refactor bien planteado, el modelo parece entender el sistema… y quince minutos después ya olvidó una decisión clave tomada cuatro mensajes atrás.
El autorresumen busca precisamente evitar eso, manteniendo la precisión incluso cuando la memoria se vuelve limitada, y conservando lo importante para poder seguir avanzando sin perder el hilo.
Eso sí, resumir siempre tiene riesgos. Si el resumen se come una constraint crítica —“no tocar esta API”, “esto va por compliance”, “tiene que ser backward compatible”—, el desastre puede ser silencioso pero serio.
Por eso Cursor insiste en que no se trata de recortar texto sin más, sino de preservar la esencia operativa del plan, incluyendo decisiones, restricciones y contexto relevante para la ejecución.
A todo esto se suma una mejora general en el manejo de tareas de programación complejas, especialmente en retos difíciles o de varios pasos, donde las versiones anteriores tendían a desmoronarse con más facilidad.
El verdadero diferencial de Composer 1.5, al menos sobre el papel, no es que “escriba más código”, sino que se comporta mejor cuando le pides algo que obliga a encadenar acciones.
Ese tipo de tareas suelen implicar investigar una base de código existente, proponer un enfoque, aplicar cambios en varios ficheros, ajustar tests y corregir errores que van apareciendo por el camino.
En otras palabras, hacer lo que haría un developer con experiencia, pero en formato asistente que no se cansa y no pierde la paciencia a las dos horas.
Ahora bien, conviene ser honestos: estas herramientas siguen siendo peligrosas si se usan con fe ciega. Cuanto más autónomas parecen, más fácil es que cuelen una suposición falsa que luego cuesta detectar.
El flujo sano sigue siendo el de siempre: tú marcas dirección y restricciones, y el modelo acelera la ejecución. Si no revisas, te la juegas.
Composer 1.5 ya está disponible para uso público, y Cursor remite los detalles de precios a su documentación oficial. No llega como un “próximamente”, sino con una invitación bastante directa: pruébalo en tu pipeline y decide si realmente te ahorra horas o si solo te genera más trabajo de revisión.
Porque, al final, la batalla no va solo de features. Va de confianza. Si en tres semanas demuestra consistencia en tareas reales, lo adoptas. Si un día lo clava y al siguiente te rompe el repo, lo desinstalas sin nostalgia.
Ese “20x más RL” suena, más que a promesa puntual, a una declaración de intenciones: Cursor quiere que las mejoras no sean aleatorias, sino acumulativas y medibles. Si la apuesta sale bien, podríamos empezar a ver asistentes de código que no solo escriben, sino que planifican, recuerdan y ejecutan con un mínimo de criterio. Tocará esperar para ver si la competencia responde y, sobre todo, si esto se nota en los commits de lunes a viernes, no solo en benchmarks bonitos.
Me dedico al SEO y la monetización con proyectos propios desde 2019. Un friki de las nuevas tecnologías desde que tengo uso de razón.
Estoy loco por la Inteligencia Artificial y la automatización.
La Newsletter Diaria Sobre Inteligencia Artificial. Además: Portal de Noticias, Tutoriales, Tips y Trucos de ChatGpt, Openai e Inteligencia Artificial.
Nuestra web está alojada en:
