Durante unos cuatro meses y medio, mi sitio llevó la piel de TRANSMISSION: oscuro, cian, ámbar, y deliberadamente técnico.
Fondo azul marino tirando a carbón. Acentos en cian. Paneles vidriados. Lo construí así a propósito. Llevaba dieciocho años en publicidad. Me había enseñado a programar a los cuarenta. Quería que el sitio hiciera visible esa transición — que cualquiera que aterrizara en un post del blog, pasara el wordmark con la mirada y notara la estética de herramienta de desarrollador captara la señal: esta persona cruzó al otro lado.
Cumplió su trabajo. Y luego se terminó.
Durante el largo fin de semana de Memorial Day publiqué un rediseño que no se parece en nada a lo anterior. Modo claro. Fondo de papel cálido. Rojo carmín en lugar de cian. Reglas finísimas en lugar de tarjetas redondeadas. Un visible "Vol. 04 · Issue NN" en una esquina — el volumen cuenta los años desde que empecé a construir en público, el issue es la semana ISO actual, y ambos están conectados para actualizarse solos. El número del día en que leas esto puede decir Issue 22 o 23 o 41, según cuándo aterrices. No hay ningún icono de Sparkles por ningún lado. El sitio ya está en vivo en chandlernguyen.com.
Podría escribir un post entero sobre esas decisiones. Pero la historia más útil es el flujo de trabajo. Dividí el rediseño entre dos modelos de IA distintos. Claude Opus 4.7 con extended thinking se ocupó del diseño. Codex sobre GPT-5.5 en su nivel más alto de reasoning se ocupó de la ejecución. Y la función /goal en Codex le permitió correr en autonomía durante casi cuatro horas seguidas, mientras yo salía a caminar o cenaba.
Cuatro días. Dos modelos. Casi treinta commits. Un sitio.
Esto es lo que aprendí sobre qué modelo usar para qué — y dónde sigue estando la frontera.
Por qué TRANSMISSION tenía que irse
Crucé de la publicidad al código a lo largo de los últimos dos años. A principios de este año el sitio se había puesto al día: lo rediseñé como TRANSMISSION precisamente para hacer visible esa transición. Cuatro meses y medio después, la señal ya está dada.
El próximo trabajo es distinto. Quien llega desde un post del blog, desde un hilo de LinkedIn, desde una búsqueda en Google no viene a confirmar que escribo código. Viene a aprender algo sobre IA en operaciones de medios, a considerar comprar el curso, o a comparar el curso, Prova, DIALØGUE y STRAŦUM como una escalera de producto. El sitio necesitaba señalar menos y guiar más.
La forma más fácil de describir el cambio: el sitio anterior era una personalidad. El sitio nuevo es un modelo operativo. La misma persona detrás, otro trabajo que hacer. Eso implicaba otra estética — más liviana, más calmada, editorial, el tipo de superficie donde un post largo puede respirar y un CTA del curso puede sentirse honesto en lugar de insistente. Papel cálido en lugar de vidrio.
Pero el problema más difícil no era la estética. Era el volumen de trabajo. El sitio tiene trece idiomas, unas ocho superficies públicas (home, blog, post, products, learn, about, ask, página de venta del curso), un flujo autenticado de acceso al curso, un checkout de Stripe y un endpoint del RAG de Sydney. Reconstruir todo eso a mano me habría llevado semanas. Y semanas no tenía.
Así que dividí el trabajo entre dos modelos de IA.
Por qué separar diseño y ejecución
Diseño y ejecución son tareas cognitivas distintas.
El diseño es lento. Es criterio sobre composición, sobre restricción, sobre si un tono de papel cálido se ve demasiado amarillo en un iPhone y otro tono se ve demasiado frío. Es preguntar "¿qué tipo de superficie está tratando de ser esto?" antes de "¿cómo renderizamos esta sección?". El buen trabajo de diseño comprime el tiempo — piensas durante dos horas y luego tomas una decisión que te ahorra diez horas de ejecución.
La ejecución es rápida. Es aplicación de patrones. Dado un sistema de diseño, generá los componentes. Dado un componente, cableálo a través de trece idiomas. Dado el layout de una página, publicá las variantes. El trabajo no es menos calificado, pero es menos ambiguo. La respuesta correcta suele ser defendible contra la especificación.
Distintos modelos de IA son mejores para distintas tareas cognitivas. Por mi propia experiencia de los últimos meses — primero con Claude Opus 4.6 y ahora con 4.7, ambos en modo extended thinking — Opus es el partner más completo. Mejor para el brainstorming. Mejor en criterio de diseño. Más lento y menos quirúrgicamente preciso en código puro, pero considera toda la composición antes de responder y razona de una forma que atrapa por qué una fuente se siente demasiado amistosa y otra se siente correcta.
Codex sobre GPT-5.5 en su nivel alto de reasoning se siente como un ingeniero de software senior competente que nunca se acercó al equipo de diseño. Es rápido. Es excelente para el uso de herramientas en múltiples pasos — abrir archivos, leerlos, editarlos, correr tests, abrir el siguiente. No tiene opiniones fuertes sobre si un botón se ve demasiado alto, pero entrega el botón, y entrega cada variante del botón a través de trece idiomas sin protestar. Su función /goal te deja darle un objetivo — por ejemplo, "convert the v3 design tokens into the Next.js app, wire the new shell, ship working BottomNav, MobileAppBar, ReadingProgress, verify the build passes with the flag off" — y alejarte. Va a planificar sub-pasos, ejecutarlos, correr el build, arreglar lo que se rompa y seguir adelante. El tramo más largo que ha corrido sin supervisión para mí, en este proyecto, fue de poco menos de cuatro horas.
Tengo que admitir que no planeé esta división de forma deliberada al inicio. Había tenido la conversación de diseño con Opus durante los días previos al fin de semana. Cuando arrancó el fin de semana largo ya tenía el documento de dirección de diseño y el prototipo de escritorio en la mano. El fin de semana en sí fue cuando le pasé la ejecución a Codex, y dentro de la primera hora me di cuenta de cuánto mejor encajaba cada modelo en su mitad del trabajo.
Lo que hizo Opus: la fase de diseño
El trabajo de diseño ocurrió en una larga conversación con Opus durante los días previos al rediseño. De esa conversación salieron dos artefactos, ambos viven hoy en el repo:
1. Un documento de dirección de diseño. Seis archivos markdown en doc/v3-design/ — el porqué, los tokens, los patrones móviles, las especificaciones de página, las restricciones de accesibilidad, el plan de ejecución. Más de trece mil palabras de decisiones, escritas en su mayoría por Opus a partir de un brief que yo le había dado. La directiva: "el próximo sitio debe sentirse como una pequeña revista impresa, no como un dashboard SaaS. Ganarse la atención por restricción. Usar el framework Operating Model 2×2 como firma visual."
2. Un prototipo HTML de escritorio. Un directorio plano en public/design-prototype-v2/ con seis páginas y un style.css compartido. Sin React, sin Tailwind, sin framework — solo HTML escrito a mano para poder clickear por cada página en un servidor local y sentir si el sistema de diseño realmente se sostenía como sistema. El prototipo fue la fuente de verdad para el tratamiento visual el resto del fin de semana. Ante la duda durante la reconstrucción, la respuesta era "que coincida con el prototipo."
Opus tomó las decisiones que más importaban. Algunos momentos concretos:
-
El cambio de fuente. Una pasada de diseño anterior había fijado Manrope como fuente display por disponibilidad y facilidad de publicación — definida en una sesión con Claude Sonnet 4.6. Dieciocho horas después había movido la conversación de diseño a Opus 4.7 con extended thinking, y el primer movimiento de Opus fue reconsiderar esa decisión. Después de que pasé una tarde en la página oficial de specimen de PP Neue Montreal comparando letras, el cambio entró. El mensaje del commit se lee como una escena del crimen tipográfica: "Manrope rendered too rounded and friendly... Satoshi has the same condensed-grotesque proportions, the same double-storey
a, single-storeyg, sweptRleg, cleanly-sheared terminals." La arruga interesante es que dos modelos distintos de Claude llegaron a juicios distintos sobre la misma decisión. Sonnet eligió la opción segura. Opus eligió la correcta. -
La elección del carmín. El cian es el acento por defecto de la IA. Opus y yo aterrizamos en rojo carmín —
#c33824, un rojo de tinta de imprenta, el color de la marca de un editor sobre una galera o de un volumen latino en una estantería de la Loeb Classical Library. El razonamiento fue específico: "el sitio está tratando de sentirse editorial, no herramienta de desarrollador. El cian señala tech. El carmín señala oficio. Usar el carmín con moderación, siempre en alto contraste, idealmente sobre papel cálido." Esa no es una decisión a la que un modelo optimizado para ejecución llegaría por sí solo. -
El Operating Model como firma visual. El framework 2×2 que enseño en el curso — Automate / Protect / Deepen / Change — pasa a ser una marca discreta del nuevo sitio. En la implementación actual aparece en dos lugares contenidos: el bloque de tesis de la home y un pequeño marcador de tesis en los posts de formato largo. El framework en sí era mío; la decisión de convertirlo en identidad visual del sitio salió de la conversación de diseño con Opus.
-
Claro sobre oscuro. Opus argumentó por modo claro como personalidad y modo oscuro como variante soportada. El argumento: leer en formato largo es más fácil sobre papel cálido que sobre vidrio; las etiquetas de precio se sienten más honestas sobre fondos claros; casi toda herramienta de IA viene en oscuro por defecto, así que claro es el diferenciador. No estuve de acuerdo durante unas horas, y después estuve de acuerdo.
Opus fue sobre todo el loop de diseño y revisión; Codex hizo las pasadas de implementación. El trabajo de Opus era la parte donde ser lento daba sus frutos.
Lo que hizo Codex: la fase de ejecución
Una vez listos el documento de diseño y el prototipo, el trabajo se trasladó a Codex.
Abrí una sesión nueva de Codex, le pasé los archivos de dirección de diseño como contexto, y empecé a correr sesiones de /goal. Cada goal era un objetivo de múltiples pasos con un estado final claro:
Goal: Convert the v3 design tokens from
doc/v3-design/components/tokens.cssintosrc/app/globals.css. Remove the conflicting TRANSMISSION tokens. Wire up the three new fonts viasrc/lib/fonts.tsandsrc/app/layout.tsx. Generate the v3 shell behind the feature flagNEXT_PUBLIC_ENABLE_V3_DESIGN. Ship a workingBottomNav,MobileAppBar, andReadingProgress. Verify the build passes and that no existing pages are visually affected when the flag is off.
Ese tipo de objetivo multi-etapa es exactamente para lo que está pensado /goal. Codex planifica los sub-pasos, los ejecuta, corre pnpm build para chequear errores de tipo, arregla lo que se rompe, vuelve a correr el build y sigue. Volví de una caminata y el shell de v3 estaba vivo en el código detrás del flag, con las nuevas fuentes cargadas y el bottom nav renderizando en móvil.
Sesiones de /goal posteriores:
- Generar la home y la archive de v3 a partir del prototipo.
- Generar el layout de post de v3, incluyendo la barra de progreso de lectura y el botón de compartir de v3.
- Generar las páginas de products y learn de v3, respetando la estructura de la escalera definida en la spec.
- Alinear visualmente a v3 las páginas existentes de venta del curso, login, signup, MFA y access, sin tocar nada de la lógica subyacente de Stripe ni de Supabase Auth.
- Localizar las superficies de v3 del curso y de Ask Sydney en los trece idiomas, usando los archivos
messages/{locale}.jsonexistentes como fuente de traducción.
La corrida más larga sin intervención fue de poco menos de cuatro horas. La más corta, cerca de cuarenta y cinco minutos. A lo largo de los cuatro días publiqué casi treinta commits — la mayoría primera o segunda pasada de Codex, con pequeños ajustes manuales donde la salida del modelo era correcta pero no tenía exactamente la forma adecuada. Para ser honesto: creo que Codex escribió la gran mayoría del código real que corre hoy en producción. El resto lo escribí o lo edité yo.
Lo más útil de /goal no es la velocidad. Es la autonomía. La mayoría de las sesiones de código que he corrido con herramientas de IA me exigen quedarme en el teclado — confirmar un cambio, aceptar el siguiente archivo, revisar el diff. /goal te deja especificar el estado final que querés y alejarte. Volvés a un cambio terminado o a una sesión en pausa en el punto exacto donde el modelo necesita que tomes una decisión. La forma del trabajo es distinta. Pasás a ser planificador de sesiones de varias horas en vez de niñero de ediciones individuales.
Dónde sigue estando la frontera
Dividir diseño y ejecución entre dos modelos no es un truco de magia. Sigue habiendo momentos en los que un modelo necesita al otro, y unos cuantos momentos en los que ninguno alcanza por sí solo.
El icono de Sparkles. Codex generó un shell móvil de v3 limpio con un icono de Sparkles ✨ en la pestaña de Ask — el clásico delator universal de herramienta de IA. El icono era correcto contra la spec; la spec no decía "no uses el cliché." Lo noté un par de días después y volví a Opus para discutir reemplazos. Pasamos por varias iteraciones: la marca del Operating Model, después un signo de interrogación en cursiva Newsreader en rojo carmín — el tipo de glifo que podrías encontrar como marginalia en un ensayo viejo. La solución final fue idea de Opus. Codex la publicó en quince minutos.
El momento Hinomaru. Mientras la marca del Operating Model estaba en la esquina superior izquierda de la app bar móvil, junto a mi nombre, llevaba dos o tres días mirándola. Un pequeño punto carmín sobre un cuadrado de papel cálido. Una noche la miré como la miraría otra persona y sentí un pequeño escalofrío de realización. Se veía exactamente como la bandera japonesa. El Hinomaru. Un pequeño sol rojo sobre un fondo pálido. Ni Opus ni Codex lo cazaron. Opus había diseñado la marca; Codex la había implementado; ambos la habían revisado. La asociación visual era un patrón cultural que ninguno de los dos modelos podía ver. Borré la marca del wordmark y busqué otra solución. (El mismo ? en cursiva terminó ocupando su lugar en la pestaña de Ask.)
El rollout de los 13 idiomas. Opus podría haber diseñado los matices de UI de cada idioma con cuidado, pero le habría llevado días. Codex no podría haber tomado el criterio de diseño por sí solo, pero podía publicar los trece idiomas en una tarde una vez que los patrones estaban definidos. Este es el ejemplo más literal de la división: diseño lento, ejecución rápida.
Elegir tres fuentes que funcionen juntas. Opus eligió Satoshi (display), Newsreader (acento itálico) y JetBrains Mono (etiquetas). Codex no habría elegido esta combinación por su cuenta — y tampoco estoy seguro de que yo lo hubiera hecho sin la lentitud de Opus en la conversación. La composición a tres fuentes es una decisión de diseño, no de ejecución.
La conversación entre los dos sistemas ocurre en mi cabeza, no entre los modelos. Esa es la parte que todavía no se puede automatizar en 2026 — y creo que es la parte que define qué significa tener gusto ahora mismo.
Cuentas honestas
Cuatro días. Casi treinta commits. La v3 de producción está en vivo en chandlernguyen.com. El nuevo sitio está haciendo el nuevo trabajo — ayudar a quien lo visita a encontrar qué leer después en lugar de avisarle que crucé al otro lado.
El sitio tiene un problema pendiente que sigo persiguiendo. En el momento del borrador, Lighthouse móvil en producción mostraba el archive del blog llegando a 4.6 segundos, mientras que mi traza local de Chrome DevTools mostraba la misma imagen pintando en 264 milisegundos — el mismo código, modelos de red muy distintos. Mi hipótesis líder ahora es presión del preload de fuentes: tres webfonts precargadas más tres chunks de CSS que bloquean el render compitiendo contra la imagen hasta la línea de meta sobre una conexión móvil con throttling. Desplegué la versión de menor palanca de esa solución en el último día y todavía me hace falta una nueva corrida de Lighthouse para confirmar que aterrizó. El post que estás leyendo lo escribí antes de tener el número posterior al fix.
Costo de las suscripciones: mi suscripción de Codex en el nivel más alto, más la suscripción de Claude Max que ya tenía. Juntas, unos pocos cientos de dólares por mes. Barato, dado el throughput.
El hecho de que v3 ocurriera en cuatro días en vez de tres semanas se explica sobre todo porque las fases de diseño y ejecución estuvieron separadas y asignadas a los modelos que eran mejores para cada una. No creo que esto sea universal. Hay proyectos donde un solo modelo puede con ambas cosas, y proyectos donde ninguno de los dos modelos es el partner correcto. Pero para un rediseño multi-página, multi-idioma, multi-superficie con un punto de vista de diseño fuerte, esta división es el flujo de trabajo al que volvería a recurrir.
Si has hecho hace poco una reconstrucción propia asistida por IA, me encantaría de verdad escuchar cómo dividiste el trabajo. ¿Usaste un único modelo de punta a punta? ¿Dividiste por fase como hice yo, o por algún otro eje — por componente, por archivo, por tipo de tarea? Creo que la próxima ola del oficio de build-in-public va a ser sobre qué IA para qué parte del trabajo, no solo sobre si usás IA o no.
Si querés ver el resultado, lo estás leyendo. La home está en chandlernguyen.com. La escalera de producto está en /es/products/. El curso que dio origen a toda la idea del "operating model" está en /es/learn/.
Un abrazo, Chandler