Selama kurang lebih empat setengah bulan, situs saya memakai kulit TRANSMISSION: gelap, cyan, amber, dan sengaja terasa teknis.
Latar navy-charcoal. Aksen cyan. Panel-panel kaca. Saya membangunnya seperti itu dengan sengaja. Saya sudah menghabiskan delapan belas tahun di industri periklanan. Saya mengajari diri sendiri coding di usia empat puluh. Saya ingin situsnya membuat transisi itu terlihat — siapa pun yang mendarat di sebuah blog post, scroll melewati wordmark, dan menyadari estetika developer-tool itu, sinyalnya adalah: orang ini sudah menyeberang.
Dia menjalankan tugasnya. Lalu selesai.
Selama akhir pekan panjang Memorial Day, saya merilis redesign yang sama sekali berbeda dari sebelumnya. Light mode. Latar kertas hangat. Merah carmine menggantikan cyan. Garis-garis tipis menggantikan kartu-kartu rounded. Tulisan "Vol. 04 · Issue NN" yang terlihat di pojok — angka volume menghitung tahun sejak saya mulai build in public, angka issue adalah ISO week saat ini, keduanya terhubung untuk update sendiri. Kicker yang Anda lihat saat membaca ini mungkin Issue 22 atau 23 atau 41, tergantung kapan Anda mampir. Tidak ada ikon Sparkles di mana pun. Situsnya sekarang live di chandlernguyen.com.
Saya bisa saja menulis satu post penuh tentang keputusan-keputusan itu. Tapi cerita yang lebih berguna adalah workflow-nya. Saya membagi redesign ini ke dua model AI yang berbeda. Claude Opus 4.7 dengan extended thinking menangani desainnya. Codex di GPT-5.5 dengan setting reasoning tertinggi menangani eksekusinya. Dan fungsi /goal di Codex membuat dia bisa berjalan otonom hampir empat jam tanpa henti, sementara saya jalan-jalan atau makan malam.
Empat hari. Dua model. Hampir tiga puluh commit. Satu situs.
Berikut yang saya pelajari tentang model mana untuk apa — dan di mana batasnya masih berada.
Kenapa TRANSMISSION harus pergi
Saya menyeberang dari periklanan ke coding selama dua tahun terakhir. Di awal tahun ini, situsnya sudah menyusul: saya mendesain ulang menjadi TRANSMISSION justru untuk membuat transisi itu terlihat. Empat setengah bulan kemudian, sinyalnya sudah selesai.
Tugas berikutnya berbeda. Pengunjung yang datang dari blog post, dari thread LinkedIn, dari pencarian Google bukan datang untuk konfirmasi bahwa saya menulis code. Mereka datang untuk belajar sesuatu tentang AI di media operations, untuk mempertimbangkan membeli course-nya, atau untuk membandingkan course, Prova, DIALØGUE, dan STRAŦUM sebagai sebuah product ladder. Situsnya perlu lebih sedikit memberi sinyal dan lebih banyak memandu.
Cara termudah menggambarkan pergeserannya: situs lama adalah sebuah personality. Situs baru adalah sebuah operating model. Orangnya sama, tugasnya berbeda. Itu berarti estetika yang berbeda — lebih ringan, lebih tenang, lebih editorial, jenis permukaan di mana blog post yang panjang bisa bernapas dan CTA course bisa terasa jujur, bukan memaksa. Kertas hangat, bukan kaca.
Tapi masalah yang lebih sulit bukan estetika. Masalahnya adalah throughput. Situsnya punya tiga belas locale, sekitar delapan public surface (home, blog, post, products, learn, about, ask, course sales), authenticated course access flow, Stripe checkout, dan endpoint Sydney RAG. Membangun ulang semua itu dengan tangan akan butuh berminggu-minggu. Saya tidak punya berminggu-minggu.
Jadi saya membagi pekerjaannya ke dua model AI.
Kenapa memisahkan desain dan eksekusi sejak awal
Desain dan eksekusi adalah tugas kognitif yang berbeda.
Desain itu lambat. Dia adalah judgment soal komposisi, soal restraint, soal apakah satu shade kertas hangat terlihat terlalu kuning di iPhone dan shade lain terlihat terlalu dingin. Dia adalah pertanyaan "permukaan macam apa sebenarnya yang ingin kita buat?" sebelum "bagaimana kita render bagian ini?". Pekerjaan desain yang bagus memampatkan waktu — Anda berpikir dua jam lalu mengambil satu keputusan yang menghemat sepuluh jam eksekusi.
Eksekusi itu cepat. Dia adalah penerapan pola. Berikan design system, generate komponennya. Berikan sebuah komponen, sambungkan ke tiga belas locale. Berikan layout halaman, kirim semua variannya. Pekerjaannya bukan lebih rendah skill-nya, tapi lebih sedikit ambiguitasnya. Jawaban yang benar biasanya bisa dipertahankan di hadapan spec.
Model AI yang berbeda lebih jago di tugas kognitif yang berbeda. Dari pengalaman saya beberapa bulan terakhir — dulu dengan Claude Opus 4.6, sekarang dengan 4.7, keduanya di setting extended thinking — Opus adalah partner yang lebih well-rounded. Lebih jago brainstorming. Lebih jago dalam keputusan desain. Lebih lambat dan kurang presisi bedah di pure code, tapi dia mempertimbangkan komposisi secara keseluruhan sebelum menjawab, dan dia bernalar dengan cara yang menangkap kenapa satu font terasa terlalu friendly dan font lain terasa pas.
Codex di GPT-5.5 dengan setting high-reasoning terasa seperti senior software engineer yang kompeten yang tidak pernah sekalipun mendekati tim desain. Dia cepat. Dia sangat hebat di multi-step tool use — membuka file, membacanya, mengeditnya, menjalankan test, membuka file berikutnya. Dia tidak punya opini kuat soal apakah sebuah tombol terasa terlalu tinggi, tapi dia mengirim tombolnya, dan dia mengirim setiap variannya ke tiga belas locale tanpa mengeluh. Fungsi /goal-nya memungkinkan Anda memberinya target — misalnya, "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" — lalu pergi begitu saja. Dia akan merencanakan sub-step, mengeksekusinya, menjalankan build, memperbaiki yang rusak, dan terus jalan. Rentang terlama dia berjalan tanpa pengawasan di proyek ini, hampir empat jam.
Saya harus jujur, saya tidak merencanakan pembagian ini secara sadar di awal. Saya sudah ngobrol soal desain dengan Opus selama hari-hari sebelum akhir pekan. Saat akhir pekan panjang itu dimulai, saya sudah punya dokumen arah desain dan prototype desktop-nya. Akhir pekan itu sendiri adalah momen saya menyerahkan eksekusi ke Codex, dan dalam satu jam setelah itu saya sadar betapa pas-nya setiap model untuk separuh pekerjaannya masing-masing.
Apa yang Opus kerjakan: fase desain
Pekerjaan desain terjadi dalam percakapan panjang dengan Opus di hari-hari sebelum rebuild. Dua artifact lahir dari percakapan itu, keduanya sekarang tinggal di repo:
1. Dokumen arah desain. Enam file markdown di doc/v3-design/ — the why, the tokens, mobile patterns, page specs, accessibility constraints, execution plan. Lebih dari tiga belas ribu kata berisi keputusan, sebagian besar ditulis Opus dari brief yang saya berikan. Direktifnya: "situs berikutnya harus terasa seperti majalah cetak kecil, bukan SaaS dashboard. Earn attention through restraint. Pakai framework Operating Model 2×2 sebagai signature visual."
2. Prototype HTML desktop. Direktori datar di public/design-prototype-v2/ dengan enam halaman dan satu style.css bersama. Tanpa React, tanpa Tailwind, tanpa framework — hanya HTML yang ditulis tangan supaya saya bisa klik setiap halaman di local server dan merasakan apakah design system-nya benar-benar bertahan sebagai sebuah sistem. Prototype itu menjadi source of truth untuk visual treatment sepanjang sisa akhir pekan. Saat ragu selama rebuild, jawabannya adalah "match the prototype."
Opus mengambil keputusan-keputusan yang paling penting. Beberapa momen spesifik:
-
Pembalikan keputusan font. Sesi desain sebelumnya sudah mengunci Manrope sebagai display font dengan alasan availability dan kemudahan shipping — di-commit di sesi Claude Sonnet 4.6. Delapan belas jam kemudian saya sudah memindahkan percakapan desain ke Opus 4.7 dengan extended thinking, dan langkah pertama Opus adalah mempertimbangkan ulang kuncian itu. Setelah saya menghabiskan satu malam di halaman specimen resmi PP Neue Montreal membandingkan bentuk huruf, perubahannya masuk. Commit message-nya terbaca seperti TKP tipografi: "Manrope rendered too rounded and friendly... Satoshi has the same condensed-grotesque proportions, the same double-storey
a, single-storeyg, sweptRleg, cleanly-sheared terminals." Bagian yang menarik adalah dua model Claude yang berbeda sampai pada penilaian yang berbeda untuk keputusan yang sama. Sonnet memilih opsi yang aman. Opus memilih yang benar. -
Pilihan carmine. Cyan adalah aksen default AI. Opus dan saya akhirnya memilih carmine red —
#c33824, merah tinta printer, warna coretan editor di galley proof atau warna jilid Latin di rak Loeb Classical Library. Alasannya spesifik: "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." Itu bukan keputusan yang akan diambil model yang dioptimasi untuk eksekusi. -
Operating Model sebagai signature visual. Framework 2×2 yang saya ajarkan di course — Automate / Protect / Deepen / Change — menjadi brand mark yang tenang di situs baru. Di implementasi saat ini, dia muncul di dua tempat yang sengaja dibuat terkendali: di thesis block halaman home dan sebagai thesis marker kecil di blog post panjang. Framework-nya sendiri dari saya; gerakan menjadikannya identitas visual situs lahir dari percakapan desain dengan Opus.
-
Light over dark. Opus berargumen bahwa light mode adalah personality-nya dan dark mode adalah varian yang didukung. Argumennya: membaca long-form lebih enak di kertas hangat daripada di kaca; price tag terasa lebih jujur di latar terang; hampir semua AI tool default-nya dark, jadi light adalah pembedanya. Saya tidak setuju selama beberapa jam, lalu setuju.
Opus sebagian besar adalah loop desain dan review; Codex yang melakukan pass implementasi. Tugas Opus adalah bagian pekerjaan di mana lambat itu menguntungkan.
Apa yang Codex kerjakan: fase eksekusi
Begitu dokumen desain dan prototype selesai, pekerjaannya pindah ke Codex.
Saya membuka sesi Codex baru, memberinya file-file arah desain sebagai konteks, dan mulai menjalankan sesi /goal. Setiap goal adalah target multi-step dengan end state yang jelas:
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.
Target multi-stage semacam itu persis seperti yang dirancang untuk /goal. Codex merencanakan sub-step-nya, mengeksekusinya, menjalankan pnpm build untuk mengecek type error, memperbaiki yang rusak, menjalankan build lagi, dan terus jalan. Saya pulang dari jalan-jalan dan shell v3 sudah live di codebase di balik flag, dengan font-font baru sudah dimuat dan bottom nav sudah render di mobile.
Sesi-sesi /goal berikutnya:
- Generate halaman v3 home dan archive dari prototype.
- Generate layout post v3, termasuk reading progress bar dan share button v3.
- Generate halaman v3 products dan learn, sesuai struktur ladder di spec.
- Selaraskan halaman course sales, login, signup, MFA, dan access yang sudah ada secara visual ke v3, tanpa mengubah logika Stripe atau Supabase Auth di belakangnya.
- Lokalisasi permukaan v3 course dan Ask Sydney ke seluruh tiga belas locale, memakai file
messages/{locale}.jsonyang ada sebagai sumber terjemahan.
Run terpanjang yang selesai tanpa intervensi adalah hampir empat jam. Yang terpendek sekitar empat puluh lima menit. Sepanjang empat hari itu saya mengirim hampir tiga puluh commit — sebagian besar pass pertama atau kedua dari Codex, dengan pembersihan manual kecil di tempat output model sudah benar tapi bentuknya belum pas. Akuntansi yang jujur: saya pikir Codex menulis sebagian besar code yang berjalan di production hari ini. Sisanya saya yang tulis atau edit.
Hal paling berguna dari /goal bukan kecepatannya. Tapi otonominya. Kebanyakan sesi coding yang saya jalankan dengan AI tools menuntut saya tetap di keyboard — konfirmasi sebuah perubahan, terima file berikutnya, review diff-nya. /goal memungkinkan Anda menentukan end state yang Anda mau dan pergi. Anda kembali ke perubahan yang sudah selesai, atau ke sesi yang berhenti di titik di mana model butuh judgment call dari Anda. Bentuk pekerjaannya berbeda. Anda jadi planner untuk sesi multi-jam, bukan babysitter untuk edit-edit tunggal.
Di mana batasnya masih berada
Memisahkan desain dan eksekusi ke dua model bukan trik sulap. Masih ada momen-momen di mana satu model butuh yang lain, dan beberapa momen di mana keduanya pun tidak cukup sendiri.
Ikon Sparkles. Codex menghasilkan mobile shell v3 yang bersih dengan ikon Sparkles ✨ di tab Ask — penanda universal AI tool. Ikonnya benar terhadap spec; spec-nya tidak bilang "do not use the cliché." Saya baru menyadarinya beberapa hari kemudian dan kembali ke Opus untuk membahas penggantinya. Kami melewati beberapa iterasi: tanda Operating Model, lalu tanda tanya Newsreader miring berwarna carmine red — jenis glyph yang mungkin Anda temukan sebagai catatan pinggir di sebuah esai lama. Solusi finalnya adalah ide Opus. Codex mengirimnya dalam lima belas menit.
Momen Hinomaru. Saat tanda Operating Model duduk di pojok kiri atas mobile app bar, di sebelah nama saya, saya sudah menatapnya selama dua atau tiga hari. Titik carmine kecil di atas kotak kertas hangat. Lalu suatu malam saya melihatnya dengan cara orang lain melihatnya dan terasa ada sengatan kesadaran kecil. Dia persis terlihat seperti bendera Jepang. Hinomaru. Matahari merah kecil di atas hamparan pucat. Baik Opus maupun Codex tidak menangkap ini. Opus yang mendesain tandanya; Codex yang mengimplementasikannya; keduanya sudah me-review. Asosiasi visualnya adalah pola kultural yang tidak bisa dilihat oleh model mana pun. Saya menghapus tandanya dari wordmark dan meraih solusi lain. (Tanda ? miring yang sama akhirnya mengisi tempatnya di tab Ask.)
Rollout ke 13 locale. Opus bisa saja mendesain nuansa UI tiap locale dengan teliti, tapi akan butuh berhari-hari. Codex tidak bisa membuat keputusan desain itu sendiri, tapi bisa mengirim semua tiga belas locale dalam satu malam begitu pola-polanya ditetapkan. Ini contoh paling harfiah dari pembagian itu: design slow, execute fast.
Memilih tiga font yang cocok bersama. Opus memilih Satoshi (display), Newsreader (italic accent), dan JetBrains Mono (label). Codex tidak akan memilih kombinasi ini sendiri — dan saya tidak yakin saya juga bisa tanpa kelambatan Opus di percakapan. Komposisi tiga font adalah panggilan desain, bukan eksekusi.
Percakapan antara dua sistem ini terjadi di kepala saya, bukan antar model. Itulah bagian yang masih belum bisa diotomasi di 2026 — dan saya pikir itulah bagian yang mendefinisikan apa arti taste sekarang.
Akuntansi yang jujur
Empat hari. Hampir tiga puluh commit. Production v3 sudah live di chandlernguyen.com. Situs barunya sedang menjalankan tugas barunya — membantu pengunjung menemukan apa yang harus dibaca berikutnya, bukan memberi tahu mereka bahwa saya sudah menyeberang.
Situsnya masih punya satu masalah yang sedang saya kejar. Saat draft post ini ditulis, Lighthouse mobile di production menunjukkan halaman archive blog mendarat di 4,6 detik, sementara trace Chrome DevTools lokal saya menunjukkan gambar yang sama selesai di-paint dalam 264 milidetik — code yang sama, model jaringan yang sangat berbeda. Tebakan utama saya saat ini: tekanan preload font — tiga webfont yang di-preload plus tiga chunk CSS yang render-blocking, berlomba dengan gambar menuju garis akhir di koneksi mobile yang di-throttle. Saya men-deploy versi paling sederhana dari fix itu kemarin dan masih perlu run Lighthouse baru untuk konfirmasi bahwa dia berhasil. Post yang Anda baca ini ditulis sebelum saya punya angka pasca-fix-nya.
Biaya subscription: Codex subscription saya di tier tertinggi, plus Claude Max subscription yang sudah saya punya. Bersama-sama beberapa ratus dolar per bulan. Murah, kalau dibandingkan dengan throughput-nya.
Fakta bahwa v3 ini selesai dalam empat hari, bukan tiga minggu, sebagian besar karena fase desain dan eksekusi dipisahkan dan diberikan ke model yang lebih cocok untuk masing-masingnya. Saya tidak pikir ini universal. Ada proyek di mana satu model bisa mengerjakan keduanya, dan ada proyek di mana tidak ada satu pun model yang menjadi partner yang tepat. Tapi untuk redesign multi-page, multi-locale, multi-surface dengan sudut pandang desain yang kuat, pembagian ini adalah workflow yang akan saya pakai lagi.
Kalau Anda baru-baru ini melakukan rebuild dengan bantuan AI sendiri, saya benar-benar ingin mendengar bagaimana Anda membagi pekerjaannya. Apakah Anda memakai satu model dari awal sampai akhir? Apakah Anda membagi per fase seperti saya, atau dengan sumbu yang lain — per komponen, per file, per jenis tugas? Saya pikir gelombang build-in-public berikutnya akan tentang AI yang mana untuk bagian pekerjaan yang mana, bukan lagi sekadar tentang apakah Anda memakai AI atau tidak.
Kalau Anda ingin melihat hasilnya, Anda sedang membacanya. Halaman utamanya ada di chandlernguyen.com. Product ladder-nya ada di /products/. Course yang memulai seluruh ide "operating model" ini ada di /learn/.
Salam hangat, Chandler