करीब साढ़े चार महीनों तक मेरी site पर TRANSMISSION वाला look चढ़ा हुआ था: dark, cyan, amber, और जान-बूझकर technical।
Navy-charcoal background. Cyan accents. Glassy panels. मैंने यह सब सोच-समझकर बनाया था। मैंने अठारह साल advertising में बिताए हैं। चालीस की उम्र में मैंने खुद को coding सिखाई। मैं चाहता था कि site उस transition को दिखा सके — कोई blog post पर आए, wordmark से नीचे scroll करे, developer-tool वाला aesthetic देखे, और signal साफ़ हो: यह बंदा पार उतर गया।
उसने अपना काम कर दिया। फिर बस, बात पूरी हो गई।
Memorial Day के लंबे weekend में मैंने एक redesign ship कर दिया जो पहले वाले से बिल्कुल अलग दिखती है। Light mode. Warm paper background. Cyan की जगह carmine red. Rounded cards की जगह hairline rules. कोने में एक दिखता हुआ "Vol. 04 · Issue NN" — volume उन सालों को गिनता है जब से मैंने public में build करना शुरू किया, और issue current ISO week है, दोनों खुद-ब-खुद update होते हैं। जिस दिन आप यह पढ़ रहे हैं, उस दिन kicker पर शायद Issue 22 लिखा हो, या 23, या 41 — depend करता है कब आते हैं आप। Sparkles icon कहीं नहीं है। Site अब live है chandlernguyen.com पर।
मैं इन decisions पर एक पूरी post लिख सकता हूँ। लेकिन ज़्यादा काम की बात है workflow। मैंने redesign को दो अलग AI models में बाँट दिया। Claude Opus 4.7 with extended thinking ने design किया। Codex on GPT-5.5 with its highest reasoning setting ने execution किया। और Codex में /goal function की वजह से वह करीब चार घंटे तक अकेले run करता रहा, जब मैं walk पर निकला हुआ था या dinner कर रहा था।
चार दिन। दो models. लगभग तीस commits. एक site.
यहाँ बता रहा हूँ कि किस model को किस काम के लिए इस्तेमाल करना है — और सीमा अभी कहाँ खींची हुई है।
TRANSMISSION को क्यों जाना था
पिछले दो साल में मैं advertising से code की तरफ़ पार उतरा। इस साल की शुरुआत तक site भी catch up कर चुकी थी: मैंने उसे TRANSMISSION के रूप में redesign किया था ख़ास तौर पर उस transition को दिखाने के लिए। साढ़े चार महीने बाद, वह signal भेजने का काम पूरा है।
अब अगला काम अलग है। जो लोग किसी blog post से, LinkedIn thread से, या Google search से आ रहे हैं, वे यह confirm करने नहीं आ रहे कि मैं code लिखता हूँ। वे आ रहे हैं media operations में AI के बारे में कुछ सीखने, course ख़रीदने पर विचार करने, या course, Prova, DIALØGUE और STRAŦUM को एक product ladder की तरह compare करने। Site को कम signal भेजना था और ज़्यादा guide करना था।
इस shift को सबसे आसान तरीक़े से कहूँ: पुरानी site एक personality थी। नई site एक operating model है। पीछे वही इंसान है, बस काम अलग है। इसका मतलब था एक अलग aesthetic — हल्का, शांत, editorial, ऐसी surface जहाँ एक लंबी blog post साँस ले सके और course CTA pushy की बजाय honest लगे। Glass की जगह warm paper।
लेकिन मुश्किल problem aesthetic नहीं थी। मुश्किल थी throughput। Site पर तेरह locales हैं, क़रीब आठ public surfaces (home, blog, post, products, learn, about, ask, course sales), एक authenticated course access flow, एक Stripe checkout, और एक Sydney RAG endpoint। यह सब हाथ से दोबारा build करने में हफ्तों लग जाते। मेरे पास हफ़्ते नहीं थे।
तो मैंने काम को दो AI models में बाँट दिया।
Design और execution को बाँटना ज़रूरी क्यों था
Design और execution दो अलग cognitive tasks हैं।
Design slow होता है। यह judgment की बात है — composition, restraint, इस बात की कि warm paper का एक shade iPhone पर ज़्यादा पीला दिखता है और दूसरा shade ज़्यादा ठंडा। यह पूछना है "यह surface आख़िर बनना क्या चाहती है?" इससे पहले कि "इस section को render कैसे करें?"। अच्छा design समय को compress कर देता है — आप दो घंटे सोचते हैं और फिर एक decision लेते हैं जो आपके दस घंटे की execution बचा देता है।
Execution fast है। यह pattern application है। एक design system दिया है, तो components generate कर दो। एक component दिया है, तो उसे तेरह locales में wire कर दो। एक page layout दिया है, तो variants ship कर दो। काम कम skilled नहीं है, बस उसमें ambiguity कम है। सही जवाब अक्सर spec के against defend किया जा सकता है।
अलग-अलग AI models अलग cognitive tasks में बेहतर हैं। पिछले कुछ महीनों में मेरे अपने experience से — पहले Claude Opus 4.6 के साथ और अब 4.7 के साथ, दोनों ही extended-thinking setting पर — Opus ज़्यादा well-rounded partner है। Brainstorming में बेहतर। Design judgment में बेहतर। शुद्ध code पर slow और कम surgically precise, लेकिन answer देने से पहले पूरी composition पर सोचता है और इस तरह reason करता है कि पकड़ लेता है क्यों एक font बहुत friendly लगता है और दूसरा सही लगता है।
High-reasoning setting पर Codex on GPT-5.5 ऐसा लगता है जैसे कोई competent senior software engineer हो जो design team के क़रीब कभी गया ही नहीं। Fast है। Multi-step tool use में excellent है — files open करना, पढ़ना, edit करना, tests चलाना, अगली file open करना। यह strong opinions नहीं रखता कि एक button कितना tall लगता है, लेकिन button ship कर देता है, और तेरह locales में हर variant बिना शिकायत के ship कर देता है। इसका /goal function आपको एक 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" — और आप दूर चले जाइए। यह sub-steps plan करेगा, उन्हें execute करेगा, build run करेगा, जो टूटे उसे fix करेगा, और चलता रहेगा। इस project में इसने सबसे लंबा unattended run लगभग चार घंटे का किया था।
मुझे मानना होगा कि मैंने यह split शुरू में जान-बूझकर plan नहीं किया था। Weekend से पहले के दिनों में मेरी design conversation Opus के साथ चलती रही थी। जब लंबा weekend शुरू हुआ, मेरे पास design direction document और desktop prototype दोनों थे। Weekend तब था जब मैंने execution Codex को सौंपा, और ऐसा करने के एक घंटे के अंदर मुझे महसूस हुआ कि हर model अपने आधे काम के लिए कितना बेहतर suited है।
Opus ने क्या किया: design phase
Design का काम Opus के साथ एक लंबी conversation में हुआ, rebuild से पहले के दिनों में। उस conversation से दो artifacts निकले, दोनों अब repo में हैं:
1. एक design direction document. doc/v3-design/ में छह markdown files — why, tokens, mobile patterns, page specs, accessibility constraints, execution plan। तेरह हज़ार से ज़्यादा शब्दों के decisions, ज़्यादातर Opus ने उस brief से लिखे जो मैंने उसे दिया था। Directive था: "अगली site को एक छोटा printed magazine लगना चाहिए, न कि SaaS dashboard। Restraint से attention earn करो। Operating Model 2×2 framework को visual signature की तरह use करो।"
2. एक desktop HTML prototype. public/design-prototype-v2/ पर एक flat directory छह pages और एक shared style.css के साथ। न React, न Tailwind, न framework — बस hand-written HTML ताकि मैं local server पर हर page पर click करके feel कर सकूँ कि design system वाक़ई एक system के तौर पर held together है या नहीं। Prototype बाक़ी weekend के लिए visual treatment का source of truth बना। Rebuild के दौरान जब doubt हुआ, answer था "prototype से match करो।"
जो decisions सबसे ज़्यादा मायने रखते थे, वे Opus ने लिए। कुछ specific moments:
-
Font का reversal. एक पुराने design pass में Manrope को display font के तौर पर lock किया गया था, availability और ship करने में आसानी के आधार पर — Claude Sonnet 4.6 के साथ एक session में commit हुआ। अठारह घंटे बाद मैं design conversation Opus 4.7 with extended thinking पर move कर चुका था, और Opus का पहला move उस lock पर फिर से सोचना था। एक शाम मैंने official PP Neue Montreal specimen page पर letterforms compare करने में बिताई, और switch हो गया। Commit message किसी 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." दिलचस्प twist यह है कि एक ही decision पर दो अलग Claude models ने अलग judgments दिए। Sonnet ने safe option चुना। Opus ने सही option चुना। -
Carmine का चुनाव. Cyan AI-default accent है। Opus और मैं carmine red पर आ कर रुके —
#c33824, printer's-ink red, उस editor के mark का रंग जो galley proof पर लगाता है, या Loeb Classical Library की shelf पर रखे एक Latin volume का रंग। Reasoning specific थी: "site editorial feel करना चाहती है, developer-tool नहीं। Cyan tech signal करता है। Carmine craft signal करता है। Carmine को कम use करो, हमेशा high contrast पर, ideally warm paper पर।" यह वह decision नहीं है जिस तक execution-optimized model अकेले पहुँचेगा। -
Operating Model एक visual signature के तौर पर. Course में जो 2×2 framework मैं पढ़ाता हूँ — Automate / Protect / Deepen / Change — वही नई site पर एक शांत brand mark बनता है। मौजूदा implementation में यह दो जगह संयम के साथ दिखता है: homepage के thesis block पर, और long-form posts पर एक छोटे thesis marker के तौर पर। Framework तो मेरा था; उसे site की visual identity बनाने का move Opus के साथ हुई design conversation से आया।
-
Light over dark. Opus ने light mode को personality और dark mode को एक supported variant के तौर पर रखने की वकालत की। Argument: long-form reading glass की बजाय warm paper पर आसान है; price tags light backgrounds पर ज़्यादा honest लगते हैं; almost हर AI tool default पर dark ship करता है, इसलिए light differentiator है। मैं कुछ घंटे disagree करता रहा, फिर मान गया।
Opus ज़्यादातर design और review loop था; implementation passes Codex ने किए। Opus का काम वह हिस्सा था जहाँ slow होना pay off करता था।
Codex ने क्या किया: execution phase
जब design document और prototype तैयार हो गए, काम Codex पर shift हो गया।
मैंने एक नया Codex session खोला, उसे context की तरह design direction files दीं, और /goal sessions चलाने शुरू किए। हर goal एक clear end state वाला multi-step target था:
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.
ऐसा multi-stage target ठीक उसी तरह का है जिसके लिए /goal design किया गया है। Codex sub-steps plan करता है, उन्हें execute करता है, type errors check करने के लिए pnpm build चलाता है, जो टूटे उसे fix करता है, build फिर से चलाता है, और चलता रहता है। मैं walk से वापस आया और flag के पीछे v3 shell codebase में live थी, नए fonts loaded थे और mobile पर bottom nav render हो रहा था।
बाद के /goal sessions:
- Prototype से v3 home और archive pages generate करना।
- v3 post layout generate करना, reading progress bar और v3 share button समेत।
- v3 products और learn pages generate करना, spec में दी गई ladder structure से match करते हुए।
- मौजूदा course sales, login, signup, MFA, और access pages को v3 के visual hisaab से align करना, underlying Stripe या Supabase Auth logic को छेड़े बिना।
- तेरह locales में v3 course और Ask Sydney surfaces को localize करना, translation source के तौर पर मौजूदा
messages/{locale}.jsonfiles का use करते हुए।
बिना intervention के सबसे लंबा run लगभग चार घंटे चला। सबसे छोटा क़रीब पैंतालीस मिनट का था। चार दिनों में मैंने लगभग तीस commits ship किए — ज़्यादातर Codex के first या second pass, कुछ छोटे manual cleanups के साथ जहाँ model का output सही था लेकिन shape बिल्कुल सही नहीं थी। Honest accounting: मुझे लगता है कि production में आज जो actual code चल रहा है, उसका बड़ा हिस्सा Codex ने लिखा है। बाक़ी मैंने लिखा या edit किया।
/goal की सबसे useful बात speed नहीं है। Autonomy है। AI tools के साथ जो ज़्यादातर coding sessions मैंने चलाए हैं, उनमें मुझे keyboard पर बने रहना पड़ता है — एक change confirm करो, अगली file accept करो, diff review करो। /goal आपको वह end state specify करने देता है जो आप चाहते हैं, और दूर चले जाने देता है। आप वापस आते हैं या तो एक finished change पर, या एक paused session पर उस जगह जहाँ model को आपकी judgment call चाहिए। काम का shape अलग है। आप single edits के babysitter की बजाय multi-hour sessions के planner बन जाते हैं।
सीमा अभी कहाँ खींची हुई है
Design और execution को दो models में बाँटना कोई जादू का trick नहीं है। अभी भी कुछ moments हैं जहाँ एक model को दूसरे की ज़रूरत पड़ती है, और कुछ moments जहाँ कोई भी अकेले काफ़ी नहीं है।
Sparkles icon. Codex ने एक साफ़ v3 mobile shell generate की जिसमें Ask tab पर Sparkles ✨ icon था — universal AI-tool वाला tell। Icon spec के against सही था; spec में नहीं लिखा था "क्लीशे use मत करना।" मैंने उसे एक-दो दिन बाद notice किया और replacement पर discuss करने Opus के पास वापस गया। हमने कई iterations किए: Operating Model mark, फिर carmine red में एक italic Newsreader question mark — वैसा glyph जैसा आपको किसी पुराने essay की marginalia में मिल जाए। Final solution Opus का idea था। Codex ने उसे पंद्रह मिनट में ship कर दिया।
Hinomaru moment. जब Operating Model mark mobile app bar के top-left में, मेरे नाम के बगल में बैठा था, मैं उसे दो-तीन दिनों से देख रहा था। Warm paper square पर एक छोटा carmine dot। फिर एक शाम मैंने उसे ऐसे देखा जैसे कोई और देखता और एक छोटा-सा realization का flush महसूस किया। यह बिल्कुल Japanese flag जैसा दिख रहा था। Hinomaru। एक pale field पर एक छोटा red sun। न Opus, न Codex इसे पकड़ पाए। Opus ने mark design किया था; Codex ने उसे implement किया था; दोनों ने उसे review किया था। यह visual association एक cultural pattern था जिसे कोई भी model देख नहीं सकता। मैंने उसे wordmark से delete किया और एक अलग solution की तरफ़ बढ़ा। (वही italic ? Ask tab पर उसकी जगह भर गया।)
13-locale rollout. Opus हर locale की UI nuances को सोच-समझकर design कर सकता था लेकिन उसमें दिन लग जाते। Codex अकेले design judgment नहीं ले सकता था लेकिन एक बार patterns set हो जाने पर एक शाम में तेरह locales ship कर सकता था। यह split का सबसे literal example है: slow design, fast execution.
तीन fonts चुनना जो एक साथ काम करें. Opus ने Satoshi (display), Newsreader (italic accent), और JetBrains Mono (labels) चुने। Codex यह combination अकेले नहीं चुनता — और मुझे यक़ीन नहीं कि Opus की slowness वाली conversation के बिना मैं भी चुन पाता। तीन-font composition एक design call है, execution नहीं।
दोनों systems के बीच की conversation मेरे सिर में होती है, models के बीच नहीं। यह वह हिस्सा है जो 2026 में अभी automate नहीं किया जा सकता — और मुझे लगता है कि अभी taste का मतलब क्या है, यह वही define करता है।
Honest accounting
चार दिन। लगभग तीस commits. Production v3 chandlernguyen.com पर live है। नई site नया काम कर रही है — visitors को यह बताने की बजाय कि मैं पार उतर गया, उन्हें अगला पढ़ने वाला piece ढूँढने में मदद कर रही है।
Site पर एक बची हुई problem है जिसके पीछे मैं अभी भी पड़ा हूँ। Draft time पर production Lighthouse mobile blog archive को 4.6 seconds पर land करता हुआ दिखा रहा था जबकि मेरे local Chrome DevTools trace में वही image 264 milliseconds में paint हो रही थी — same code, बहुत अलग network model। मेरा current leading fix है font preload pressure: तीन preloaded webfonts और तीन render-blocking CSS chunks throttled mobile connection पर image के साथ finish line पर race कर रहे हैं। मैंने उस fix का smallest-leverage version पिछले दिन deploy किया है और अभी भी एक fresh Lighthouse run चाहिए ताकि confirm हो सके कि वह land हुआ। जो post आप पढ़ रहे हैं, वह post-fix number आने से पहले लिखी गई।
Subscription cost: मेरा Codex subscription highest tier पर, साथ ही पहले से मेरे पास मौजूद Claude Max subscription। मिलाकर महीने के कुछ सौ dollars। Throughput के हिसाब से सस्ता है।
v3 तीन हफ्तों की बजाय चार दिनों में हुआ, इसकी बड़ी वजह यह है कि design और execution phases अलग किए गए और उन models को assign किए गए जो हर एक में बेहतर थे। मुझे नहीं लगता यह universal है। ऐसे projects हैं जहाँ एक ही model दोनों कर सकता है, और ऐसे भी जहाँ कोई भी model सही partner नहीं है। लेकिन एक multi-page, multi-locale, multi-surface redesign के लिए जहाँ design point of view strong है, यह split वह workflow है जिसे मैं फिर use करूँगा।
अगर हाल में आपने अपना कोई AI-assisted rebuild किया है, तो मुझे सच में जानना अच्छा लगेगा कि आपने काम को कैसे बाँटा। क्या आपने एक ही model end-to-end use किया? क्या आपने phase के हिसाब से बाँटा जैसे मैंने किया, या किसी और axis पर — component के हिसाब से, file के हिसाब से, task type के हिसाब से? मुझे लगता है build-in-public craft की अगली wave इस बात पर होगी कि काम के किस हिस्से के लिए कौनसी AI, सिर्फ़ इस पर नहीं कि आप AI use करते हैं या नहीं।
अगर आप result देखना चाहते हैं, तो आप उसी को पढ़ रहे हैं। Home page chandlernguyen.com पर है। Product ladder /hi/products/ पर है। जिस course से पूरा "operating model" idea शुरू हुआ, वह /hi/learn/ पर है।
शुभकामनाओं सहित, Chandler