Spec Driven Development - ทำให้ vibe coding ทรงพลังยิ่งขึ้น
(ainativedev.io)ก่อนเริ่ม
IDE ชื่อ Kiro เคยถูกนำเสนอใน GeekNews มาแล้ว
แต่ยังไม่มีการแนะนำในมุมมองของ Spec Driven Development (SDD) ซึ่งเป็นแนวคิดของวิธีการพัฒนาที่ Kiro มุ่งไปสู่
จึงขอแนะนำวิดีโอที่ช่วยให้เข้าใจ Spec Driven Development ได้ดี
Kiro
-
IDE แบบเอเจนต์: ช่วยพัฒนาด้วยภาษาธรรมชาติ แต่มีแนวคิดเอนเอียงให้ “สเปกเป็นอาร์ติแฟกต์ชั้นหนึ่ง”
-
รักษาความเร็วของ “vibe coding” แบบ IDE เอเจนต์เดิมไว้ พร้อมทั้งกำหนดการตัดสินใจ สมมติฐาน และข้อจำกัดไว้ในเอกสารสเปก
-
เวิร์กโฟลว์: เมื่อป้อนไอเดียเข้าไป จะเริ่มต้นทันทีด้วยการสร้างไฟล์ 3 ไฟล์คือ requirements / design / tasks ตัวเอดิเตอร์อยู่บนฟอร์กของ Code OSS และเพิ่มแท็บ “Specs / Hooks / Steering” เข้าไป
- Specs: จัดโครงสร้างความต้องการ (user story + acceptance criteria ในรูปแบบ EAR) แล้วเชื่อมการพัฒนา การทดสอบ และการเปลี่ยนแปลงเข้ากับสเปกในภายหลัง
- Hooks: เฝ้าดูการเปลี่ยนแปลงของไฟล์/โค้ดเพื่อทริกเกอร์เวิร์กโฟลว์ของสเปก
- Steering: เช็กอินไกด์ของทีมเป็นกฎ (markdown) ไว้ใน
.kiro/ที่รากของรีโพซิทอรี—เช่น ใส่กฎ TDD เพื่อทำให้การทำงานของเอเจนต์สม่ำเสมอ
ความจำเป็นของ Spec Driven
-
ช่วยอุดข้อจำกัดของ vibe coding: เมื่อสร้างโค้ดได้เร็วผ่านการโต้ตอบในแชต เหตุผลของการตัดสินใจมักจมหายไปในสตรีมแชต จนภายหลังไม่ชัดว่า “สร้างอะไรไป และทำไมถึงสร้างแบบนั้น” SDD จึงเน้นตั้งสเปกที่ยึด behavior เป็นศูนย์กลางก่อน เพื่อใช้เป็นเข็มทิศที่มั่นคง
-
คำนิยามของสเปก (behavior, property, invariant): อธิบายว่าระบบควรทำงานอย่างไร ไม่ใช่อธิบายการ implement—ดึงแนวคิดอย่างคุณสมบัติด้าน safety/liveness และ invariant มาใช้ แต่พยายามทำให้เข้าถึงได้ด้วยรูปแบบไวยากรณ์ที่เป็นมิตรกับนักพัฒนา
ข้อดีของ SDD
-
ทำให้การตัดสินใจมองเห็นได้และนำกลับมาใช้ซ้ำได้: สเปกกลายเป็น “ต้นทาง” ของการเปลี่ยนแปลงโค้ด ทำให้รีวิวและตกลงร่วมกันได้ง่ายขึ้น และแม้ฟีเจอร์จะเปลี่ยนไป เจตนา (behaviors) ก็ยังคงถูกบันทึกไว้
-
สเปกที่มีชีวิตและประกอบต่อกันได้: โมดูลาร์ user scenario, acceptance criteria, interface/data contract, ประสิทธิภาพ/SLA ฯลฯ เพื่อให้สามารถนำกลับมาใช้ซ้ำและประกอบรวมกันได้ (จากระดับ service ไปสู่ระดับ system)
-
ใช้ได้ตลอดทั้ง SDLC: ตั้งแต่การจัดแนวกันในช่วง requirement/การออกแบบ ไปจนถึงฟีดแบ็กลูปของปัญหาหลัง deploy—เป็นแนวคิดที่พยายามรักษาการรีวิว คุณภาพ และความสม่ำเสมอ แม้ในยุคที่ AI ทำให้การสร้างโค้ดเร็วมาก
เดโม SDD
- ลิงก์จุดเริ่มเดโมในวิดีโอที่โพสต์ไว้ใน Main link ดูได้ที่ URL นี้: https://youtu.be/olMxlFSxydc?si=sei-bBZ0Q0yszaWn&t=1085
ลำดับขั้นของ SDD
A. การตั้งค่าเริ่มต้น
- ตั้งค่าโปรเจกต์ - Hooks, Steering, MCP
- ตั้งค่า TDD (แนะนำ)
- ตั้งค่า Spec - เขียน Spec ตามรูปแบบ EAR (แนะนำ) โดย AI สามารถสร้างอัตโนมัติจากการวิเคราะห์โปรเจกต์เดิมได้
B. การพัฒนาฟีเจอร์
- แตกแขนงจาก Spec - สะท้อน/อัปเดตความต้องการใหม่ลงใน Spec
- ตั้งค่า guardrail (แนะนำ) - สร้าง test stub และเขียนกฎ
- implement <-> test - ช่วงนี้ส่วนใหญ่จะวนซ้ำผ่าน AI โดยนักพัฒนาจะเข้าไปแทรกแซงเฉพาะการแก้โค้ดเล็กน้อยที่ AI ยังแก้ได้ไม่ดี
- หลังจากตั้งค่าโครงสร้างโปรเจกต์เสร็จแล้ว จะขยายฟีเจอร์ด้วยการวนซ้ำขั้นตอน 'B. การพัฒนาฟีเจอร์'
ข้อควรระวัง
- หากคุณภาพของเอกสาร Spec ไม่ถึงระดับที่กำหนด ระบบจะไม่ทำงาน
- ในวิดีโอยังไม่ได้อธิบายกฎเกณฑ์มาตรฐานของเอกสาร Spec อย่างละเอียด (อ้างอิง: https://kiro.dev/docs/specs/)
- แนะนำให้ใช้ TDD และมีการบอกว่าโปรเจกต์ส่วนใหญ่ที่ไม่ได้ใช้ TDD มักไม่ค่อยได้รับประโยชน์จากวิธีการนี้
ความเห็นส่วนตัว
- เป็นหนึ่งในแนวทางที่ถูกเสนอจากอีกมุมมองหนึ่งสำหรับการใช้ AI ให้มีประสิทธิภาพ
- เอกสารที่เขียนได้ 'ดี' ย่อมมีข้อดีมากมายเสมอ แต่จากประสบการณ์จริงที่เอกสารจำนวนไม่น้อยถูกดูแลต่อเนื่องได้ไม่ดีนัก ประเด็นสำคัญจึงน่าจะอยู่ที่ว่าจะสร้างฉันทามติร่วมจากผู้คนได้มากแค่ไหน
- ณ เวลานี้ กลยุทธ์การพัฒนาแบบ AI + TDD เป็นแนวทางที่นักพัฒนาจำนวนมากยอมรับร่วมกันและผ่านการพิสูจน์มาในระดับหนึ่ง หากมีการพิสูจน์ผลลัพธ์ผ่านการเปรียบเทียบระหว่างการใช้ TDD อย่างเดียวกับการใช้ SDD ร่วมด้วย ก็น่าจะได้รับการยอมรับในวงกว้างมากขึ้น
ยังไม่มีความคิดเห็น