ผมไปอ่านบทความของ Jaroslaw Wasowski เรื่อง How to write specs for AI แล้วรู้สึกว่าตรงกับสิ่งที่ผมทำอยู่ แต่ก็มีบางข้อน่าสนใจที่ผมต้องปรับเพิ่ม โดยเขาพูดตรงๆ ว่า หลายครั้งปัญหาไม่ได้อยู่ที่ model อย่างเดียว แต่อยู่ที่ spec ที่เราเขียนให้มันต่างหาก

เพราะ AI ไม่ได้อ่านใจเราออก ดังนั้นถ้าเราเขียน requirement แบบคลุมเครือ มันก็ไม่ได้หยุดแล้วถามเหมือน senior developer ที่นั่งข้างๆ แต่มันจะเดาต่อจาก pattern ที่มันเคยเห็นมาใน training data แล้วบางทีเดาได้เนียนมาก เนียนจนสรุปออกมา หรือ code ดูเหมือนจะถูกต้อง แต่การใช้งานผิด (เป็นเหตุผลว่าผมต้องมี skill ให้มันตั้งคำถามผมไปเรื่อยๆ นอกจากช่วยคิดแล้ว ผมใช้เพื่อคอยเช็กความเข้าใจของมัน)

หมายเหตุ: บทความนี้อ้างอิงจากประสบการณ์ฟิวส์กับเอเจ้นชมพู เพื่อเรียบเรียงและแปลจากต้นฉบับของ Jaroslaw Wasowski เรื่อง How to write specs for AI: 7 rules and a checklist for better code

ปัญหาไม่ใช่แค่ AI เขียนโค้ดผิด แต่คือมันไม่รู้ว่าอะไรห้ามเดา

ตั้งแต่ปีก่อนที่ vibe code มาใหม่ๆ จนถึงปัจจุบัน เรามักใส่ความต้องการของเราว่าอยากได้อะไร แต่ไม่ได้ใส่ว่ามันห้ามทำอะไร

ซึ่งประโยคที่ผมชอบที่สุดในบทความนี้คือ AI ไม่มีสถานะว่า “อันนี้ไม่แน่ใจ ขอถามเพิ่มก่อน” เวลา requirement ขาดอะไรไป มันจะไม่หยุด และมันจะเติมเอง

สิ่งที่ไม่อยู่ spec เราในตอนแรก แต่จู่ๆ มันก็โผล่มา เพราะ AI จะเอา pattern จาก training data มาเติมแทนเจตนาของเรา (ซึ่งอาจจะผิด)

นี่แหละครับที่น่ากลัว เพราะ code ที่ออกมาอาจ compile ผ่าน, test ผ่าน หน้าตาดูดี แต่จริงๆ มันกำลังทำระบบที่มีการใช้งานหรือ behavior คนละแบบกับที่เราต้องการ

เหมือนเราจ้างช่างมาทำบ้าน แล้วบอกแค่ว่า “ทำครัวให้ดีๆ หน่อย” ถ้าช่างทำครัวสวยมาก แต่ไม่มีปลั๊ก ไม่มีที่วางเตา หรือเปิดประตูตู้แล้วชนผนัง ปัญหาไม่ได้อยู่ที่ช่างไม่ขยันอย่างเดียว แต่อยู่ที่แบบบ้านของเราก็ไม่ได้บอกอะไรเขาเลย (อยากได้ครัวฝรั่งเตาไฟฟ้า แต่เอไอตั้งเตาอั่งโล่มาให้เพราะสเปกบอกว่ามีเตา 555)

Spec ที่ดีต้องปิด 5 เรื่อง ที่ AI ชอบเดาเอง

บทความนี้สรุป 5 เรื่องหลักๆ ซึ่งผมว่าตรงนี้เอาไปใช้กับ Jira ticket, GitHub/GitLab issue, Markdown spec หรือ prompt ตรงๆ ได้เลย

1. Outcome ต้องชัดว่าอยากได้พฤติกรรมอะไร

เริ่มจากบอกผลลัพธ์ที่ต้องการ ไม่ใช่บอกให้มันไปเขียน code แบบกว้างๆ เช่น แทนที่จะบอกว่า “ทำ endpoint export users เป็น CSV” ให้บอกว่า “endpoint นี้ต้องคืน active users เป็นไฟล์ CSV ที่ download ได้” และต้องมีเงื่อนไขความสำเร็จอะไรบ้าง (ภาษาเทคนิคจะเรียกว่า Acceptance Criteria)

จุดนี้ช่วยแยก what ออกจาก how ได้ดีมาก เพราะ AI จะได้ไม่รีบเลือก implementation pattern ที่มันคุ้น แต่เริ่มจาก behavior ที่เราต้องการก่อน

2. Scope กับ non-goals ต้องเขียนคู่กัน

อันนี้ผมว่าเป็นจุดที่หลายคนพลาด รวมถึงผมเองก็เคยและก็ยังพลาดบ่อย เราชอบเขียนว่า change นี้ต้องทำอะไร แต่ไม่ค่อยเขียนว่า change นี้ไม่ต้องทำอะไร

เช่น ถ้าให้ AI ทำ export users ก็ควรบอกไปเลยว่า export เฉพาะ active users เท่านั้น ไม่ export deleted accounts ไม่ export billing data และไม่แก้ database schema

เพราะถ้าไม่บอก มันอาจ “ใจดี” เพิ่ม feature ให้เอง ซึ่งฟังดูดี แต่ทำให้ diff บวม และบางทีไปแตะของที่ไม่ควรแตะ

จากประสบการณ์ผมเองที่สังเกต โมเดลฉลาดๆ อย่าง Claude Opus 4.8+ / ChatGPT 5.5+ มักจะบอกเลยว่า ผมจะทำสิ่งนี้ แต่ไม่ทำสิ่งนี้เพราะจะกระทบอะไรก็ว่าไป ซึ่งมันไม่เป็นกับบางโมเดลอื่นๆ ตรงนี้เราโดนพวก Frontier Model สปอยจนมองข้ามไป ฮ่าๆ

3. Constraints คือรั้วกัน AI หลุดโลก

AI ไม่ได้รู้จัดโค้ดทั้ง repo ของเราจริงๆ ถ้าเราไม่ได้ให้ context มันแต่แรก, มันไม่รู้ว่าใช้ framework เวอร์ชันไหน มี convention อะไร library ไหนห้ามใช้ response format ต้องเป็นแบบไหน หรือ performance limit คือเท่าไร (แต่ก็ได้ยินบ่อยจากคนรอบข้าง (ระดับมหาราชา/มหาราชินี) คือให้ AI อ่านโค้ดทั้ง repo ก่อนเลย)

ดังนั้น constraints ควรมีของพวกนี้:

• stack และ version ที่ใช้
• repo convention ที่ต้องตาม
• library ที่ใช้ได้หรือห้ามใช้
• output format เช่น UTF-8, JSON shape, CSV delimiter
• security หรือ performance limit
• integration boundary เช่นห้ามแก้ schema หรือห้ามกระทบ API เดิม

คือถ้าไม่มีสิ่งเหล่านี้ เราจะตรวจสอบได้ยากมากว่า AI ทำอะไรไป เพราะไฟล์อาจจะเยอะมาก รวมถึงถ้าต้องแก้ บางเรื่องอาจต้องรื้อทั้งโครงสร้างเลย เสียเวลา เสียโทเค็นไปเปล่าๆ

4. Acceptance criteria ต้องพิสูจน์ได้ ไม่ใช่แค่ฟังดูดี

คำว่า “ใช้งานได้ดี” หรือ “make it work nicely” เป็นประโยคที่น่ากลัวมากสำหรับ AI เพราะมันไม่มีทางรู้ว่า nicely ของเราคืออะไร ดังนั้นเราต้องบอกมันว่า เงื่อนไขการรับงาน (Acceptance criteria) ของเราคืออะไร

ซึ่ง Acceptance criteria ที่ดีควรเป็นแบบตรวจสอบได้ เช่น:

• ถ้ามี active users 3 คน ต้องได้ CSV 3 data rows และ header 1 แถว
• ถ้าไม่มี users ต้องได้ header อย่างเดียวและ status 200
• ถ้า user ไม่มี admin role ต้องได้ 403 และไม่ส่ง CSV body
• ถ้ามีข้อมูล 50,000 records ต้องใช้ streaming และ response ไม่เกินเวลาที่กำหนด

ถ้าไม่มีเกณฑ์ตรวจสอบได้ (ไม่ว่าจะมนุษย์ไม่เขียน หรือเอไอไม่ทำให้) ยังถือว่าเป็น Draft Requirement ไม่ใช่ Requirement จริง

เพราะการที่ Spec มี acceptance criteria มันจะเปลี่ยนจากคำอธิบายสวยๆ ให้กลายเป็น Goal ที่ AI ทำให้สำเร็จ และระบบเราจะใช้งานได้ตามที่ต้องการ

5. Edge case กับ failure path ต้องมีตั้งแต่ก่อนเขียน code

Happy path เป็นแค่ส่วนหนึ่งของ production เท่านั้น แต่ spec จำนวนมากเขียนเหมือนโลกมีแต่ happy path ฮาาา

อย่างน้อย spec ที่ส่งให้ AI ควรมี:

• error path 1 กรณี
• edge case 1 กรณี
• empty state หรือ permission case 1 กรณี

เพราะถ้าเราไม่เขียน มันจะเดาวิธี handle error จาก pattern ที่มันเห็นบ่อย ซึ่งอาจไม่ตรงกับระบบเราเลย

Checklist ก่อนโยนงานให้ AI coding agent

ผมลองเอาแนวคิดในบทความมาจัดเป็น checklist table แบบที่น่าจะใช้จริงกับงานประจำวันได้ประมาณนี้ครับ

checklist นี้ไม่ได้บอกให้เขียน spec ยาวเสมอไป แต่มันบอกให้ AI เขียน spec แบบเดาน้อยลง

Spec ไม่ได้ต้องยาว แต่ต้องมี signal พอ

บทความต้นฉบับใช้คำว่า signal redundancy matched to complexity ซึ่งผมแปลแบบบ้านๆ ว่า รายละเอียดต้องพอดีกับความเสี่ยงของงาน

ถ้าแค่แก้ margin หรือเปลี่ยน text เล็กๆ จะเขียน spec ยาว 3 หน้า ก็อาจเกินไป แต่ถ้างานแตะ authorization, payment, data integrity, migration, report export หรือ performance ตรงนี้ผมว่าไม่ควรประหยัด spec

เพราะงานพวกนี้ถ้าพลาด ไม่ใช่แค่ UI เพี้ยน แต่มันอาจกระทบข้อมูล สิทธิ์ผู้ใช้ หรือ logic สำคัญของระบบ

Workflow ที่ผมคิดว่าเอาไปใช้ได้ทันที

ถ้าจะเอาเรื่องนี้ไปใช้กับทีม software จริงๆ ผมคิดว่าไม่ต้องเริ่มจาก process ใหญ่โต แต่เริ่มจากงานหนึ่งชิ้นก่อนก็พอ

1. เลือก feature หรือ change ที่มีขอบเขตงานและโค้ดชัดเจน (boundary)
2. เขียน spec ให้มี 5 เรื่องหลัก: outcome, scope, constraints, acceptance criteria, edge cases
3. review spec ก่อนให้ AI ลงมือ
4. ให้ AI implement พร้อม test
5. ถ้า test fail หรือ reviewer ต้องถามเพิ่ม ให้กลับไปแก้ spec ก่อน ไม่ใช่แค่สั่ง AI แก้ code ไปเรื่อยๆ

จุดนี้ผมว่ามันต่อกับแนวคิด Spec-Driven Development มาก คือ spec ไม่ใช่เอกสารประกอบงาน แต่เป็น contract ของงาน ถ้า code กับ spec ขัดกัน ต้องถามก่อนว่า spec ยังถูกไหม ไม่ใช่ปล่อยให้ code ที่ AI generate มาเป็นความจริงใหม่ของระบบ

ข้อสุดท้ายสำคัญมาก และทำให้ Spec มีการอัพเดทตลอดเวลา (หรือที่เรียกว่า Living documentation)

เรื่องที่ต้องระวัง อย่าเอา checklist ไปทำให้ทีมเหนื่อยกว่าเดิม

ถึงผมจะชอบ checklist นี้มาก แต่ก็ไม่คิดว่าต้องใช้เต็มรูปแบบกับทุกงานนะครับ

ถ้าเป็น bug fix เล็กๆ ที่ test เดียวพิสูจน์ได้ หรือ prototype ที่ตั้งใจ throw away อยู่แล้ว การเขียน spec ยาวอาจไม่คุ้ม

อีกอย่างคือ spec ที่ดีไม่ได้แก้ทุกปัญหา AI ยังพลาดได้จาก model limitation, context retrieval ไม่ครบ, repo ใหญ่เกินไป หรือระบบเดิมซับซ้อนจน spec อธิบายไม่หมด

ดังนั้นอย่าใช้ checklist นี้เป็นพิธีกรรมใหม่ของทีม แต่ใช้เป็นเครื่องมือถามตัวเองว่า “งานนี้มีอะไรที่ AI ไม่ควรเดาเองบ้าง”

สรุปแบบฟิวส์ๆ

สิ่งที่ผมได้จากบทความนี้คือ AI ไม่ได้ทำให้ requirement หายไป แต่มันทำให้ requirement ที่คลุมเครือส่งผลแรงขึ้นกว่าเดิม

เมื่อก่อนถ้า requirement คลุมเครือ senior developer อาจถามกลับ หรืออย่างน้อยก็รู้จาก context ของระบบว่าอะไรควรทำไม่ควรทำ แต่ AI coding agent ไม่ทำแบบนั้น ถ้าเราไม่บอก มันจะเดา

และบางครั้งมันเดาแบบมั่นใจมากด้วยว่าจะถูก!

ยิ่ง AI เขียน code เร็วเท่าไร เราก็ยิ่งต้องเขียนให้ชัดขึ้นเท่านั้นครับ

แหล่งอ้างอิง

• How to write specs for AI: 7 rules and a checklist for better code โดย Jaroslaw Wasowski, Level Up Coding