2026.09.01 (Mar)

✨ Resumen de GPT-5.6 Sol

Por mucho que le diera DESIGN.md y referencias de aspecto premium, el PPT seguía viéndose anticuado. Cuando elegí primero una imagen terminada, la fijé como referencia visual definitiva y pedí que la trasladara a una diapositiva editable, por fin se desbloqueó el método de producción que llevaba días atascado.

Durante días, el folleto no dejaba de salir hecho una basura

Mientras preparaba un folleto comercial para hoteles en el trabajo, pasé varios días probándolo prácticamente todo. Busqué referencias de folletos de hoteles de lujo y se las pasé, preparé un DESIGN.md con los colores, las tipografías y los espacios, separé el contenido y las instrucciones de cada página e incluso puse en marcha un montón de sesiones de coordinadores y workers.

Pero el resultado seguía siendo anticuado y extraño. Aunque le mandara rehacer la misma página, no parecía un folleto comercial de un hotel de lujo, sino un informe interno o una propuesta vieja. Codex traía orgulloso sus comprobaciones: el texto no se desbordaba, el archivo se abría correctamente y las fuentes coincidían. Sin embargo, cuando yo abría el PPT, mi primera reacción era: “Uf, ¿qué es esto?”

Cuando pensé que necesitaba DESIGN.md porque el diseño cambiaba cada vez que hacía el folleto, creía que al menos reduciría las veces que la IA tenía que volver a adivinar el ambiente desde una pantalla vacía. DESIGN.md sí era necesario. Pero esta vez entendí que tener ese archivo no genera automáticamente un buen diseño.

Codex decía haber leído DESIGN.md y las referencias, pero el PPT real no captaba por qué aquellas referencias parecían de alta gama. Tomaba algunos colores, construía cajas parecidas y daba por hecho que ya las había aplicado. Desaparecían la composición, las proporciones de superficie, el peso visual, los espacios, el recorrido de la mirada y la impresión general. Solo quedaba un documento de cajas con el contenido bien ordenado.

Cuando el código iba primero, la pantalla final quedaba para después

Al observar el proceso una y otra vez, vi que la propia forma de diseñar era extraña. No empezaba imaginando cómo debía verse la página terminada. Dividía el contenido, asignaba coordenadas a cuadros de texto y rectángulos, añadía líneas y colores y terminaba el código del PPT. Solo entonces renderizaba y descubría que el resultado era una basura.

A partir de ahí volvía a cambiar los espacios, reducir los colores y mover las cajas. Pero seguía siendo raro porque solo hacía pequeños retoques sin abandonar una composición que estaba mal desde el principio. El render no era el objetivo del diseño. Se parecía más a una pantalla de depuración para descubrir problemas después de escribir el código.

Codex es increíblemente bueno encontrando patrones, así que me parecía extraño que no pudiera encontrar el patrón de lo “premium” por muchas referencias elegantes que le diera. Pensándolo mejor, explicar con palabras las características de un buen diseño y crear esa impresión completa desde un PPT vacío son capacidades distintas. Un resultado puede aprobar todos los criterios de alineación, contraste, espacio, fuente y color, y aun así verse terriblemente anticuado.

Al empezar por una imagen, de repente supo diseñar

Entonces le pedí que reconstruyera primero la misma página como una imagen usando la combinación de colores que yo había elegido. Y, de manera absurda, la imagen salió bien. La jerarquía de la información se entendía, el equilibrio de las superficies y los espacios funcionaba, y los iconos y las líneas compartían un mismo estilo. Por fin apareció el ambiente moderno, sencillo y exclusivo de hotel que llevaba tanto tiempo pidiendo.

“¿En imagen sí que te sale bien…? Entonces, ¿por qué el PPT tiene esa pinta?”

Ahí vi la respuesta. En lugar de traducir directamente DESIGN.md y las referencias a código PPT, primero debía hacer una imagen terminada de la página. Podía corregirla en la fase de imagen hasta que me gustara y después fijarla como la “referencia visual definitiva” de esa página. El PPT original y las instrucciones de la página quedarían separados como la “referencia definitiva del contenido”, encargada de proteger el texto, los hechos, las relaciones y los elementos obligatorios.

Después ya no le pido a Codex que invente un diseño nuevo. Le pido que reproduzca la imagen aprobada con elementos editables de PPT de la forma más fiel posible. Al final vuelvo a renderizar el PPT guardado como imagen y lo comparo al mismo tamaño, colocado junto a la referencia visual.

La página rehecha con este método fue claramente distinta de los resultados anteriores. Conservó el texto y las relaciones organizativas originales, pero llevó casi tal cual al PPT editable la composición, la proporción de colores, la tipografía, los iconos y las líneas de la imagen que yo había aprobado. Al verla, de verdad dije: “¡Vaya…! ¡¡¡He encontrado la respuesta!!!”

Al final, la revisión del diseño tengo que hacerla yo

Desde el día en que no recibí el folleto por estar ocupado gestionando coordinadores y workers, desconfiaba bastante del trabajo en paralelo. Ahora veo que la estructura de coordinador y workers no es mala en todos los casos. Sirve para generar rápidamente propuestas visuales en varias direcciones o para convertir en PPT distintas páginas que ya han sido aprobadas.

Pero no puedo dejar la elección del diseño y la revisión final en manos del coordinador. El coordinador puede comprobar textos omitidos, relaciones incorrectas, desbordamientos, fuentes e integridad del archivo, y preparar las imágenes de comparación. Yo tengo que decidir qué resultado parece más exclusivo, qué página podría hacer que un responsable de hotel quisiera firmar un contrato y si el resultado me gusta de verdad.

A partir de ahora haré las páginas del folleto en este orden.

  1. Fijar el contenido con el PPT original y las instrucciones de la página.
  2. Crear varias propuestas de imagen a partir de DESIGN.md y las referencias.
  3. Revisarlas personalmente y aprobar la que me guste como referencia visual definitiva.
  4. Reproducir la imagen aprobada con la mayor fidelidad posible en un PPT editable.
  5. Comparar al mismo tamaño el render del PPT y la referencia visual, y dar yo mismo la aprobación final.

Antes hacía primero el PPT y descubría el diseño por primera vez al renderizarlo. Ahora termino primero el diseño como imagen y trato el PPT como la implementación que lo traslada.

Durante días sentí que iba a volverme loco intentando entender por qué esto no funcionaba. Al menos ahora sé dónde debe decidirse el diseño y quién debe revisarlo. La respuesta no era escribir un DESIGN.md más largo ni ordenar con más fuerza que “trabajara como un diseñador con 30 años de experiencia”. Primero creo una imagen terminada que yo elijo con mis propios ojos y después hago que Codex la implemente con precisión. Por ahora, este es el mejor método que he encontrado.

Deja un comentario