Después de varios días probando GPT 5.6 dentro de Codex, mi conclusión es bastante clara: en frontend me sorprendió de verdad.
No lo digo desde la emoción del primer día ni desde una demo bonita hecha para impresionar. Lo digo después de usarlo en trabajo real, probándolo con una tarea que me importa mucho: replicar diseños de alto nivel visual y convertirlos en sitios funcionales, bien estructurados y con una lógica más cercana a una implementación profesional que a una simple maqueta improvisada.
Y acá está el punto importante. Muchas herramientas pueden generar algo que “se ve más o menos bien”. Pero una cosa muy distinta es tomar una referencia visual, interpretar el estilo, separar correctamente los elementos, construir assets independientes, respetar una estructura HTML razonable y entregar una web que funcione.
Con GPT 5.6 en Codex sentí que ese salto se volvió mucho más real.
Tabla de contenido
- 🚀 Qué cambió en Codex y por qué importa
- 🧠 Lo que quise probar realmente
- 🗾 Primer experimento: una landing con estética japonesa
- 🎨 No quedó igual, y eso está bien
- 🧩 La diferencia entre una demo bonita y un frontend útil
- 🛠️ Mi método mejoró porque el modelo ahora resuelve más pasos
- 📱 El caso Japón: qué hizo bien exactamente
- 🍷 Segundo experimento: una web de vinos más compleja
- ✅ Lo que más me gustó de la web de vinos
- ⏱️ Tiempo de ejecución versus calidad entregada
- 🏗️ Por qué separar assets sigue siendo clave
- 💡 Mi opinión honesta: hoy es la mejor herramienta que estoy usando para esto
- 💳 El plan que uso y por qué me da libertad para probar
- 🔍 ¿Es mejor que otras alternativas? Mi respuesta es más simple
- 🧪 Lo que estas pruebas sí demuestran
- 🖼️ Trabajar desde una referencia sigue siendo una ventaja enorme
- 🌐 Si quieres mejorar prompts, aprender el flujo o trabajar conmigo
- 📚 Qué haría después de generar una web así
- 🧭 Mi conclusión final sobre GPT 5.6 en Codex
🚀 Qué cambió en Codex y por qué importa
Codex no está en el mismo punto en el que estaba hace poco. La experiencia se siente más integrada con el ecosistema de ChatGPT, y eso importa porque ya no da la sensación de estar usando una herramienta separada, aislada o secundaria. Todo se está unificando más.
Se nota una dirección clara: juntar capacidades de conversación, trabajo técnico y ejecución dentro de un mismo entorno. Y para quienes trabajamos construyendo productos, prototipos o sitios, eso tiene bastante valor. No se trata solo de “preguntarle cosas” al modelo, sino de usarlo como una pieza activa del flujo de producción.
En mi caso, la parte que más me interesaba evaluar no era la versión más general o más simple de uso. Lo que quería era ver cómo se comporta GPT 5.6 específicamente en Codex cuando le pides trabajo de frontend con un estándar visual alto.
Porque una cosa es que un modelo sea bueno respondiendo. Otra cosa es que sea bueno construyendo.
🧠 Lo que quise probar realmente
Mi prueba fue bien concreta. No me interesaba hacer benchmarks raros ni pasar horas acumulando mini tests sin contexto. Quería comprobar algo muy práctico: si el método que yo ya venía usando para crear webs animadas, webs premium y experiencias visuales más cuidadas podía subir de nivel con GPT 5.6.
Ese método normalmente implica varios pasos:
- Partir de una referencia visual clara.
- Interpretar la composición general del diseño.
- Separar fondo, textos, UI y distintos assets.
- Reconstruir cada parte de forma independiente.
- Integrarlo todo en una web funcional.
Antes, gran parte de ese trabajo la hacía en más etapas. Ahora, usando Codex con un skill que fui preparando para este tipo de tareas, noté que GPT 5.6 puede encargarse de mucho más del proceso completo.
Y eso cambia bastante el panorama.
🗾 Primer experimento: una landing con estética japonesa
La primera prueba la hice con un diseño que tenía una onda japonesa muy marcada. Un look editorial, atmosférico, con imágenes potentes, jerarquía tipográfica grande y una composición bastante cuidada.
La idea era simple: tomar esa referencia y pedirle a Codex que la replicara.
No una copia exacta pixel por pixel, porque eso además de ser poco realista no siempre es el objetivo. Lo que me importaba era si entendía el lenguaje visual del diseño y si era capaz de reconstruirlo con lógica de frontend de verdad.
Le entregué la referencia y lo dejé trabajar solo.
El resultado tardó 14 minutos.
Ese tiempo, para este tipo de tarea, me parece completamente razonable. De hecho, bastante bueno. Sobre todo porque no estaba solamente armando una pantalla estática, sino generando componentes, imágenes separadas y la estructura del sitio.
🎨 No quedó igual, y eso está bien
Algo que conviene decir de frente: el resultado no quedó idéntico al original.
Pero eso no fue lo interesante.
Lo interesante fue que entendió muy bien la lógica detrás del diseño. Captó el fondo. Captó la sensación general. Captó que no debía resolver todo como una sola imagen plana, sino como una composición armada con piezas separadas.
Ese detalle cambia todo.
Cuando una IA “replica” un diseño pegando un screenshot como fondo, no está resolviendo frontend. Está maquillando el problema. En cambio, cuando separa elementos, crea assets por secciones, construye títulos reales, botones reales, formularios reales y mantiene una estructura HTML coherente, ya estamos hablando de otra liga.
Acá, por ejemplo, los textos eran texto real. El encabezado principal estaba construido como un h1. Las secciones tenían su estructura. El fondo y los elementos visuales estaban tratados como piezas independientes.
Ese enfoque es exactamente el que me interesa.
🧩 La diferencia entre una demo bonita y un frontend útil
Hay una diferencia enorme entre algo que “se ve bien en una captura” y algo que está bien construido.
En esta prueba, GPT 5.6 no solo generó una composición convincente. También produjo los archivos que esperarías en un proyecto real:
- El index del proyecto.
- Los estilos.
- Scripts.
- Los assets visuales separados.
- Imágenes por secciones.
Eso es importante porque cuando trabajas con clientes, con iteraciones o con publicación posterior, necesitas una base que puedas tocar, corregir y mejorar. No solo un resultado aparente.
En otras palabras, no me interesa únicamente que una IA haga algo bonito. Me interesa que deje una estructura aprovechable. Y en esta prueba, la dejó.
🛠️ Mi método mejoró porque el modelo ahora resuelve más pasos
Esto para mí fue uno de los hallazgos más importantes.
Yo ya venía trabajando con un método bastante claro para este tipo de webs. Siempre parto de una referencia. A veces genero imágenes específicas. A veces incorporo animación. Y casi siempre separo letras, interfaz, fondos y otros recursos para que la web final no dependa de una sola pieza gráfica.
Con GPT 5.6 sentí que ese método llegó a un siguiente nivel, porque el modelo ya no se queda esperando microinstrucciones a cada rato. Puede tomar una lógica de trabajo mejor definida y ejecutar bastante por su cuenta.
Eso no significa que reemplaza criterio, dirección o revisión. Significa que reduce fricción.
Y en workflows creativos, reducir fricción vale oro.
📱 El caso Japón: qué hizo bien exactamente
En la landing inspirada en Japón hubo varias cosas que me parecieron especialmente bien resueltas:
- Interpretación visual: respetó la atmósfera general de la referencia.
- Descomposición del diseño: no intentó resolver todo como una sola capa.
- Tipografía estructural: usó texto real en vez de incrustarlo como imagen.
- Jerarquía: mantuvo una sección hero potente, bloques intermedios y cierre visual consistente.
- Formulario funcional: la sección final no era decorativa, funcionaba.
Claro, siempre se puede pulir más. Ajustar espaciados, mejorar proporciones, retocar algunos detalles de composición, afinar contraste, corregir pequeñas desviaciones. Pero eso ya entra en una etapa de refinamiento.
Lo valioso es que la base salió bien.
🍷 Segundo experimento: una web de vinos más compleja
La segunda prueba fue distinta. En lugar de una sola landing muy enfocada en una atmósfera concreta, probé una web de vinos con varias secciones visuales bien marcadas.
Acá ya no era solo “lograr una estética”. También había que resolver contenido, navegación visual, enlaces, composición editorial y una sensación de marca más premium.
Y honestamente, el resultado también me dejó bastante satisfecho.
Esta ejecución tardó 24 minutos y 54 segundos.
Otra vez, no me parece un tiempo excesivo considerando la cantidad de trabajo que estaba haciendo.
✅ Lo que más me gustó de la web de vinos
En este segundo caso hubo algo muy relevante: no solo se veía bien, sino que además la interfaz era funcional.
Los textos estaban implementados como texto. Los elementos navegables funcionaban como enlaces. Las distintas partes de la página tenían sentido como componentes de una web real.
Eso para mí pesa mucho más que cualquier comparación superficial de “se parece mucho” o “se parece poco”.
Porque una herramienta útil no es la que te hace una imagen linda. Es la que te deja una pieza con la que puedes trabajar.
En esta web se notaba una intención clara de estructura:
- Una apertura visual fuerte con branding premium.
- Bloques editoriales con imagen y texto.
- Sección de productos destacando distintas botellas.
- Llamados a la acción.
- Formularios y enlaces operativos.
Cuando veo ese tipo de resultado en menos de media hora, sí siento que hay una mejora real y no solo marketing.
⏱️ Tiempo de ejecución versus calidad entregada
A veces se discute mucho sobre si un modelo tarda demasiado. Mi opinión acá es bastante simple: el tiempo importa, pero hay que ponerlo en contexto.
Si un modelo tarda 14 minutos o 25 minutos, pero durante ese tiempo está resolviendo una parte importante del frontend, separando assets, armando estructura y dejando una base funcional, entonces el costo temporal tiene sentido.
Más aún si lo comparas con el tiempo que normalmente se va en:
- Preparar el layout inicial.
- Organizar imágenes.
- Escribir estructura base.
- Probar proporciones.
- Conectar secciones.
- Arreglar pequeños detalles manuales desde cero.
Muchas veces el verdadero ahorro no está en que termine en 30 segundos. Está en que te entregue un punto de partida mucho mejor.
Y eso fue exactamente lo que sentí con GPT 5.6.
🏗️ Por qué separar assets sigue siendo clave
Quiero insistir en esto porque me parece una de las grandes diferencias entre un resultado amateur y uno más serio.
Cuando tomas una referencia visual, hay varias formas de abordarla. La peor suele ser usarla casi como un póster y montar encima elementos mínimos. Eso rompe flexibilidad, accesibilidad, mantenimiento y escalabilidad.
La mejor forma es separar el sistema visual:
- Fondo por un lado.
- Elementos ilustrativos por otro.
- Interfaz por otro.
- Tipografía como contenido real.
- Interacciones como comportamiento real.
Eso fue precisamente lo que el modelo interpretó bastante bien en estas pruebas.
Y por eso me dejó una impresión tan positiva. Porque entendió el fondo del trabajo, no solo la apariencia externa.
💡 Mi opinión honesta: hoy es la mejor herramienta que estoy usando para esto
Si me preguntas por mi evaluación directa, sin vueltas: sí, estoy bastante satisfecho con las capacidades de frontend de GPT 5.6 en Codex.
De hecho, hoy la siento como la mejor herramienta del momento dentro de este tipo de flujo que yo uso.
No porque sea mágica. No porque haga todo perfecto. No porque elimine la necesidad de criterio humano. Sino porque en la práctica está resolviendo mejor que antes una parte muy difícil del trabajo: traducir una referencia visual en una implementación útil.
Y eso, para mí, pesa muchísimo.
💳 El plan que uso y por qué me da libertad para probar
Yo estoy usando el plan de 100 dólares. En mi caso me ha funcionado bien, sobre todo porque OpenAI me ha ido dando resets adicionales, lo que me ha permitido trabajar con más tranquilidad y sin estar tan pendiente de llegar a un límite demasiado rápido.
Eso influye bastante en la experiencia, porque cuando estás probando en serio, iterando y llevando proyectos reales, no quieres estar frenándote todo el tiempo por miedo a consumir de más.
La libertad de uso cambia cómo exploras una herramienta. Te permite experimentar mejor, probar variantes y confiar más en el flujo.
🔍 ¿Es mejor que otras alternativas? Mi respuesta es más simple
Acá no me interesa entrar en guerras absurdas de herramientas.
No siento que sea necesario andar repitiendo que una opción “destruye” a otra. Eso normalmente aporta poco y confunde bastante. La realidad es que hoy hay varios modelos frontera muy potentes, y muchos tienen capacidades muy altas aunque con perfiles distintos.
Si alguien ya está trabajando cómodo con otra línea de herramientas y esa línea le resuelve bien, perfecto. Que siga ahí.
En mi caso uso GPT 5.6 porque me gusta trabajar en Codex y porque este entorno encaja bien con mi flujo. Esa es la razón real.
No por fanatismo. No por ideología. Simplemente porque me funciona.
Mi consejo es ese: elige la herramienta que mejor encaje con tu forma de trabajar y quédate con la que te dé más fluidez.
🧪 Lo que estas pruebas sí demuestran
Con solo estas dos webs ya hay varias conclusiones que me parecen razonables:
- GPT 5.6 mejoró bastante para tareas de frontend visual.
- Entiende mejor referencias estéticas complejas.
- Puede construir una base más cercana a producción.
- Resuelve mejor la separación entre assets y estructura.
- Entrega resultados útiles en tiempos aceptables.
No digo que cualquier prompt vaya a producir maravillas. Tampoco digo que todo salga perfecto al primer intento. Pero sí digo que el techo práctico que sentí usando esta versión es más alto que antes.
🖼️ Trabajar desde una referencia sigue siendo una ventaja enorme
Algo que reafirmé con estas pruebas es que partir desde una referencia visual sigue siendo una de las mejores decisiones cuando quieres construir algo con calidad estética.
La referencia te da dirección. Te da lenguaje visual. Te da una intención clara para composición, color, tipografía y atmósfera. Y cuando el modelo tiene capacidad suficiente para interpretar esa referencia de forma inteligente, el resultado mejora mucho.
Por eso sigo defendiendo ese método. No parto del vacío. Parto de una imagen o diseño que marca un norte. Luego separo lo que haga falta, estructuro mejor el problema y dejo que la herramienta haga una parte importante de la ejecución.
Con GPT 5.6 esa combinación me está dando resultados más sólidos.
🌐 Si quieres mejorar prompts, aprender el flujo o trabajar conmigo
Como en estas pruebas el prompt y la dirección importan mucho, si quieres crear mejores instrucciones para este tipo de trabajos, te recomiendo Primera. Es el producto que menciono cuando hablo de prompts profesionales y puede ayudarte a estructurar mejor lo que le pides a la IA.
Si además quieres compartir procesos, aprender más sobre creación de apps y flujos con IA, puedes unirte a mi comunidad.
Y si tienes un caso concreto y quieres que trabajemos tu proyecto, puedes contarme tu idea aquí.
📚 Qué haría después de generar una web así
Aunque los resultados me parecieron muy buenos, yo igual seguiría un proceso de revisión después de cada ejecución. Ese paso sigue siendo fundamental.
Normalmente revisaría lo siguiente:
- Estructura HTML: validar jerarquía y semántica.
- Assets: comprobar pesos, nombres y organización.
- Responsive: ajustar comportamiento en distintas resoluciones.
- Interacciones: revisar botones, enlaces y formularios.
- Detalles visuales: corregir espaciados, tipografías y alineaciones.
- Publicación: llevar la versión aprobada a una URL temporal o entorno de demo.
Lo importante es que ya no estás empezando desde cero. Estás editando una base prometedora.
🧭 Mi conclusión final sobre GPT 5.6 en Codex
Después de usarlo varios días, mi lectura es simple: GPT 5.6 es muy bueno para frontend y me sorprendió de forma positiva.
Lo probé en proyectos reales. Le exigí una tarea visualmente difícil. Le pedí replicar diseños con sensibilidad estética. Y respondió mejor de lo que esperaba.
¿Es perfecto? No.
¿Hay que seguir guiándolo y revisar lo que hace? Sí, por supuesto.
¿Pero está en un punto donde realmente acelera y mejora el flujo de trabajo? También.
Para mí, esa es la parte clave.
No necesito que una herramienta sea perfecta para que sea valiosa. Necesito que me permita llegar más rápido a resultados buenos, con una estructura útil y con menos fricción en el proceso. Y eso, hoy, GPT 5.6 en Codex sí lo está haciendo.
Si trabajas creando sitios, prototipos o experiencias visuales premium apoyadas en IA, vale mucho la pena tenerlo en el radar.
