Probé GPT 5.4: por qué sigo usando un modelo más simple

Captura de ChatGPT mostrando un mensaje que propone una versión front-end en React/Tailwind

Hace poco hice una prueba práctica: usar GPT-5.4 para rediseñar mi web personal. No fue un experimento teórico ni una comparación de benchmarks; fue una prueba real con un prompt que ya venía usando para generar interfaces. Quería ver dos cosas concretas: qué tan bien sigue instrucciones y qué tan usable resultaba el HTML/CSS/JS que entregaba en una sola corrida. Lo que salió me dio motivos para sonreír y para mantener la calma sobre escoger siempre lo «más nuevo».

Tabla de contenidos

🧭 Qué buscaba con la prueba

Mi objetivo fue simple: generar una versión moderna y usable de mi sitio usando únicamente HTML, CSS y JavaScript (sin frameworks extra). Tenía un prompt ya afinado, quería igualdad de condiciones y que el modelo produjese un prototipo descargable que pudiera abrir en un navegador y pulir.

No era una prueba de velocidad ni de razonamiento profundo. Era una prueba de diseño aplicado: ¿el modelo respeta la estructura pedida? ¿incorpora assets y enlaces correctamente? ¿el resultado es lo suficientemente pulido para usar como base de trabajo?

⚙️ Cómo configuré la comparación

Para que la evaluación fuera justa seguí tres reglas sencillas:

  • Mismo prompt base: utilicé el mismo prompt que ya había usado antes, sin cambios que favorecieran a un modelo en particular.
  • Mismo objetivo técnico: pedí explícitamente que se devolviera solo HTML, CSS y JavaScript, nada de React u otros frameworks.
  • Modo de pensamiento extendido: activé la opción de razonamiento extendido para que el modelo tuviera «toda la potencia» a la hora de generar la UI.

Esta metodología ayuda a que las diferencias entre modelos se reflejen en la salida y no en la configuración.

📝 El prompt que usé (ejemplo)

Compartiré una versión simplificada del prompt para que puedas reproducir la idea. Lo importante ahí es ser claro en dos aspectos: tecnología requerida y objetivo visual/funcional.


Genera una página web estática (solo HTML, CSS y JavaScript) que sirva como prototipo para mi sitio personal.
Requisitos:
- Solo archivos HTML, CSS y JS (sin React, sin frameworks).
- Usa Google Fonts (indica las fuentes usadas).
- Incluye una barra de logotipos, secciones de hero, características, testimonio y footer.
- Mantén código bien estructurado y listo para descargar como prototipo.
- Asegúrate de que los enlaces de navegación apunten a secciones internas.
- Entrega todo en un único archivo HTML con estilos y scripts embebidos para la vista previa, y adicionalmente indica cómo separar CSS/JS.

Con este prompt mi expectativa era sencilla: un prototipo que pueda abrir, revisar y descargar sin necesidad de instalar dependencias.

🔍 Observaciones durante la generación

La primera sorpresa fue que, al iniciar la generación, el modelo comenzó a producir una estructura en React. No había pedido React explícitamente, y mi prompt no lo indicaba. Esto evidencia algo interesante: los modelos a veces «asumen» frameworks modernos porque son comunes en proyectos reales. En mi caso, paré la ejecución y volví a especificar claramente: solo HTML, CSS, JavaScript.

Tras la aclaración, el modelo reemprendió y generó una gran cantidad de CSS —muchas clases y reglas—, lo cual es normal en prototipos visualmente ricos. Los archivos resultaron muy orientados a la vista previa (clases largas, estilos embebidos), pensados más para prototipado que para producción inmediata.

Captura de ChatGPT mostrando DOCTYPE, enlaces a Google Fonts y variables CSS en el prototipo

Esa salida pesadamente estilada es útil como punto de partida, pero requiere pasos adicionales para convertirla en código limpio y desacoplado:

  • Separar CSS del HTML (mover a archivos .css).
  • Optimizar y renombrar clases para mantener consistencia semántica.
  • Externalizar fuentes y assets si hace falta, y revisar accesibilidad.

🎨 Resultado visual y nivel de pulido

En una sola corrida el prototipo se veía bastante pulido. Tenía tipografías, espaciados, animaciones suaves y una estructura coherente. No fue perfecto: había pequeños detalles que yo ajustaría (orden de estilos, pequeños huecos de diseño), pero para un primer pase el trabajo fue notable.

Un punto práctico: el prototipo permitió usar Google Fonts y el modelo incluyó la referencia. Al obtener la vista previa, tuve que aceptar el permiso para usar las fuentes de Google, algo que el entorno pidió explícitamente.

Diálogo '¿Permitir el acceso a la red?' mostrando fonts.googleapis.com y botones para denegar o permitir

Después de descargar el archivo pude abrirlo en mi servidor de pruebas, revisar enlaces y comprobar que la mayor parte de lo solicitado estaba incorporado. Sí: enlaces, barra de logos y secciones estaban presentes y funcionales.

Homepage generada abierta en localhost mostrando la cabecera con logo y navegación, y el hero principal con tipografía grande

🛠️ Flujo recomendado para convertir el prototipo en código de producción

Aunque el prototipo es muy útil, hay pasos imprescindibles para que el resultado sea sostenible en un proyecto real:

  1. Separar y minificar: extraer CSS a un archivo independiente y minificarlo para producción. Lo mismo para JavaScript.
  2. Renombrar clases con criterios: transformar clases generadas aleatoriamente a nombres semánticos o a un sistema como BEM si tiene sentido.
  3. Auditar accesibilidad: revisar contrastes, etiquetas aria y navegación por teclado.
  4. Optimizar assets: comprimir imágenes, usar formatos modernos (WebP) y cargar imágenes de forma perezosa (lazy loading).
  5. Pruebas de enlace: verificar que todos los enlaces y rutas internas funcionen al moverlo a servidor.

💡 Consejos prácticos para prompts cuando pides diseño web

  • Sé explícito sobre la tecnología: si no quieres React, dilo. Los modelos pueden asumir frameworks modernos por defecto.
  • Pide un único archivo para previsualización: facilita abrir y revisar rápido. Luego puedes solicitar separarlo.
  • Solicita guías de separación: pide al final del prompt cómo separar CSS/JS en archivos independientes.
  • Incluye restricciones de accesibilidad: pedir contraste y roles ARIA puede ahorrar trabajo posterior.
  • Versiones alternativas: pide variantes de color o layout para tener opciones de diseño.

📊 ¿Por qué no uso siempre el «mejor» modelo?

La respuesta corta: porque lo que importa en el día a día es la relación coste-beneficio y la disponibilidad, no solo la puntuación máxima en benchmarks. En mi flujo cotidiano hay modelos que, aunque no sean los más recientes, ofrecen velocidad, estabilidad y disponibilidad que hacen la diferencia.

Por ejemplo, en mis proyectos uso mucho un modelo llamado Gemini 3 Flash. No es el más moderno, pero es rápido, consistente y casi siempre accesible. Cuando me quedo sin créditos en modelos más potentes, Gemini 3 Flash sigue ahí funcionando y me ahorra bloqueos en el trabajo.

También existen modelos con gran potencia en reasoning o creatividad, como Cloud Opus 4.6, que mucha gente consideró el mejor hasta hace poco. Pero su coste o disponibilidad pueden no justificar su uso en producción masiva o en una SaaS donde cada llamada tiene un precio.

💸 Cómo elegir un modelo según tu caso de uso

Elegir un modelo va más allá del mejor resultado en un test aislado. Hay factores prácticos:

  • Necesidad real: ¿requieres razonamiento profundo o generación de interfaz repetible y rápida?
  • Costo por llamada: en una aplicación con miles de usuarios, incluso pequeñas diferencias por llamada suman mucho.
  • Latencia: algunos modelos son más rápidos y eso impacta la experiencia de usuario.
  • Disponibilidad y límites: tener un modelo que esté siempre disponible evita bloqueos en operaciones críticas.
  • Licencia y uso comercial: revisa términos para integrarlo en tu producto.

Para SaaS es clave definir un «presupuesto por llamada» y probar varios modelos con ese presupuesto. A menudo la mejor elección es combinar modelos: uno económico y rápido para tareas comunes y otro más potente para casos especiales.

📋 Checklist para evaluar un modelo en tareas de UI/Frontend

  1. El modelo sigue las instrucciones tecnológicas? (HTML vs React, frameworks, etc.)
  2. La salida es coherente visualmente y funcionalmente?
  3. Incorpora assets y enlaces correctamente?
  4. ¿Qué tan fácil es convertir el prototipo en producción (separar archivos, limpiar clases)?
  5. ¿Cuál es la latencia promedio y el coste por generación?
  6. ¿La calidad es consistente entre varias ejecuciones?
  7. ¿La integración con tu pipeline es sencilla (API, límites, SDKs)?

🧩 Integración y escalado: recomendaciones técnicas

Si planeas integrar generación de UI en una app o SaaS, considera estas prácticas:

  • Caching de prototipos: guarda resultados para evitar regeneraciones innecesarias por cada visita.
  • Preprocesamiento: valida y limpia HTML antes de servirlo al usuario.
  • Transformaciones automáticas: scripts que extraigan CSS, normalicen clases y apliquen minificación automáticamente.
  • Pipeline híbrido: usa un modelo económico para tareas repetitivas y uno potente para ajustes críticos.
  • Monitorización de costes: establece alertas cuando el gasto mensual supere umbrales.

🔎 Ejemplos de prompts para distintos objetivos

Aquí tienes 3 plantillas rápidas que uso según el objetivo:

1) Prototipo rápido (vista previa)


Genera un único archivo HTML que sirva de prototipo. Solo HTML, CSS y JS embebidos.
Incluir: hero, features, testimonial, footer y barra de logos.
Usa Google Fonts: Roboto y Inter.
Explica al final cómo separar CSS y JS a archivos independientes.

2) Producción ligera


Genera HTML semántico y un archivo CSS separado. Evita clases auto-generadas largas; usa nombres semánticos.
Incluir comentario al inicio con instrucciones para minificar y dónde ubicar los archivos.
Asegúrate de accesibilidad básica (roles ARIA, alt en imágenes).

3) Variantes de diseño


Genera 3 variantes del mismo layout con paletas de color distintas. Cada variante en una sección del HTML y con CSS modular.
Incluye una breve justificación de cada paleta (audiencia, sensación buscada).

📚 Recursos y enlaces mencionados

Puedes profundizar con los recursos que uso en mi flujo:

  • Comunidad en Skool: https://www.skool.com/vibe-coding-crea-apps-con-ia-5930
  • Playlist para crear apps web con IA: https://www.youtube.com/playlist?list=PLBTuX25MUpdo9YuMzu-o9c80p1q40EBfI
  • Mi canal: https://www.youtube.com/channel/UCzyOS_56H5kiBCs4UnIp0HA
  • Enlace del experimento (referencia): https://www.youtube.com/watch?v=sLXOEY3rAuQ

✅ Conclusiones y decisión práctica

GPT-5.4 demostró ser capaz de generar prototipos muy pulidos en una sola corrida. Fue capaz de seguir la mayoría de las instrucciones y entregar un HTML que se podía descargar y prototipar rápidamente.

Aun así, no significa que deba ser la primera opción para todos los casos. En mi día a día prefiero soluciones más económicas y estables cuando el flujo de trabajo lo exige. Modelos como Gemini 3 Flash me dan velocidad, disponibilidad y costes controlables. Para tareas puntuales o cuando necesito la máxima calidad, considero modelos más potentes, pero con un criterio claro: que el beneficio justifique el coste.

🔁 Recomendación final para quien quiera probar

  1. Pide siempre la tecnología exacta que necesitas.
  2. Solicita un único archivo de vista previa y las instrucciones para separar CSS/JS.
  3. Haz varias corridas y compara consistencia.
  4. Mide latencia y coste por generación antes de integrar en producción.
  5. Combina modelos según la criticidad de la tarea.

🧾 Resumen rápido

  • GPT-5.4 genera prototipos pulidos y coherentes.
  • Los modelos pueden asumir frameworks; especifica tecnología.
  • En producción, la relación coste-beneficio y disponibilidad importan más que el ranking teórico.
  • Gemini 3 Flash es una opción práctica y eficiente para uso diario.

Si quieres reproducir este experimento, usa las plantillas de prompt arriba, ajusta la instrucción tecnológica y evalúa no solo la calidad del resultado sino también el coste y la consistencia. Ese es el único camino para elegir el modelo adecuado para tu proyecto.

🔗 Enlaces rápidos otra vez

  • Skool comunidad: https://www.skool.com/vibe-coding-crea-apps-con-ia-5930
  • Playlist: https://www.youtube.com/playlist?list=PLBTuX25MUpdo9YuMzu-o9c80p1q40EBfI
  • Canal: https://www.youtube.com/channel/UCzyOS_56H5kiBCs4UnIp0HA
  • Referencia del experimento: https://www.youtube.com/watch?v=sLXOEY3rAuQ

Si te interesa, puedo compartir plantillas de prompt listas para copiar/pegar adaptadas a distintos niveles de detalle y tecnología.

Entradas relacionadas