Creo que fui demasiado desdeñoso con el nuevo LLM de codificación Composer-1 de Cursor. Claro, es estrictamente peor que GPT-5 High Effort y GPT-5-Codex, y en ese sentido, cuando estoy diseñando e implementando proyectos de código importantes, realmente no veo un lugar para ello en mis flujos de trabajo. Por otro lado, es extremadamente rápido (me pregunto cómo lo hicieron; ¿están usando hardware Groq o Cerebras? ¿Es porque el modelo es tan pequeño y eficiente? no estoy seguro), y esto por sí solo desbloquea muchos flujos de trabajo nuevos y técnicas de trabajo para cuando el código no es tan crítico, o cuando está comenzando un nuevo proyecto y no tiene que preocuparse por romper el código existente. También es mucho, mucho más barato en comparación con cualquier sabor de GPT-5. La combinación de mucho más rápido y mucho más barato crea una diferencia cualitativa en la forma en que puede usar el modelo que antes no apreciaba completamente. Cuando el costo de la iteración es tan bajo tanto en términos de tiempo como de dinero, puede iterar muchas más veces. Eso reduce el valor de la "corrección de una sola vez"; es decir, la capacidad de un modelo como GPT-5 Pro para obtener incluso una asignación de codificación compleja correcta la primera vez sin errores (aunque incluso ese modelo a menudo falla en esta prueba tan estricta). Pero si puede cerrar el ciclo de depuración y devolver rápidamente los errores / advertencias al modelo, y cada ronda de iteración toma de 20 segundos a un minuto (en lugar de 5 a 10 veces ese tiempo, al menos usando GPT-5 con gran esfuerzo), entonces puede resolver rápidamente todos los errores descuidados que comete la primera vez (o incluso la segunda, la tercera o cuarta vez) y aún así terminar con el código de trabajo antes de lo que podría con GPT-5. Si está desarrollando algo en el navegador, ahora puede cerrar el ciclo por completo usando la nueva pestaña del navegador de Cursor, que es, con mucho, la mejor implementación de este tipo de cosas que he visto en cualquier herramienta de codificación (¡está muy por delante de usar Playwright MCP de Codex o Claude Code!). He estado usando este mensaje con gran efecto hoy: "Use la pestaña del navegador para explorar sistemáticamente esta aplicación y use la interfaz de manera natural; mientras eso sucede, esté atento a CUALQUIER advertencia o error en la consola de desarrollo. Cuando vea uno, comience a diagnosticar y corregir los errores y problemas de forma interactiva e iterativa y, a continuación, actualice la aplicación y verifique que el error o la advertencia se hayan resuelto por completo. Cuando arregle las cosas, concéntrese en determinar la verdadera causa raíz subyacente del error y no en aplicar correcciones falsas de "curita". Sin embargo, donde este enfoque realmente falla es en las fases conceptuales y de planificación, donde está averiguando qué hacer y la mejor manera de implementarlo a un alto nivel. Allí, la falta de pensamiento profundo y exploración puede iniciarlo en un mal camino del que es difícil recuperarse. Esto es mucho más evidente cuando la tarea en la que está trabajando se aleja de la "variedad de datos" de las tareas de codificación comunes. Si está creando otro sitio web CRUD simple, probablemente no lo notará mucho. Si estás tratando de pisar un nuevo terreno en una simulación de vida artificial o algo extraño como eso, lo notarás mucho. Pero hay un buen enfoque híbrido que funciona muy bien: combinar el modelo más inteligente para la planificación con estos modelos rápidos y baratos para producir iteraciones. Por lo tanto, use GPT-5 Pro en la aplicación del navegador para idear su plan y una implementación inicial, luego péguelo en Cursor y comience a iterar, corregir y mejorar. Es mucho mejor para modificar una base sólida existente que para establecer esa base en sí. Donde todo esto realmente brilla es cuando estás jugando y explorando con algo divertido, en un nuevo proyecto donde no hay plazos ni expectativas. En este contexto, la velocidad es un verdadero cambio de juego. Me recuerda a esa vieja investigación realizada por IBM a principios de los años 80 que analizó la latencia con sistemas informáticos, que encontró que cuando la latencia cae por debajo de un nivel mágico, como 50 ms, se produce este gran cambio en el comportamiento porque el cerebro humano percibe que está tratando con un "sistema en vivo". Y, a la inversa, cuando la latencia supera incluso un nivel sorprendentemente modesto, como 500 ms, obtienes mucho menos compromiso, y es mentalmente agotador y frustrante. Cuando la latencia aumenta a unos pocos segundos o más, las personas tienden a retirarse mentalmente y se convierte en una lucha mantenerse comprometido. Ver que el modelo de codificación responde en segundos y hace una ráfaga de 10 ediciones en menos de 15 segundos es una experiencia completamente diferente a esperar 5 minutos para que GPT-5 haga un gran esfuerzo para ejecutar metódicamente algo. ...