Anthropic จัดเวิร์กชอป "How we Claude Code" ความยาว 31 นาทีบน YouTube โดยมี Ara สถาปนิกจากทีม Applied AI ของ Anthropic มาถ่ายทอดแนวทางการใช้งาน Claude Code ภายในองค์กร เนื้อหาต่อยอดจากการบรรยายของ Tar หนึ่งในทีมพัฒนา Claude Code ที่ซานฟรานซิสโก และบทความ "The Unreasonable Effectiveness of HTML Files" นี่จึงเป็นโอกาสพิเศษที่เราได้เห็น Workflow จริงของทีมผู้สร้าง Claude Code โดยเฉพาะในจังหวะที่ Opus 4.7 ก้าวขึ้นมาเป็นโมเดลหลัก

บทความนี้สรุป 3 แนวทางสำคัญที่ทีมวิศวกรของ Anthropic ปรับใช้ในการทำงานจริง เพื่อให้นักพัฒนาไทยนำไปปรับจังหวะการทำงานร่วมกับ AI Agent ได้ทันที

ทำไมทีม Anthropic ถึงต้องเปลี่ยน habit การทำงาน

Ara เริ่มต้นด้วยการชี้ให้เห็นว่า AI Agent เก่งขึ้นเรื่อยๆ ตามความสามารถของโมเดลเบื้องหลัง เมื่อโมเดลฉลาดขึ้น Agent ก็สามารถรับงานที่ซับซ้อนและรันได้ยาวนานขึ้น แต่ปัญหาที่ตามมาคือ ถ้าเรากำหนดทิศทางผิดตั้งแต่ต้น Agent จะผลาญ Token ระหว่างทางไปอย่างมหาศาล ทีม Anthropic จึงเลือกที่จะให้ความสำคัญกับการตรวจสอบความต้องการ (Verification) ตั้งแต่ขั้นตอนการทำ Spec ก่อนปล่อยให้ Agent เริ่มลงมือเขียนโค้ด

หลักคิดเบื้องหลังทั้งหมดอิงจาก The Bitter Lesson ของ Richard Sutton บิดาแห่งวงการ Reinforcement Learning ที่กล่าวไว้ว่า ในระยะยาว ระบบ AI ที่ขับเคลื่อนด้วย Compute และข้อมูลมหาศาลจะเหนือกว่าระบบที่มนุษย์พยายามเขียนกฎ (Rules) บังคับขึ้นมาเสมอ Ara จึงสรุปเป็นคำแนะนำง่ายๆ ว่า:

"the more capable the models get, the more you should try to resist constraining them"

ความหมายคือ ยิ่งโมเดลฉลาดขึ้นเท่าไร เรายิ่งควรลดการตีกรอบหรือเขียนกฎตายตัวลง แล้วเปลี่ยนมาใช้ 3 เทคนิคที่ทีม Claude Code ใช้งานจริงในปัจจุบัน

อัพเกรดที่ 1: เลิกเขียน spec ยาว ปล่อยให้ Claude สัมภาษณ์ requirements

เทคนิคแรกคือการหยุดเขียนเอกสาร Spec ยาวเหยียดส่งให้โมเดลตั้งแต่เริ่มเซสชัน แล้วเปลี่ยนมาใช้ Prompt ที่กระตุ้นให้ Claude เรียกใช้ Tool ชื่อ ask_user_question เพื่อสัมภาษณ์ความต้องการจากเราทีละข้อ จากนั้นค่อยให้ Claude นำคำตอบไปร่าง Spec จริง

เหตุผลที่ทีม Anthropic ปรับมาใช้วิธีนี้ Ara อธิบายไว้อย่างน่าสนใจว่า:

"the model is probably better at extracting requirements from you than you are at defining your requirements"

และขยายความเพิ่มเติมว่า:

"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"

ความต้องการส่วนใหญ่มักเป็นลักษณะ "เห็นแล้วถึงจะรู้ว่าใช่" ซึ่งคล้ายกับเวลาที่ Designer หรือ Product Manager พูดคุยกับลูกค้า การให้ Claude รุ่นใหม่สัมภาษณ์เจาะลึกทีละประเด็น จะช่วยดึงความต้องการที่แท้จริงออกมาได้ครบถ้วนกว่าการที่เราพยายามนั่งเขียนบรรยายให้ครบทุกมิติตั้งแต่แรก

Ara ยังชี้ความแตกต่างระหว่าง Prompt ที่ดีและไม่ดีไว้ด้วย:

"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"

Bad Prompt คือคำสั่งกว้างๆ ที่ไม่มีทิศทาง เช่น "ทำให้ดีขึ้นหน่อย" ส่วน Good Prompt คือการระบุขอบเขต (Domain) ที่ต้องการ เช่น กลุ่มผู้ใช้งาน (Audience), ขอบเขตของฟีเจอร์ หรือบริบทการนำไปใช้ โดยไม่ไปล็อกผลลัพธ์ล่วงหน้า เพื่อเปิดโอกาสให้ Claude เรียกใช้ ask_user_question มาถามเจาะลึกทีละจุด

ในการสาธิต Ara ลองสร้างแอปหารค่าใช้จ่ายกับเพื่อน โดยเปิด Claude Code สองเซสชันควบคู่กัน แล้วส่ง Prompt ที่ระบุให้ถามคำถามผ่าน UI ระบบจะแสดงตัวเลือกขึ้นมาให้คลิกตอบ เช่น "กลุ่มผู้ใช้งานหลักคือใคร" หรือ "มีกลุ่มผู้ใช้งานรองหรือไม่" เมื่อตอบครบ Claude จึงสรุปเป็น Spec ที่ชัดเจนและครอบคลุม ช่วยลดโอกาสที่ Agent จะหลุดโฟกัสตอนรันงานยาว

อัพเกรดที่ 2: เลิกใช้ markdown ยาว เปลี่ยนไปเป็น HTML spec

เทคนิคที่สองต่อยอดมาจากบทความ "The Unreasonable Effectiveness of HTML Files" ของ Tar แม้หลายคนจะมองว่าไฟล์ Markdown เป็นภาษากลางของการพัฒนาซอฟต์แวร์ยุค AI แต่เมื่อ Markdown ยาวเกินจุดหนึ่ง มันจะกลายเป็นภาระในการอ่าน Ara กำหนดเส้นแบ่งไว้ว่า:

"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"

เมื่อ Markdown ยาวเกิน 200 บรรทัด แทบจะไม่มีใครเปิดอ่านอย่างละเอียด ทีมพัฒนาจึงหันมาใช้ ไฟล์ HTML ในการกำหนด Spec และทิศทางการออกแบบแทน เพราะรวบรวมข้อมูลได้กระชับและเปิดดูในเบราว์เซอร์ได้ทันที

"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 คือความสามารถในการทำงานร่วมกับโมเดล Vision ของ Opus 4.7 เราสามารถจับภาพหน้าจอ (Screenshot) ผลลัพธ์ส่งกลับไปให้ Claude ปรับแต่งได้ตรงจุด เช่น การจัดตำแหน่งปุ่ม หรือโทนสีของหน้าเว็บ ซึ่งการสื่อสารด้วยภาพผ่านเบราว์เซอร์ทำได้รวดเร็วกว่าการนั่งอธิบายด้วยตัวอักษรบน Markdown หลายเท่า ยิ่งเมื่อต่อเข้ากับ Playwright MCP ตัว Claude ก็จะสามารถเข้าไปมีปฏิสัมพันธ์กับองค์ประกอบต่างๆ บนหน้าเว็บได้โดยตรง

เมื่อมีคำถามว่า 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"

แม้การสร้าง HTML รอบแรกจะใช้ Token มากกว่า แต่การได้เห็นภาพชัดเจนตั้งแต่เริ่มช่วยลดรอบการปรับแก้ (Iteration) ลงได้มาก เมื่อคิดต้นทุนรวมแล้วจึงประหยัดกว่าการวนแก้บน Markdown Spec

อัพเกรดที่ 3: ฝัง verification ลงใน DOM โดยตรง

เทคนิคที่สามเป็นหัวใจสำคัญของการปรับกระบวนการทดสอบ จากเดิมที่ต้องเขียน Test แยกต่างหากแล้วปล่อยให้ Agent พยายามขูดข้อมูล (Scrape) จากหน้าเว็บ ทีม Claude Code ปรับสถาปัตยกรรมให้ Component ประกาศสถานะ (State) ของตัวเองออกมาทาง DOM โดยตรงผ่าน Custom Attribute ชื่อ data-verify-unit พร้อมกำหนด Schemas, Fixtures, Invariants และ Probes ฝังไว้ในโค้ด ทำให้ Agent ตรวจสอบสถานะของแอปได้อย่างแม่นยำ

Ara สรุปเป้าหมายสั้นๆ ไว้ว่า:

"we want to make it part of the artifact"

การตรวจสอบกลายเป็นส่วนหนึ่งของระบบ ไม่ใช่ชุดทดสอบภายนอกที่แยกขาด:

"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"

องค์ประกอบของ DOM Contract

DOM Contract ของทีม Claude Code ประกอบด้วย 5 ส่วนสำคัญ:

• data-verify-unit: Attribute ที่ Component ใช้ส่งสถานะของตัวเองออกมาที่ DOM (เช่น จำนวนรายการทั้งหมด, ทำเสร็จแล้ว, กำลังทำ)
• Schemas: โครงสร้างข้อมูลที่กำหนดว่าสถานะแต่ละตัวควรมี Field อะไรบ้าง
• Fixtures: สถานะเริ่มต้นที่เตรียมไว้สำหรับทดสอบ (เช่น Storybook Fixtures)
• Invariants: เงื่อนไขทางตรรกะที่ต้องเป็นจริงเสมอ เช่น จำนวนรวมต้องเท่ากับรายการที่เสร็จแล้วบวกกับรายการที่ค้างอยู่
• Probes: จุดทดสอบที่จงใจส่งข้อมูลผิดปกติเข้าไปเพื่อตรวจหาขอบเขตข้อผิดพลาด (Edge Cases)

3 ระดับการใช้งาน Verification

Contract เดียวกันนี้สามารถนำไปตรวจสอบได้ใน 3 รูปแบบ:

1. Human-readable Dashboard: หน้าเว็บที่เปิดผ่าน Localhost เพื่อดูสถานะการทำงานของแต่ละ Step กดทดสอบทีละข้อหรือรันทั้งหมดได้ เหมาะสำหรับการตรวจสอบด้วยตนเอง
2. Agent-driven ผ่าน Playwright MCP: Claude เชื่อมต่อกับเบราว์เซอร์ผ่าน Playwright MCP เพื่ออ่านค่าจาก data-verify-unit และวินิจฉัยปัญหาเมื่อการทดสอบไม่ผ่าน
3. Headless bun verify ใน CI: รันคำสั่งทดสอบผ่าน Terminal โดยตรงในกระบวนการ CI/CD Pipeline

Ara สาธิตให้เห็นว่า หากระบบมีบั๊ก เช่น ตรรกะของ Invariant ไม่ถูกต้อง ตัว Dashboard และ Claude จะสามารถชี้จุดผิดพลาดได้ตรงกันทันที และหากมีการลบ Key สำคัญใน Component การทดสอบในส่วนที่เกี่ยวข้องก็จะแจ้งเตือนข้อผิดพลาดทันที ทำให้แยกปัญหาของ Contract ออกจากปัญหาของตัวแอปได้อย่างชัดเจน

นอกจากนี้ ทีมพัฒนายังมีระบบบันทึกคลิปวิดีโอของการทดสอบเก็บไว้ เพื่อใช้เป็นหลักฐานและอำนวยความสะดวกในการตรวจสอบย้อนหลังร่วมกับเพื่อนร่วมทีม

Runtime configuration ที่ Ara แนะนำ

Ara แนะนำการตั้งค่า Runtime สำหรับการใช้งาน Claude Code ดังนี้:

นำไปปรับใช้กับการทำงานจริง

บทเรียนจากเวิร์กชอป "How we Claude Code" มุ่งเน้นการเปลี่ยนจากการเขียนกฎตายตัว มาเป็นการเปิดโอกาสให้ AI สื่อสารกับระบบและชิ้นงานได้โดยตรง เราสามารถเริ่มปรับใช้ 3 จุดนี้ได้ทันที:

1. เปลี่ยน Spec ยาวเป็น HTML: สำหรับงานที่มีรายละเอียดซับซ้อน ลองให้ Claude ร่างทางเลือกเป็น HTML Spec สัก 2 ถึง 3 แบบ แล้วเปิดดูผ่านเบราว์เซอร์จริงเพื่อเลือกทิศทางที่ต้องการ
2. ใช้การสัมภาษณ์ความต้องการ: แทนที่จะพิมพ์บรีฟยาวหน้าเดียว ให้ระบุขอบเขตของงานแล้วเปิดทางให้ Claude เรียก Tool สัมภาษณ์ความต้องการกลับมาทีละจุด
3. กำหนด DOM Contract ให้ชัดเจน: เติม Attribute เช่น data-verify-unit ลงใน Component สำคัญ เพื่อให้ AI Agent สามารถเข้าถึงและตรวจสอบสถานะของแอปได้โดยตรงผ่าน Playwright

เวิร์กชอปนี้สะท้อนว่า เครื่องมือต่างๆ ไม่ว่าจะเป็น DOM Attribute, Storybook Fixtures, Playwright MCP หรือไฟล์ HTML ล้วนเป็นสิ่งที่เราคุ้นเคยอยู่แล้ว สิ่งสำคัญคือการนำเครื่องมือเหล่านี้มาจัดวางใหม่ เพื่อให้ AI Agent เข้ามาอ่าน ทำงาน และตรวจสอบความถูกต้องได้อย่างเป็นระบบ

รับชมเวิร์กชอปฉบับเต็มได้ที่ How we Claude Code (Claude YouTube channel)