spec-driven development คืออะไร และทำไม คนไม่เขียนโค้ด ก็ทำได้

ช่วงนี้พอเข้าไปในวงการ AI coding หันไปทางไหนก็เจอคำว่า spec-driven development เครื่องมือใหม่ๆ ก็ชูคำนี้ ค่ายใหญ่ก็ออก toolkit มารองรับ ฟังผ่านๆ เหมือนเป็นศัพท์เทคนิคของสายโปรแกรมเมอร์ที่คนทั่วไปไม่เกี่ยว

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

บทความนี้เล่าสามเรื่อง spec-driven development คืออะไรกันแน่ ทำไมมันถึงมาแรงเอาตอนนี้ และทำไมคนที่ไม่เขียนโค้ดถึงทำได้ (แถมทำได้ดี)

ช่วงที่ 1spec-driven development คืออะไรกันแน่

ตัดศัพท์ออกให้หมด แล้วมันเหลือประโยคเดียว เขียนให้ชัดก่อนว่าจะสร้างอะไร แล้วค่อยให้สร้างตามนั้น เอกสารที่บอกว่าจะสร้างอะไรเรียกว่า spec และ spec นี่แหละคือแหล่งความจริงของงาน ไม่ใช่โค้ด ไม่ใช่ประวัติแชต

ต่างจากการสั่ง AI ไปเรื่อยๆ ตรงไหน

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

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

ทำไมลำดับถึงสำคัญ

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

ช่วงที่ 2ทำไมถึงมาแรงเอาตอนนี้

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

โค้ดกลายเป็นของถูก คอขวดเลยย้ายที่

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

พอโค้ดไม่ใช่ของหายากอีกต่อไป ของที่มีค่าที่สุดในกระบวนการเลยกลายเป็น spec ที่ดี นี่คือเหตุผลที่เครื่องมือใหม่ๆ ถึงหันมาชูเรื่องนี้กันหมด

ผลที่ซ้ำได้ ทั้งที่ AI เดาใหม่ทุกครั้ง

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

ช่วงที่ 3ทำไมคนไม่เขียนโค้ดถึงทำได้ดี

มาถึงส่วนที่เซอร์ไพรส์คนส่วนใหญ่ ในเมื่อของที่มีค่าที่สุดย้ายมาอยู่ที่ spec และ spec คือการคิดให้ชัดว่าจะสร้างอะไร งานหลักเลยเป็นทักษะการคิด ไม่ใช่ทักษะการเขียนโค้ด

spec คือการคิด ไม่ใช่การพิมพ์โค้ด

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

ที่จริงคนไม่เขียนโค้ดบางทีได้เปรียบด้วยซ้ำ เพราะไม่เผลอกระโดดไปคิดเรื่องวิธีสร้างก่อนเวลา เลยโฟกัสที่ "จะสร้างอะไรและทำไม" ได้เต็มที่ ซึ่งเป็นหัวใจของ spec

spec สำหรับงานทั่วไป ก็คือ PRD ย่อๆ

ข่าวดีคือคุณไม่ต้องเรียนศัพท์เทคนิคใหม่ทั้งกอง สำหรับงานเล็กถึงกลาง spec ก็คือ PRD (product requirements document) ย่อๆ ที่ระบุปัญหา ผู้ใช้ ขอบเขต สิ่งที่ต้องทำได้ และเกณฑ์ยอมรับที่ตรวจได้ ครึ่งหน้าก็พอ เขียนเป็นภาษาคน ไม่ต้องมีโค้ดสักบรรทัด

ถ้าอยากลงมือ เราเขียนสองบทความที่พาทำละเอียดไว้แล้ว ตอนแรกว่า ทำไม vibe coding ถึงต้องมี PRD และตอนที่สองเป็น วิธีเขียน PRD ทีละหัวข้อ พร้อมตัวอย่างจริง อ่านสองอันนั้นก็เขียน spec แรกได้เลย

สรุป

spec-driven development ไม่ใช่เทรนด์เทคนิคที่คนทั่วไปมองข้ามได้ มันคือการบอกว่าพอ AI สร้างของได้เร็ว คนที่คิดโจทย์ให้ชัดได้ คือคนที่ได้เปรียบ ไม่ใช่คนที่พิมพ์โค้ดเร็วที่สุด ถ้าคุณคิดเป็นระบบอยู่แล้ว คุณมีของชิ้นที่สำคัญที่สุดอยู่ในมือ เหลือแค่เอามันลง spec ให้เป็น ถ้าอยากได้ตัวช่วยเช็กว่าไอเดียพร้อมยัง แล้วตีกลับเป็นโครง PRD ให้เลย เราทำเครื่องมือฟรีไว้ที่ productize.life/services/prd