ปัญหา Spec Rot และวิธีแก้ด้วยแนวทาง Spec-Driven Development
วิเคราะห์ปัญหา Spec Rot จากเครื่องมืออย่าง OpenSpec และ spec-kit ที่สร้างไฟล์ขยะจำพวก markdown จำนวนมาก พร้อมแนวทางทำ SDD แบบไร้บล็อกเตท
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- แนวคิด Spec-Driven Development มักประสบปัญหา Spec Rot จากการสร้างฐานความรู้สะสมโดยไม่จำเป็น
- การทดลองของ Scott Logic พบว่าการใช้เครื่องมือสร้าง markdown มากถึง 2,577 บรรทัด เทียบกับโค้ดเพียง 689 บรรทัด
- การจัดการ context budget และการจำกัดขอบเขตงานช่วยตัดไฟล์ขยะส่วนเกินออกได้อย่างหมดจด
- หันมาใช้เครื่องมืออย่าง Pi และกำหนดไฟล์ AGENTS.md เพียง 9 บรรทัดเพื่อตัดความเยิ่นเย้อ
เมื่อพูดถึงกระบวนการพัฒนาซอฟต์แวร์ที่ขับเคลื่อนด้วยสเปก หรือ Spec-Driven Development (SDD) สิ่งที่มักตามมาคือเสียงสะท้อนถึงปัญหา Spec Rot เครื่องมือยอดนิยมอย่าง OpenSpec, spec-kit และ BMAD ต่างสร้างฐานข้อมูลและความรู้สะสมขึ้นมาโดยที่ผู้พัฒนาไม่ได้ร้องขอ ซึ่งสุดท้ายแล้วกลายเป็นภาระในการจัดการระยะยาว
หัวใจสำคัญของการทำ SDD มีเพียง 2 ขั้นตอนหลัก คือ การเขียนสเปกขึ้นมาก่อน แล้วจึงพัฒนาโค้ดตามสเปกนั้น ทั้งสองขั้นตอนนี้ต้องทำงานภายใต้ขีดจำกัดของ context budget เนื่องจากหน้าต่างประมวลผลขนาด 1 ล้านโทเค็นในปัจจุบันยังคงเป็นเพียงตัวเลขทางการตลาด การปล่อยให้อุปกรณ์และเอเจนต์ AI อ่านไฟล์เอกสารขยะเดิมซ้ำๆ ทุกเซสชันจึงเป็นเรื่องที่สิ้นเปลืองทรัพยากรอย่างมาก
กรณีศึกษาจาก Scott Logic ที่นำ spec-kit มาทดสอบกับฟีเจอร์เดี่ยว พบว่ามีการสร้างไฟล์ markdown ออกมาสูงถึง 2,577 บรรทัด เทียบกับโค้ดโปรแกรมที่มีเพียง 689 บรรทัด และยังต้องใช้เวลาตรวจสอบนานถึง 3.5 ชั่วโมง ก่อนหน้านี้เคยมีการลบไฟล์ขยะประเภทย่อย เช่น หน่วยความจำ แผนงาน รายการงานคงค้าง บันทึกเซสชัน และไฟล์สำรองออกจากไดเรกทอรี ~/.claude เป็นปริมาณรวมกว่า 250 เมกะไบต์ ปรากฏว่าระบบทั้งหมดไม่มีส่วนใดเสียหายหรือได้รับผลกระทบแต่อย่างใด
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ปัญหาที่เกิดขึ้นมาจากชั้นซอฟต์แวร์จำนวนมากที่พยายามจดจำข้อมูลแทนผู้พัฒนา แต่กลับไม่มีเจ้าหน้าที่ดูแลที่แท้จริง นอกจากการจัดการด้วยการลบไฟล์ออกเอง การตัดสินใจเลือกรูปแบบการจัดวางวงเล็บปีกกา ({) ควรเป็นเรื่องของเครื่องมือจัดรูปแบบโค้ด (make fmt) ไม่ใช่สิ่งที่เราต้องไปค้นหาผ่านตัวติดตามสามตัว ระบบความจำสองแห่ง และเอกสาร ADR เพื่อหาคำตอบ
"A constitution, a spec, a plan and a task list per feature, a memlog. Scott Logic ran spec-kit on one feature and counted 2,577 lines of generated markdown against 689 lines of code, plus 3.5 hours of review."
Scott Logic
แนวทางแก้ไขที่ได้ผลคือการหยุดผสมผสานหน้าที่ต่างๆ เข้าด้วยกัน หลักการหนึ่งเครื่องมือหนึ่งหน้าที่ยังคงใช้ได้ดีในสถานการณ์นี้ การเปลี่ยนมาใช้งานเครื่องมืออย่าง Pi ช่วยตัดซอฟต์แวร์ส่วนเกินและลดความเห็นที่ไม่จำเป็นลง โดยไฟล์ AGENTS.md ส่วนกลางมีความยาวเพียง 9 บรรทัด ประกอบด้วยกฎสำคัญ 6 ข้อ หัวข้อ 2 ส่วน และบันทึกสภาพแวดล้อม 1 บรรทัด พร้อมด้วยชุดทักษะที่เขียนขึ้นเองอีก 3 รายการ
ปรากฏการณ์ Spec Rot สะท้อนให้เห็นว่าความพยายามในการพึ่งพา AI agent และโมเดลภาษาขนาดใหญ่ (LLM) มักนำไปสู่ความซับซ้อนที่เกินความจำเป็นในระดับสถาปัตยกรรมซอฟต์แวร์ การสร้างเอกสารหรือสเปกอัตโนมัติปริมาณมหาศาลอาจดูน่าสนใจในตอนแรก แต่ในระยะยาวไฟล์ขยะเหล่านี้จะกลายเป็นภาระทางเทคนิค (Technical Debt) ที่ทั้งมนุษย์และ AI ต้องเสียเวลาอ่านและประมวลผลซ้ำอย่างไร้ประสิทธิภาพ การกลับมาใช้แนวทาง Minimalist และให้โค้ดเบสเป็นแหล่งความจริงเพียงหนึ่งเดียวจึงเป็นทางออกที่ยั่งยืนกว่า
กระบวนการทำงานถูกแบ่งเป็นสัดส่วนอย่างชัดเจน เช่น ส่วนการค้นคว้าจะทำหน้าที่อ่านอย่างเดียวโดยแยกคำถามออกเป็นมุมย่อย ส่งซับเอเจนต์แบบอ่านอย่างเดียว และไม่เขียนไฟล์ใดๆ ลงในระบบ ส่วนการถ่ายโอนข้อมูลจะสร้างเอกสารสรุป Markdown ชั่วคราวโดยลบข้อมูลลับออก ก่อนที่ขั้นตอนการนำไปใช้จะตรวจสอบข้อเท็จจริงกับคลังโค้ดและทำการเปลี่ยนแปลงในจุดที่เล็กที่สุด เมื่อเซสชันมีโทเค็นเกินกว่า 100,000 โทเค็น จะทำการถ่ายโอนและเริ่มเซสชันใหม่ทันที
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น