"จริงๆ แล้วโมเดลมันเก่งกว่าคุณนะ ในการดึง requirement…
"The model is probably better at extracting requirements from you than you are at defining your requirements."
— Arnaud Doko (Ara)
Member of Technical Staff · Applied AI team · Anthropic
ผู้ที่ทำงานในทีมที่ build harness และ pattern ที่ Anthropic ใช้กับ Claude Code ภายในเอง
ผมไปฟัง "How we Claude Code" จากช่อง Claude มาครับ เป็น session จากงาน Code w/ Claude ที่ Ara ขึ้นพูดวิธีที่ทีม Anthropic ใช้ Claude Code จริงๆ ในแต่ละวัน (ต่อยอดจาก talk ของ Tar ที่ SF ก่อนหน้านี้ 1 อาทิตย์ครึ่ง ที่กลายเป็น blog post ดังชื่อ "The unreasonable effectiveness of HTML files")
เหมาะมากสำหรับคนที่ใช้ Claude Code อยู่แล้วแต่รู้สึกว่ายังใช้ไม่สุด หรือคนที่กำลังจะเปลี่ยน workflow จาก markdown มาเป็นอะไรที่หนาแน่นกว่า เลยอยากมาแชร์ให้ฟังครับ
1. Models เก่งขึ้น = agent วิ่งได้นานขึ้น
Ara เปิดมาด้วย logic ง่ายๆ ครับ โมเดล AI เก่งขึ้น แปลว่า agent (ตัว AI ที่ทำงานต่อเนื่องด้วยตัวเอง ไม่ใช่ถาม-ตอบทีละครั้ง) run ได้ยาวขึ้น รับ task ซับซ้อนขึ้นได้ แต่นั่นแปลว่าเราต้อง "เปลี่ยน habit" ในการทำงานด้วย ไม่ใช่ใช้แบบเดิม
2. Agent run นาน = เผาเงินเยอะถ้าผิดทาง
ประเด็นต่อมา ถ้าปล่อย agent run นานๆ แล้วมันไปผิดทาง คุณ burn tokens เยอะมาก (token = หน่วยที่ AI คิดเงิน ยิ่ง agent คิด/เขียนนาน ยิ่งจ่ายเยอะ) เพราะงั้นต้อง frontload การ verify ตั้งแต่ต้น คือเช็คก่อนปล่อยให้มันลุยยาว ไม่ใช่รอจน agent ทำเสร็จแล้วค่อยมาพบว่าผิด
3. The bitter lesson ของ Richard Sutton
อ้างถึง Richard Sutton (เจ้าพ่อสาย Reinforcement Learning — แขนงนึงของ AI ที่ให้เครื่องเรียนรู้เองจากการลองผิดลองถูก) ที่บอกว่าการพยายาม hard code ทุกอย่างเองสุดท้ายจะแพ้การโยน data + compute ใส่ระบบ พูดง่ายๆ คือ "อย่าพยายามฉลาดกว่าโมเดล" เอามาใช้กับ Claude ก็คือ อย่าพยายาม over-constrain มัน ปล่อยให้มันถามและดึง requirement ออกจากตัวเราเอง
4. "Just make it better" = bad prompting
ประโยคที่ฟังแล้วเจ็บนิดๆ ครับ Ara บอกว่าเห็นคนใช้ Claude Code พิมพ์ "make it better" เยอะมาก ซึ่งไม่ดี ที่ดีคือบอก domain ที่สนใจ (เช่น "เน้น UX สำหรับมือใหม่" "ให้มัน mobile-friendly") แต่ไม่ต้อง over-specify outcome (ห้ามสั่งทุกอย่างจนตาย) แล้วให้ Claude มันถามต่อเอง
5. ใช้ ask user question tool ในตัว prompt
Ara แนะนำให้พิมพ์ใน prompt ตรงๆ เลยว่าให้ Claude ใช้ ask_user_question tool (เครื่องมือที่ทำให้ Claude หยุดถามกลับเป็นข้อๆ ก่อนเริ่มงาน) จะได้ flow เป็นแบบ interview turn-by-turn เรานั่งตอบคำถามมัน แทนที่เราจะต้องบรรยายทุกอย่างตั้งแต่ต้น
6. Auto mode + effort high + fast mode คือ default ของทีม Anthropic
Ara ขอ show of hands แล้วดีใจที่หลายคนใช้ auto mode (โหมดที่ Claude วิ่งงานเองได้โดยไม่ต้องกดอนุมัติทุก step) "you need to be using auto mode" คำแนะนำคือ effort = X high หรือ max (ปรับให้ Claude คิดหนักขึ้น) + เปิด fast mode สำหรับ iterate เร็วๆ
7. Markdown file = lingua franca ที่กำลังหมดอายุ
มีโควทเพื่อนร่วมงาน Ara ที่ poetic ดี "the markdown file is the lingua franca of the AI native software development life cycle" คือบอกว่าไฟล์ markdown เป็นภาษากลางของยุค AI dev แต่ Ara บอกว่ามันเริ่มจะตันแล้ว ยาวเกิน อ่านไม่ไหว เพื่อนร่วมทีมยิ่งไม่อ่าน
8. ถ้า markdown ยาวเกิน 200 บรรทัด = ไม่มีใครอ่าน
ตัวเลขเจ็บอีก Ara บอกตรงๆ ว่าถ้า markdown file ยาวเกิน 200 บรรทัด โอกาสที่คุณจะอ่านมันน้อย และโอกาสที่เพื่อนร่วมงานจะอ่าน "certainly unlikely" — เคยเขียน spec ยาว 500 บรรทัดแล้วไม่มีใครอ่านครบ คุ้นมั้ยครับ
9. HTML spec = information dense + ergonomic กว่า
ทางออกคือเปลี่ยนจาก markdown มาเป็น HTML file เพราะมัน dense กว่า (ใส่ข้อมูลในพื้นที่เท่ากันได้เยอะกว่า) interact ได้รวยกว่า ถ่าย screenshot กลับมา feed Claude ได้ ใช้ Playwright MCP (เครื่องมือที่ให้ Claude เปิดเบราว์เซอร์คลิกดูได้เอง) เปิดดูได้ ดีกว่าอ่าน markdown ยาวๆ เยอะ
10. ลอง generate design directions 4-5 แบบใน HTML
Ara โชว์ตัวอย่าง bill splitting app (แอปหารเงินเวลาไปกินข้าวกับเพื่อน) ที่ขอให้ Claude generate 4 design directions เป็น HTML แล้วคลิกดูจริง อันนึง brutalist (สไตล์ดิบๆ block ใหญ่ๆ) อีกอันเป็น Tokyo fintech (สไตล์เนี้ยบแบบแอปการเงินญี่ปุ่น) แต่ละอันคลิกเข้าไปดูได้ ให้ feedback ง่ายกว่าอ่าน markdown เยอะ
11. Verification ต้องเป็น "agent native"
ส่วนที่เด็ดที่สุดของ talk ครับ Ara บอกว่าต้องฝัง verification เข้าไปใน artifact เอง ไม่ใช่ทำเป็น test แยก ให้ component publish state ของตัวเองลงไปใน DOM (DOM = โครงสร้างหน้าเว็บที่เบราว์เซอร์เห็น) ผ่าน data attributes (แท็กเล็กๆ ที่ฝังในหน้าเว็บไว้บอกว่า state ตอนนี้คืออะไร) เพื่อให้ agent อ่านได้ตรงๆ ไม่ต้อง scrape เดาเอง
12. โชว์ to-do app ที่ทำ verification 3 surface
เคสจริงที่ Ara โชว์ใน workshop คือ React to-do app ที่ทำ verification ได้ 3 ทางใน contract เดียวกัน — (1) human-readable dashboard ที่คนเปิดดูเอง (2) agent-driven จาก browser ผ่าน Playwright MCP (3) headless ผ่าน bun verify ใน CI (รันบน build pipeline ไม่มีหน้าจอ) — ทุกทางอ่าน DOM contract เดียวกัน
13. แตะ contract = แตะ verification (ไม่ใช่ app)
ตอน demo Ara ลบ data attribute ใน DOM ทิ้งแล้ว rerun แล้ว verification fail หมด พร้อม comment ว่า "not because we broke the app, but because we broke the contract" คือแอปยังใช้งานได้ปกตินะ แต่ contract (ข้อตกลงว่าหน้าเว็บต้อง expose state อะไรบ้างให้ agent อ่าน) พังก็ verify ไม่ผ่านแล้ว ฟังแล้วเข้าใจ pattern ทันที
14. Record verification เป็น clip เก็บเป็น evidence
ทีม Claude Code ที่ Anthropic record verification ทุกครั้งเป็น video clip เก็บใน S3 (cloud storage ของ AWS) share กันในทีม Ara บอกว่า "the cloud code team records basically all the code changes that they do like this" โดยเฉพาะ front-end คือเปลี่ยนอะไรไป มี video proof เลยว่ามันยัง work
15. HTML spec ไม่ใช่ token inefficient
มีคนถามคำถามที่หลายคนน่าจะสงสัย "HTML spec ไม่กิน token เยอะกว่า markdown หรอ" Ara ตอบว่า no เพราะถ้า spec ดีตั้งแต่ต้น คุณ iterate น้อยลง long term คุ้มกว่า แม้ครั้งเดียวจะ generate แพงกว่าก็จริง
ผมว่า insight ที่ติดในใจที่สุดของคลิปนี้คือ "ให้ Claude ทำหน้าที่ดึง requirement จากคุณ ไม่ใช่คุณนั่งเขียน spec เอง" เปลี่ยน mental model จาก "ฉันต้องเขียน spec ให้ครบก่อนค่อยพิมพ์ให้ AI" เป็น "ฉันรู้คร่าวๆ ว่าอยากได้อะไร แล้วปล่อยให้ AI สัมภาษณ์ฉันออกมา" และเรื่อง HTML spec แทน markdown เป็นอีกอย่างที่น่าลอง โดยเฉพาะใครที่เริ่มรู้สึกว่า markdown ยาวจนไม่มีใครอ่านครับ
https://dub.sh/k2FDMb1
อยากใช้ AI กับงานจริงเป็นระบบ?
เรียน Claude Method — วิธีคิดและลงมือใช้ Claude/AI กับงานจริง ตั้งแต่วันแรก
📍 โพสต้นฉบับบน Facebook: AI กับ Peesamac