Mga apat at kalahating buwan, suot ng site ko ang TRANSMISSION skin: dark, cyan, amber, at sadyang technical.
Navy-charcoal background. Cyan accents. Glassy panels. Sinadya ko talaga itong gawin ganoon. Labing-walong taon ako sa advertising. Sa edad na apatnapu, tinuruan ko sarili ko mag-code. Gusto kong ipakita ng site ang transition na yun — para kahit sino na dumating sa isang blog post, mag-scroll past sa wordmark, at mapansin ang developer-tool aesthetic, malinaw ang signal: crossed over na 'tong tao.
Nagawa niya ang trabaho niya. Tapos, tapos na rin.
Sa mahabang Memorial Day weekend, nag-ship ako ng redesign na kabaligtaran ng dating itsura. Light mode. Warm paper background. Carmine red kapalit ng cyan. Hairline rules kapalit ng rounded cards. Sa corner, may nakikitang "Vol. 04 · Issue NN" — yung volume bilang ng mga taon mula nung nag-build-in-public ako, yung issue ay yung current ISO week, parehong naka-wire para mag-update mag-isa. Sa araw na binabasa mo 'to, baka Issue 22 o 23 o 41 ang nakalagay, depende kung kailan ka dumating. Wala nang Sparkles icon kahit saan. Live na ang site sa chandlernguyen.com.
Pwede akong magsulat ng buong post tungkol sa mga decision na yan. Pero ang mas useful na kuwento ay yung workflow. Hinati ko ang redesign sa dalawang magkaibang AI model. Claude Opus 4.7 with extended thinking ang gumawa ng design. Codex sa GPT-5.5 sa pinakamataas na reasoning setting niya ang nag-execute. At dahil sa /goal function ng Codex, halos apat na oras siyang tumakbo mag-isa, habang naglalakad ako o kumakain ng hapunan.
Apat na araw. Dalawang model. Halos tatlumpung commit. Isang site.
Eto ang natutunan ko tungkol sa kung anong model para saan — at kung saan pa rin nakaupo ang boundary.
Bakit kailangan nang mawala ang TRANSMISSION
Nag-cross ako mula advertising papunta sa code nitong nakaraang dalawang taon. Pagdating ng simula ng taong 'to, naka-catch up na ang site: nire-redesign ko siya bilang TRANSMISSION para mismong ipakita yung transition na 'yon. Apat at kalahating buwan pagkatapos, tapos na yung signal na 'yon.
Iba na ang susunod na trabaho. Yung mga visitor na galing sa blog post, sa LinkedIn thread, sa Google search, hindi sila pumupunta para i-confirm na nagco-code ako. Pumupunta sila para matuto ng tungkol sa AI sa media operations, para mag-consider bilhin yung course, o para i-compare ang course, Prova, DIALØGUE, at STRAŦUM bilang product ladder. Kailangan ng site na mag-signal ng mas konti at mag-guide ng mas marami.
Pinakamadaling paraan para i-describe ang shift: yung dating site, isa siyang personality. Yung bagong site, isa siyang operating model. Parehong tao sa likod, ibang trabaho. Yun ay ibig sabihin, iba ang aesthetic — mas magaan, mas calm, mas editorial, yung klase ng surface kung saan kayang huminga ng mahabang blog post at kung saan makakaramdaman na honest ang course CTA, hindi pushy. Warm paper kapalit ng glass.
Pero ang mas mahirap na problem hindi yung aesthetic. Yung throughput. May labintatlong locale ang site, may walo o ganun na public surfaces (home, blog, post, products, learn, about, ask, course sales), isang authenticated course access flow, isang Stripe checkout, at isang Sydney RAG endpoint. Aabutin ng linggo kung manual lahat 'to. Wala akong linggo.
Kaya hinati ko ang trabaho sa dalawang AI model.
Bakit kailangan talagang hatiin ang design at execution
Iba ang design at execution na cognitive tasks.
Mabagal ang design. Judgment 'to tungkol sa composition, sa restraint, sa kung yung isang shade ng warm paper ay mukhang sobrang dilaw sa iPhone at yung isa ay mukhang sobrang malamig. Itong pagtanong na "anong klaseng surface ba talaga ang gusto nitong maging?" bago yung "paano natin ire-render ang section na 'to?". Mga good design work, kino-compress nila ang oras — nag-iisip ka ng dalawang oras tapos nag-decide ng isa na magse-save sayo ng sampung oras na execution.
Mabilis naman ang execution. Pattern application 'to. Bigyan mo ng design system, mag-generate ng components. Bigyan mo ng component, i-wire sa labintatlong locale. Bigyan mo ng page layout, mag-ship ng mga variant. Hindi 'to less skilled, pero less ambiguous. Yung tamang sagot, kadalasan, defensible against sa spec.
May ibang AI model na mas magaling sa ibang cognitive task. Galing sa sariling experience ko ngayong nakaraang buwan — una sa Claude Opus 4.6 tapos ngayon sa 4.7, pareho sa extended-thinking setting nila — mas well-rounded partner si Opus. Mas magaling sa brainstorming. Mas magaling sa design judgment. Mas mabagal at hindi gaanong surgically precise sa puro code, pero ini-consider niya yung buong composition bago sumagot at nag-re-reason siya sa paraang nahuhuli niya kung bakit yung isang font sobrang friendly at yung isa naman, tama.
Si Codex sa GPT-5.5 sa high-reasoning setting, parang competent senior software engineer na hindi lang talaga lumapit sa design team. Mabilis siya. Excellent sa multi-step tool use — nagbubukas ng files, nagbabasa, nag-eedit, nagpa-patakbo ng tests, nagbubukas ng susunod. Walang strong opinions kung sobrang tall ng button, pero nai-ship niya ang button, at nai-ship niya lahat ng variant sa labintatlong locale ng walang reklamo. Sa /goal function niya, pwede mong sabihin ang target — for example, "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" — at umalis ka na. Mag-plan siya ng sub-steps, ie-execute niya, ipa-run niya ang build, aayusin niya ang nasira, at magpapatuloy. Yung pinakamatagal na run niya na hindi ko siya binabantayan sa project na 'to ay halos apat na oras.
Aaminin ko, hindi ko 'to planado talaga sa simula. May design conversation na ako kasama si Opus nung mga araw bago mag-weekend. Pagsimula nung mahabang weekend, hawak ko na yung design direction document at yung desktop prototype. Yung weekend mismo, dun ko inabot kay Codex ang execution, at sa loob ng isang oras, na-notice ko kung paano kaninong model ang mas suited sa kalahati ng trabaho.
Ano ang ginawa ni Opus: ang design phase
Yung design work, nangyari siya sa mahabang conversation kasama si Opus, sa mga araw bago ang rebuild. Dalawang artifacts ang lumabas dun, at parehong nasa repo na ngayon:
1. Isang design direction document. Anim na markdown files sa doc/v3-design/ — yung why, yung tokens, yung mobile patterns, yung page specs, yung accessibility constraints, yung execution plan. Mahigit labintatlong libong salita ng decisions, karamihan sinulat ni Opus mula sa brief na binigay ko. Yung directive: "yung susunod na site dapat parang maliit na printed magazine, hindi SaaS dashboard. Earn attention through restraint. Gamitin ang Operating Model 2×2 framework bilang visual signature."
2. Isang desktop HTML prototype. Isang flat directory sa public/design-prototype-v2/ na may anim na pages at shared style.css. Walang React, walang Tailwind, walang framework — puro hand-written HTML, para makapag-click ako sa bawat page sa local server at ma-feel ko kung yung design system, talagang held together as a system. Yung prototype ang naging source of truth para sa visual treatment sa natitirang weekend. Pag may doubt sa rebuild, yung sagot ay "i-match yung prototype."
Si Opus ang gumawa ng mga decision na pinaka-importante. Ilang specific moments:
-
Yung font reversal. Yung naunang design pass, nai-lock na yung Manrope bilang display font, based sa availability at dali ng ship — naka-commit sa isang Claude Sonnet 4.6 session. Labing-walong oras pagkatapos, na-move ko na yung design conversation sa Opus 4.7 with extended thinking, at yung first move ni Opus ay pag-reconsider sa lock. Pagkatapos kong gumugol ng isang gabi sa official PP Neue Montreal specimen page nag-co-compare ng letterforms, pumasok yung switch. Yung commit message basahin mo, parang typography crime scene: "Manrope rendered too rounded and friendly... Satoshi has the same condensed-grotesque proportions, the same double-storey
a, single-storeyg, sweptRleg, cleanly-sheared terminals." Yung interesting wrinkle: dalawang magkaibang Claude model, nag-iba ng judgment sa parehong decision. Pinili ni Sonnet yung safe option. Pinili ni Opus yung tamang option. -
Yung carmine choice. Cyan ang AI-default accent. Si Opus at ako, dumating kami sa carmine red —
#c33824, isang printer's-ink red, yung kulay ng marka ng editor sa galley proof o ng isang Latin volume sa shelf ng Loeb Classical Library. Specific ang reasoning: "yung site nag-try maging editorial, hindi developer-tool. Cyan signals tech. Carmine signals craft. Gamitin sparingly ang carmine, palaging high contrast, ideally on warm paper." Hindi 'yan yung klase ng decision na maa-arrive ng execution-optimized model mag-isa. -
Operating Model bilang visual signature. Yung 2×2 framework na tinuturo ko sa course — Automate / Protect / Deepen / Change — naging tahimik na brand mark sa bagong site. Sa current implementation, lumalabas lang siya sa dalawang restrained na lugar: sa thesis block ng homepage, at bilang maliit na thesis marker sa long-form posts. Yung framework mismo, akin yun; yung move na gawin siyang visual identity ng site, galing yun sa design conversation kasama si Opus.
-
Light over dark. Sinabi ni Opus na light mode dapat ang personality at dark mode ang supported variant. Yung argument: mas madaling magbasa ng long-form sa warm paper kesa sa glass; mas honest tingnan ang price tags sa light backgrounds; halos lahat ng AI tool nag-ship ng dark by default, kaya light ang differentiator. Hindi ako pumayag ng ilang oras, tapos pumayag ako.
Si Opus ang karamihan ng design at review loop; si Codex naman ang gumawa ng implementation passes. Yung trabaho ni Opus, yun yung part na nag-pay off na maging mabagal.
Ano ang ginawa ni Codex: ang execution phase
Pag tapos na ang design document at prototype, naka-shift na yung trabaho kay Codex.
Nag-open ako ng bagong Codex session, binigyan ko siya ng design direction files bilang context, at sinimulan kong i-run ang /goal sessions. Bawat goal ay multi-step target na may malinaw na end state:
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.
Ganyang klaseng multi-stage target, exactly yung ginawan ng /goal. Nag-plan si Codex ng sub-steps, nag-execute, nag-run ng pnpm build para mag-check ng type errors, inayos yung nasira, ni-run yung build ulit, at nagpatuloy. Bumalik ako galing lakad at live na yung v3 shell sa codebase, sa likod ng flag, naka-load yung mga bagong font at nagre-render yung bottom nav sa mobile.
Yung mga sumunod na /goal sessions:
- I-generate yung v3 home at archive pages mula sa prototype.
- I-generate yung v3 post layout, kasama yung reading progress bar at yung v3 share button.
- I-generate yung v3 products at learn pages, na nag-match sa ladder structure sa spec.
- I-align yung existing course sales, login, signup, MFA, at access pages sa v3 visually, na hindi binabago kahit anong Stripe o Supabase Auth logic.
- I-localize yung v3 course at Ask Sydney surfaces sa lahat ng labintatlong locale, gamit yung existing
messages/{locale}.jsonfiles bilang translation source.
Yung pinakamatagal na run na natapos ng walang intervention, halos apat na oras. Yung pinakamaikli, mga apatnapu't limang minuto. Sa loob ng apat na araw, nag-ship ako ng halos tatlumpung commit — karamihan, first o second pass ni Codex, na may maliliit na manual cleanups kung saan tama yung output ng model pero hindi gaanong tama yung shape. Honest accounting: sa tingin ko, si Codex ang sumulat ng malaking bahagi ng actual code na tumatakbo sa production ngayon. Yung iba, ako ang sumulat o nag-edit.
Yung pinaka-useful na bagay sa /goal hindi yung speed. Yung autonomy. Karamihan ng coding sessions na ginagawa ko gamit ang AI tools, kailangan akong nasa keyboard — i-confirm ang change, i-accept yung next file, i-review yung diff. Sa /goal kasi, pwede mong i-specify yung end state na gusto mo at umalis ka na. Babalik ka, either tapos na yung change, o naka-pause yung session sa lugar kung saan kailangan ka ng model para mag-judgment call. Iba na ang hugis ng trabaho. Nagiging planner ka ng multi-hour sessions, hindi babysitter ng single edits.
Saan pa rin nakaupo ang boundary
Hindi magic trick yung pag-hati ng design at execution sa dalawang model. May mga moments pa rin kung saan kailangan ng isang model yung isa, at ilang moments kung saan kahit isa hindi sapat mag-isa.
Yung Sparkles icon. Nag-generate si Codex ng malinis na v3 mobile shell na may Sparkles ✨ icon sa Ask tab — yung universal AI-tool tell. Tama yung icon against sa spec; sa spec naman, hindi sinabi "wag gamitin yung cliché." Na-notice ko siya nung makalipas yung ilang araw at bumalik ako kay Opus para mag-discuss ng replacement. Dumaan kami sa ilang iterations: yung Operating Model mark, tapos yung italic Newsreader question mark sa carmine red — yung klaseng glyph na maa-find mo sa marginalia ng isang lumang essay. Yung final solution, idea ni Opus. Ni-ship 'to ni Codex sa loob ng labinlimang minuto.
Yung Hinomaru moment. Habang yung Operating Model mark nasa top-left ng mobile app bar, kasama ng pangalan ko, tinitignan ko 'to ng dalawang o tatlong araw. Isang maliit na carmine dot sa warm paper square. Tapos isang gabi, tiningnan ko 'to gaya ng pagtingin ng ibang tao at naramdaman ko yung maliit na flush ng realization. Mukhang Japanese flag talaga. Yung Hinomaru. Maliit na red sun sa pale field. Hindi nahuli kahit ni Opus o ni Codex. Si Opus, siya ang nag-design ng mark; si Codex, siya ang nag-implement; pareho silang nag-review. Yung visual association, cultural pattern siyang hindi makikita ng kahit anong model. Tinanggal ko siya sa wordmark at humanap ako ng ibang solution. (Yung parehong italic ? ang napunta sa lugar niya sa Ask tab.)
Yung 13-locale rollout. Pwede sana ni Opus na mag-design ng UI nuances ng bawat locale ng thoughtful, pero mauubos siya ng mga araw. Si Codex hindi mag-isa makakagawa ng design judgment, pero kayang mag-ship ng lahat ng labintatlong locale sa isang gabi pag set na yung patterns. Eto yung pinaka-literal na example ng split: slow design, fast execute.
Yung pag-pili ng tatlong font na bagay sa isa't isa. Si Opus ang pumili ng Satoshi (display), Newsreader (italic accent), at JetBrains Mono (labels). Hindi pipiliin ni Codex 'tong combination na 'to mag-isa — at hindi rin ako sigurado na ako mismo pumili nito kung walang slowness ni Opus sa conversation. Yung three-font composition, design call 'to, hindi execution.
Yung conversation between sa dalawang systems, nangyayari sa ulo ko, hindi between sa models. Yun ang part na hindi pa automatable sa 2026 — at sa tingin ko, yan yung part na nagde-define ng kahulugan ng taste sa ngayon.
Honest accounting
Apat na araw. Halos tatlumpung commit. Live na ang production v3 sa chandlernguyen.com. Yung bagong site, ginagawa na yung bagong trabaho — tinutulungan yung mga visitor na hanapin kung anong susunod babasahin, hindi sinasabihan sila na nag-cross over ako.
May natitirang problem na hinahabol ko pa. Sa draft time, yung production Lighthouse mobile nag-land yung blog archive sa 4.6 seconds, samantalang sa local Chrome DevTools trace ko, yung same image nag-paint sa loob ng 264 milliseconds — same code, ibang-iba ang network model. Yung current leading fix ko, font preload pressure: tatlong preloaded webfonts at tatlong render-blocking CSS chunks ang naka-race against sa image papunta sa finish line, sa throttled mobile connection. Ni-deploy ko yung smallest-leverage version ng fix kahapon at kailangan pa rin ako ng fresh Lighthouse run para ma-confirm na nag-land siya. Yung post na binabasa mo, sinulat 'to bago ko nakuha yung post-fix number.
Subscription cost: yung Codex subscription ko sa highest tier, kasama yung Claude Max subscription na meron na ako dati. Pagsama, ilang daang dollars per month. Mura, kung tingnan ang throughput.
Yung katotohanang nangyari ang v3 sa loob ng apat na araw, hindi tatlong linggo, karamihan dahil hinati yung design at execution phases at na-assign sa mga model na mas magaling sa bawat isa. Hindi ko iniisip na universal 'to. May mga project kung saan isang model lang kayang gawin yung dalawa, at may mga project kung saan kahit alin na model, hindi tamang partner. Pero para sa multi-page, multi-locale, multi-surface redesign na may strong design point of view, 'tong split na 'to ang workflow na babalikan ko ulit.
Kung may sariling AI-assisted rebuild ka recently, gusto ko talagang marinig kung paano mo hinati ang trabaho. Gumamit ka ba ng isang model end-to-end? Hinati mo ba per phase tulad ng ginawa ko, o sa ibang axis — per component, per file, per task type? Sa tingin ko, yung next wave ng build-in-public craft ay tungkol sa kung aling AI para sa kung aling parte ng trabaho, hindi lang kung gumagamit ka ba ng AI o hindi.
Kung gusto mong makita yung result, binabasa mo na siya. Yung home page nasa chandlernguyen.com. Yung product ladder nasa /tl/products/. Yung course na nagsimula ng buong "operating model" idea nasa /tl/learn/.
Maraming salamat, Chandler