- Arno từ đội Applied AI của Anthropic tổ chức workshop về "cách chúng tôi dùng Claude Code tại Anthropic", gồm ba cấp độ: để Claude phỏng vấn bạn nhằm trích xuất yêu cầu, dùng file
HTMLgiàu thông tin thay cho specMarkdown, và xây dựng kiểm chứng (verification) ngay trong artifact. - Khi mô hình mạnh hơn, bạn nên tránh ràng buộc chúng quá mức (theo "bitter lesson" của Richard Sutton) và để Claude phỏng vấn bạn qua công cụ ask-user-question, vì Claude thường giỏi trích xuất yêu cầu tiềm ẩn của bạn hơn chính bạn diễn đạt.
- Workshop xây một app chia hóa đơn và một app to-do bằng React, cho thấy cách sinh nhiều hướng thiết kế
HTMLđể phản hồi phong phú hơn, và cách nhúng kiểm chứng đọc được bởi agent (DOM state contract, Storybook fixtures,Playwright MCP) chạy ở ba dạng: dashboard cho người, luồng do agent điều khiển, và headless trong CI.
How we Claude Code
- Phiên dựa trên bài nói của Tariq ở San Francisco và bài blog "The Unreasonable Effectiveness of HTML files", lập luận chuyển từ
MarkdownsangHTMLcho spec; có một repo đi kèm ("how we Claude Code" trong "Claude with Code workshops") để code theo qua ba phase. - Khi mô hình tốt hơn, agent chạy lâu hơn với tác vụ phức tạp hơn, có thể đốt nhiều token nếu đi sai hướng — nên hãy dồn (front-load) phần kiểm chứng mà con người sẽ làm vào định dạng
HTMLphong phú, thân thiện hơn. - Tránh ràng buộc mô hình mạnh ("bitter lesson" của Richard Sutton): Claude thường giỏi trích xuất điều bạn muốn hơn chính bạn diễn đạt, nên để nó phỏng vấn để loại bỏ sự mơ hồ thay vì áp đặt kết quả từ đầu.
- Prompt tốt là cho Claude các lĩnh vực và vùng quan tâm, dùng công cụ ask-user-question để kích hoạt phỏng vấn lặp; prompt tệ là chỉ gõ "make it better".
- Cấu hình Claude Code khuyến nghị: dùng
auto mode(shift-tab để chuyển), đặt tham sốeffort(khuyến nghị extra-high hoặc max), và dùngfast modeđể lặp spec nhanh — đồng thời chụp màn hình để cho Claude phản hồi trực quan, nhất là khi làm front-end. - File
HTMLgiàu thông tin và tiện hơnMarkdownđể xem app sẽ trông ra sao (file Markdown trên ~200 dòng hiếm khi được đọc); Opus 4.7 sinh bốn hướng thiết kế (ví dụ brutalist, Tokyo fintech) cho app chia hóa đơn để click qua và góp ý. - Cách kiểm chứng làm cho trạng thái đọc được bởi agent bằng cách publish state của component ra
DOM(data-verify, schema, fixture, known state, invariant, probe), để agent chạy kiểm chứng độc lập với React internals thay vì scrape DOM. - Kiểm chứng chạy ba dạng — dashboard cho người, luồng do agent điều khiển từ trình duyệt qua
Playwright MCP, và headless quabun verifytrong CI — và đội Claude Code ghi lại các lần kiểm chứng thành clip lưu trên S3 làm bằng chứng; specHTMLkhông kém hiệu quả token về dài hạn vì spec phong phú nghĩa là ít lần lặp hơn.
HTML spec— HTML speccông cụ ask-user-question— ask-user-question toolbitter lesson— the bitter lessonauto mode— auto modetham số effort— effort parameterfast mode— fast modePlaywright MCP— Playwright MCPDOM contract— DOM contractinvariant— invariantStorybook fixtures— Storybook fixtures
Bối cảnh: Agent ngày càng mạnh, cách làm phải đổi
Arno, kiến trúc sư thuộc đội Applied AI của Anthropic, dẫn dắt workshop về "cách chúng tôi dùng Claude Code tại Anthropic". Nội dung dựa trên bài nói của Tariq tại San Francisco và bài blog "The Unreasonable Effectiveness of HTML files", với một repo đi kèm gồm ba phase để code theo.
Luận điểm cốt lõi: mô hình ngày càng mạnh nên agent chạy lâu hơn và nhận tác vụ phức tạp hơn — nhưng nếu đi sai, chúng đốt rất nhiều token. Vì vậy nên thay đổi thói quen làm việc và dồn phần kiểm chứng (verification) mà con người vốn làm vào một định dạng giàu thông tin, thân thiện hơn: file HTML. Workshop tập trung ba cấp độ: (1) để Claude phỏng vấn bạn, (2) dùng HTML thay Markdown, (3) nhúng kiểm chứng vào artifact.
Cấp 1: Để Claude phỏng vấn và trích xuất yêu cầu
Liên hệ với "bitter lesson" của Richard Sutton (cha đẻ học tăng cường): dồn thêm dữ liệu và tính toán thường thắng mọi ràng buộc do con người hard-code. Tương tự, Claude thường giỏi trích xuất yêu cầu từ bạn hơn chính bạn diễn đạt — yêu cầu nằm tiềm ẩn trong bạn, giống như người dùng "biết khi nhìn thấy" nhưng khó nói rõ.
Phân biệt prompt:
- Prompt tệ: chỉ gõ "make it better".
- Prompt tốt: đưa ra các lĩnh vực/vùng quan tâm, không áp đặt kết quả, và yêu cầu Claude dùng công cụ
ask-user-questionđể phỏng vấn lặp lại nhằm tạo spec.
Cấu hình khuyến nghị: dùng auto mode (shift-tab để chuyển vào), đặt tham số effort ở mức extra-high (hoặc max), và fast mode để lặp spec nhanh.
Cấp 2: Dùng file HTML thay Markdown
Markdown từng được gọi là "lingua franca" của vòng đời phát triển phần mềm AI-native, nhưng nó bị giới hạn: file dài hơn ~200 dòng thì hiếm ai (kể cả đồng nghiệp) đọc. File HTML giàu thông tin và tiện hơn để hình dung app sẽ trông ra sao, có thể kèm screenshot và tương tác phong phú (qua Playwright MCP).
Trước phiên, diễn giả đã dùng Opus 4.7 sinh bốn hướng thiết kế cho app chia hóa đơn (ví dụ brutalist, Tokyo fintech) để click qua và góp ý — dễ hơn nhiều so với suy diễn từ file Markdown. Mẹo: thường xuyên chụp màn hình đưa lại cho Claude, đặc biệt với front-end; Opus 4.7 có vision model tốt hơn nên trích xuất vấn đề từ ảnh rất hiệu quả.
Cấp 3: Kiểm chứng đọc được bởi Agent
Phần quan trọng nhất là nhúng kiểm chứng vào chính artifact. Workshop dùng Storybook fixtures, thư viện test, các thuộc tính dữ liệu, và Playwright MCP cho một app to-do bằng React. Ý tưởng: component publish trạng thái ra DOM (data-verify unit, total done/active) để agent đọc trực tiếp thay vì scrape DOM, cho phép chạy kiểm chứng độc lập với React internals.
Mỗi component có: schema, fixture, các trạng thái đã biết (known states), các invariant (điều kiện luôn phải đúng) được kiểm bằng probe đẩy ra ngoài happy path.
Kiểm chứng chạy ba bề mặt:
- Dashboard cho người đọc: chạy từng bước hoặc tất cả; có thể ghi lại thành clip làm bằng chứng (lưu lên S3, chia sẻ đồng nghiệp).
- Do agent điều khiển từ trình duyệt: qua
Playwright MCP, đọc manifest các bước kiểm chứng từ state trong DOM. - Headless trong CI: chạy
bun verify.
Trong demo, một lỗi được cài sẵn (3 + 4 không bằng 10) khiến kiểm chứng thất bại; khi "phá contract nhưng không phá app", các kiểm chứng vẫn fail vì agent đọc DOM contract. Cuối cùng để Opus 4.7 (đã nối Playwright MCP) tự chẩn đoán nguyên nhân.
Tổng kết
Ba bề mặt — người, agent từ trình duyệt, và CI (bun verify) — đều nhắm tới việc nhúng kiểm chứng vào artifact. Điều mới không phải là công cụ lạ, mà là sắp xếp lại các primitive quen thuộc để agent dùng được trước tiên. Khuyến nghị: dùng Opus 4.7 (vision tốt hơn Sonnet) và fast mode. Về câu hỏi "spec HTML có tốn token hơn không?", câu trả lời thường là không — vì spec phong phú giúp lặp ít hơn về dài hạn, dù một lần sinh có thể tốn token hơn.
TL;DR
- Arno từ đội Applied AI của Anthropic tổ chức workshop về "cách chúng tôi dùng Claude Code tại Anthropic", gồm ba cấp độ: để Claude phỏng vấn bạn nhằm trích xuất yêu cầu, dùng file
HTMLgiàu thông tin thay cho specMarkdown, và xây dựng kiểm chứng (verification) ngay trong artifact. - Khi mô hình mạnh hơn, bạn nên tránh ràng buộc chúng quá mức (theo "bitter lesson" của Richard Sutton) và để Claude phỏng vấn bạn qua công cụ ask-user-question, vì Claude thường giỏi trích xuất yêu cầu tiềm ẩn của bạn hơn chính bạn diễn đạt.
- Workshop xây một app chia hóa đơn và một app to-do bằng React, cho thấy cách sinh nhiều hướng thiết kế
HTMLđể phản hồi phong phú hơn, và cách nhúng kiểm chứng đọc được bởi agent (DOM state contract, Storybook fixtures,Playwright MCP) chạy ở ba dạng: dashboard cho người, luồng do agent điều khiển, và headless trong CI.
Điểm chính
- Phiên dựa trên bài nói của Tariq ở San Francisco và bài blog "The Unreasonable Effectiveness of HTML files", lập luận chuyển từ
MarkdownsangHTMLcho spec; có một repo đi kèm ("how we Claude Code" trong "Claude with Code workshops") để code theo qua ba phase. - Khi mô hình tốt hơn, agent chạy lâu hơn với tác vụ phức tạp hơn, có thể đốt nhiều token nếu đi sai hướng — nên hãy dồn (front-load) phần kiểm chứng mà con người sẽ làm vào định dạng
HTMLphong phú, thân thiện hơn. - Tránh ràng buộc mô hình mạnh ("bitter lesson" của Richard Sutton): Claude thường giỏi trích xuất điều bạn muốn hơn chính bạn diễn đạt, nên để nó phỏng vấn để loại bỏ sự mơ hồ thay vì áp đặt kết quả từ đầu.
- Prompt tốt là cho Claude các lĩnh vực và vùng quan tâm, dùng công cụ ask-user-question để kích hoạt phỏng vấn lặp; prompt tệ là chỉ gõ "make it better".
- Cấu hình Claude Code khuyến nghị: dùng
auto mode(shift-tab để chuyển), đặt tham sốeffort(khuyến nghị extra-high hoặc max), và dùngfast modeđể lặp spec nhanh — đồng thời chụp màn hình để cho Claude phản hồi trực quan, nhất là khi làm front-end. - File
HTMLgiàu thông tin và tiện hơnMarkdownđể xem app sẽ trông ra sao (file Markdown trên ~200 dòng hiếm khi được đọc); Opus 4.7 sinh bốn hướng thiết kế (ví dụ brutalist, Tokyo fintech) cho app chia hóa đơn để click qua và góp ý. - Cách kiểm chứng làm cho trạng thái đọc được bởi agent bằng cách publish state của component ra
DOM(data-verify, schema, fixture, known state, invariant, probe), để agent chạy kiểm chứng độc lập với React internals thay vì scrape DOM. - Kiểm chứng chạy ba dạng — dashboard cho người, luồng do agent điều khiển từ trình duyệt qua
Playwright MCP, và headless quabun verifytrong CI — và đội Claude Code ghi lại các lần kiểm chứng thành clip lưu trên S3 làm bằng chứng; specHTMLkhông kém hiệu quả token về dài hạn vì spec phong phú nghĩa là ít lần lặp hơn.
Từ vựng
HTML spec— HTML speccông cụ ask-user-question— ask-user-question toolbitter lesson— the bitter lessonauto mode— auto modetham số effort— effort parameterfast mode— fast modePlaywright MCP— Playwright MCPDOM contract— DOM contractinvariant— invariantStorybook fixtures— Storybook fixtures
Nội dung chi tiết
Bối cảnh: Agent ngày càng mạnh, cách làm phải đổi
Arno, kiến trúc sư thuộc đội Applied AI của Anthropic, dẫn dắt workshop về "cách chúng tôi dùng Claude Code tại Anthropic". Nội dung dựa trên bài nói của Tariq tại San Francisco và bài blog "The Unreasonable Effectiveness of HTML files", với một repo đi kèm gồm ba phase để code theo.
Luận điểm cốt lõi: mô hình ngày càng mạnh nên agent chạy lâu hơn và nhận tác vụ phức tạp hơn — nhưng nếu đi sai, chúng đốt rất nhiều token. Vì vậy nên thay đổi thói quen làm việc và dồn phần kiểm chứng (verification) mà con người vốn làm vào một định dạng giàu thông tin, thân thiện hơn: file HTML. Workshop tập trung ba cấp độ: (1) để Claude phỏng vấn bạn, (2) dùng HTML thay Markdown, (3) nhúng kiểm chứng vào artifact.
Cấp 1: Để Claude phỏng vấn và trích xuất yêu cầu
Liên hệ với "bitter lesson" của Richard Sutton (cha đẻ học tăng cường): dồn thêm dữ liệu và tính toán thường thắng mọi ràng buộc do con người hard-code. Tương tự, Claude thường giỏi trích xuất yêu cầu từ bạn hơn chính bạn diễn đạt — yêu cầu nằm tiềm ẩn trong bạn, giống như người dùng "biết khi nhìn thấy" nhưng khó nói rõ.
Phân biệt prompt:
- Prompt tệ: chỉ gõ "make it better".
- Prompt tốt: đưa ra các lĩnh vực/vùng quan tâm, không áp đặt kết quả, và yêu cầu Claude dùng công cụ
ask-user-questionđể phỏng vấn lặp lại nhằm tạo spec.
Cấu hình khuyến nghị: dùng auto mode (shift-tab để chuyển vào), đặt tham số effort ở mức extra-high (hoặc max), và fast mode để lặp spec nhanh.
Cấp 2: Dùng file HTML thay Markdown
Markdown từng được gọi là "lingua franca" của vòng đời phát triển phần mềm AI-native, nhưng nó bị giới hạn: file dài hơn ~200 dòng thì hiếm ai (kể cả đồng nghiệp) đọc. File HTML giàu thông tin và tiện hơn để hình dung app sẽ trông ra sao, có thể kèm screenshot và tương tác phong phú (qua Playwright MCP).
Trước phiên, diễn giả đã dùng Opus 4.7 sinh bốn hướng thiết kế cho app chia hóa đơn (ví dụ brutalist, Tokyo fintech) để click qua và góp ý — dễ hơn nhiều so với suy diễn từ file Markdown. Mẹo: thường xuyên chụp màn hình đưa lại cho Claude, đặc biệt với front-end; Opus 4.7 có vision model tốt hơn nên trích xuất vấn đề từ ảnh rất hiệu quả.
Cấp 3: Kiểm chứng đọc được bởi Agent
Phần quan trọng nhất là nhúng kiểm chứng vào chính artifact. Workshop dùng Storybook fixtures, thư viện test, các thuộc tính dữ liệu, và Playwright MCP cho một app to-do bằng React. Ý tưởng: component publish trạng thái ra DOM (data-verify unit, total done/active) để agent đọc trực tiếp thay vì scrape DOM, cho phép chạy kiểm chứng độc lập với React internals.
Mỗi component có: schema, fixture, các trạng thái đã biết (known states), các invariant (điều kiện luôn phải đúng) được kiểm bằng probe đẩy ra ngoài happy path.
Kiểm chứng chạy ba bề mặt:
- Dashboard cho người đọc: chạy từng bước hoặc tất cả; có thể ghi lại thành clip làm bằng chứng (lưu lên S3, chia sẻ đồng nghiệp).
- Do agent điều khiển từ trình duyệt: qua
Playwright MCP, đọc manifest các bước kiểm chứng từ state trong DOM. - Headless trong CI: chạy
bun verify.
Trong demo, một lỗi được cài sẵn (3 + 4 không bằng 10) khiến kiểm chứng thất bại; khi "phá contract nhưng không phá app", các kiểm chứng vẫn fail vì agent đọc DOM contract. Cuối cùng để Opus 4.7 (đã nối Playwright MCP) tự chẩn đoán nguyên nhân.
Tổng kết
Ba bề mặt — người, agent từ trình duyệt, và CI (bun verify) — đều nhắm tới việc nhúng kiểm chứng vào artifact. Điều mới không phải là công cụ lạ, mà là sắp xếp lại các primitive quen thuộc để agent dùng được trước tiên. Khuyến nghị: dùng Opus 4.7 (vision tốt hơn Sonnet) và fast mode. Về câu hỏi "spec HTML có tốn token hơn không?", câu trả lời thường là không — vì spec phong phú giúp lặp ít hơn về dài hạn, dù một lần sinh có thể tốn token hơn.