- Spec-Driven Development(SDD) เป็นแนวทางแบบ Waterfall ที่ฟื้นการเขียนเอกสารจำนวนมากก่อนลงมือเขียนโค้ด โดยมุ่งสร้างโครงสร้างสำหรับเครื่องมือช่วยเขียนโค้ดด้วย AI แต่ก็มีความเสี่ยงที่จะ บั่นทอนความคล่องตัว
- ชุมชนโอเพนซอร์สได้พัฒนาเครื่องมือที่สร้าง สเปก แผนการติดตั้งใช้งาน และรายการงาน อัตโนมัติจากพรอมป์ต์เริ่มต้นและคำสั่งต่าง ๆ โดยตัวอย่างเด่นคือ Spec-Kit, Kiro, Tessl, BMad Method
- อย่างไรก็ตาม เมื่อใช้งานจริงกลับพบข้อจำกัดหลายอย่าง เช่น การรับรู้บริบทที่ไม่เพียงพอ การทำเอกสารมากเกินไป การรีวิวโค้ดซ้ำซ้อน และความรู้สึกมั่นใจลวง และในโค้ดเบสขนาดใหญ่ ประสิทธิภาพจะลดลงอย่างมาก
- บทความชี้ว่า SDD เป็นความพยายามที่จะมาแทนนักพัฒนา และกำลัง ทำซ้ำความล้มเหลวของโมเดล Waterfall พร้อมเสนอทางเลือกเป็น การพัฒนาแบบวนซ้ำที่ใช้ภาษาธรรมชาติเป็นฐาน
- แนวทางที่ผสาน หลักการ Agile และ Lean Startup เหมาะกับการพัฒนาสมัยใหม่ที่ใช้ coding agent มากกว่า และโจทย์ถัดไปคือการพัฒนาเครื่องมือสำหรับ ปฏิสัมพันธ์เชิงภาพ
การเกิดขึ้นของการพัฒนาแบบขับเคลื่อนด้วยสเปก (SDD)
- Spec-Driven Development(SDD) นำขั้นตอนการเขียนเอกสารสเปกก่อนเขียนโค้ดเข้ามาใช้ เพื่อมอบรูปแบบการพัฒนาเชิงโครงสร้างสำหรับเครื่องมือช่วยเขียนโค้ดด้วย AI
- จากพรอมป์ต์เริ่มต้นและคำสั่งต่าง ๆ LLM จะสร้าง สเปกผลิตภัณฑ์ แผนการติดตั้งใช้งาน และรายการงาน
- เอกสารแต่ละชิ้นอาศัยผลลัพธ์จากขั้นก่อนหน้า และผู้ใช้จะปรับแก้เพื่อขัดเกลาสเปก
- เอกสารที่เสร็จสมบูรณ์จะถูกส่งต่อไปยัง coding agent อย่าง Claude Code, Cursor, Copilot เพื่อใช้เขียนโค้ด
- เครื่องมือที่เป็นตัวแทนได้แก่ Spec-Kit ของ GitHub, Kiro ของ AWS, Tessl, BMad Method(BMM)
- มีการกล่าวถึงบทวิเคราะห์เปรียบเทียบ Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl ของ Birgitta Böckeler
ปัญหาของการทำเอกสารด้วย Markdown
- สเปกของ SDD ส่วนใหญ่จัดทำในรูปแบบ ไฟล์ Markdown และตัวอย่างการพัฒนาฟีเจอร์ง่าย ๆ ด้วย GitHub Spec-Kit ก็มีถึง 8 ไฟล์ 1,300 บรรทัด
- กรณีการเพิ่มฟิลด์ “referred by” ให้ Atomic CRM โดยใช้ Kiro ก็ถูกแยกออกเป็นเอกสารจำนวนมากเช่นกัน
- เมื่อใช้งานจริงพบข้อเสียต่อไปนี้
- การมองไม่เห็นบริบท(Context Blindness) : มองข้ามฟังก์ชันเดิมหรือบริบทของโค้ด ทำให้ยังต้องมีผู้เชี่ยวชาญมาตรวจทาน
- ความคลั่งเอกสาร Markdown(Markdown Madness) : เอกสารยาวทำให้เสียเวลามากกับการไล่หาข้อผิดพลาดง่าย ๆ
- ระบบราชการเชิงกระบวนการ(Systematic Bureaucracy) : ความซ้ำซ้อนที่ไม่จำเป็นและการลงรายละเอียดมากเกินไปทำให้เกิดความไร้ประสิทธิภาพ
- Agile ปลอม(Faux Agile) : ใช้แนวคิด “User Story” ผิดทางจนทำให้เกิดความกระจัดกระจาย
- การรีวิวโค้ดสองรอบ(Double Code Review) : ต้องตรวจทั้งโค้ดในสเปกและการติดตั้งใช้งานจริงแยกกัน
- ความรู้สึกมั่นใจลวง(False Sense of Security) : agent ไม่ได้ปฏิบัติตามสเปกอย่างสมบูรณ์เสมอไป
- ผลตอบแทนที่ลดลง(Diminishing Returns) : มีประโยชน์กับโปรเจ็กต์ระยะต้น แต่ยิ่งขนาดใหญ่ก็ยิ่งช้าลง
- เนื่องจาก coding agent ส่วนใหญ่มี plan mode และ ฟังก์ชันรายการงาน อยู่แล้ว ประโยชน์เพิ่มเติมของ SDD จึงมีจำกัด และอาจกลับเพิ่มต้นทุนการพัฒนาแทน
การเอาคืนของผู้จัดการโครงการ
- ข้อจำกัดของ SDD อาจเกิดจากเครื่องมือที่ยังไม่สุกงอมพอ แต่โดยพื้นฐานแล้วมาจาก การตั้งโจทย์ผิดตั้งแต่ต้น
- ตั้งอยู่บนเป้าหมายว่า “จะเอานักพัฒนาออกจากการพัฒนาซอฟต์แวร์ได้อย่างไร”
- เป็นโครงสร้างที่พยายามแทนนักพัฒนาด้วย coding agent และควบคุมมันด้วยแผนที่ละเอียดมาก
- สิ่งนี้คล้ายกับ โมเดล Waterfall ที่ใช้เอกสารจำนวนมหาศาลเพื่อทำให้นักพัฒนากลายเป็นเพียงผู้แปลความ
- แต่การพัฒนาซอฟต์แวร์เป็นกระบวนการ ไม่กำหนดตายตัว(non-deterministic) ซึ่งไม่อาจกำจัดความไม่แน่นอนได้ด้วยการวางแผนเพียงอย่างเดียว (อ้างถึงบทความ No Silver Bullet)
- ในขั้นกำหนดความต้องการ SDD ต้องใช้ความเชี่ยวชาญของ นักวิเคราะห์ธุรกิจ และในขั้นออกแบบก็ต้องใช้ความเชี่ยวชาญของ นักพัฒนา จึงในทางปฏิบัติมีเพียงคนส่วนน้อยที่ทำได้ครบทั้งสองบทบาท
- สุดท้ายแล้วมันก็เหมือนกับเครื่องมือ No Code ที่สัญญาว่าจะทำ “การพัฒนาโดยไม่มีนักพัฒนา” แต่ท้ายที่สุดก็ยังต้องพึ่งนักพัฒนา
ทางเลือกใหม่: การพัฒนาแบบวนซ้ำด้วยภาษาธรรมชาติ
- แนวทาง Agile เลือก ความสามารถในการปรับตัว แทนความคาดการณ์ได้ เพื่อแก้ปัญหาการพัฒนาแบบไม่กำหนดตายตัว
- หัวใจของการใช้ coding agent คือการ แยกข้อกำหนดที่ซับซ้อนออกเป็นปัญหาง่ายหลายข้อ
- มีการเสนอขั้นตอนวนซ้ำแบบง่ายโดยใช้หลักการของ Lean Startup
- ระบุสมมติฐานที่เสี่ยงที่สุดของผลิตภัณฑ์
- ออกแบบการทดลองขั้นต่ำเพื่อทดสอบมัน
- พัฒนาการทดลองและวนซ้ำตามผลลัพธ์
- ตัวอย่างเช่น มีการพัฒนา เครื่องมือปั้น 3D(sculpt-3D) ภายในเวลาราว 10 ชั่วโมงด้วย Claude Code
- เพิ่มฟีเจอร์ทีละน้อยด้วยคำสั่งสั้น ๆ โดยไม่มีสเปก
- หากติดตั้งใช้งานผิดก็แก้ทันทีและวนซ้ำอย่างรวดเร็ว
- วิธีนี้ทำให้สามารถลู่เข้าสู่ผลลัพธ์ได้เร็ว โดยไม่ต้องมีเอกสารแบบ Waterfall และการผสาน Agile เข้ากับ coding agent ก็ทำให้สร้างผลิตภัณฑ์แบบเรียลไทม์ได้
- อย่างไรก็ตาม coding agent ยัง ยึดข้อความเป็นศูนย์กลาง จึงขาดปฏิสัมพันธ์เชิงภาพ และในอนาคตจำเป็นต้องพัฒนาเครื่องมือที่ เสริมอินเทอร์เฟซเชิงภาพ
บทสรุป
- แนวทาง Agile ทำให้เอกสารสเปกกลายเป็นสิ่งไม่จำเป็นไปนานแล้ว และ SDD ถูกมองว่าเป็นความพยายามนำสิ่งนั้นกลับมา
- SDD เป็น แนวทางเชิงทฤษฎี ที่พยายามกันนักพัฒนาออกไป ทำให้พลาดโอกาสในการ เสริมพลังให้นักพัฒนารุ่นใหม่ ผ่าน coding agent
- บทความเปรียบ coding agent ว่าเป็น เครื่องยนต์สันดาปภายใน โดย SDD พยายามผูกมันไว้กับหัวรถจักรเท่านั้น ขณะที่เราควรขยายไปสู่ รถยนต์ เครื่องบิน และรูปแบบอื่น ๆ
- ท้ายที่สุด หากคำนึงถึงสิ่งแวดล้อม ก็จำเป็นต้อง ใช้ coding agent อย่างพอประมาณ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ในฐานะนักพัฒนา วิธีที่ช่วยเพิ่ม ประสิทธิภาพการทำงาน ได้มากที่สุดคือการสร้างนิสัยวางแผนทุกอย่างไว้ล่วงหน้า
ทุกครั้งที่ได้รับตั๋วงาน ก็จะแยกมันออกเป็นรายการ TODO ขนาดใหญ่ เพื่อทำให้การออกแบบ การพึ่งพา และสเปกชัดเจนล่วงหน้า
แบบนี้จะช่วยให้เข้าสู่ ภาวะลื่นไหลในการทำงาน (flow) ได้บ่อยขึ้นตอนเขียนโปรแกรม
เหตุผลที่แนวทางนี้ได้ผลกับ AI coding agent ด้วย ก็เพราะมันเป็นการถ่ายทอดกระบวนการคิดเอาไว้ล่วงหน้า
รายละเอียดเพิ่มเติมสรุปไว้ในบทความของฉัน
ในความเป็นจริง การแยกปัญหาออกเป็นส่วนย่อยและการเขียนสเปกเป็นเรื่องที่ดี
แต่ปัญหาคือ สเปกที่แก้ไขไม่ได้ หากเริ่มลงมือพัฒนาหลังจากผ่านไปหลายเดือน สเปกก็จะถูกตรึงตายตัว
ในทางกลับกัน Agile มักถูกใช้เป็นข้ออ้างในการเลื่อนการวางแผนเชิงกลยุทธ์ออกไป ส่งผลให้ต้องแก้งานซ้ำมากขึ้น
สุดท้ายแล้วมันคือเรื่องของความสมดุล และคิดว่า “It depends” เป็นคติที่ดีทั้งในชีวิตและการพัฒนา
ถ้าให้ LLM ช่วยดูแลสเปก ก็น่าจะมีข้อดีตรงลดภาระการบำรุงรักษาได้
บทความที่เกี่ยวข้องอยู่ที่นี่
ถ้าคาดการณ์ได้ยาก ก็จะทำ spike ก่อนเพื่อสำรวจโค้ดและไลบรารี
เราจะทำทั้งแผนภาพโครงสร้างในอุดมคติและแผนภาพที่สะท้อนข้อจำกัดจริง เพื่อหลีกเลี่ยง กับดักด้านสถาปัตยกรรม ในระยะยาว
หลังจากทำ vibe coding มาหลายเดือน ช่วง 6 เดือนหลังมานี้เปลี่ยนมาใช้ spec-driven development
ใช้เวลา 2-3 ชั่วโมงต่อวันในการเขียนสเปก แล้วก็ deploy ฟีเจอร์ที่ผ่านการทดสอบภายในวันเดียวกัน
การเขียนสเปกไม่ได้ทำให้คล่องตัวน้อยลง ตรงกันข้าม มันทำให้ทำรอบการพัฒนาเร็วระดับ 8 ชั่วโมงได้
สเปกไม่ใช่พรอมต์ แต่คือ เกณฑ์ตัดสินความถูกต้อง
การทดสอบ end-to-end ที่นิยามไว้อย่างดีช่วยลดความผิดพลาดของ AI ได้มาก
แต่ละครั้งที่รันได้ผลลัพธ์ต่างกัน และสุดท้ายก็ต้องให้มนุษย์ตรวจทานอยู่ดี เลยอาจไม่มีประสิทธิภาพ
การเรียกงานที่ใช้เวลาหนึ่งวันว่า ‘สเปก’ ทำให้เข้าใจผิด สุดท้ายก็เป็นแค่กระบวนการเดิมที่เปลี่ยนชื่อใหม่
บ่อยครั้งยังตีความนิพจน์ตรรกะแบบง่าย ๆ ผิด ดังนั้นการให้มันเข้าใจสเปกภาษาธรรมชาติจึงเสี่ยง
จากนั้นก็ส่งให้ agent ไปจัดการ implement เอง ส่วนฉันคอยตรวจเป็นระยะ
ระหว่างที่ AI ทำงาน ฉันก็ได้ไปยุ่งกับ รถแข่ง ของตัวเอง เลยถือว่า win-win สุด ๆ
สุดท้ายแล้วสิ่งสำคัญมีแค่ว่าโค้ดผ่านการทดสอบหรือไม่
บทความนี้ดูเหมือนเขียนสำหรับคนที่สรุปไปแล้วว่า “spec-based development ไม่เหมาะกับฉัน”
ฉันมองว่าสเปกคือ จุดเข้าสู่คอนเท็กซ์ของ LLM
ถ้าให้ข้อมูลเกี่ยวกับโครงสร้างของโปรเจกต์ โมเดล ฟังก์ชัน และข้อกำหนดอย่างเพียงพอ LLM ก็จะเข้าใจบริบทและต่อยอดได้
ยิ่งไปกว่านั้น ถ้าให้ LLM อัปเดตสเปกด้วยตัวเอง ก็จะเกิด การวนซ้ำแบบ Agile ได้
การทดสอบทำหน้าที่เป็น grounding กับความเป็นจริง ให้ LLM และช่วยป้องกันอาการหลอน
การทดสอบเป็นทั้งเอกสารและเกณฑ์คุณภาพ และต้องบริหาร LLM เหมือนเป็น นักพัฒนาระดับจูเนียร์
ถ้ารันหลาย agent แบบขนานกัน แล้วให้ตรวจสอบไขว้กันผ่านชั้นการทดสอบ ก็จะได้ผลลัพธ์ที่น่าทึ่ง
เพียงแค่ด้วย LLM ทำให้สามารถวนซ้ำกับสเปกทั้งชุดได้เร็วขึ้นและถูกลง แต่แก่นแท้ยังเหมือนเดิม
สเปกที่ยาวเกินไปกลับไปขัดขวาง การคิดเชิงสำรวจ
LLM ไม่ใช่ระบบกำหนดผลลัพธ์ตายตัว แต่เป็นระบบเชิงความน่าจะเป็น ดังนั้นตอนนี้เราจึงต้อง debug สเปกแทนโค้ด
นักพัฒนาจำเป็นต้องวิวัฒน์ไปเป็น สถาปนิกระบบการรับรู้ (cognitive systems architect)
มีทั้งสเปกระดับสูงและสเปกของคอมโพเนนต์รายละเอียดที่อยู่ร่วมกัน
ฉันเคยลองสร้างเครื่องมือ CLI ด้วย Spec-Kit ของ GitHub แต่ต้องผ่านกระบวนการ แก้ไข·วิเคราะห์·เขียนใหม่ จำนวนมากเกินไป
มันน่าอึดอัดเพราะแทบไม่มี feedback loop แบบวนซ้ำเหมือน waterfall
สุดท้ายแทนที่จะไล่หาสาเหตุจากโค้ดผิด ๆ การเริ่มใหม่กลับดีกว่า
การเขียนโค้ดร่วมกับ LLM นั้นดี แต่ SDD ให้ความรู้สึกเป็น เวิร์กโฟลว์ที่หนักและไม่มีประสิทธิภาพ
LLM ชอบบริบท จึงต้องสั่งซ้ำ ๆ ให้ชัดเจน
ตัวอย่างเช่นตอนสร้างแอป NextJS ก็ต้องระบุให้ชัดเรื่องล็อกอิน, RBAC, การพัฒนาแบบทดสอบนำก่อน เป็นต้น
การเริ่มจากหน่วยเล็ก ๆ แล้วค่อยเพิ่มฟังก์ชันทีละน้อยเหมาะสมกว่า
ปัญหาของ waterfall คือ ระยะเวลานำที่ยาว และ ต้นทุนการวนซ้ำที่แพง
สำหรับ SDD แล้ว สองอย่างนี้ถูกแก้ได้ จึงคิดว่าใช้ได้
การเรียกสเปกที่ใช้เวลาไม่กี่ชั่วโมงว่า waterfall ถือว่าเกินจริง
ถ้ารีบเข้าไปอยู่ในพื้นที่คำตอบที่ซับซ้อนเร็วเกินไป ก็จะทำให้การแก้ปัญหาแบบง่ายกลายเป็นเรื่องยาก
Agile เริ่มจากพื้นที่เล็ก ๆ แล้วค่อย ๆ ขยายออกไป
ถ้าสเปกละเอียดพอ การวนซ้ำก็จะช้าลง แต่ถ้ารายละเอียดไม่พอ LLM ก็จะทำงานได้ไม่ดี
สุดท้ายก็ยังคง ความย้อนแย้งของ waterfall ที่ผู้จัดการชอบ ไว้เหมือนเดิม
LLM ทำงานได้ดีที่สุดเมื่อได้รับคำสั่งที่ชัดเจนในหน่วยเล็ก ๆ
เขียนสเปกระยะหลายปี รัน LLM ทุก 6 เดือน แล้วถ้าล้มเหลวก็โทษนักพัฒนา
ฉันคือผู้เขียนบทความเอง
ยังรู้สึกว่าน่าสนใจที่ ข้อถกเถียง waterfall vs Agile ยังร้อนแรงอยู่
การได้อ่านภูมิหลังของคนที่รู้สึกว่า SDD มีคุณค่าก็สนุกดี
แต่ฉันใช้ โหมด Plan ก่อนลงมือ implement อยู่แล้ว ดังนั้น SDD เลยไม่ได้เพิ่มคุณค่าอะไรเป็นพิเศษ
แทบไม่เคยมีครั้งไหนที่ coding agent implement ได้สมบูรณ์แบบในรอบเดียว
สุดท้ายจึงต้องมีการวนซ้ำอยู่ดี ทำให้ความหมายของ Big Design Up Front หายไป
อย่างไรก็ตาม ฉันเชื่อว่า coding agent กำลังเปิด กระบวนทัศน์การพัฒนาแบบใหม่
ทำให้นึกถึงวิดีโอที่เคยดู
เขาพูดถึงสิ่งที่วิศวกรกับโปรแกรมเมอร์เรียนรู้จากกันและกันได้ และเรื่อง ความสำคัญของการวางแผนล่วงหน้า น่าประทับใจมาก
มีคนบอกว่า Agile ฆ่าเอกสารสเปกทิ้ง แต่จริง ๆ แล้วมันแค่หั่นมันออกเป็น Jira ticket หลายพันใบ เท่านั้น
AI สามารถบันทึก การตัดสินใจและบริบทที่กระจัดกระจาย เหล่านี้ทั้งหมดไว้ และตั้งคำถามได้เมื่อมันขัดกับตัวเลือกในอดีต
เช่นให้ feedback ว่า “เหตุผลที่ Jim เขียนโค้ดชิ้นนี้ไว้แบบนี้เมื่อ 5 ปีก่อน ยังใช้ได้อยู่ไหม?”
บทความนี้ให้ความรู้สึกแปลก ๆ
การได้รับสเปกที่ไม่สมบูรณ์แล้วลองผิดลองถูกเพื่อแก้ปัญหา ไม่ว่ามนุษย์นักพัฒนาหรือ AI ก็เจอเหมือนกัน
ถ้ารู้อยู่แล้วอย่างชัดเจน ก็ควร สั่งรายละเอียดให้ชัด
บางทีประเด็นของบทความอาจจริง ๆ แล้วคือเรื่อง “สเปกที่ไม่ดี”
โดยรวมแล้วมันดูเหมือน ตรรกะป้องกันตัวเองของอุตสาหกรรม Agile
ฉันเคยลองทำ SDD ด้วย ไฟล์สเปก Markdown หลายไฟล์ แต่สิ่งที่มีประสิทธิภาพจริง ๆ คือ ** beads**
มันช่วยให้ agent โฟกัสได้ด้วยการไล่ไปตาม task tree
แบ่งแต่ละงานออกตามแนวทาง TDD และไม่ให้ข้ามไปขั้นถัดไปจนกว่าจะผ่านการทดสอบ
ตัว agent ยังบอกคำสั่งรีวิวให้ด้วย ทำให้ code review ง่ายขึ้น
Spec-Kit หนักเกินไป ดังนั้น beads จึงใช้งานได้จริงกว่ามาก
โปรเจกต์ zmx ที่ทำแบบ vibe ล้วน ๆ ก็สุดท้ายต้องกลับมา rewrite ทั้งหมดโดยอ้างอิงโค้ดจาก agent ทีหลัง