Anthropic ปล่อยเวิร์กชอปชื่อ "How we Claude Code" บนช่อง YouTube ของตัวเองเมื่อวันที่ 23 พฤษภาคม 2026 ความยาว 31 นาที 43 วินาที ในคลิปนี้ Ara สถาปนิกทีม Applied AI ของ Anthropic ขึ้นเวทีถ่ายทอดวิธีที่ทีมภายในใช้ Claude Code ทำงานจริง เนื้อหาต่อยอดจากเซสชันที่ Tar สมาชิกทีม Claude Code ขึ้นเล่าที่ซานฟรานซิสโกก่อนหน้านั้นประมาณหนึ่งสัปดาห์ครึ่ง และจากบล็อกโพสต์ชื่อ "The Unreasonable Effectiveness of HTML Files" นี่เป็นโอกาสไม่บ่อยนักที่ Anthropic เปิดให้เห็น internal workflow ของทีมที่สร้าง Claude Code เอง โดยเฉพาะช่วงที่ Opus 4.7 เพิ่งออกเป็น default model
บทความนี้สรุปเนื้อหาจากเวิร์กชอปดังกล่าว เพื่อให้คนไทยที่ใช้ Claude Code ระดับพื้นฐานอยู่แล้วนำไปปรับ habit การทำงานได้ทันที โดยยึดโครงจากเวิร์กชอปที่ Ara วางไว้
ทำไมทีม Anthropic ถึงต้องเปลี่ยน habit การทำงาน
Ara เปิดเวิร์กชอปด้วยการชี้ว่า agent กำลังเก่งขึ้นเรื่อยๆ เพราะโมเดลเบื้องหลังเก่งขึ้น และเมื่อโมเดลเก่งขึ้น agent ก็รันได้นานขึ้น รับงานซับซ้อนได้มากขึ้น ปัญหาคือถ้าให้ทิศผิดตั้งแต่ต้น agent จะ burn token ระหว่างทางเยอะมาก ทีม Anthropic จึงต้อง front-load การ verify ของมนุษย์ไว้ตั้งแต่ขั้น spec ก่อนปล่อย agent วิ่ง
หลักคิดเบื้องหลังทุกอย่างที่ Ara นำเสนอในเวิร์กชอปนี้คือ Bitter Lesson ของ Richard Sutton บิดาของ reinforcement learning ใจความสำคัญคือ ในระยะยาว ระบบ AI ที่ใช้ compute + data มหาศาลจะเหนือกว่าระบบที่มนุษย์พยายาม hard-code rule ใส่ เพราะกำลังประมวลผลที่เพิ่มขึ้นเรื่อยๆ จะค้นพบ pattern ที่ดีกว่า rule ที่มนุษย์เขียนไว้ล่วงหน้า Ara จึงสรุปออกมาเป็นคำแนะนำตรงๆ ว่า
"the more capable the models get, the more you should try to resist constraining them"
แปลสั้นๆ คือ โมเดลยิ่งเก่ง ยิ่งควรลดกรอบที่ครอบมันลง Ara นำหลักคิดนี้มาถ่ายทอดเป็น 3 อัพเกรดเชิงปฏิบัติที่ทีม Claude Code ใช้กันจริงในปัจจุบัน
อัพเกรดที่ 1: เลิกเขียน spec ยาว ปล่อยให้ Claude สัมภาษณ์ requirements
อัพเกรดแรกที่ Ara เสนอคือ เลิกพิมพ์ spec ยาวเหยียดให้โมเดลตั้งแต่ต้น session แล้วเปลี่ยนมาใส่ prompt ที่บังคับให้ Claude เรียก tool ชื่อ ask_user_question กลับมาสัมภาษณ์ requirements ทีละข้อ ผู้ใช้เลือกคำตอบผ่าน tab UI ได้ทีละข้อ จากนั้น Claude ค่อยเริ่มเขียน spec จริง
เหตุผลที่ทีม Anthropic เปลี่ยนวิธีนี้สรุปไว้ในคำพูดของ Ara เองว่า
"the model is probably better at extracting requirements from you than you are at defining your requirements"
Ara ขยายความต่อโดยเทียบกับการคุยกับลูกค้าทั่วไป
"the requirements are latent within you. Just like when you talk to your users, they have an idea of they know it when they see it, but they're often not very good at articulating what they need"
แนวคิดคือ requirements ส่วนใหญ่ฝังอยู่ในตัวผู้ใช้แบบ "เห็นแล้วรู้" แต่ "พูดออกมาไม่ถูก" เป็นปัญหาเดียวกับที่ designer หรือ product manager เจอตอนสัมภาษณ์ลูกค้า Claude รุ่นใหม่ดึง requirement จากผู้ใช้ได้แม่นกว่าการให้ผู้ใช้พยายาม define ให้ครบจบในหน้าเดียว
Ara ยังแยกให้ชัดว่า prompt แบบไหนที่ทำให้ Claude สัมภาษณ์ได้ดี
"Bad prompting is when you say just make it better. A lot of people that I watch using Claude Code just type 'make it better'. That's not good prompting"
ตามที่ Ara อธิบายในเวิร์กชอป bad prompt คือคำสั่งสั้นๆ แบบ "ทำให้ดีกว่านี้" โดยไม่บอกอะไรเพิ่ม ส่วน good prompt คือการระบุ "domain" ที่สนใจ เช่น audience, scope ของ feature หรือบริบทการใช้งาน แต่ไม่ล็อก outcome ล่วงหน้า เพื่อเปิดทางให้ Claude ใช้ tool ask_user_question สัมภาษณ์ต่อทีละเรื่อง
ในเวิร์กชอป Ara สาธิตด้วยการสร้าง bill-splitting app สำหรับเพื่อน โดยเปิด Claude Code สอง session คู่กัน (mode ปกติกับ fast mode) แล้ววาง prompt ที่อ้างถึง tool ask_user_question ให้ Claude เด้งคำถามมาเลือกผ่าน tab UI เช่น "audience เป็นใคร" และ "มี secondary audience หรือไม่" Ara ตอบทีละ tab ตัดออปชั่นที่ไม่ต้องการออก (no secondary audience) แล้วจึง submit จากนั้น Claude จึงเขียน spec ที่ครอบคลุม โดยผู้ใช้ไม่ต้อง verbalize เองตั้งแต่ต้น Ara เน้นว่าวิธีนี้เหมาะกับ long-running agent ที่ต้องการ spec ครบถ้วนก่อน execute เพราะถ้า spec ผิด agent จะ burn token ระหว่างวิ่งมากตามไปด้วย
อัพเกรดที่ 2: เลิกใช้ markdown ยาว เปลี่ยนไปเป็น HTML spec
อัพเกรดที่สองคือสิ่งที่ Tar เคยเขียนเป็นบล็อกโพสต์ชื่อ "The Unreasonable Effectiveness of HTML Files" ก่อนที่ Ara จะนำมาเล่าต่อในเวิร์กชอปครั้งนี้ เพื่อนร่วมทีมคนหนึ่งของ Ara เคยตั้งฉายาให้ markdown ว่า
"the markdown file is the lingua franca of the AI-native software development life cycle"
Ara ยอมรับว่าคำนี้กินใจ แต่ทีม Claude Code เริ่มย้าย spec/design direction ของระบบไปเป็น HTML file เพราะเมื่อ markdown ยาวเกินจุดหนึ่ง มันเริ่มเป็นภาระมากกว่าประโยชน์ Ara ระบุ threshold ไว้ตรงๆ ว่า
"especially if the markdown files get more than about 200 lines long, it's unlikely you're going to read it and certainly unlikely that your colleagues are going to read them"
ตัวเลข 200 บรรทัด คือเส้นที่ markdown spec เริ่มไม่มีใครอ่านจริง ทั้งตัวเจ้าของ spec เองและเพื่อนร่วมทีม ส่วน HTML รวมข้อมูลได้แน่นกว่าและเปิดดูใน browser ได้ทันที ตามที่ Ara สรุปไว้ว่า
"an HTML file is more dense, much more information dense, much more ergonomic for you to understand what the thing is going to look like"
ข้อดีอีกข้อของ HTML spec คือส่ง screenshot กลับเข้า Claude ได้ตรงๆ โดยเฉพาะงาน frontend ที่ภาษาเขียนอธิบายไม่พอว่า "ตรงนี้เพี้ยนนิดหน่อย" หรือ "alignment ไม่ตรง" เมื่อรวมกับ Opus 4.7 ที่ Anthropic เน้นว่า vision model ดีขึ้นชัดเจน รอบ iterate จึงสั้นลง อีกทั้งยังต่อกับ Playwright MCP ได้ ทำให้ Claude interact กับ HTML file ได้ละเอียดกว่า markdown มาก
Ara สาธิตการใช้งานจริงด้วยการบอก Claude (Opus 4.7) ว่า "give me a few different directions, four different design directions, explore them, generate them as HTML and let me explore them across each other" จากนั้น Claude generate mock-up HTML 4 แบบที่มี aesthetic ต่างกัน ตั้งแต่ brutalist ไปจนถึง Tokyo fintech Ara คลิกเปิดทีละหน้าใน browser เพื่อเทียบ aesthetic แล้วเลือกและ feedback ได้ทันที เร็วกว่าการอ่าน markdown spec แล้วจินตนาการเอาเองหลายเท่า
มีคำถามจากผู้เข้าร่วมเวิร์กชอปว่า HTML spec จะกิน token มากกว่า markdown หรือไม่ Ara ตอบตรงๆ ว่าไม่ พร้อมเหตุผลว่า
"in the long term you iterate less if you have a good and rich HTML spec, even if on one-off instances you spend more tokens to generate it"
หลักคิดคือยอม spend token เพิ่มตอน generate รอบแรก เพื่อแลกกับการ iterate น้อยลงในระยะยาว สุทธิแล้ว token รวมจะน้อยกว่า markdown spec ที่ต้องวนปรับ
อัพเกรดที่ 3: ฝัง verification ลงใน DOM โดยตรง
อัพเกรดที่สามเป็นเนื้อหาที่ Ara ใช้เวลาสาธิตมากที่สุด เพราะเป็นจุดที่เปลี่ยน habit การ test ของทีม Claude Code ไปไกลที่สุด จากเดิมที่ต้องเขียน test แยกแล้วให้ agent ไล่ scrape DOM ทีม Claude Code ออกแบบให้ component publish state ของตัวเองออกไปที่ DOM ผ่าน attribute มาตรฐานชื่อ data-verify-unit พร้อม schemas, fixtures, invariants และ probes ครบใน source code ทำให้ agent อ่าน state ของ app ได้โดยไม่ต้องเดา
Ara สรุปเป้าหมายของ verification framework นี้ในประโยคเดียวว่า
"we want to make it part of the artifact"
verification กลายเป็นส่วนหนึ่งของ artifact ไม่ใช่ test สำรองที่แยกอยู่ ที่สำคัญกว่านั้น Ara อธิบายจุดเปลี่ยนของ DOM contract ไว้ว่า
"the component itself here is publishing its state to the DOM, so this is what the agent can read later as opposed to having to scrape the DOM"
agent ไม่ต้อง scrape DOM แบบเดาๆ อีกต่อไป เพราะ component ประกาศ state ของตัวเองผ่าน data attribute โดยตรง นอกจากนี้ verification framework เดียวกันยังรันได้บน 3 surface ที่ใช้ contract เดียวกัน ครอบคลุมตั้งแต่ debug ด้วยมือไปจนถึง CI
DOM contract ประกอบด้วยอะไรบ้าง
DOM contract ของทีม Claude Code ประกอบด้วย 5 ส่วนหลัก Ara สาธิตผ่าน to-do app เล็กๆ ที่เขียนด้วย React และเพิ่ม/ลบ/clear item ได้ตามปกติ
data-verify-unitคือ attribute ที่ component publish state ของตัวเองออกไปที่ DOM (ใน to-do app คือ total/done/active)- schemas คือโครงสร้างของ state แต่ละ unit เพื่อให้ agent รู้ว่าควรเห็น field อะไรบ้าง
- fixtures คือสถานะที่ "known" ของ component ซึ่ง Ara ใช้ Storybook fixture เป็นแหล่งสถานะตัวอย่าง
- invariants คือเงื่อนไขที่ต้องเป็นจริงตลอดเวลา เช่น total = done + active
- probes คือจุดที่ test push state ออกจาก happy path เพื่อหา edge case
3 surface ของ verification
ทุก surface ใช้ contract เดียวกัน ต่างกันที่ผู้ใช้/ตัวรัน
Surface ที่หนึ่ง: human-readable dashboard เป็นหน้า web ปกติที่ผู้ใช้เปิด localhost เข้ามาเห็น verification step เรียงเป็น manifest กดรันทีละข้อหรือ run all ได้ พร้อมเห็นสถานะผ่าน/ไม่ผ่านและ detail ของ schema, invariant และ probe ที่ใช้ เหมาะสำหรับ debug ด้วยมือและดู contract ทั้งระบบในมุมมองเดียว
Surface ที่สอง: agent-driven จาก browser ผ่าน Playwright MCP ตัว Claude เชื่อม Playwright MCP เข้ากับ browser session เดียวกัน อ่าน DOM ผ่าน data-verify-unit และรัน manifest เดียวกับ dashboard แต่ในมุมของ agent ซึ่งจะวินิจฉัย failure ให้เองได้
Surface ที่สาม: headless bun verify ใน CI เปิด terminal แล้วรัน bun verify ตรงๆ ใน repo จะรัน test matrix ของ verification ทั้งหมดในโหมด headless เหมาะกับ CI/CD pipeline ผลลัพธ์อาจต่างจาก dashboard เพียงเล็กน้อยขึ้นกับ environment ตามที่ Ara ระบุไว้ว่า "the principle is the same"
Demo ที่ Ara วาง bug ไว้ทดสอบ contract
ในเวิร์กชอป Ara วาง bug ไว้สองชั้นเพื่อแสดงพฤติกรรมของ contract ชั้นแรกคือ hardcode invariant ผิดเป็น "3 + 4 = 10" ทั้ง human dashboard และ Claude (รันผ่าน Playwright MCP) จับ failure เดียวกันได้ Claude ที่เชื่อม MCP ตอบกลับว่า "scope got rejected, 4 + 3 does not equal 10" และเสริมว่าถ้ารัน bun verify ใน test matrix ปกติจะผ่าน เพราะ verification ตัวที่วางผิดอยู่นอก test suite จริง
ชั้นที่สอง Ara ตั้งใจลบ key ใน component ทำให้ contract พังทั้งที่ app ยังรันได้ปกติ ผลคือ verification step ทุกข้อที่ depend on key นั้น fail ทันที ยืนยันได้ว่า contract failure แยกจาก app failure ชัดเจน และเป็นเหตุผลที่ทำให้ verification framework นี้ valuable กว่าการเขียน test ที่อิง DOM โดยตรง
นอกจากนี้ Ara ยังเปิดเผยว่าทีม Claude Code มี internal automation ที่บันทึก verification step เป็น video clip เก็บใน S3 หรือแชร์กับเพื่อนร่วมทีม
"the Claude Code team records basically all the code changes that they do like this, all the front end changes at least, especially around the pace of the shipping that we have at the moment"
ทุก code change ของทีม (อย่างน้อยฝั่ง frontend) ผ่าน verification framework นี้ และทีมบันทึกไว้เป็นหลักฐานเชิง audit ในจังหวะ shipping ที่เร็วของ Anthropic ปัจจุบัน อย่างไรก็ดี Ara ยอมรับว่าไม่แน่ใจระยะเวลาเก็บที่แน่ชัด ("not certain for how long or in what context") จึงไม่ขอระบุว่าเป็น "นโยบายบริษัทอย่างเป็นทางการ"
Runtime configuration ที่ Ara แนะนำ
นอกจาก 3 อัพเกรดด้านบนแล้ว Ara เน้นย้ำค่า runtime ที่ทีม Anthropic แนะนำให้ตั้งก่อนเริ่ม session ของ Claude Code ทุกครั้ง
| ค่า | คำสั่ง/วิธีตั้ง | เหตุผลที่ Ara แนะนำ |
|---|---|---|
| auto mode | Shift + Tab cycle | "auto mode is the best, if you're not using auto mode, you need to be using auto mode. It makes it so much easier" |
| fast mode | /fast | iterate spec รอบสั้นได้เร็ว "costs more, but it's great for iterating quickly on specs" |
| effort | /effort ตั้งเป็น xhigh หรือ max | recommendation ของทีมคือ xhigh เป็น default และ Ara เองก็ใช้ xhigh ในเวิร์กชอปครั้งนี้ |
| model | Opus 4.7 | "Opus 4.7 works really well because it has a better vision model, that's where this really excels. If you use Sonnet, I wouldn't recommend that" |
vision model ของ Opus 4.7 เป็นเหตุผลหลักที่ Ara แนะนำให้ใช้รุ่นนี้ในการทำงานสไตล์ HTML spec + screenshot loop เพราะ Sonnet จะตามไม่ทันงาน frontend ที่ต้องอ่านภาพหน้าจอแบบรอบสั้น
เอาไปใช้กับ stack ที่มีอยู่ได้ตั้งแต่วันนี้
เนื้อหาทั้งหมดในเวิร์กชอป "How we Claude Code" มีจุดร่วมคือ "อย่ายัด rule ใส่โมเดล ปล่อยให้ artifact พูดกับ agent ได้โดยตรง" ซึ่งสามารถเริ่มจาก 3 จุดเล็กๆ ในโปรเจ็กต์ที่มีอยู่ได้ทันที โดยไม่ต้อง rebuild ระบบทั้งหมด
จุดแรก เลิกเขียน spec markdown ยาวเกิน 200 บรรทัด ลองให้ Claude generate HTML spec ออกมา 2-3 ทางก่อนลงมือ implement เปิดเทียบกันใน browser แล้วเลือก direction ที่ใช่ก่อน
จุดที่สอง เลิก write-once spec แบบส่ง prompt ยาวหน้าเดียวแล้วรอผล เปลี่ยนเป็น prompt ที่อ้างถึง tool ask_user_question ระบุ domain ที่สนใจแต่ไม่ล็อก outcome ปล่อยให้ Claude สัมภาษณ์ requirements กลับมาก่อนเริ่มเขียน code
จุดที่สาม เริ่มจาก component สำคัญของแอป เติม attribute data-verify-unit พร้อม schema + invariant ลงไป แล้วให้ Claude (ผ่าน Playwright MCP) verify component นั้นได้เองโดยไม่ต้องเขียน test เพิ่ม แค่นี้ก็พอเริ่ม pattern แบบที่ทีม Claude Code ใช้ได้แล้ว
ตามที่ Ara สรุปไว้ในจังหวะปิดเวิร์กชอป
"what's new really is the remixing and the new arrangement of primitives that you're already familiar with, that you're already using, just to make it available to the agent first"
primitive ทั้งหมดที่ทีม Claude Code ใช้ ไม่ว่าจะเป็น DOM attribute, Storybook fixture, Playwright MCP หรือ HTML file ล้วนเป็นของที่ developer ส่วนใหญ่คุ้นเคยอยู่แล้ว สิ่งใหม่คือการ remix ของเหล่านี้ให้ agent อ่านและรันได้ก่อน แล้วค่อยให้คนอ่าน
Tip: repo workshop ของ Anthropic เปิดให้คนนอกเข้าไปดูได้ภายใต้ชื่อ CWC workshops (Coding with Claude workshops) ตามที่ Ara ระบุไว้ในเวิร์กชอปเอง
Anthropic แทบไม่เคยเปิด workflow ภายในของทีม Claude Code ให้คนนอกตามดู โดยเฉพาะช่วงที่ Opus 4.7 ออกเป็น default model พร้อม vision capability ที่ดีขึ้น เวิร์กชอป "How we Claude Code" จึงเป็นบทเรียนหายากที่ developer ไทยที่ใช้ Claude Code อยู่แล้วน่าจะนำไปปรับ habit การทำงานต่อได้
ดูเวิร์กชอปฉบับเต็มของ Anthropic ได้ที่ How we Claude Code (Claude YouTube channel)
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกที่แสดงความเห็น!