ในรายการ How I AI ที่ดำเนินรายการโดย Claire Vo มีบทสนทนาน่าสนใจกับ Thariq Shihipar วิศวกรทีม Claude Code จาก Anthropic ในงาน Code with Claude เขาเปิดประเด็นชวนคิดว่า "HTML is the new Markdown" หรือ HTML กำลังกลายเป็นสื่อกลางมาตรฐานใหม่ในการทำงานร่วมกับ AI agent แทนที่ Markdown

เหตุผลเบื้องหลังเรื่องนี้เรียบง่ายมาก ในยุคที่โมเดลอย่าง Opus 4 หรือ Claude 3.5 ยังรันงานสั้นๆ ไฟล์ plan แบบ Markdown ยาวสัก 50 บรรทัด คนยังพอเปิดอ่านและตรวจทานไหว แต่พอเป็น agent ยุคใหม่อย่าง Opus 4.5 หรือ 4.7 ที่รันงานต่อเนื่องข้ามชั่วโมง ไฟล์ plan กลับบวมขึ้นจนยาวหลายพันบรรทัด Thariq ยอมรับตรงๆ ว่าตัวเขาเองยังเลิกอ่านไปแล้ว ซึ่งนั่นกลายเป็นปัญหาใหญ่ เพราะเมื่อมนุษย์หลุดออกจากลูป ไม่รู้ว่า agent กำลังทำอะไรอยู่จริงๆ คุณภาพงานโดยรวมก็ร่วงลงมาทันที

ทีม Claude Code จึงแก้เกมด้วยการเปลี่ยนวิธีเขียน plan และ spec ทั้งหมดมาเป็นไฟล์ HTML ที่ทั้งอ่านสบายตา จัดโครงสร้าง visual ได้ดี และเปิดโต้ตอบได้จริง

1. เมื่อ agent ทำงานยาวขึ้น ทำไม Markdown ถึงเอาไม่อยู่

Thariq ชี้ให้เห็นว่าปัญหาไม่ได้อยู่ที่ฝั่งโมเดล เพราะ AI อ่านโค้ดหรือข้อความดิบได้สบายอยู่แล้ว แต่ปัญหาตกอยู่ที่มนุษย์ล้วนๆ พอเจอ plan ยาวเป็นพันบรรทัด คนเรามักจะกวาดสายตาผ่านๆ แล้วแอบหวังในใจว่าเดี๋ยวมันก็คงออกมาดีเอง ทำให้ผลลัพธ์ปลายทางหลุดกรอบได้ง่าย

เขาเลยตั้งกฎส่วนตัวไว้ข้อหนึ่งว่า จะไม่อ่าน output จาก Claude Code ที่ยาวเกินหนึ่งหน้าจอเด็ดขาด เพราะถ้า agent พ่นไอเดีย 8 ข้อออกมาเป็นบล็อกข้อความยาวพืด สุดท้ายคนก็ไม่มีทางเก็บรายละเอียดได้ครบทุกข้อ

จุดแข็งสำคัญของ HTML คือการเป็นสื่อกลางที่อุดมไปด้วยข้อมูล (information rich) ระหว่างคนกับโมเดล ไฟล์ HTML เปิด scroll ดูง่าย จัดลำดับสายตาได้ชัดเจน และเวลาที่ agent ต้องการอธิบายหน้าตาของฟีเจอร์ ก็สามารถวาด mockup ให้เห็นภาพจริงได้ทันที แทนที่จะต้องมาทนดู ASCII diagram แข็งทื่อใน terminal

ฝั่ง Claude เองก็เขียนโค้ด HTML ได้เก่งมากและรับ context ไปต่อยอดได้แม่นยำ การยอมจ่าย token เพิ่มอีกนิดเพื่อให้ได้ HTML จึงเป็นการลงทุนที่คุ้มค่า เพราะช่วยดึงให้คนกลับมามีส่วนร่วมและตรวจทาน spec ได้ละเอียดขึ้นอย่างเห็นได้ชัด Claire Vo สรุปประเด็นนี้ไว้ว่า HTML ไม่ได้ทำให้ agent ทำงานง่ายขึ้นหรือยากขึ้น แต่มันช่วยให้คนกลับเข้ามาคุม spec ได้มีประสิทธิภาพมากขึ้นต่างหาก

2. เมื่อคนเปลี่ยนบทบาทเป็น "Compute Allocator" การเขียน Spec ยิ่งสำคัญกว่าเดิม

หลายคนอาจสงสัยว่า ในเมื่อโมเดลฉลาดขึ้นเรื่อยๆ เอกสารอย่าง PRD, spec หรือ plan ยังจำเป็นอยู่จริงไหม? Thariq ยืนยันหนักแน่นว่า จำเป็น 100% และจะสำคัญตลอดไป

เขาอธิบายด้วยมุมมองเรื่องต้นทุนจริงว่า เมื่อ Claude รันงานติดต่อกัน 8 ชั่วโมง นั่นหมายถึงค่า compute ราว 500 ดอลลาร์ ดังนั้นทุกคนในยุค AI จึงต้องผันตัวมารับบทเป็น "Compute Allocator" หรือผู้จัดสรรทรัพยากรประมวลผล หน้าที่หลักของมนุษย์ไม่ได้อยู่ที่การพิมพ์โค้ดเองทุกบรรทัด แต่อยู่ที่การตัดสินใจอย่างแม่นยำว่างานชิ้นไหนคุ้มค่าที่จะปล่อยให้ AI ไปรัน และการตัดสินใจทั้งหมดนี้เกิดขึ้นในขั้นตอนการวาง spec และ planning

Claire Vo เสริมประเด็นนี้ว่า งาน product management ไม่ได้หายไปไหน เพียงแต่เปลี่ยนรูปมาเป็นการเขียนเอกสารและวางกรอบ เพื่อสั่งการให้ระบบประมวลผลทำงานออกมาได้ตรงเป้าที่สุด Thariq ยังแนะนำด้วยว่า หัวใจสำคัญคือการ "เข้าจังหวะ" คุยกับ Claude เพื่อค่อยๆ ขุดหา unknown unknowns หรือสิ่งที่เราอาจจะยังนึกไม่ถึงออกมาให้ครบก่อนเริ่มลงมือจริง

3. เจาะ Workflow จริง: จาก Brainstorm สู่ Plan ในรูปแบบ HTML

Thariq สาธิตกระบวนการทำงานจริงที่เริ่มต้นจากการคุยกับ Claude เหมือนเพื่อนร่วมทีม โดย prompt ที่ใช้สั้นกระชับและตรงไปตรงมามาก:

1. Brainstorm ใน HTML: บอก Claude ว่ากำลังเตรียมตัวไปออกรายการ demo และอยาก brainstorm ไอเดียลงไฟล์ HTML ผลลัพธ์ที่ได้คือหน้ารวม 8 visual demo พร้อม mockup เล็กๆ ให้เห็นภาพชัดเจน เช่น การแปลงภาพสเก็ตช์บนไวท์บอร์ดเป็น UI หรือการแปลงไฟล์ CSV เป็น interactive dashboard ซึ่งช่วยให้เขาไล่ดูครบทุกไอเดียได้ง่ายกว่าข้อความยาวๆ ใน terminal
2. ขุด Unknown Unknowns: ให้ Claude ตั้งคำถามสัมภาษณ์เขาเกี่ยวกับไอเดียที่เลือก เพื่อเจาะลึกความต้องการและดึงจุดที่อาจมองข้ามออกมาทำ spec
3. สร้าง Plan เป็น HTML: สั่งให้ Claude ประกอบร่างแผนการพัฒนาออกมาเป็นไฟล์ HTML โดยระบุให้ใส่โค้ดตัวอย่าง mockup และ logic สำคัญเท่าที่จำเป็น เพื่อให้ได้ context ครบถ้วนที่สุด

ผลลัพธ์คือเอกสาร HTML ที่มีครบทั้งโครงสร้างโปรเจกต์ ตัวอย่าง logic, คอมโพเนนต์ และ mood board ซึ่งคนสามารถเปิดอ่านและตรวจทานได้อย่างสบายใจ

Claire Vo เน้นย้ำว่า prompt ที่ดีไม่จำเป็นต้องซับซ้อนหรือจำกัดกรอบ AI แน่นหนาจนเกินไป (over-constrain) แค่บอกความต้องการให้ชัด และลงท้ายด้วยการเปิดพื้นที่ให้โมเดลตัดสินใจเลือก context ที่จำเป็นด้วยตัวเอง

4. Micro Software: สร้าง UI เฉพาะกิจเพื่อแก้ Spec รายโมดูล

อีกหนึ่งเทคนิคที่น่าสนใจมากคือ Micro Software หรือการสร้างเครื่องมือชั่วคราวขึ้นมาแก้ปัญหาเฉพาะจุด

ในเคสตัวอย่าง ไฟล์ plan แบบ HTML มีตารางกำหนดกฎการแสดงผล (visualization rules) ตามประเภทข้อมูลใน CSV อยู่ แต่ Thariq ไม่ค่อยถูกใจกฎชุดนี้นัก แทนที่จะต้องพิมพ์สั่งแก้ไปมาใน terminal เขากลับสั่งให้ Claude เขียน HTML Artifact ที่เป็น UI โต้ตอบได้ ขึ้นมาทันที

UI ตัวนี้ถูกออกแบบมาเพื่อแก้ปัญหานี้โดยเฉพาะ มีฟังก์ชันให้คลิกแก้ field, ซ่อน, ทำซ้ำ หรือเพิ่มกฎใหม่ได้ตามใจชอบ พร้อมปุ่มกดคัดลอก output กลับออกมาเป็น Markdown เพื่อนำไปใช้งานต่อ

Claire Vo มองว่านี่คือการยกระดับ personal software ขึ้นไปอีกขั้น ด้วยการสร้าง UI ใช้แล้วทิ้งขึ้นมาปรับแต่ง spec เฉพาะส่วนอย่างละเอียด ช่วยให้คนเข้าไปคุมงานได้แม่นยำโดยไม่ต้องเปลืองแรง

Thariq เสริมว่า โค้ดที่เขา generate ออกมาแล้วกลายเป็น production code จริงๆ อาจมีเพียง 1% เท่านั้น แต่ token ส่วนใหญ่ถูกใช้ไปกับการสร้าง dashboard และ interface ชั่วคราวเหล่านี้ เพื่อช่วยให้มนุษย์ตกผลึกความคิดและมองเห็นภาพตรงกัน นอกจากนี้ไฟล์ HTML ยังนำไปใช้กับ verification agent เพื่อตรวจทานว่างานที่ AI สร้างตรงกับ spec หรือไม่ โดยยึด type interface และ test criteria เป็นหมุดหมายสำคัญ

5. Living Design System และการส่งต่องานข้ามทีม

อีกหนึ่ง use case ที่น่าประทับใจคือ Living Design System ที่รวมค่าสี, typography, spacing, radius ตลอดจน core component ต่างๆ ไว้ในไฟล์ HTML ไฟล์เดียว

เวลาจะเริ่มโปรเจกต์ใหม่ แค่สั่งให้ Claude อ่านโฟลเดอร์แล้วดึง design system ออกมาเป็น HTML artifact ก็สามารถส่งต่อ context ไปยังโปรเจกต์อื่นได้ทันที Thariq ถึงกับเปรียบเปรยว่า "design.md ตายไปแล้ว design.html เข้ามาแทนที่" ขณะที่ Claire Vo ต่อยอดด้วยการทำหน้ารวมคอมโพเนนต์ที่กดเล่นได้จริง เพื่อให้ทีมการตลาดสามารถก๊อปปี้ visual ที่เหมือนจริงไปใช้ในงานนำเสนอหรือภาพโปรโมทได้สะดวก

ต้นทุนในการสร้างและค้นหาเอกสารในยุคนี้แทบจะลดลงเหลือศูนย์ เราจึงไม่จำเป็นต้องยึดติดกับเอกสารแบบรวมศูนย์ชุดเดียว (single source of truth) ที่ใช้ฟอร์แมตเดิมเสมอไป เพราะ AI สามารถค้นหา context ที่ต้องการได้เองตามจังหวะเวลา (Just In Time Documentation)

ยิ่งไปกว่านั้น การแชร์เอกสาร spec แบบ HTML ขึ้น cloud ยังช่วยให้ทีมเปิดอ่านและทำความเข้าใจร่วมกันได้ง่ายขึ้นมาก เหมือนกับที่ทีม Stripe สร้างแพลตฟอร์ม vibe coding ภายในองค์กรขึ้นมาในรูปแบบ HTML เพื่อใช้อนุมัติและรีวิว spec ได้อย่างราบรื่น