Pendant environ quatre mois et demi, mon site portait la peau TRANSMISSION : sombre, cyan, ambre, et délibérément technique.
Fond navy-charcoal. Accents cyan. Panneaux glassy. Je l'avais construit comme ça exprès. J'avais passé dix-huit ans dans la pub. Je m'étais appris à coder à quarante ans. Je voulais que le site rende cette transition visible — pour quiconque atterrissait sur un article, défilait au-delà du wordmark, et remarquait l'esthétique d'outil de développeur, le signal était : cette personne a traversé.
Le site a fait son travail. Puis c'était fini.
Pendant le long week-end du Memorial Day, j'ai livré une refonte qui ne ressemble en rien à ce qui existait avant. Light mode. Fond warm paper. Rouge carmin à la place du cyan. Filets fins à la place des cartes arrondies. Un visible « Vol. 04 · Issue NN » dans le coin — le volume compte les années depuis que j'ai commencé à build in public, l'issue est l'ISO week en cours, les deux se mettent à jour tout seuls. Le kicker, le jour où tu lis ce texte, pourrait afficher Issue 22 ou 23 ou 41, selon le moment de ton passage. Il n'y a plus d'icône Sparkles nulle part. Le site est en ligne maintenant sur chandlernguyen.com.
Je pourrais écrire un article entier sur ces décisions. Mais l'histoire la plus utile, c'est la méthode. J'ai séparé la refonte entre deux modèles d'IA différents. Claude Opus 4.7 avec extended thinking a fait le design. Codex sur GPT-5.5 avec son réglage de reasoning le plus élevé a fait l'exécution. Et la fonction /goal dans Codex l'a laissé tourner en autonomie pendant près de quatre heures d'affilée, pendant que j'étais en balade ou en train de dîner.
Quatre jours. Deux modèles. Presque trente commits. Un site.
Voici ce que j'ai appris sur quel modèle utiliser pour quoi — et où se trouve encore la frontière.
Pourquoi TRANSMISSION devait partir
J'ai traversé de la pub vers le code sur les deux dernières années. Au début de cette année, le site avait rattrapé : je l'avais redesigné en TRANSMISSION précisément pour rendre cette transition visible. Quatre mois et demi plus tard, le signal a fini son boulot.
Le job suivant est différent. Les visiteurs qui arrivent depuis un article, depuis un thread LinkedIn, depuis une recherche Google ne viennent pas confirmer que j'écris du code. Ils viennent apprendre quelque chose sur l'IA dans les media operations, envisager d'acheter le cours, ou comparer le cours, Prova, DIALØGUE et STRAŦUM comme une échelle de produits. Le site avait besoin de signaler moins et de guider plus.
La manière la plus simple de décrire le changement : l'ancien site était une personnalité. Le nouveau site est un operating model. La même personne derrière, un job différent à faire. Cela impliquait une esthétique différente — plus légère, plus calme, éditoriale, le genre de surface où un article long peut respirer et où un CTA cours peut sembler honnête plutôt que pushy. Warm paper à la place du glass.
Mais le problème le plus dur n'était pas l'esthétique. C'était le throughput. Le site a treize locales, à peu près huit surfaces publiques (home, blog, post, products, learn, about, ask, course sales), un flow d'accès cours authentifié, un Stripe checkout, et un endpoint Sydney RAG. Refaire tout ça à la main aurait pris des semaines. Je n'avais pas des semaines.
Alors j'ai séparé le travail entre deux modèles d'IA.
Pourquoi séparer design et exécution
Le design et l'exécution sont deux tâches cognitives différentes.
Le design est lent. C'est du jugement sur la composition, sur la retenue, sur le fait qu'une teinte de warm paper ait l'air trop jaune sur un iPhone et qu'une autre teinte ait l'air trop froide. C'est se demander « quel genre de surface essaie-t-on de faire ici ? » avant « comment rend-on cette section ? ». Le bon travail de design comprime le temps — tu réfléchis pendant deux heures, puis tu prends une décision qui t'épargne dix heures d'exécution.
L'exécution est rapide. C'est de l'application de pattern. Étant donné un design system, génère les composants. Étant donné un composant, câble-le sur treize locales. Étant donné un layout de page, livre les variantes. Le travail n'est pas moins compétent, mais il est moins ambigu. La bonne réponse est généralement défendable par rapport au spec.
Des modèles d'IA différents sont meilleurs sur des tâches cognitives différentes. D'après ma propre expérience sur les derniers mois — d'abord avec Claude Opus 4.6, maintenant avec 4.7, tous les deux en extended thinking — Opus est le partenaire le plus complet. Meilleur en brainstorming. Meilleur en jugement design. Plus lent et moins chirurgicalement précis sur du pur code, mais il considère toute la composition avant de répondre et il raisonne d'une manière qui attrape pourquoi une police a l'air trop friendly et une autre a l'air juste.
Codex sur GPT-5.5 avec son réglage high-reasoning donne l'impression d'un ingénieur logiciel senior compétent qui n'est jamais passé près de l'équipe design. Il est rapide. Il est excellent en multi-step tool use — ouvrir des fichiers, les lire, les éditer, lancer des tests, ouvrir le suivant. Il n'a pas d'opinions fortes sur le fait qu'un bouton soit trop haut, mais il livre le bouton, et il livre chaque variante du bouton sur treize locales sans râler. Sa fonction /goal te laisse lui passer une cible — par exemple, "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" — et t'éloigner. Il planifiera les sous-étapes, les exécutera, lancera le build, réparera ce qui casse, et continuera. La plus longue plage où il a tourné sans surveillance pour moi, sur ce projet, a été d'un peu moins de quatre heures.
Je dois admettre que je n'avais pas planifié cette séparation délibérément au début. J'avais eu la conversation design avec Opus pendant les jours qui précédaient le week-end. Quand le long week-end a commencé, j'avais le document de direction design et le prototype desktop en main. C'est le week-end lui-même qui a vu Codex recevoir l'exécution, et dans l'heure suivant ce passage, j'ai remarqué à quel point chaque modèle était mieux adapté à sa moitié du travail.
Ce qu'a fait Opus : la phase design
Le travail de design s'est passé dans une longue conversation avec Opus pendant les jours qui précédaient la refonte. Deux artefacts en sont sortis, et tous les deux vivent maintenant dans le repo :
1. Un document de direction design. Six fichiers markdown dans doc/v3-design/ — le why, les tokens, les patterns mobile, les specs de page, les contraintes d'accessibilité, le plan d'exécution. Plus de treize mille mots de décisions, écrits pour l'essentiel par Opus à partir d'un brief que je lui avais donné. La directive : « le prochain site doit ressembler à un petit magazine imprimé, pas à un dashboard SaaS. Mériter l'attention par la retenue. Utiliser le framework Operating Model 2×2 comme signature visuelle. »
2. Un prototype HTML desktop. Un dossier plat dans public/design-prototype-v2/ avec six pages et un style.css partagé. Pas de React, pas de Tailwind, pas de framework — juste du HTML écrit à la main pour que je puisse cliquer dans chaque page sur un serveur local et sentir si le design system tenait vraiment comme un système. Le prototype a été la source de vérité du traitement visuel pour le reste du week-end. En cas de doute pendant la refonte, la réponse était « match the prototype. »
Opus a pris les décisions qui comptaient le plus. Quelques moments précis :
-
L'inversion de police. Un pass design antérieur avait verrouillé Manrope comme police d'affichage sur la base de la disponibilité et de la facilité de livraison — commit fait dans une session Claude Sonnet 4.6. Dix-huit heures plus tard, j'avais déplacé la conversation design vers Opus 4.7 en extended thinking, et le premier mouvement d'Opus a été de reconsidérer le verrou. Après avoir passé une soirée sur la page de specimen officielle de PP Neue Montreal à comparer les letterforms, le changement est entré. Le commit message se lit comme une scène de crime typographique : "Manrope rendered too rounded and friendly... Satoshi has the same condensed-grotesque proportions, the same double-storey
a, single-storeyg, sweptRleg, cleanly-sheared terminals." Le pli intéressant, c'est que deux modèles Claude différents ont atteint des jugements différents sur la même décision. Sonnet a pris l'option safe. Opus a pris la bonne. -
Le choix du carmin. Le cyan est l'accent par défaut de l'IA. Opus et moi avons atterri sur le rouge carmin —
#c33824, un rouge encre d'imprimeur, la couleur d'une marque d'éditeur sur une galley proof ou d'un volume latin sur une étagère de la Loeb Classical Library. Le raisonnement était précis : « le site essaie d'être éditorial, pas outil de développeur. Le cyan signale tech. Le carmin signale craft. Utiliser le carmin avec parcimonie, toujours à fort contraste, idéalement sur warm paper. » Ce n'est pas une décision qu'un modèle optimisé pour l'exécution serait allé chercher tout seul. -
L'Operating Model comme signature visuelle. Le framework 2×2 que j'enseigne dans le cours — Automate / Protect / Deepen / Change — devient une marque de fabrique discrète sur le nouveau site. Dans l'implémentation actuelle, il n'apparaît qu'à deux endroits, avec retenue : le bloc thesis de la page d'accueil et un petit marqueur thesis sur les articles longs. Le framework lui-même était à moi ; l'idée d'en faire l'identité visuelle du site est sortie de la conversation design avec Opus.
-
Light over dark. Opus a plaidé pour le light mode comme personnalité et le dark mode comme variante supportée. L'argument : la lecture longue est plus facile sur warm paper que sur glass ; les étiquettes de prix paraissent plus honnêtes sur fond clair ; presque tous les outils d'IA livrent en dark par défaut, donc le light est le différenciateur. J'ai été en désaccord pendant quelques heures, puis j'ai été d'accord.
Opus, c'était surtout la boucle design et review ; Codex a fait les pass d'implémentation. Le job d'Opus, c'était la part du travail où être lent payait.
Ce qu'a fait Codex : la phase exécution
Une fois le document de design et le prototype faits, le travail a basculé vers Codex.
J'ai ouvert une nouvelle session Codex, je lui ai donné les fichiers de direction design en contexte, et j'ai commencé à lancer des sessions /goal. Chaque goal était une cible multi-étapes avec un end state clair :
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.
Ce genre de cible multi-étapes est exactement ce pour quoi /goal est conçu. Codex planifie les sous-étapes, les exécute, lance pnpm build pour vérifier les erreurs de typage, répare ce qui casse, relance le build, et continue. Je suis revenu d'une balade et le v3 shell était en place dans la codebase derrière le flag, avec les nouvelles polices chargées et la bottom nav qui rendait sur mobile.
Sessions /goal suivantes :
- Générer les pages home et archive v3 depuis le prototype.
- Générer le layout d'article v3, avec la barre de progression de lecture et le bouton de partage v3.
- Générer les pages products et learn v3, en collant à la structure de l'échelle dans le spec.
- Aligner visuellement les pages course sales, login, signup, MFA, et access existantes sur la v3, sans toucher à la logique sous-jacente Stripe ou Supabase Auth.
- Localiser les surfaces course v3 et Ask Sydney sur les treize locales, en utilisant les fichiers
messages/{locale}.jsonexistants comme source de traduction.
La plus longue exécution sans intervention a duré un peu moins de quatre heures. La plus courte, environ quarante-cinq minutes. Sur ces quatre jours, j'ai livré presque trente commits — la plupart issus du premier ou du deuxième pass de Codex, avec de petits nettoyages manuels là où la sortie du modèle était correcte mais pas tout à fait à la bonne forme. Le bilan honnête : je pense que Codex a écrit la grande majorité du code qui tourne réellement en production aujourd'hui. J'ai écrit ou édité le reste.
La chose la plus utile de /goal n'est pas la vitesse. C'est l'autonomie. La plupart des sessions de code que j'ai faites avec des outils d'IA m'obligent à rester au clavier — confirmer un changement, accepter le fichier suivant, relire le diff. /goal te laisse spécifier l'end state que tu veux et t'éloigner. Tu reviens soit à un changement fini, soit à une session en pause à l'endroit où le modèle a besoin que tu prennes une décision. La forme du travail est différente. Tu deviens un planificateur de sessions de plusieurs heures au lieu d'être le baby-sitter d'éditions unitaires.
Où se trouve encore la frontière
Séparer design et exécution entre deux modèles n'est pas un tour de magie. Il y a encore des moments où l'un a besoin de l'autre, et quelques moments où ni l'un ni l'autre ne suffit seul.
L'icône Sparkles. Codex a généré une mobile shell v3 propre avec une icône Sparkles ✨ sur l'onglet Ask — le tell universel des outils d'IA. L'icône était correcte par rapport au spec ; le spec ne disait pas « ne pas utiliser le cliché. » Je l'ai remarqué quelques jours plus tard et je suis retourné voir Opus pour discuter des remplacements. On a fait plusieurs itérations : la marque Operating Model, puis un point d'interrogation Newsreader en italique en rouge carmin — le genre de glyphe qu'on pourrait trouver en marginalia dans un vieil essai. La solution finale était l'idée d'Opus. Codex l'a livrée en quinze minutes.
Le moment Hinomaru. Pendant que la marque Operating Model était posée en haut à gauche de la mobile app bar, à côté de mon nom, je l'avais sous les yeux depuis deux ou trois jours. Un petit point carmin sur un carré warm paper. Puis un soir, je l'ai regardée comme quelqu'un d'autre l'aurait fait, et j'ai senti une petite bouffée de prise de conscience. Elle ressemblait exactement au drapeau japonais. Le Hinomaru. Un petit soleil rouge sur un champ pâle. Ni Opus ni Codex n'avaient attrapé ça. Opus avait designé la marque ; Codex l'avait implémentée ; tous les deux l'avaient relue. L'association visuelle était un pattern culturel qu'aucun des deux modèles ne pouvait voir. J'ai supprimé la marque du wordmark et je suis allé chercher une autre solution. (Le même ? italique a fini par remplir sa place sur l'onglet Ask.)
Le rollout sur 13 locales. Opus aurait pu designer les nuances UI de chaque locale avec soin mais aurait pris des jours pour le faire. Codex n'aurait pas pu prendre le jugement design seul, mais il pouvait livrer les treize locales en une soirée une fois les patterns posés. C'est l'exemple le plus littéral de la séparation : design lent, exécution rapide.
Choisir trois polices qui marchent ensemble. Opus a choisi Satoshi (display), Newsreader (italic accent), et JetBrains Mono (labels). Codex n'aurait pas choisi cette combinaison tout seul — et je ne suis pas sûr que je l'aurais fait non plus sans la lenteur d'Opus dans la conversation. La composition à trois polices est un choix design, pas un choix d'exécution.
La conversation entre les deux systèmes se passe dans ma tête, pas entre les modèles. C'est la part qui n'est toujours pas automatisable en 2026 — et je pense que c'est la part qui définit ce que le goût veut dire en ce moment.
Bilan honnête
Quatre jours. Presque trente commits. La v3 en production est en ligne sur chandlernguyen.com. Le nouveau site fait le nouveau job — aider les visiteurs à trouver quoi lire ensuite, au lieu de leur dire que j'ai traversé.
Le site a un problème qui reste, que je continue de poursuivre. Au moment du draft, Lighthouse mobile en production donnait l'archive blog à 4,6 secondes alors que ma trace Chrome DevTools en local montrait la même image peinte en 264 millisecondes — même code, modèle réseau très différent. Ma piste de correction de tête en ce moment, c'est la pression des préchargements de polices : trois webfonts préchargées plus trois chunks CSS render-blocking qui courent contre l'image jusqu'à la ligne d'arrivée sur une connexion mobile throttlée. J'ai déployé la version la plus petite de ce fix le dernier jour et il me faut encore un Lighthouse frais pour confirmer que c'est bien passé. L'article que tu lis a été écrit avant que j'aie le chiffre post-fix.
Coût d'abonnement : mon abonnement Codex au tier le plus élevé, plus l'abonnement Claude Max que j'avais déjà. Ensemble, quelques centaines de dollars par mois. Pas cher, vu le throughput.
Le fait que la v3 soit arrivée en quatre jours plutôt qu'en trois semaines tient principalement à ce que les phases de design et d'exécution ont été séparées et confiées aux modèles qui étaient meilleurs sur chacune. Je ne pense pas que ce soit universel. Il y a des projets où un seul modèle peut faire les deux, et des projets où aucun des deux n'est le bon partenaire. Mais pour une refonte multi-pages, multi-locales, multi-surfaces avec un point de vue design fort, cette séparation est la méthode que je reprendrais.
Si tu as fait toi-même une refonte assistée par IA récemment, j'aimerais sincèrement entendre comment tu as réparti le travail. Tu as utilisé un seul modèle de bout en bout ? Tu as séparé par phase comme moi, ou sur un autre axe — par composant, par fichier, par type de tâche ? Je pense que la prochaine vague du build-in-public craft va porter sur quelle IA pour quelle part du travail, pas seulement sur le fait d'utiliser ou non de l'IA.
Si tu veux voir le résultat, tu es en train de le lire. La page d'accueil est sur chandlernguyen.com. L'échelle de produits est sur /products/. Le cours qui a lancé toute l'idée d'« operating model » est sur /learn/.
À bientôt,
Chandler