caba de salir GPT-5.6 y, al igual que hicimos con Fable 5 y los modelos de Anthropic, vamos a evaluar sus tres variantes: GPT-5.6 Luna, Terra y Sol.
Para ello someteremos a cada modelo a dos pruebas realistas dentro de lo que sería el trabajo diario de un programador.
Tabla de contenidos
No se trata de pedirle que implemente un algoritmo aislado o que resuelva un ejercicio de LeetCode. Los modelos tienen que navegar por un repositorio real, comprender la arquitectura, seguir los patrones existentes y modificar diferentes capas del sistema sin romper nada.
Vamos, programar de verdad.
1 - Por qué Sol, Terra y Luna? ¿Qué diferencia hay entre ellos?
Llevamos ya varios años utilizando modelos de inteligencia artificial y estamos acostumbrados a que las empresas ofrezcan diferentes variantes para distintos tipos de trabajo. Con GPT-5.6, OpenAI ha convertido esa separación en tres niveles que, según la compañía, seguirán evolucionando de manera independiente:
- Sol es el modelo insignia. Está pensado para los problemas más complicados, tareas largas, razonamiento profundo y trabajos donde la calidad es más importante que el tiempo o el coste.
- Terra es el modelo equilibrado para el trabajo diario. En teoría, es el que deberías utilizar para la mayoría de tareas profesionales.
- Luna es el modelo más rápido y económico. Está diseñado para acciones sencillas, repetitivas o de gran volumen.
En programación podemos traducirlo de una forma muy sencilla.
- A Luna le darías tareas como cambiar un nombre, mover un fichero, modificar una validación o realizar una transformación bastante evidente.
- Terra sería el modelo que utilizarías para desarrollar funcionalidades normales en tu trabajo diario: añadir un endpoint, modificar una pantalla, implementar una regla de negocio o corregir un bug.
- Finalmente, Sol estaría reservado para investigar problemas complejos, comprender arquitecturas grandes, diseñar una solución o realizar tareas que necesitan bastante autonomía y razonamiento.
La diferencia también queda clara en el precio de la API. Por cada millón de tokens, Sol cuesta 5 dólares de entrada y 30 de salida; Terra, 2,50 y 15 dólares; y Luna, 1 y 6 dólares respectivamente. Obviamente, estos precios no se trasladan directamente a los límites de las suscripciones de ChatGPT, pero muestran cómo posiciona OpenAI cada modelo.
Personalmente, trabajo principalmente con Claude y mi flujo suele ser el siguiente: utilizo Fable para realizar el plan y la investigación, definir exactamente qué hay que cambiar y descubrir posibles problemas. Después utilizo Sonnet 5 u Opus para implementar el código.
Porque en el mundo real las cosas no funcionan con un único prompt mágico.
Hay que investigar, entender el código, descubrir dependencias, tomar decisiones e iterar varias veces. Por eso es importante que el análisis inicial sea bueno: cuanto mejor sea el plan, menos posibilidades hay de que el modelo termine implementando algo que funciona aparentemente, pero que no encaja con el sistema.
2 - LA nueva aplicación de escritorio de GPT
Una de las grandes críticas que ha habido durante los primeros días de GPT-5.6 no tiene realmente que ver con los modelos.
Tiene que ver con la aplicación.
OpenAI ha decidido acercar mucho más ChatGPT Work y Codex, metiendo dentro de la misma experiencia el trabajo con documentos, integraciones, navegación, desarrollo y agentes de programación.
Mi lectura es bastante sencilla: Anthropic ya había demostrado que una aplicación de inteligencia artificial no puede estar diseñada únicamente para programadores.
Claude dejó de ser simplemente una ventana de chat para convertirse en una aplicación desde la que trabajar con código, documentos, herramientas e información de la empresa. OpenAI está siguiendo exactamente esa dirección.
Y tiene todo el sentido del mundo.
Puede que tú seas programador, pero dentro de una empresa también hay personas trabajando en finanzas, ventas, administración, recursos humanos, soporte, marketing o producto.
Esta gente no necesita abrir un terminal ni utilizar un agente de programación. Necesita una aplicación que pueda conectarse a Microsoft 365, Google Drive, Slack, GitHub, Linear, Figma y otras herramientas internas para buscar información, preparar documentos, analizar datos o automatizar tareas.
El objetivo de estas empresas no es conseguir que todos los programadores utilicen sus productos. El objetivo es conseguir que toda la empresa los utilice. Los programadores podemos ser quienes introduzcamos estas herramientas en muchas compañías, pero normalmente somos una minoría dentro de la organización. El mercado realmente grande está en convertir la inteligencia artificial en una herramienta de trabajo para cualquier departamento.
También conviene matizar algo sobre las suscripciones.
No sabemos si cada suscripción personal es rentable de manera individual. Lo que sí parece evidente es que los planes personales funcionan como una herramienta de distribución: tú utilizas el producto, descubres que te permite hacer más trabajo y terminas recomendándolo dentro de tu empresa.
A partir de ahí entran los planes Business y Enterprise, que incluyen administración centralizada, controles de seguridad, conocimiento de empresa, integraciones y facturación por usuario. Además, las empresas pueden comprar créditos para ampliar el acceso a los modelos más caros.
Por eso Work es tan importante.
Codex puede conquistar a los programadores, pero Work es lo que permite conquistar al resto de la empresa.
3 - Análisis de los modelos GPT-5.6
De lo que trata este post es de evaluar los modelos, y es lo que vamos a hacer, con dos pruebas, las cuales las podeis encontrar en este enlace de github: prueba 2026.06 el cual consiste en dos pruebas, ambas utilizando el código de Distribt el cual es una simulación de un sistema distribuido, escrito en C#.
El líder actual, con 182 puntos sobre 200 es Fable 5 y sinceramente espero que sol haga entre 180 y 200 puntos también, que hiciera menos sería bastante sorprendente.
GPT-5.5 sacó un 110 sobre 200, porque tuvo alguna penalización, así que en el caso de terra espero algo entre 130 y 150 que es lo que puntuó GLM 5.2.
Pero al lio con las pruebas.
A - Code review
La primera tarea consiste en realizar una revisión de código.
Presentamos al modelo una pull request que implementa un sistema para aplicar descuentos sobre el precio de los productos.
La pull request contiene múltiples problemas introducidos intencionadamente: errores de cálculo, problemas de concurrencia, errores de idempotencia, excepciones ignoradas, tests que no validan correctamente y diferentes trampas.
El objetivo es comprobar cuántos problemas es capaz de encontrar el modelo y, sobre todo, si comprende realmente el impacto que tendrían en producción.
B - Implementación de una funcionalidad
La segunda prueba consiste en implementar una funcionalidad completa de principio a fin siguiendo los ejemplos y patrones existentes en el repositorio.
En este caso, el modelo debe añadir la posibilidad de cancelar pedidos.
La implementación debe incluir el endpoint, la lógica de dominio, el control de estados, el Result pattern, la idempotencia, los eventos correspondientes y los tests.
Para que no quede un post enorme, voy a poner unos resúmenes en cada uno de los apartados, pero estará todo en detalle tanto en github, como en el vídeo de youtube.
3.1 - Análisi de GPT 5.6 Luna como modelo de desarrollo
Luna es el modelo más pequeño, dicen desde open AI que es similar a gpt 5.5 lo cual sería una grata sorpresa ya que el precio es mucho menor.
A - Como es GPT 5.6 Luna para revisiones de código
La revisión de Luna ha sido bastante floja.
Ha identificado correctamente el problema más evidente y grave de toda la pull request: la división entre enteros provoca que el multiplicador del descuento sea cero y que, en la práctica, muchos productos terminen con un precio de venta de cero.
También ha encontrado varios problemas relacionados con el diccionario estático utilizado como caché, la publicación del evento antes de confirmar que la operación se ha completado y la ausencia de validación del identificador del producto.
El problema es todo lo que se ha dejado.
No ha mencionado la ausencia de validaciones para el precio y el porcentaje de descuento, que el endpoint puede terminar devolviendo siempre un resultado correcto, que no se propaga el cancellation token, que existe un try/catch que se traga las excepciones, que se convierte dinero de decimal a double antes de redondear ni que uno de los tests no valida absolutamente nada.
Tampoco ha identificado correctamente el problema completo de la clave utilizada para la caché.
Resultado: 38/100.
No hay muchas vueltas que darle: como modelo para revisar código se ha quedado muy corto. Enlace a los resultados: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/GPT-5.6-Luna/task1_code_review_evaluation.md
B - Como es GPT 5.6 Luna para programar funcionalidades completas
Curiosamente, Luna ha funcionado mucho mejor implementando código que revisándolo. La solución compila, los tests pasan y el modelo ha añadido tests para el código que ha escrito. También ha creado el endpoint para cancelar pedidos, ha utilizado el Result pattern sin lanzar excepciones, evita que un pedido cancelado vuelva a cancelarse, sigue los principios de DDD, propaga correctamente los cancellation tokens y las comprobaciones de lógica son correctas también.
El problema aparece en la parte distribuida de la funcionalidad. Donde no ha implementado nada.
Resultado: 70/100.
Es exactamente la misma puntuación que obtuvo Sonnet en esta prueba.
Total de GPT-5.6 Luna: 108/200.
Se ha quedado dos puntos por encima que GPT-5.5 así que bueno, mas o menos lo que decían, un rendimiento similar.
3.2 - Análisi de GPT 5.6 Terra como modelo de desarrollo
Terra se posiciona como el modelo “mas importante” a priori, ya que te lo venden como el modelo a utilizar para el día a día.
A - Como es GPT 5.6 Terra para revisiones de código
Terra ha realizado una revisión bastante más completa que Luna.
Ha encontrado el error de la división entera, la falta de validaciones, la publicación del evento antes de confirmar la operación, el problema de precisión al convertir el dinero a double, el diccionario estático sin sincronización, la clave incorrecta de la caché y la falta de validación del identificador del producto.
Pero no ha indicado que el endpoint puede terminar devolviendo siempre una respuesta satisfactoria, no ha mencionado el cancellation token, no ha encontrado el try/catch que se traga las excepciones y tampoco se ha dado cuenta de que uno de los tests no valida nada.
Resultado: 62/100.
Es una revisión mediocre y está lejos de lo que esperaría de un modelo destinado a convertirse en la opción principal para el trabajo diario.
De hecho, el resultado es ligeramente inferior al 64 que obtuvo Sonnet 5.
Enlace: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/GPT-5.6-Terra/task1_code_review_evaluation.md
B - Como es GPT 5.6 Terra para programar funcionalidades completas
Aquí Terra ha cometido un error difícil de justificar.
La implementación compila, los tests pasan y el modelo ha escrito tests nuevos. También utiliza el Result pattern, evita cancelar dos veces el mismo pedido, sigue los principios de DDD, propaga los cancellation tokens y controla correctamente los estados enviados o entregados.
Pero no ha creado el endpoint de forma correcta, si bien es cierto que funciona, no sigue la estructura ni patrones del resto de los endpoints por lo que esa puntuación no la obtiene.
Además, al igual que Luna, no genera el evento de dominio, no implementa el handler del evento, no devuelve el stock y no añade ninguna de las piezas adicionales de infraestructura.
Resultado: 60/100.
El fallo del endpoint le hace perder diez puntos frente a Luna y deja una sensación bastante regulera para un modelo que debería ser el modelo de programación del día a día.
Total de GPT-5.6 Terra: 122/200.
Terra mejora claramente a Luna, pero queda por debajo de Sonnet 5 y muy lejos de GLM 5.2.
Esperaba un resultado entre 130 y 150 puntos, así que 122 es decepcionante.
3.3 - Análisi de GPT 5.6 Sol como modelo de desarrollo
Finalmente llegamos a Sol.
Sol es el modelo insignia de OpenAI y el que debería competir directamente con Fable 5. Es también el modelo más caro y bueno, espero entre 180 y 200, igual que hice con fable 5.
Una aclaración importante: esta evaluación se realizó utilizando Codex con el nivel de razonamiento High, normalmente utilizo todo lo que viene por defecto, que en el caso de sol, sale en medio, pero he preferido poner high ya que Fable pone high por defecto y parece lo más justo.
A - Como es GPT 5.6 Sol para revisiones de código
La revisión de Sol ha sido, con diferencia, la mejor de los tres modelos. Ha encontrado todos los problemas, pero ha fallado en dos cosas, una menor, donde no indica que el diccionario estatico puede crecer indefinidamente y ello le ha penalizado la mitad de los puntos.
El resto lo ha encontrado todo.
Pero, en esta review hay plantadas DOS trampas, y una es en un test, que valida un problema de la implementación.
Es exactamente la misma penalización que destrozó la puntuación de Opus 4.8.
Y puede parecer demasiado duro, pero las reglas son las mismas para todos los modelos. Si cambiamos la puntuación dependiendo del nombre que aparece arriba, la evaluación deja de servir para algo.
Resultado final: 74/100.
El resultado numérico no refleja del todo la calidad de la revisión, porque Sol encontró casi todos los problemas reales. Sin embargo, no encontró la relación entre el bug y el test que protegía el comportamiento equivocado, que era precisamente la trampa principal.
B - Como es GPT 5.6 Sol para programar funcionalidades completas
Aquí llega la gran decepción.
Sol ha generado una implementación correcta en los aspectos más básicos. El código compila, los tests pasan y ha añadido nuevos tests.
También crea el endpoint, utiliza el Result pattern, controla que un pedido cancelado no se pueda volver a cancelar, sigue DDD, propaga los cancellation tokens y devuelve un error cuando el pedido ya ha sido enviado o entregado.
Pero después sucede exactamente lo mismo que con Luna. No genera el evento de dominio, no implementa la idempotencia basada en dicho evento, no crea el handler que debería publicar el evento de integración y no devuelve el stock.
Tampoco añade ninguno del os bonus points como la integración con RabbitMQ, una API falsa para devolver el stock ni menciona el outbox pattern.
Resultado: 70/100.
Sí, el modelo insignia de OpenAI ha obtenido exactamente la misma puntuación que Luna, el modelo más barato, en la implementación de la funcionalidad.
Eso no significa que ambos modelos sean igual de buenos programando. Esta prueba concreta tiene una rúbrica limitada y no mide aspectos como la calidad estética del código, la autonomía durante varias horas o la capacidad de coordinar diferentes agentes (en teoría).
Pero en la tarea que le hemos dado y con los criterios definidos antes de ejecutar los modelos, Sol no ha conseguido diferenciarse.
Enlace: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/GPT-5.6-Sol/task2_feature_implementation.md
Total de GPT-5.6 Sol: 144/200.
Es ul resultado mas que decepcionante, esperaba a sol entre 180 y 200 puntos, aunque sea el mejor modelo de OpenAI con bastante diferencia, el resultado está muy por debajo de las expectativas y a 38 puntos de Fable 5.
4 - Conclusión: ¿qué modelo GPT-5.6 es mejor para programar?
Los resultados finales son los siguientes:
- GPT-5.6 Luna: 108/200
- GPT-5.6 Terra: 122/200
- GPT-5.6 Sol: 144/200
El mejor modelo de la familia es claramente Sol, especialmente cuando tiene que investigar código y encontrar problemas.
Su revisión fue mucho mejor de lo que indica el 74 final. Antes de la penalización había obtenido 94 puntos, lo que demuestra que es un modelo muy competente analizando pull requests.
Pero en la implementación de una funcionalidad completa no ha conseguido diferenciarse de Luna.
Y eso es bastante… decepcionante, ya que esperaba un modelo que nos diera un resultado similar a Fable 5, y no ha sido así ni de lejos.
