Trong khoảng bốn tháng rưỡi, site của tôi khoác bộ áo TRANSMISSION: tối, cyan, amber, và cố ý đậm chất kỹ thuật.
Nền navy-charcoal. Điểm nhấn cyan. Panel glassy. Tôi cố ý xây như vậy. Tôi đã dành mười tám năm trong ngành quảng cáo. Tôi tự học lập trình ở tuổi bốn mươi. Tôi muốn site làm cho cú chuyển đó hiện ra — để ai đó vô tình rơi vào một bài blog, lướt qua wordmark, và nhận ra cái thẩm mỹ developer-tool, signal là: người này đã bước qua bên kia.
Nó làm xong việc của nó. Rồi xong.
Cuối tuần dài Memorial Day, tôi ship một bản redesign trông chẳng giống thứ trước đó chút nào. Light mode. Nền warm paper. Đỏ carmine thay cho cyan. Hairline rules thay cho card bo tròn. Một dòng "Vol. 04 · Issue NN" hiện ở góc — volume đếm số năm kể từ lúc tôi bắt đầu build in public, issue là ISO week hiện tại, cả hai đều tự cập nhật. Cái kicker ở ngày bạn đọc bài này có thể là Issue 22 hay 23 hay 41, tùy lúc bạn ghé qua. Không còn icon Sparkles ở đâu cả. Site giờ đã live trên chandlernguyen.com.
Tôi có thể viết hẳn một bài về những quyết định đó. Nhưng phần đáng kể hơn là cách làm việc. Tôi chia bản redesign cho hai mô hình AI khác nhau. Claude Opus 4.7 với extended thinking lo thiết kế. Codex trên GPT-5.5 ở mức reasoning cao nhất lo thi công. Và hàm /goal trong Codex cho phép nó chạy tự động gần bốn tiếng liên tục, trong lúc tôi đi dạo hay ăn tối.
Bốn ngày. Hai mô hình. Gần ba mươi commit. Một site.
Đây là những gì tôi rút ra về việc mô hình nào dùng vào việc gì — và ranh giới vẫn nằm ở đâu.
Vì sao TRANSMISSION phải đi
Tôi bước từ quảng cáo sang code trong hai năm qua. Đến đầu năm nay, site mới bắt kịp: tôi redesign nó thành TRANSMISSION chính là để làm cú chuyển đó hiện ra. Bốn tháng rưỡi sau, signal đã làm xong.
Việc tiếp theo lại khác. Người ghé từ một bài blog, từ một thread LinkedIn, từ một lượt tìm Google không đến để xác nhận rằng tôi biết viết code. Họ đến để học về AI trong vận hành media, để cân nhắc mua khoá học, hoặc để so sánh khoá học, Prova, DIALØGUE, và STRAŦUM như một thang sản phẩm. Site cần signal ít lại và dẫn dắt nhiều lên.
Cách dễ nhất để mô tả cú chuyển: site cũ là một personality. Site mới là một operating model. Cùng một người đứng sau, nhưng có việc khác để làm. Điều đó kéo theo một thẩm mỹ khác — nhẹ hơn, bình tĩnh hơn, editorial hơn, kiểu bề mặt mà một bài blog dài có thể thở, và một CTA khoá học có thể nghe thật thà thay vì chèo kéo. Warm paper thay cho glass.
Nhưng vấn đề khó hơn không phải thẩm mỹ. Đó là throughput. Site có mười ba locale, khoảng tám bề mặt công khai (home, blog, post, products, learn, about, ask, course sales), một flow course access có xác thực, một Stripe checkout, và một endpoint Sydney RAG. Dựng lại tất cả thứ đó bằng tay sẽ tốn hàng tuần. Tôi không có hàng tuần.
Nên tôi chia việc cho hai mô hình AI.
Vì sao lại chia thiết kế và thi công
Thiết kế và thi công là hai dạng nhận thức khác nhau.
Thiết kế thì chậm. Nó là phán đoán về bố cục, về sự kiềm chế, về việc một tông warm paper trông có quá vàng trên iPhone hay tông kia trông có quá lạnh. Nó là hỏi "bề mặt này đang cố trở thành thứ gì?" trước khi hỏi "chúng ta render section này như thế nào?". Công việc thiết kế tốt nén thời gian — bạn nghĩ hai tiếng rồi đưa ra một quyết định tiết kiệm được mười tiếng thi công.
Thi công thì nhanh. Nó là áp pattern. Cho một design system, sinh ra các component. Cho một component, dây nó qua mười ba locale. Cho một page layout, ship hết các variant. Công việc không kém phần kỹ năng, nhưng ít mơ hồ hơn. Đáp án đúng thường có thể bảo vệ được so với spec.
Các mô hình AI khác nhau giỏi ở những dạng nhận thức khác nhau. Từ kinh nghiệm của riêng tôi trong vài tháng qua — đầu tiên với Claude Opus 4.6 rồi giờ là 4.7, đều ở extended-thinking — Opus là người bạn đồng hành toàn diện hơn. Brainstorm tốt hơn. Phán đoán thiết kế tốt hơn. Chậm hơn và kém sắc bén hơn ở pure code, nhưng nó cân nhắc toàn bộ bố cục trước khi trả lời, và nó suy luận theo kiểu bắt được vì sao một font cảm giác quá friendly và một font khác cảm giác đúng.
Codex trên GPT-5.5 với reasoning cao cấp cảm giác như một senior software engineer giỏi nhưng chưa bao giờ bước chân gần phía thiết kế. Nó nhanh. Nó xuất sắc ở multi-step tool use — mở file, đọc, sửa, chạy test, mở file kế tiếp. Nó không có quan điểm mạnh về việc một cái nút có quá cao hay không, nhưng nó ship cái nút, và nó ship mọi variant của cái nút trên mười ba locale mà không kêu ca. Hàm /goal của nó cho phép bạn giao cho nó một mục tiêu — ví dụ, "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" — rồi bỏ đi. Nó sẽ lên kế hoạch các sub-step, thực thi, chạy build, sửa cái nào hỏng, và đi tiếp. Khoảng thời gian dài nhất nó chạy không giám sát cho tôi, trong project này, là gần bốn tiếng.
Tôi phải thừa nhận tôi đã không chủ ý chia tách kiểu này từ đầu. Tôi đã nói chuyện thiết kế với Opus trong những ngày trước cuối tuần. Đến lúc cuối tuần dài bắt đầu, tôi đã có document hướng thiết kế và một prototype desktop trong tay. Chính cuối tuần đó tôi giao phần thi công cho Codex, và trong vòng một tiếng làm vậy, tôi nhận ra mỗi mô hình hợp với nửa công việc của nó tới mức nào.
Opus đã làm gì: pha thiết kế
Công việc thiết kế diễn ra trong một cuộc trò chuyện dài với Opus trong những ngày trước cuộc dựng lại. Hai artifact ra đời từ cuộc trò chuyện đó, và cả hai giờ đều nằm trong repo:
1. Một document hướng thiết kế. Sáu file markdown trong doc/v3-design/ — phần why, các token, các pattern mobile, page spec, ràng buộc accessibility, và execution plan. Hơn mười ba ngàn chữ quyết định, phần lớn do Opus viết từ một bản brief tôi đưa. Chỉ thị: "site tiếp theo nên cảm giác như một tạp chí in nhỏ, không phải một SaaS dashboard. Giành lấy sự chú ý bằng sự kiềm chế. Lấy Operating Model 2×2 framework làm chữ ký thị giác."
2. Một prototype HTML cho desktop. Một thư mục phẳng tại public/design-prototype-v2/ với sáu page và một style.css chung. Không React, không Tailwind, không framework — chỉ HTML viết tay để tôi có thể click qua từng page trên local server và cảm nhận xem design system có thật sự đứng vững như một hệ thống không. Prototype là nguồn chân lý cho cách xử lý thị giác trong phần còn lại của cuối tuần. Khi do dự trong lúc dựng lại, câu trả lời là "match the prototype."
Opus đưa ra những quyết định quan trọng nhất. Vài khoảnh khắc cụ thể:
-
Cú đảo chiều font. Một lần thiết kế trước đó đã chốt Manrope làm display font vì lý do availability và dễ ship — được commit trong một session Claude Sonnet 4.6. Mười tám tiếng sau, tôi đã đưa cuộc trò chuyện thiết kế sang Opus 4.7 với extended thinking, và bước đầu tiên của Opus là xem lại cái chốt đó. Sau khi tôi dành một buổi tối trên trang specimen chính thức của PP Neue Montreal để so các letterform, cú đổi được vào. Commit message đọc như hiện trường án mạng về typography: "Manrope rendered too rounded and friendly... Satoshi has the same condensed-grotesque proportions, the same double-storey
a, single-storeyg, sweptRleg, cleanly-sheared terminals." Cái nếp gấp thú vị là hai mô hình Claude khác nhau đưa ra hai phán đoán khác nhau cho cùng một quyết định. Sonnet chọn phương án an toàn. Opus chọn phương án đúng. -
Lựa chọn carmine. Cyan là điểm nhấn mặc định của AI. Opus và tôi dừng lại ở đỏ carmine —
#c33824, một sắc đỏ mực in, màu của vết bút biên tập trên galley proof hay một quyển Latin trên kệ Loeb Classical Library. Lập luận rất cụ thể: "site đang cố cảm giác editorial, không phải developer-tool. Cyan signals tech. Carmine signals craft. Dùng carmine tiết chế, luôn ở contrast cao, lý tưởng nhất là trên warm paper." Đó không phải kiểu quyết định mà một mô hình tối ưu cho thi công sẽ tự nghĩ ra. -
Operating Model như chữ ký thị giác. Framework 2×2 tôi dạy trong khoá học — Automate / Protect / Deepen / Change — trở thành một dấu thương hiệu lặng lẽ trên site mới. Ở bản hiện tại, nó chỉ xuất hiện ở hai chỗ rất tiết chế: khối thesis trên trang chủ và một dấu thesis nhỏ trên các bài viết dài. Bản thân framework là của tôi; nước đi biến nó thành căn cước thị giác của site đến từ cuộc trò chuyện thiết kế với Opus.
-
Sáng thay vì tối. Opus tranh luận chọn light mode làm personality và dark mode làm một variant được hỗ trợ. Lập luận: đọc dài dễ hơn trên warm paper so với trên glass; giá tiền cảm giác thật thà hơn trên nền sáng; gần như mọi công cụ AI đều ship dark mặc định, nên light chính là điểm khác biệt. Tôi không đồng ý trong vài tiếng, rồi đồng ý.
Opus chủ yếu là vòng thiết kế và review; Codex làm các pass implementation. Việc của Opus là phần công việc mà chậm thì lợi.
Codex đã làm gì: pha thi công
Một khi document thiết kế và prototype xong, công việc chuyển sang Codex.
Tôi mở một session Codex mới, đưa các file design direction làm context, rồi bắt đầu chạy các session /goal. Mỗi goal là một mục tiêu nhiều bước với một end state rõ ràng:
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.
Kiểu mục tiêu nhiều giai đoạn đó chính xác là thứ /goal được thiết kế để làm. Codex lên kế hoạch các sub-step, thực thi, chạy pnpm build để check type error, sửa cái nào hỏng, chạy build lần nữa, và đi tiếp. Tôi đi dạo về và v3 shell đã live trong codebase phía sau feature flag, các font mới đã load và bottom nav đang render trên mobile.
Các session /goal tiếp theo:
- Sinh trang home và archive v3 từ prototype.
- Sinh post layout v3, gồm cả reading progress bar và share button v3.
- Sinh trang products và learn v3, khớp với cấu trúc thang trong spec.
- Căn các trang course sales, login, signup, MFA, và access hiện có sang v3 về mặt thị giác, mà không đổi bất kỳ logic Stripe hay Supabase Auth bên dưới.
- Localize các bề mặt course v3 và Ask Sydney trên toàn bộ mười ba locale, dùng các file
messages/{locale}.jsonhiện có làm nguồn dịch.
Lần chạy dài nhất hoàn thành mà không can thiệp là gần bốn tiếng. Lần ngắn nhất khoảng bốn mươi lăm phút. Trong bốn ngày, tôi ship gần ba mươi commit — phần lớn là pass đầu hoặc pass thứ hai của Codex, với một ít cleanup tay khi output của mô hình đúng nhưng chưa hẳn đúng hình dáng. Thành thật mà nói: tôi nghĩ Codex viết phần lớn code thật sự đang chạy ở production hôm nay. Tôi viết hoặc sửa phần còn lại.
Điều hữu ích nhất ở /goal không phải tốc độ. Là tính tự chủ. Hầu hết các session code tôi chạy với công cụ AI yêu cầu tôi ngồi ở bàn phím — confirm một thay đổi, accept file kế, review diff. /goal cho phép bạn chỉ ra end state bạn muốn và đi đi. Bạn quay lại thấy hoặc một thay đổi đã xong, hoặc một session đã pause tại chỗ mô hình cần bạn đưa ra phán đoán. Hình dáng công việc khác đi. Bạn trở thành người lên kế hoạch các session dài hàng tiếng thay vì babysit từng edit nhỏ.
Ranh giới vẫn nằm ở đâu
Chia thiết kế và thi công cho hai mô hình không phải trò ảo thuật. Vẫn có những khoảnh khắc mô hình này cần mô hình kia, và một vài khoảnh khắc cả hai đều chưa đủ một mình.
Icon Sparkles. Codex sinh một v3 mobile shell sạch với icon Sparkles ✨ trên tab Ask — dấu chỉ phổ quát của công cụ AI. Icon đúng so với spec; spec không nói "đừng dùng cliché." Tôi để ý vài ngày sau và quay lại Opus để bàn các phương án thay thế. Chúng tôi đi qua nhiều vòng: dấu Operating Model, rồi một dấu hỏi Newsreader in nghiêng màu carmine — kiểu glyph bạn có thể thấy như marginalia trong một bài tiểu luận cũ. Phương án cuối là ý của Opus. Codex ship nó trong mười lăm phút.
Khoảnh khắc Hinomaru. Trong lúc dấu Operating Model đang nằm ở góc trên bên trái của mobile app bar, cạnh tên tôi, tôi đã nhìn nó hai ba ngày liền. Một chấm carmine nhỏ trên một ô warm paper. Rồi một buổi tối tôi nhìn nó theo cách một người khác sẽ nhìn, và cảm thấy một cú nhận ra hơi đỏ mặt. Nó trông y hệt cờ Nhật Bản. Hinomaru. Một mặt trời đỏ nhỏ trên nền nhạt. Cả Opus lẫn Codex đều không bắt được điều này. Opus đã thiết kế dấu đó; Codex đã implement nó; cả hai đã review nó. Liên tưởng thị giác là một pattern văn hoá mà cả hai mô hình đều không thấy. Tôi xoá dấu khỏi wordmark và tìm hướng giải khác. (Cùng cái ? in nghiêng đó kết thúc bằng việc lấp chỗ trên tab Ask.)
Cú rollout 13 locale. Opus có thể đã thiết kế các nuance UI của từng locale một cách thấu đáo nhưng sẽ tốn nhiều ngày để làm vậy. Codex không thể tự đưa ra phán đoán thiết kế nhưng có thể ship cả mười ba locale trong một buổi tối khi các pattern đã được dựng. Đây là ví dụ rõ nhất theo nghĩa đen của cú chia: thiết kế chậm, thi công nhanh.
Chọn ba font đi chung được với nhau. Opus chọn Satoshi (display), Newsreader (italic accent), và JetBrains Mono (label). Codex sẽ không tự chọn được tổ hợp này — và tôi cũng không chắc tôi sẽ chọn được nếu thiếu cái chậm của Opus trong cuộc trò chuyện. Bố cục ba font là quyết định thiết kế, không phải quyết định thi công.
Cuộc trò chuyện giữa hai hệ thống xảy ra trong đầu tôi, không phải giữa các mô hình. Đó là phần vẫn chưa tự động hoá được năm 2026 — và tôi nghĩ đó là phần định nghĩa "taste" lúc này.
Tổng kết thành thật
Bốn ngày. Gần ba mươi commit. v3 production đã live trên chandlernguyen.com. Site mới đang làm việc mới — giúp người ghé tìm đọc tiếp cái gì thay vì kể với họ rằng tôi đã bước qua bên kia.
Site còn một vấn đề tôi vẫn đang đuổi theo. Lúc draft, Lighthouse mobile ở production cho blog archive ra 4.6 giây trong khi trace Chrome DevTools local của tôi cho cùng tấm hình paint trong 264 mili giây — cùng code, network model rất khác. Cách sửa dẫn đầu hiện tại của tôi là áp lực từ font preload: ba webfont preload cộng ba chunk CSS render-blocking đua với hình về đích trên một kết nối mobile bị throttle. Tôi đã deploy bản nhỏ nhất của fix đó trong ngày cuối và vẫn cần một lượt Lighthouse mới để xác nhận nó đã landing. Bài bạn đang đọc được viết trước khi tôi có con số sau-fix.
Chi phí subscription: subscription Codex của tôi ở tier cao nhất, cộng subscription Claude Max tôi đã có sẵn. Cộng lại vài trăm đô một tháng. Rẻ, so với throughput.
Việc v3 xong trong bốn ngày thay vì ba tuần phần lớn là vì pha thiết kế và pha thi công được tách ra và giao cho các mô hình giỏi ở từng phần. Tôi không nghĩ điều này phổ quát. Có những project mà một mô hình có thể làm cả hai, và những project mà chẳng mô hình nào là bạn đồng hành đúng. Nhưng với một bản redesign multi-page, multi-locale, multi-surface có một quan điểm thiết kế mạnh, cú chia này là cách làm tôi sẽ chọn lại.
Nếu bạn vừa làm một bản dựng lại có AI hỗ trợ của riêng mình, tôi rất muốn nghe bạn đã chia công việc ra sao. Bạn có dùng một mô hình từ đầu đến cuối không? Bạn chia theo pha như tôi, hay theo một trục khác — theo component, theo file, theo loại task? Tôi nghĩ đợt build-in-public tiếp theo sẽ xoay quanh AI nào cho phần nào của công việc, không chỉ là chuyện bạn có dùng AI hay không.
Nếu bạn muốn xem kết quả, bạn đang đọc nó. Home page ở chandlernguyen.com. Thang sản phẩm ở /products/. Khoá học khởi nguồn cho cả ý tưởng "operating model" ở /learn/.
Thân mến,
Chandler