Etwa viereinhalb Monate lang trug meine Site das TRANSMISSION-Gewand: dunkel, cyan, bernsteinfarben und bewusst technisch.
Marineblau-anthrazitfarbener Hintergrund. Cyanfarbene Akzente. Glasartige Panels. Ich hatte das ganz bewusst so gebaut. Achtzehn Jahre hatte ich in der Werbung verbracht. Mit vierzig habe ich mir selbst das Programmieren beigebracht. Ich wollte, dass die Site diesen Übergang sichtbar macht — wer auf einem Blogpost landete, am Wortzeichen vorbeiscrollte und die Developer-Tool-Ästhetik bemerkte, sollte das Signal lesen können: dieser Mensch hat die Seite gewechselt.
Sie hat ihren Job erfüllt. Und dann war Schluss.
Über das lange Memorial-Day-Wochenende habe ich ein Redesign ausgeliefert, das nichts mehr mit dem davor zu tun hat. Lichter Modus. Warmer Papier-Hintergrund. Karminrot statt Cyan. Haarfeine Linien statt abgerundeter Karten. Oben in der Ecke ein gut sichtbares "Vol. 04 · Issue NN" — die Volume-Zahl zählt die Jahre, seit ich öffentlich baue, die Issue-Nummer ist die aktuelle ISO-Woche, beides aktualisiert sich von selbst. Wenn du das hier liest, kann der Kicker also Issue 22, 23 oder 41 lauten, je nachdem, wann du vorbeischaust. Kein Sparkles-Icon mehr, nirgendwo. Die Site läuft jetzt live auf chandlernguyen.com.
Ich könnte über all diese Entscheidungen einen eigenen Beitrag schreiben. Aber die nützlichere Geschichte ist der Workflow. Ich habe das Redesign auf zwei verschiedene KI-Modelle aufgeteilt. Claude Opus 4.7 mit Extended Thinking hat das Design gemacht. Codex auf GPT-5.5 mit der höchsten Reasoning-Stufe hat die Umsetzung übernommen. Und die /goal-Funktion in Codex ließ es eigenständig fast vier Stunden am Stück arbeiten, während ich spazieren war oder zu Abend gegessen habe.
Vier Tage. Zwei Modelle. Fast dreißig Commits. Eine Site.
Hier ist, was ich darüber gelernt habe, welches Modell wofür taugt — und wo die Grenze immer noch verläuft.
Warum TRANSMISSION gehen musste
Über die letzten zwei Jahre habe ich von der Werbung in den Code gewechselt. Anfang dieses Jahres hatte die Site aufgeholt: Ich hatte sie als TRANSMISSION neu gestaltet, gerade um diesen Übergang sichtbar zu machen. Viereinhalb Monate später hatte dieses Signal seinen Job erledigt.
Die nächste Aufgabe ist eine andere. Wer von einem Blogpost, einem LinkedIn-Thread oder einer Google-Suche herkommt, ist nicht da, um sich bestätigen zu lassen, dass ich Code schreibe. Diese Leute wollen etwas über KI in Media-Operations lernen, überlegen, den Kurs zu kaufen, oder wollen den Kurs, Prova, DIALØGUE und STRAŦUM als Produktleiter vergleichen. Die Site musste weniger signalisieren und mehr führen.
Am leichtesten lässt sich der Wechsel so beschreiben: die alte Site war eine Persönlichkeit. Die neue Site ist ein Operating Model. Gleicher Mensch dahinter, anderer Job. Das hieß eine andere Ästhetik — leichter, ruhiger, redaktioneller, eine Oberfläche, auf der ein langer Blogpost atmen kann und ein Kurs-CTA ehrlich statt aufdringlich wirkt. Warmes Papier statt Glas.
Das schwierigere Problem war aber gar nicht die Ästhetik. Es war der Durchsatz. Die Site hat dreizehn Lokalisierungen, etwa acht öffentliche Oberflächen (Home, Blog, Post, Products, Learn, About, Ask, Course-Sales), einen authentifizierten Kurszugang-Flow, einen Stripe-Checkout und einen Sydney-RAG-Endpoint. Das alles per Hand neu zu bauen, hätte Wochen gebraucht. Wochen hatte ich nicht.
Also habe ich die Arbeit auf zwei KI-Modelle aufgeteilt.
Warum Design und Umsetzung überhaupt trennen
Design und Umsetzung sind unterschiedliche kognitive Aufgaben.
Design ist langsam. Es ist Urteilsvermögen über Komposition, über Zurückhaltung, darüber, ob ein bestimmter Warmweißton auf einem iPhone zu gelb wirkt und ein anderer zu kalt. Es bedeutet, "was für eine Art Oberfläche will das hier eigentlich sein?" zu fragen, bevor man fragt "wie rendern wir diesen Abschnitt?". Gute Designarbeit komprimiert Zeit — du denkst zwei Stunden nach und triffst dann eine Entscheidung, die dir zehn Stunden Umsetzung erspart.
Umsetzung ist schnell. Sie ist Musteranwendung. Gegeben ein Designsystem, generiere die Komponenten. Gegeben eine Komponente, verdrahte sie über dreizehn Lokalisierungen hinweg. Gegeben ein Seitenlayout, liefere die Varianten. Die Arbeit ist nicht weniger anspruchsvoll, aber sie ist weniger mehrdeutig. Die richtige Antwort lässt sich meistens gegen die Spezifikation verteidigen.
Verschiedene KI-Modelle sind in verschiedenen kognitiven Aufgaben besser. Aus meiner Erfahrung der letzten Monate — erst mit Claude Opus 4.6, jetzt mit 4.7, beide auf ihrer Extended-Thinking-Einstellung — ist Opus der ausgewogenere Partner. Besser im Brainstorming. Besser beim Designurteil. Langsamer und weniger chirurgisch präzise bei reinem Code, aber Opus betrachtet die gesamte Komposition, bevor es antwortet, und es argumentiert auf eine Weise, die mitbekommt, warum eine Schrift zu freundlich wirkt und eine andere richtig.
Codex auf GPT-5.5 mit hoher Reasoning-Stufe fühlt sich an wie ein kompetenter Senior-Software-Engineer, der dem Designteam nie auch nur nahe gekommen ist. Es ist schnell. Es ist exzellent in mehrstufiger Tool-Nutzung — Dateien öffnen, lesen, editieren, Tests laufen lassen, die nächste Datei öffnen. Es hat keine starken Meinungen darüber, ob ein Button zu hoch wirkt, aber es liefert den Button, und es liefert jede Variante des Buttons über dreizehn Lokalisierungen hinweg, ohne zu murren. Seine /goal-Funktion erlaubt dir, ihm ein Ziel zu übergeben — zum Beispiel "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" — und einfach wegzugehen. Es plant die Teilschritte, führt sie aus, lässt den Build laufen, repariert, was kaputtgeht, und macht weiter. Die längste Strecke, die es bei diesem Projekt unbeaufsichtigt durchgezogen hat, waren knapp vier Stunden.
Ich muss zugeben, dass ich diese Aufteilung am Anfang gar nicht bewusst geplant hatte. Ich hatte das Designgespräch mit Opus über die Tage vor dem Wochenende geführt. Als das lange Wochenende anfing, hatte ich das Designrichtungs-Dokument und den Desktop-Prototypen in der Hand. Das Wochenende selbst war der Moment, in dem ich die Umsetzung an Codex übergeben habe, und innerhalb einer Stunde habe ich gemerkt, wie viel besser jedes Modell zu seiner Hälfte der Arbeit passte.
Was Opus gemacht hat: die Designphase
Die Designarbeit lief in einem langen Gespräch mit Opus über die Tage vor dem Rebuild. Zwei Artefakte sind aus diesem Gespräch entstanden, die beide jetzt im Repo liegen:
1. Ein Designrichtungs-Dokument. Sechs Markdown-Dateien in doc/v3-design/ — das Warum, die Tokens, die Mobile-Patterns, die Page-Specs, die Accessibility-Constraints, der Umsetzungsplan. Mehr als dreizehntausend Wörter an Entscheidungen, größtenteils von Opus geschrieben, ausgehend von einem Briefing, das ich ihm gegeben hatte. Die Direktive: "die nächste Site sollte sich anfühlen wie ein kleines gedrucktes Magazin, nicht wie ein SaaS-Dashboard. Aufmerksamkeit durch Zurückhaltung verdienen. Das Operating Model 2×2-Framework als visuelle Signatur nutzen."
2. Ein Desktop-HTML-Prototyp. Ein flaches Verzeichnis in public/design-prototype-v2/ mit sechs Seiten und einem gemeinsamen style.css. Kein React, kein Tailwind, kein Framework — nur handgeschriebenes HTML, damit ich auf einem lokalen Server jede Seite durchklicken und spüren konnte, ob das Designsystem als System tatsächlich trägt. Der Prototyp war für den Rest des Wochenendes die Quelle der Wahrheit für die visuelle Behandlung. Im Zweifel war die Antwort: "match the prototype."
Opus hat die Entscheidungen getroffen, die am meisten zählten. Ein paar konkrete Momente:
-
Die Schrift-Kehrtwende. Ein früherer Designdurchgang hatte Manrope als Display-Schrift festgelegt, mit der Begründung, dass sie verfügbar und leicht auszuliefern sei — committet in einer Claude-Sonnet-4.6-Session. Achtzehn Stunden später hatte ich das Designgespräch auf Opus 4.7 mit Extended Thinking verlegt, und Opus' erster Zug war, diese Festlegung nochmal infrage zu stellen. Nachdem ich einen Abend lang auf der offiziellen PP-Neue-Montreal-Specimen-Page Buchstabenformen verglichen hatte, war der Wechsel gemacht. Die Commit-Message liest sich wie ein typografischer Tatortbericht: "Manrope rendered too rounded and friendly... Satoshi has the same condensed-grotesque proportions, the same double-storey
a, single-storeyg, sweptRleg, cleanly-sheared terminals." Der spannende Twist ist, dass zwei verschiedene Claude-Modelle bei derselben Entscheidung zu unterschiedlichen Urteilen kamen. Sonnet wählte die sichere Option. Opus wählte die richtige. -
Die Karmin-Entscheidung. Cyan ist die AI-Default-Akzentfarbe. Opus und ich sind bei Karminrot gelandet —
#c33824, einem Druckerfarben-Rot, der Farbe einer Lektorenkorrektur auf einer Fahnenprobe oder eines lateinischen Bandes im Regal der Loeb Classical Library. Die Begründung war konkret: "the site is trying to feel editorial, not developer-tool. Cyan signals tech. Carmine signals craft. Use the carmine sparingly, always at high contrast, ideally on warm paper." Diese Entscheidung würde ein auf Umsetzung optimiertes Modell von sich aus nicht treffen. -
Das Operating Model als visuelle Signatur. Das 2×2-Framework, das ich im Kurs unterrichte — Automate / Protect / Deepen / Change — wird zu einer ruhigen Marken-Marke auf der neuen Site. In der aktuellen Umsetzung taucht es an zwei zurückhaltenden Stellen auf: im Thesen-Block auf der Startseite und als kleiner Thesen-Marker auf langen Blogposts. Das Framework selbst kam von mir; der Move, es zur visuellen Identität der Site zu machen, kam aus dem Designgespräch mit Opus.
-
Hell statt Dunkel. Opus hat argumentiert, dass der lichte Modus die Persönlichkeit ist und der dunkle Modus eine unterstützte Variante. Das Argument: Long-Form-Lesen geht auf warmem Papier leichter als auf Glas; Preisschilder wirken auf hellem Hintergrund ehrlicher; nahezu jedes KI-Tool wird standardmäßig dunkel ausgeliefert, also ist hell der Differenzierer. Ich war ein paar Stunden lang anderer Meinung, dann habe ich zugestimmt.
Opus war hauptsächlich die Design- und Review-Schleife; Codex hat die Implementierungsdurchgänge gemacht. Opus' Job war der Teil der Arbeit, bei dem es sich auszahlt, langsam zu sein.
Was Codex gemacht hat: die Umsetzungsphase
Sobald das Designdokument und der Prototyp standen, ist die Arbeit zu Codex gewandert.
Ich habe eine neue Codex-Session geöffnet, ihr die Designrichtungs-Dateien als Kontext gegeben und angefangen, /goal-Sessions zu fahren. Jedes Goal war ein mehrstufiges Ziel mit einem klaren Endzustand:
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.
Genau für diese Art mehrstufiges Ziel ist /goal gebaut. Codex plant die Teilschritte, führt sie aus, lässt pnpm build laufen, um Type-Errors zu finden, repariert, was kaputtgeht, lässt den Build nochmal laufen und macht weiter. Ich kam von einem Spaziergang zurück, und der v3-Shell war hinter dem Flag live in der Codebasis, mit den neuen Schriften geladen und der Bottom-Nav, die auf Mobil rendert.
Spätere /goal-Sessions:
- Die v3-Home- und Archive-Pages aus dem Prototypen generieren.
- Das v3-Post-Layout generieren, inklusive Reading-Progress-Bar und v3-Share-Button.
- Die v3-Products- und Learn-Pages generieren, passend zur Ladder-Struktur in der Spec.
- Die bestehenden Course-Sales-, Login-, Signup-, MFA- und Access-Pages visuell auf v3 ausrichten, ohne die zugrunde liegende Stripe- oder Supabase-Auth-Logik zu verändern.
- Die v3-Course- und Ask-Sydney-Oberflächen über alle dreizehn Lokalisierungen hinweg lokalisieren, mit den bestehenden
messages/{locale}.json-Dateien als Übersetzungsquelle.
Der längste Lauf, der ohne Eingriff durchlief, waren knapp vier Stunden. Der kürzeste rund fünfundvierzig Minuten. Über die vier Tage habe ich fast dreißig Commits ausgeliefert — die meisten davon Codex' erster oder zweiter Durchgang, mit kleinen manuellen Aufräumarbeiten dort, wo der Output korrekt, aber nicht ganz die richtige Form hatte. Ehrliche Bilanz: ich glaube, Codex hat den Großteil des Codes geschrieben, der heute in Produktion läuft. Den Rest habe ich geschrieben oder editiert.
Das mit Abstand Nützlichste an /goal ist nicht die Geschwindigkeit. Es ist die Autonomie. In den meisten Coding-Sessions mit KI-Tools muss ich an der Tastatur bleiben — eine Änderung bestätigen, die nächste Datei akzeptieren, den Diff reviewen. Bei /goal kannst du den Endzustand spezifizieren, den du willst, und einfach weggehen. Du kommst entweder zu einer fertigen Änderung zurück oder zu einer pausierten Session genau an der Stelle, an der das Modell ein Urteil von dir braucht. Die Form der Arbeit ändert sich. Du wirst zur Planerin oder zum Planer mehrstündiger Sessions statt zum Babysitter einzelner Edits.
Wo die Grenze immer noch verläuft
Design und Umsetzung auf zwei Modelle aufzuteilen, ist kein Zaubertrick. Es gibt nach wie vor Momente, in denen das eine Modell das andere braucht, und ein paar Momente, in denen keines von beiden allein reicht.
Das Sparkles-Icon. Codex hat einen sauberen v3-Mobile-Shell mit einem Sparkles ✨-Icon auf dem Ask-Tab generiert — das universelle AI-Tool-Erkennungszeichen. Das Icon war korrekt gegen die Spec; die Spec sagte nicht "do not use the cliché." Ein paar Tage später ist es mir aufgefallen und ich bin zu Opus zurück, um Ersatz zu besprechen. Wir sind durch mehrere Iterationen gegangen: das Operating-Model-Zeichen, dann ein kursives Newsreader-Fragezeichen in Karminrot — die Art Glyphe, die du als Randbemerkung in einem alten Essay finden könntest. Die finale Lösung war Opus' Idee. Codex hat sie in fünfzehn Minuten ausgeliefert.
Der Hinomaru-Moment. Während das Operating-Model-Zeichen oben links in der mobilen App-Bar saß, neben meinem Namen, hatte ich es zwei oder drei Tage lang angeschaut. Ein kleiner karminroter Punkt auf einem warmen Papier-Quadrat. Dann, eines Abends, habe ich es so angeschaut, wie jemand anderes es ansehen würde, und eine kleine Welle der Erkenntnis kam über mich. Es sah genau aus wie die japanische Flagge. Der Hinomaru. Eine kleine rote Sonne auf blassem Feld. Weder Opus noch Codex hatten das gesehen. Opus hatte das Zeichen entworfen; Codex hatte es implementiert; beide hatten es reviewt. Die visuelle Assoziation war ein kulturelles Muster, das kein Modell sehen konnte. Ich habe das Zeichen aus dem Wortzeichen gelöscht und nach einer anderen Lösung gegriffen. (Genau das kursive ? ist am Ende auf dem Ask-Tab gelandet.)
Der Rollout über 13 Lokalisierungen. Opus hätte die UI-Nuancen jeder Sprache wohldurchdacht entwerfen können, aber dafür Tage gebraucht. Codex hätte das Designurteil allein nicht treffen können, hätte aber alle dreizehn Lokalisierungen an einem Abend ausgeliefert, sobald die Muster standen. Das ist das wörtlichste Beispiel für die Aufteilung: design slow, execute fast.
Drei Schriften zu wählen, die zusammenpassen. Opus hat Satoshi (Display), Newsreader (kursiver Akzent) und JetBrains Mono (Labels) gewählt. Codex hätte diese Kombination von sich aus nicht gewählt — und ich bin nicht sicher, ob ich es ohne Opus' Langsamkeit im Gespräch geschafft hätte. Die Drei-Schriften-Komposition ist eine Designentscheidung, keine Umsetzungsentscheidung.
Das Gespräch zwischen den beiden Systemen findet in meinem Kopf statt, nicht zwischen den Modellen. Das ist der Teil, der 2026 noch nicht automatisierbar ist — und ich glaube, das ist der Teil, der gerade definiert, was Geschmack bedeutet.
Ehrliche Bilanz
Vier Tage. Fast dreißig Commits. Production-v3 ist live auf chandlernguyen.com. Die neue Site macht den neuen Job — sie hilft Besucherinnen und Besuchern, das Nächste zu finden, was sie lesen wollen, statt ihnen zu erzählen, dass ich die Seite gewechselt habe.
Die Site hat ein verbleibendes Problem, hinter dem ich noch her bin. Beim Schreiben dieses Beitrags zeigte Production-Lighthouse-Mobile das Blog-Archiv bei 4,6 Sekunden landen, während mein lokaler Chrome-DevTools-Trace dasselbe Bild in 264 Millisekunden gemalt hat — gleicher Code, sehr unterschiedliches Netzwerkmodell. Mein aktueller Hauptverdacht: Font-Preload-Druck — drei vorgeladene Webfonts plus drei render-blockierende CSS-Chunks, die auf einer gedrosselten Mobilverbindung mit dem Bild um die Ziellinie rennen. Ich habe gestern die kleinste sinnvolle Version dieses Fixes deployt und brauche immer noch einen frischen Lighthouse-Lauf, um zu bestätigen, dass er wirkt. Der Post, den du gerade liest, wurde geschrieben, bevor ich die Zahl danach habe.
Abo-Kosten: mein Codex-Abo auf der höchsten Stufe plus das Claude-Max-Abo, das ich ohnehin hatte. Zusammen ein paar hundert Dollar im Monat. Günstig, gemessen am Durchsatz.
Dass v3 in vier Tagen statt drei Wochen passiert ist, liegt vor allem daran, dass Design- und Umsetzungsphase getrennt und den Modellen zugewiesen wurden, die jeweils besser darin waren. Ich glaube nicht, dass das universell gilt. Es gibt Projekte, in denen ein Modell beides kann, und Projekte, bei denen keines der beiden Modelle der richtige Partner ist. Aber für ein mehrseitiges, mehrsprachiges, oberflächenreiches Redesign mit einer klaren Designhaltung ist diese Aufteilung der Workflow, zu dem ich wieder greifen würde.
Falls du in letzter Zeit selbst einen KI-gestützten Rebuild gemacht hast, würde ich wirklich gerne hören, wie du die Arbeit aufgeteilt hast. Hast du ein einziges Modell von Anfang bis Ende benutzt? Hast du wie ich nach Phasen aufgeteilt — oder nach einer anderen Achse, nach Komponente, nach Datei, nach Task-Typ? Ich glaube, die nächste Welle Build-in-Public-Handwerk wird darum gehen, welche KI für welchen Teil der Arbeit — nicht mehr nur, ob du überhaupt KI benutzt.
Wenn du das Ergebnis sehen willst, du liest es gerade. Die Startseite ist auf chandlernguyen.com. Die Produktleiter ist auf /products/. Der Kurs, mit dem die ganze "Operating Model"-Idee angefangen hat, ist auf /learn/.
Viele Grüße, Chandler