Comparativa Actualizada de Modelos de IA para Programación: GPT Codex 5.3 vs Opus 4.6

Durante las dos últimas semanas hemos visto como el ecosistema de herramientas para programar con inteligencia

artificial ha vuelto a evolucionar con la salida de nuevas herramientas para programar, como la nueva aplicación de

escritorio de Codex, nuevos modelos insignia como el nuevo Opus 4.6 Tropic o la nueva versión GPT Codex 5.3 de Open

AI. Y novedad es que lo que buscan es sorprender como el nuevo GPT Codex Spark, que es una versión de Codex capaz

de generar tokens a una velocidad de vértigo a más de 1000 tokens por segundo para programar a toda velocidad, a una

velocidad tan rápida como la de los anuncios que estamos viendo, que se suceden de una forma precipitada y que

nos obliga pues a tener que sacar tiempo para intentar evaluar cuál de todas estas herramientas pues a día de hoy es

la mejor para hacer esta labor de programación a la que todos nos enfrentamos. ahora sí o sí en 2026

acompañados de la inteligencia artificial. Y por eso os traigo el vídeo de hoy, donde siguiendo la estela de lo

que ya hicimos hace un par de meses, vamos a estar comparando pues los dos modelos insignia que tenemos a la hora

de desarrollar un proyecto en igualdad de condiciones sobre un tiempo limitado, algo que no solo nos va a permitir

comparar en igualdad de condiciones a ambos modelos, sino también poder comparar los resultados con lo que

hicimos hace unos meses. Y antes de comenzar, vamos a conocer a los contrincantes. Por un lado, presentamos

a GPT 5.3 tres Codex modelo salido hace un par de semanas por parte de Open AI que evoluciona pues lo que ya GPT 5.2

Codex venía ofreciendo y donde la principal mejor y es lo que vamos a estar comentando, es que consiguen pues

reducir esos tiempos de generación que hacían a Codex un modelo más incómodo para trabajar. Y yo en mi caso, durante

toda esta pausa de Navidades donde todo el mundo probó Opus 4.5 y comprobó la evolución que habían tenido los modelos

de generación de código, pues yo estuve trabajando mucho con Codex 5.2 en problemas de deep learning, de

planteamiento de arquitecturas, intentar encontrar soluciones a partir de unos datos de cómo entrenar modelos de

inteligencia artificial. Ahí me encontraba que Opus 4.5, a pesar de ser un modelo más ágil, más rápido, pues me

daba soluciones más erráticas, pues a veces funcionaban, a veces no. donde Codex pues me podía hacer one shot

muchas de las soluciones que yo estaba buscando. Eso sí, a costa de la velocidad de generación, lo acabo de

decir, Opus siempre se ha sentido un modelo mucho más ágil que Codex, donde Codex muchas veces se quedaba pensando

40 minutos, 50 minutos, una hora para darte una solución. Y aquí es donde está el principal de mejora que Codex ahora

ofrece una mayor eficiencia a la hora de entregar esa inteligencia artificial haciendo un menor uso de tokens de

tiempo de generación. Así podemos ver que en esta gráfica, quizás la más importante de lo que han presentado,

pues para un benchmark como SWBCH Pro, pues vemos que el modelo GPT5.3 Codec consigue un desempeño similar a lo que

conseguíamos antes, pero con un uso de tokens mucho menor, ¿vale? Esto es lo que nos va a permitir pues tener una

mayor agilidad trabajando con el modelo. Y las mejoras no son solo de velocidad, también hay mejoras en inteligencia, en

capacidades agénticas. El modelo es un mejor modelo y eso se agradece, pero como digo, pues donde más he notado yo

la ventaja de trabajar con Codex es en este aspecto de sentirlo un modelo mucho más ágil de lo que teníamos antes. De

hecho, Open AI lo ha hecho muy bien en este caso porque la mejora no solo viene a nivel de que el modelo sea más rápido

a la hora de generar estos tokens, sino también en la propia usabilidad del modelo. Hay una diferencia que para mí

es fundamental y la vamos a comprobar aquí dentro de la propia aplicación de Codex en escritorio. Voy a generar pues

un nuevo hilo y voy a seleccionar primero el modelo 5.2 Codex, el que teníamos hasta hace un par de semanas y

le voy a pedir que bueno, me analice los puntos de mejora de este proyecto, un prompt normal y vamos a dejar que

trabaje. Vamos a seleccionar el mismo prompt y vamos a lanzar de nuevo otro hilo por aquí. Vamos a ahora sí el

modelo actual 5.3 Codex y vamos a lanzar el mismo prompt para que veáis cuál es la diferencia de la que estamos

hablando. Fijaos que en este caso el modelo está trabajando. La versión 5.2 pues empieza a analizar archivos,

empieza a explorar pues todo el proyecto que tengo planteado, empieza a leer el Redmi, el startup, pues empieza a leer

todos los scripts y esto es trabajo que él está haciendo por su cuenta sin entrar a dialogar conmigo. Por el

contrario, la versión 5.3 3 incluye una mejora agéntica que tiene que ver con que el modelo se va explicando mucho más

en su proceso de trabajo. Voy a hacer una revisión técnica holística del repositorio para detectar mejoras de

arquitectura. Explora un archivo. Vale, ya tengo un mapa general en un monorrepo ta ta. empieza a ser un proceso en el

que nos va volcando información, nos va dando feedback y por tanto nos tiene más conectado en este proceso de generación

de trabajo donde yo como humano pues no me voy a Twitter para ver novedades, sino que me quedo viendo lo que el

modelo me está contando y puedo revisar mucho mejor cuál es su proceso. Es una tontería, pero esto hace que el modelo

se sienta mucho más rápido, porque no es solamente yo te doy un prompt y ponte a trabajar y yo me desconecto 30 minutos o

40, sino que en este caso el modelo nos hace partícipe de su propio trabajo. Ahora reviso el frontend y script de

ejecución despliegue para identificar mejoras. Ya identifiqué varias áreas en código config. Se siente mucho mejor,

con lo cual 5.3 Codex añade estas mejoras agénticas a la par que mejoras en inteligencia y agilidad. Y por otro

lado tenemos a nuestro otro contraincante que es Cloud Opus 4.6. Y fijaos qué interesante cómo podemos

detectar la importancia que le están dando los grandes laboratorios a esta batalla en el área de la programación.

Cuando vemos empresas como Antropic publicando una mejora de versión, la versión 4.6 frente a la 4.5, presentando

pues por primera vez al modelo Opus antes que la versión Sonet, que suele serlo habitual, o por ejemplo a Open AI

presentando la versión 5.3 Codex antes que la versión general, pues 5.3. se notan las prioridades, pero aquí

Antropic presenta pues Opus 4.6 y tenemos que darnos cuenta que a diferencia del modelo de Open AI, este

no es solamente un modelo de programación, no es la versión Codex, sino que en este caso esta actualización

os afecta a todos, tanto si programáis como si no programáis. Este es un modelo general. Aquí Antropic no hace

distinción de modelo de programación y modelo genérico, con lo cual pues felicidades para todos, tenéis nuevas

capacidades y la mejor en capacidades la vemos aquí en la tablita de los números mágicos, donde comparamos modelos pues

como Opus 4.5 con 4.6, unos 2 3 meses de diferencia, pues vemos que hay cierta mejora en capacidades agénticas de

programación, de uso de computador. Esto, por ejemplo, afecta al uso de herramientas como cowork de poder

controlar vuestro ordenador y ejecutar tareas agénticas que la IA va a resolver. Pues en este caso vemos que

este modelo va a hacer funcionar mejor a herramientas como cowork, lo cual está muy bien y vemos saltos abruptos quizás

en donde eh los modelos Opus anterior estaban empezando a fallar, que es en este razonamiento más general, pues en

benchmarks tan importantes como el Humanity Last Exam, pues vemos un salto de 10 puntos porcentuales, que dada la

dificultad de este benchmark es un salto bastante grande o benchmarks como Arc Agi, donde quizás vemos el mayor salto

duplicando casi su puntuación anterior, la de Opus 4.5, pero ya lo sé, estos números a vosotros ya no os dicen nada

porque lo que queréis realmente es ver como en la práctica pues este modelo se desempeña y por eso vamos a trabajar en

el siguiente problema que ya planteamos, como he dicho antes, hace un par de meses. Estamos trabajando con un

problema donde yo tengo un reloj, pues de una marca concreta, un reloj deportivo al que yo me gustaría

conectarme y poder traerme todos los datos que el reloj registra y visualizarlos en un dashboard, que es lo

que vamos a implementar. Este es un problema que, como ya vimos, incluye un par de trampas que pueden ralentizar el

desempeño de los modelos. pues por ejemplo, encontrar una solución no oficial para conectarte a la API,

implementar un sistema de login que incorpore pues la doble autentificación, que es lo que requiere para poder

loguearse. Bueno, diferentes cosas que vamos a evaluar en una sesión de programación de 30 minutos para cada

modelo. La idea era ver hasta dónde me permitían llegar cada uno de estos modelos trabajando durante 30 minutos

con el mismo prompt inicial. Y con Codex he de decir que bueno, pues este experimento comparado con la vez

anterior en el que lo intentamos, sin duda me ha permitido llegar más lejos. Sí, y esto lo puedo decir porque Codex

cometió el mismo error entre comillas que la vees anterior. No es tanto un error, pero sí una preferencia del

resultado final que fue basarse en la tecnología Streamlit para poder hacer este dashboard que a mí a nivel estético

pues me gusta muy poquito. Y vemos que la versión 5.3 de Codex con este mismo prompt pues ahí donde versiones como

Opus trabajan con un stack mucho más moderno y visualmente más atractivo, pues aquí la versión 5.3 también comete

ese mismo error. Aún así, esto no es problema porque en este caso dentro de los 30 minutos si me ha dado tiempo a

que Codex implemente una versión end to end sin atragantarse en ninguna de las trampas haciendo bien el login, trayendo

bien los datos desde la API y dándome margen suficiente para decirle, "Oye, no me gusta nada este Streamlit. búscame eh

una versión de frontend que se acerque más a lo que estoy buscando y por tanto reimplementar todo este front para

acabar con un resultado como este. El resultado final es este dashboard de aquí que me gusta bastante. Tiene,

bueno, pues mucho de la estética de Codex, estas cajitas, esto ya lo tengo muy bien identificado como la estética

de de este modelo, pero ciertamente es un resultado que si lo comparamos con lo que conseguimos hace 3 cu meses con la

versión de Codex, creo que 5.1, uno, pues estamos ante un resultado que en este caso dentro de los 30 minutos que

hemos establecido cumple muy bien con los objetivos que estábamos buscando. Tenemos un dashboard funcional donde

podemos sincronizar con datos, podemos traernos datos y guardarlos en una base de datos que que tiene implementada.

Tenemos visualizaciones, podemos ver diferente información, sueños por fases de hora, podemos ver los datos en crudo,

no está mal, no es quizás la interfaz más moderna que me podría imaginar, pero en general sí podemos decir que este 5.3

Codex pues ha conseguido resolver muy bien la tarea dándole tiempo dentro del slot de tiempo de 30 minutos a

implementar una versión que a mi gusto pues no se acercaba a lo que estaba buscando y generando esta nueva versión

como hemos podido ver, un modelo 5.3 tres Codex, que hay que decir se siente mucho más ligero, mucho más ágil y

también que no sacrifica velocidad por h rigor a la hora de trabajar. Cuando vas observando las trazas de razonamiento,

vas viendo que el modelo, en la mayoría de pasos que va dando, pues va generándose test, va evaluando si

realmente se ha cumplido o no se ha cumplido los objetivos que estaba programando. En general, el feedback con

GPT 5.3 es muy bueno. Y ahora sí, turno de Opus 4.6 Tropic, que si, bueno, hemos dicho que GPT 5.3 cometía los mismos

errores que su hermano menor de hace unos meses, tengo que decir que Opus 4.6 le ocurre lo mismo. vuelve a caer en las

mismas trampas, en los mismos vicios, que el modelo que estuvimos evaluando hace unos meses, que conseguía

implementar bastante ágil proyecto completo, tanto el frontend como el backend, conseguía llegar a esto en los

primeros 5 o 10 minutos dándome una sensación de que oye, pues tengo 20 minutos para introducir mejoras y

mejoras y mejoras, pero sin embargo con el problema de quedarse atascado con la trampa de la autentificación,

posiblemente he perdido unos 10, 12 minutos intentando iterar con problemas de login donde, bueno, yo sé que el

problema es que no está encontrando esta doble autentificación, pero Opus no encontraba este problema, no conseguía

incluso establecer pues logs que le dieran esta información de lo que estaba faltando y por tanto perdiendo mucho

tiempo donde el otro modelo pues realmente conseguía resolverlo sin problemas. Y el resultado es este

dashboard de aquí, un dashboard que a mi gusto es más atractivo, más moderno, más cercano a lo que yo estaba buscando que

lo que nos ha ofrecido GPT 5.3 Codex y que en este caso pues da pena que el modelo se haya atragantado tanto en

aspectos técnicos que no nos han permitido avanzar tan rápido, tan ágil durante la implementación. Pero bueno,

el resultado al final lo tenemos aquí. Tenemos la la información, tenemos data points, pues todo funcionando

correctamente y vemos como con ambos modelos, pues al final hemos conseguido un resultado bastante competitivo y

donde no hay tanta diferencia entre los resultados de los modelos como pudo haber en la comparación anterior. Ha

pasado una cosa muy interesante, fijaos, y es que le he pedido eh al modelo que bueno, que lanzara la aplicación, ¿vale?

Simplemente le he dicho, "Lanza la aplicación." Y ha terminado de lanzar la aplicación y me acabo de dar cuenta que

mientras os estaba hablando me ha actualizado el dashboard de nuevo, queriendo decir esto que me ha

implementado cosas sin mi permiso. Fijaos, yo le he pedido que lance la aplicación, la ha lanzado y me dice,

"Bueno, mientras tú la testeas, voy a empezar a implementar los las mejoras profesionales que estaban pendientes,

que esto venía del último prompt que yo le lancé, pero que ya se salía dentro de los 30 minutos de trabajo. Y no sé si

tomarme esta proactividad como algo a criticar. Al final yo solo te he pedido que lances la aplicación, no te he

pedido que me estés modificando el código ahora, así que todo este trabajo que has hecho aquí extra, pues la verdad

que bienvenido es, pero no te lo he pedido. Y ojo, eh, que sigue trabajando el Este está sacando, está

intentando sacar ventaja eh, en la competición eh fuera de fuera del reloj. Y bueno, si pensabas que la competición

se acababa aquí, tengo que decirte que tenemos un nuevo contrincante de última hora, que es el modelo 5.3 Codex Spark,

un modelo presentado por Open AI la semana pasada. en colaboración con Cerebras, la compañía de procesadores

que consigue ejecutar modelos de inteligencia artificial a una velocidad de inferencia superior de la que estamos

acostumbrados. En este caso, logrando con una versión destilada más pequeña del modelo 5.3 Codex, por tanto una

versión menos inteligente, tiempos de generación de 1000 tokens por segundo. Esto es rapidísimo y entra perfecto en

esta competición porque nos va a permitir observar si este boost de velocidad en estos 30 minutos de

implementación sacrificando esa parte de inteligencia nos deja con un mejor o peor resultado que su hermano mayor 5.3

Codex. El modelo es 5.3 Codex Spark y está solo disponible para usuarios Pro, es decir, la suscripción de $200 de Open

AI. Pero bueno, es una funcionalidad que todavía está en research preview, que lo están probando y que sabemos que a la

larga pues acabará llegando para todos. Y vamos a verlo. Tengo un reloj Garmin y quiero poder extraer y visualizar de

forma sencilla todos sus datos en dashboard propio. Lanzamos el prompt y vamos a ver los tiempos de velocidad que

tiene este modelo. Fijaos como a la hora de generar texto es rapidísimo y donde vamos a ver que se va a frenar más, pues

va a ser la parte de leer archivos y sobre todo tener que mandarlos a los servidores de Open AI y descargar la

información. Pero cuando se trata de generación, el modelo, como podéis comprobar aquí, vuela. Eso sí,

recordemos, sacrificando inteligencia, lo cual va a ser de este reto algo bastante interesante. Vale, muy

rápidamente nos ha implementado este dashboard y ahora estamos teniendo problemas de sincronización. Esto ha

ocurrido solamente en un minuto de implementación, lo cual pues bastante bastante bien, pero todavía hay mucho

trabajo que resolver, no podemos cantar victoria. Y es cierto que me estoy encontrando con

los problemas habituales, pues tengo que superar el problema de login y todo esto, pero claro, pedirle de repente,

"Oye, hazme una pantalla de login", se hace super práctico porque es que lo resuelve en 20 segundos, 30 segundos. Te

tiene implementada la app y el backend del front, todo. Y tiempo, un desastre.

Esto viene a constatar lo que yo ya había comprobado haciendo pruebas. en privado. Y es que este modelo, a pesar

de ser rapidísimo, increíblemente rápido, pues está tan destilado, es menos inteligente, que te mueves más

rápido hacia más errores y errores y errores que no consigues solucionar, haciendo que tu ratio de errores por

tiempo pues sea mayor. En este caso concreto, en 30 minutos hemos conseguido una aplicación como esta, donde hemos

perdido mucho tiempo de nuevo intentando sortear el problema del login hasta el punto de que ya hemos conseguido que la

propia API de Garmin diga, "Oye, eh, time out, ya no quiero más intentos, me estáis spameando." Así que le he tenido

que pedir que me acabe implementando una versión con datos falsos, con datos demos, que nos genera un dashboard como

este, pero ya digo, tras muchas peleas con el sistema iterando, iterando sobre errores que GPT 5.3 3 Codex velocidad

normal nos resuelve a la primera. Luego hemos conseguido un diseño que está muy alejado de lo que los modelos actuales

pueden implementar, que yo puedo entender que one shot pues los modelos tengan un vicio estético para caer sobre

ciertos patrones en la interfaz, pero cuando ya te pido que lo cambies, que lo mejores, te doy pautas concretas sobre

lo que quiero tocar y reiteras, reiteras, reiteras con los mismos errores, pues de nuevo nos estamos

moviendo muy rápido hacia pues no conseguir el resultado que queremos. Con lo cual, ¿cuál es el mejor modelo para

trabajar? Pues no podría daros una conclusión cerrada. Puedo deciros cuál es mi preferencia actual, que es el

modelo 5.3 Codex normal. He estado trabajando mucho con él en las últimas semanas. he podido implementar pues una

herramienta como esta que veis aquí, pues una herramienta que yo voy a usar para mi producción interna de trabajo

con un montón de funcionalidades y donde lo más impresionante y de lo que más orgulloso estoy es que en dos tardes me

he podido hacer un editor de vídeo plenamente funcional con el que puedo trabajar y que puedo incorporar

funcionalidades que para mí son muy útiles en mi día a día y que herramientas como Premiere no me ofrecen

actualización tras actualización. Pues aquí yo puedo hacer un diseño perfecto de las herramientas, puedo incorporar eh

funcionalidad de inteligencia artificial y como digo, todo esto está implementado con Codex en el navegador tras dos tres

tardes de vive coding y no más. Y la verdad que el resultado pues es bastante bueno. Y en este caso digo GPT 5.3

Codex, pero también seguramente Opus 4.6 me hubiera dado este acabado. La conclusión de esta última remesa de

modelos es que creo que ambos han conseguido con acierto aproximarse a las ventajas de su competidor, teniendo un

Opus 4.6 que sacrifica un poco de esa agilidad que ya tenía para convertirse en un modelo más competente. Y por el

otro lado, y quizás lo que más pues el usuario habitual de herramientas como Codex va a valorar es que 5.3 Codex es

un modelo que se siente mucho más ligero, mucho más rápido y que no sacrifica parte de esa inteligencia que

lo hace tan especial. ¿Cuál elegir? En este caso creo que no hay tanta diferencia, así que si tenéis un

favorito podéis seguir con él, ya que gran parte de los beneficios que podéis sacar de estos modelos pues vienen más

dado de saber utilizar pues todo lo que acaba afectando en el uso de trabajo diario, tanto técnicas de prompting como

skills, como todas estas funcionalidades que tienen los modelos y estas pequeñas diferencias de los modelos bases, pues

no van a marcar tanto la diferencia. Lo que sí puedo recomendar es que todavía Codex Spark eh no lo utilicéis. No hace

falta la inversión de $200 de una suscripción pro para intentar acceder a un modelo que es mucho más rápido porque

por ahora falla demasiado. Sí me interesa que os quedéis con la tendencia. Con que este modelo a día de

hoy es muy rápido, pero muy tonto, pero dentro de 6 meses, 12 meses, este va a ser posiblemente el ritmo de generación

de código con el que vamos a estar trabajando todos. Y con esta idea es como entonces tenemos que empezar a

ajustar expectativas del futuro de la programación que se viene en 2026. Ahora sí, con esto cerramos el análisis de

hoy. Si te ha gustado el vídeo, no dejes de compartirlo, dadle like, comentad abajo cuál es vuestro modelo favorito.

Os dejo por aquí un par de vídeos más que podéis ojear muy interesantes. Y chicos, chicas, suscribíos al DOTS SVAP

para estar actualizado con todas las novedades de inteligencia artificial que ocurran en las próximas semanas. Coao.