¿Qué pasa cuando dejas a GPT‑5.6 Sol Ultra trabajar durante una hora en un proyecto real?
En este vídeo ponemos a prueba Codex desde cero con un encargo concreto: construir una experiencia web 3D interactiva para entender la relación entre el Sol, la Tierra y la Luna.
No es una demo de dos minutos. Vemos cómo se organiza el trabajo, qué subagentes aparecen, qué entrega al final y qué partes todavía necesitan criterio humano.
Qué se pone a prueba
El proyecto arranca vacío y el encargo pide una simulación didáctica de Sol, Tierra y Luna: día y noche, fases lunares, eclipses y controles para explorar la escena.
Antes de lanzar la tarea aparece una lección útil: un proyecto sin Git no se trata como un worktree. Al cambiar a un proyecto local, Codex puede empezar a trabajar con el contexto correcto.
El experimento se ejecuta con GPT‑5.6 Sol Ultra, velocidad estándar y un prompt detallado con el resultado esperado y requisitos técnicos.
Qué cambia con Sol Ultra
Durante la ejecución se ve una pestaña de subagentes: Codex divide el trabajo en tareas paralelas y después reúne los resultados en una única implementación.
En esta prueba llegan a verse hasta cuatro líneas de trabajo: lectura del repositorio, definición de la experiencia educativa, implementación de la capa 3D y comprobación de la interfaz en móvil.
La clave no es que el modelo “haga todo solo”, sino que mantiene un plan de trabajo visible y permite inspeccionar cada frente mientras avanza.
Cómo se reparte el trabajo
Repo audit: revisa el punto de partida y el contenido disponible.
Experiencia educativa: decide cómo convertir el sistema solar en una interfaz que explique, no solo que se vea bonita.
Implementación 3D: monta la escena con React Three Fiber y los controles de cámara.
QA móvil: comprueba que el resultado se pueda usar también en una pantalla pequeña.
Es un buen ejemplo de cómo un proyecto amplio puede partirse en piezas comprobables en lugar de resolverse como una única caja negra.
El resultado después de 1 hora y 1 minuto
Al terminar, Codex entrega una experiencia 3D accesible por URL: se puede rotar la cámara, centrar la vista en cada cuerpo y recorrer las secciones de día y noche, fases y eclipses.
También incorpora controles de velocidad, explicaciones para las fases de la Luna y una vista general para explorar la relación entre los tres cuerpos.
La parte más interesante no es solo que aparezca una escena 3D: en un único encargo se ha construido una aplicación navegable, con estado, controles e intención didáctica.
La parte que sí hay que revisar
La prueba deja claro por qué no conviene confundir un primer resultado con un producto terminado. Las texturas de la Tierra y del Sol son planas, la velocidad de rotación necesita ajuste y algunos botones quedan pequeños en móvil.
Eso no invalida el resultado. Marca el siguiente paso: revisar visualmente, probar en el dispositivo objetivo, priorizar correcciones y volver a iterar con instrucciones concretas.
Con IA, el trabajo de construcción se acelera. El criterio para detectar errores, accesibilidad y acabado sigue siendo tuyo.
Qué coste tuvo la prueba
La ejecución completa tarda 1 hora y 1 minuto. En la cuenta mostrada en el vídeo, el uso del bloque de cinco horas pasa del 99% al 92%.
Es una referencia de esa tarea, de ese modelo y de ese plan —en el vídeo se indica una suscripción de 200 dólares—, no una estimación universal. El consumo cambia según la complejidad del encargo, el contexto y las iteraciones.
Qué aprender de esta prueba
Empieza por un resultado verificable, no por una petición vaga.
Deja claro el contexto técnico y el criterio de éxito antes de lanzar el trabajo.
Observa el plan y las tareas paralelas para entender qué está haciendo el agente.
Valida el resultado en escritorio y móvil antes de darlo por bueno.
Usa la primera versión como base para iterar, no como final automático.
La promesa útil no es “crear una app con un prompt”. Es poder pasar antes de una idea a algo que puedes inspeccionar, probar y mejorar.