Vale la pena probar GPT-5.3-Codex-Spark
Categories:
Quienes conocen las evaluaciones de LLM saben que opus a menudo supera a gpt en varias listas de evaluación, pero en el uso real la capacidad de gpt para resolver problemas es insuperable. Hasta el momento de publicar, los modelos principales más recientes de la serie gpt5 son gpt-5.2-mini, gpt-5.2, gpt-5.3-codex, gpt-5.3-codex-spark, entre otros. Los no-codex son modelos generales, con un razonamiento potente pero muy lentos. Los codex son modelos ajustados para programación; en los modelos codex de gpt5.2-codex y anteriores, mis pruebas mostraban un razonamiento degradado, por lo que seguí usando gpt-5.2 a pesar de su lentitud exasperante. En cuanto salió gpt-5.3-codex lo probé de inmediato; el resultado real fue muy bueno, y ya es difícil decir si gpt-5.3-codex es lógicamente inferior a gpt-5.2, pero en velocidad ya aplasta a gpt-5.2, convirtiéndose en mi modelo principal de programación. Recientemente salió gpt-5.3-codex-spark; al principio decían que era extremadamente rápido, pero con puntuaciones bajas en las listas, así que lo ignoré por un tiempo. Pero al ver que se podía usar gratis en cursor, decidí darle una oportunidad; en las pruebas reales funcionó muy bien, sin ser tonto. Según la información que tengo, el razonamiento de 5.3-codex-spark es ligeramente inferior al de 5.3-codex, y su contexto es solo de 128K, pero suficiente para la mayoría de necesidades. La característica principal del modelo codex-spark es su “pereza”: se mueve un poquito solo cuando le das un golpe. En primer lugar, no puede ser el modelo de conducción de un agente; de hecho, su puntuación en agentes también es baja. No hace complementos fuera de las instrucciones, incluyendo arreglar lint, ejecutar pruebas, características no mencionadas ni todos pendientes. A diferencia de modelos como opus/sonnet que parecen sofisticados a primera vista, cavan muchos hoyos, refactorizan desde el inicio y traen problemas sin fin, creo que codex spark es un modelo amigable para programadores experimentados. No añade lo innecesario, sigue la mínima modificación; si ya tienes una planificación clara de funciones del producto, puedes probar codex spark. Mi humilde reflexión, bienvenidos los comentarios. El vibe coding es programación por ambiente; algunos dicen que permite entrar en flujo, pero creo que quienes lo mencionan no conocen la definición precisa de flujo. Un punto clave para entrar en flujo es que el propio pensamiento del desarrollador no debe interrumpirse; se necesita un modelo que primero no divague, segundo tenga objetivo concentrado y tercero responda a tiempo. Antes ningún modelo lo lograba; ahora codex spark quizá pueda ser ese modelo que ayuda al desarrollador a entrar en flujo.
