ผลสำรวจจาก Sonar ในปี 2026 ระบุว่านักพัฒนา 88% เห็นว่าโค้ดที่สร้างโดย AI กำลังทำให้หนี้ทางเทคนิค (technical debt) เพิ่มสูงขึ้น และผู้สนับสนุนการพัฒนาที่ขับเคลื่อนด้วยข้อกำหนด (spec-driven development) แย้งว่าขั้นตอนการกำหนดข้อกำหนด (specification) ที่มีระเบียบวินัยสามารถหยุดยั้งการหลงทิศทางนี้ได้

ทำไมปัญหานี้จึงสำคัญ

เมื่อมนุษย์ได้รับตั๋ว (ticket) ที่คลุมเครือ พวกเขาจะถามคำถามเพื่อความชัดเจน ในทางตรงกันข้าม AI agent จะเติมช่องว่างด้วยการคาดเดาที่ดีที่สุดของมัน และส่งมอบโค้ดที่ดูเหมือนจะใช้งานได้จริง ความรู้สึกว่าโค้ดนั้นถูกต้อง (illusion of correctness) นั้นมีราคาที่ต้องจ่ายสูง: ผลสำรวจเดียวกันจาก Sonar รายงานว่าผู้ตอบแบบสอบถามมากกว่าครึ่งเคยเห็นโค้ดที่ผ่านการตรวจสอบพื้นฐานแล้ว แต่กลับซ่อนข้อบกพร่องที่แนบเนียนไว้ ข้อบกพร่องเหล่านั้นจะสะสมกลายเป็นหนี้ทางเทคนิค บีบให้ต้องมีการทำ refactor ในภายหลัง ทำให้การส่งมอบฟีเจอร์ช้าลง และทำให้งบประมาณในการบำรุงรักษาสูงขึ้น

รูปแบบของการพัฒนาที่ขับเคลื่อนด้วยข้อกำหนด (Spec-driven development)

การพัฒนาที่ขับเคลื่อนด้วยข้อกำหนด (Spec-driven development หรือ SDD) จะเปลี่ยนลำดับขั้นตอนในปัจจุบัน แทนที่จะป้อนคำสั่ง (prompt) ให้กับโมเดล AI ด้วย user story สั้นๆ ทีมงานจะเขียนข้อกำหนด (specification) ที่ละเอียดและเอเจนต์สามารถนำไปประมวลผลได้ (agent-executable) ซึ่งจัดเก็บไว้ในระบบควบคุมเวอร์ชัน (version-control system) เดียวกันกับโค้ด ข้อกำหนดนี้จะกลายเป็นแหล่งข้อมูลความจริงหนึ่งเดียว (single source of truth) โดยจะบันทึกทั้งเจตนา, กรณีขอบเขต (edge cases), ความคาดหวังด้านประสิทธิภาพ และข้อจำกัดใดๆ ที่โมเดล AI ต้องปฏิบัติตาม

กระบวนการนี้ไม่ได้มาแทนที่งานออกแบบของมนุษย์ แต่เป็นการทำให้งานนั้นอยู่ในรูปแบบที่เป็นระบบ (codifies it) การย้ายการตัดสินใจจากความจำของนักพัฒนาไปไว้ในเอกสารที่เป็นรูปธรรม จะช่วยให้ทั้งมนุษย์และ AI agent ในอนาคตสามารถตรวจสอบย้อนกลับได้ว่าทำไมโค้ดชิ้นหนึ่งถึงทำงานในลักษณะนั้น การร่างข้อกำหนดอาจต้องใช้ความพยายามในช่วงเริ่มต้น แต่การดีบั๊ก (debugging) ผลลัพธ์ของ AI ที่คลุมเครือจะมีต้นทุนที่สูงกว่ามากในภายหลัง

การเปลี่ยนเวิร์กโฟลว์ (Workflow)

Product backlog – เก็บรายการให้สั้น โดยระบุเพียงเจตนาและเกณฑ์การยอมรับ (acceptance criteria) ในระดับสูงเท่านั้น รายการนี้จะยังคงทำหน้าที่ขับเคลื่อนการจัดลำดับความสำคัญต่อไป

Sprint planning – ทีมจะหารือเกี่ยวกับเป้าหมายโดยรวมและตกลงเรื่อง Sprint Goal แต่จะยังไม่ลงรายละเอียดการ実装 (implementation) จนกว่าข้อกำหนดจะพร้อม

During the sprint – ผู้ที่รับงานจะเขียนข้อกำหนดที่แม่นยำและเครื่องสามารถอ่านได้ (machine-readable) ข้อกำหนดจะระบุรูปแบบอินพุต, ผลลัพธ์ที่คาดหวัง, การจัดการข้อผิดพลาด (error handling) และข้อกำหนดด้านอื่นๆ (non-functional requirements) เนื่องจากข้อกำหนดมีการควบคุมเวอร์ชัน ผู้ตรวจสอบจึงสามารถแสดงความคิดเห็น เสนอการแก้ไข และอนุมัติการเปลี่ยนแปลงได้เหมือนกับการตรวจโค้ด

Definition of Done – เพิ่ม “Spec reviewed and approved” ลงในเกณฑ์คุณภาพ (quality gate) โค้ดจะยังไม่ถือว่าเสร็จสมบูรณ์จนกว่าข้อกำหนดจะผ่านมาตรฐานการตรวจสอบแบบเดียวกับการเขียนโค้ดจริง

Kanban adaptation – เพิ่มคอลัมน์ใหม่สองคอลัมน์: “Spec Drafted” และ “Spec Approved” รายการงานจะไหลจาก backlog → Sprint Goal → Spec Drafted → Spec Approved → In Progress → Done การเปลี่ยนแปลงเชิงภาพนี้จะทำให้ขั้นตอนการประสานงานที่เคยไม่ชัดเจนกลายเป็นสิ่งที่มองเห็นได้ชัดเจน

เครื่องมือที่บังคับใช้ข้อกำหนดในปัจจุบัน

แพลตฟอร์มอย่าง GitHub Spec Kit และ AWS Kiro ได้เพิ่มด่านตรวจ (gates) ที่กำหนดให้ต้องมีเอกสารข้อกำหนดก่อนที่จะเริ่มการสร้างโค้ดด้วย AI เครื่องมือเหล่านี้ไม่ได้มาแทนที่โมเดล AI แต่ช่วยปรับจูนเอเจนต์ที่ทำตามคำสั่งอย่างตรงไปตรงมา (literal-minded agents) ให้สอดคล้องกับเจตนาของมนุษย์ การกำหนดให้ข้อกำหนดเป็นเงื่อนไขเบื้องต้นช่วยให้เครื่องมือเหล่านี้เปลี่ยนผ่านกระบวนการได้โดยอัตโนมัติโดยไม่กระทบต่อ CI/CD pipelines ที่มีอยู่เดิม

ข้อโต้แย้งที่อาจเกิดขึ้น

นักวิจารณ์กล่าวว่าการเขียนข้อกำหนดเป็นการเพิ่มความยุ่งยากให้กับจังหวะการทำงานแบบ agile ที่รวดเร็วอยู่แล้ว ข้อโต้แย้งในมุมกลับคือ: เวลาที่ใช้ในการร่างข้อกำหนดมักจะเป็นเพียงเศษเสี้ยวของเวลาที่ต้องเสียไปกับการดีบั๊กโค้ดที่ AI สร้างขึ้นจากคำสั่ง (prompt) ที่คลุมเครือในภายหลัง

อีกหนึ่งความกังวลคือข้อกำหนดอาจล้าสมัยเมื่อความต้องการเปลี่ยนแปลงไป การรวมเข้ากับระบบควบคุมเวอร์ชัน (version-control integration) สามารถแก้ปัญหานี้ได้: การเปลี่ยนแปลงใดๆ ในข้อกำหนดจะสร้าง commit ใหม่ กระตุ้นให้เกิดการตรวจสอบ และบีบให้ทีมต้องประเมินโค้ดที่เกี่ยวข้องใหม่ ในทางปฏิบัติ การปฏิบัติกับข้อกำหนดให้เหมือนกับโค้ดจะช่วยให้เอกสารมีความเป็นปัจจุบันอยู่เสมอ

สิ่งที่ควรจับตามองต่อไป

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

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