เหตุใดการพัฒนาแบบขับเคลื่อนด้วยสเปก (Spec-Driven Development) จึงล้มเหลวเมื่อขยายสเกล และจะแก้อย่างไร

โพสต์นี้เสนอว่าแนวทางการพัฒนาแบบขับเคลื่อนด้วยสเปก (การพัฒนาที่อิงเอกสารข้อกำหนด) แม้จะดูมีอนาคตสำหรับงานเขียนโค้ดที่ใช้ AI เอเจนต์ แต่เมื่อขยายไปสู่ระดับใหญ่ในบริบทของผลิตภัณฑ์ระดับโลก ก็จะล้มเหลวเพราะความกำกวมของสเปกที่เขียนด้วยภาษาธรรมชาติ ผู้เขียนจึงเสนอระบบแบบลำดับชั้นและพัฒนาได้ต่อเนื่องของ "สเปกที่มีชีวิต" (living specifications) ที่ผสานโค้ดเข้ากับ AI แบบโต้ตอบได้ ซึ่งจะสร้างวงจรป้อนกลับของการตัดสินใจด้านผลิตภัณฑ์ เพื่อลดความไม่สอดคล้องและทำให้การพัฒนาที่มี AI ช่วยในระดับใหญ่มีประสิทธิภาพได้

เหตุผลหลักที่การพัฒนาแบบขับเคลื่อนด้วยสเปกล้มเหลวเมื่ออยู่ในระดับใหญ่

การพัฒนาแบบขับเคลื่อนด้วยสเปกในแบบดั้งเดิมมีปัญหากับสเปกของผลิตภัณฑ์ระดับโลกด้วยเหตุผลต่อไปนี้:

• ความกำกวมของสเปกภาษาธรรมชาติ: สเปกขนาดใหญ่เขียนด้วยภาษาธรรมชาติ จึงไม่แม่นยำและกำกวม AI อาจสร้างโค้ดให้สอดคล้องกับสเปกได้อย่างสม่ำเสมอ แต่ก็อาจไม่ตรงกับเจตนาของนักพัฒนา ตัวอย่างเช่น หากเขียนสเปกของทั้งเว็บไซต์ผลิตภัณฑ์ แล้วให้ AI เอเจนต์สร้างเสร็จภายใน 2 วัน ผลลัพธ์อาจตรงกับสเปกแต่ผิดจากสิ่งที่ตั้งใจ หากพยายามแก้โดยเพิ่มส่วนย่อยเพื่ออธิบายความกำกวมให้ชัดขึ้นเรื่อย ๆ เอกสารก็จะยืดยาวเกินไปจนเสียข้อดีของการเขียนสเปก และสุดท้ายก็กลายเป็นภาษาที่มีรูปแบบตายตัวซึ่งแทบไม่ต่างจากโค้ด

• การขาดบริบทที่ใช้ร่วมกันและความเข้าใจโลก: แม้ AI จะมีความรู้กว้างจากข้อมูลสาธารณะ แต่ก็ไม่เข้าใจแนวปฏิบัติเฉพาะของบริษัท กฎของโค้ดเบส และ "วิธีการทำงาน" ภายในองค์กร ในขณะที่มนุษย์เรียนรู้สิ่งเหล่านี้ผ่านการลองผิดลองถูก การรีวิว PR การประชุม และการพูดคุยนอกรอบ เอกสารบริบทเพียงฉบับเดียวไม่สามารถเก็บสิ่งเหล่านี้ได้ครบ

• ความไม่มีประสิทธิภาพในการจัดการคำชี้แจงเพิ่มเติม: มนุษย์สามารถใช้บริบทที่มีร่วมกันเพื่อแก้เฉพาะความกำกวมที่เกี่ยวข้องได้อย่างมีประสิทธิภาพ (เช่น ไม่ต้องถามเรื่องที่ชัดเจนอยู่แล้วอย่างการเลือกไลบรารี) แต่ AI ยังขาดความละเอียดอ่อนของบริบท จึงอาจถามคำถามที่ไม่จำเป็น หรือความสามารถในการขอคำชี้แจงยังอยู่ในช่วงเริ่มต้น สิ่งนี้ทำให้ AI คล้ายกับ "เด็กฝึกงานที่ทะเยอทะยานเกินไป" ซึ่งต้องมีคนคอยกำกับอยู่ตลอด

ด้วยปัญหาเหล่านี้ การพัฒนาแบบขับเคลื่อนด้วยสเปกระดับโลกจึงไม่สมจริงหากไม่มีกลไกเพิ่มเติม และยังตามความลื่นไหลของการทำงานร่วมกันระหว่างมนุษย์ไม่ทัน

ตัวอย่างที่เป็นรูปธรรม

• สถานการณ์แบบสุดโต่งของการพัฒนาโดยขับเคลื่อนด้วยสเปก: นักพัฒนาเขียนสเปกของทั้งเว็บไซต์ แล้ว AI สร้างผลิตภัณฑ์ที่เสร็จสมบูรณ์ภายใน 2 วัน แต่ผลลัพธ์กลับไม่ตรงกับเจตนาเพราะความกำกวม
• กระบวนการเรียนรู้ของมนุษย์: นักพัฒนาเรียนรู้บรรทัดฐานของบริษัทผ่านการแก้โค้ดช่วงแรก การรีวิว PR การประชุม และการคุยกันตามทางเดิน ขณะที่ AI ไม่สามารถสะสมความรู้โดยนัยแบบนี้ได้
• โค้ดเบสที่เสื่อมสภาพตามกาลเวลา: ในเวิร์กโฟลว์แบบดั้งเดิม นักพัฒนาอ่านและแก้โค้ดโดยไม่มีสเปก ทำให้มันกลายเป็น "ผ้าห่มเย็บปะติดปะต่อ (patchwork quilts)" ที่ไม่สอดคล้องกัน และการตัดสินใจด้านผลิตภัณฑ์ที่สูญหายไปก็ถูก "กลบฝัง (trammeling over)"

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

แนวทางแก้ที่เสนอ

โพสต์นี้เสนอแนวทางแก้ที่เชื่อมโยงกัน โดยเน้นการจัดการความกำกวม การสร้างบริบท และการผสานเข้ากับโค้ด:

เปิดใช้การทำคำชี้แจงให้ชัดผ่านการโต้ตอบ

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

สร้างโลกทัศน์ของเอเจนต์ผ่านสเปกแบบลำดับชั้น

• ใช้สเปกระดับโลกที่มีโครงสร้างแบบลำดับชั้นเพื่อให้เข้าใจบรรทัดฐานของบริษัทและโค้ดเบส แทนที่จะใช้เอกสารขนาดมหึมาเพียงฉบับเดียว ให้เชื่อมสเปกหลักไปยังเอกสารสเปกย่อย:
  • สเปกระดับไฟล์ (รวมถึงเวอร์ชัน rollup ระดับไดเรกทอรี) ที่ผูกกับโครงสร้างโค้ดอย่างเคร่งครัด
  • รูปแบบอิสระสไตล์วิกิ (แต่ต้องระวังความซับซ้อนที่มากเกินไป)
• ใช้ประโยชน์จากความสามารถของ AI ในการสำรวจลิงก์ (อ้างถึงโพสต์ก่อนหน้า)

บทบาทของโค้ดในฐานะสเปกสูงสุด

• มองโค้ดที่มีอยู่เป็นสเปกระดับ "leaf level" ที่ชัดเจนสำหรับสมมติฐานระดับล่าง แทนการพยายามสร้างทุกอย่างใหม่ทั้งหมดจากมาสเตอร์สเปก ให้มุ่งสู่การเปลี่ยนแปลงบนพื้นฐานของโค้ดเบสปัจจุบัน ยอมรับว่าภาษาธรรมชาติไม่สามารถรับประกันผลลัพธ์เดียวกันได้ทุกครั้ง และหลีกเลี่ยงการเรียกร้องความแม่นยำที่เป็นไปไม่ได้

สเปกที่มีชีวิต: การใช้งานและการพัฒนาไปพร้อมกัน

• ทำให้สเปกเป็น "เอกสารที่มีชีวิต" ซึ่งพัฒนาไปพร้อมกับโค้ดเบส:
  • AI สำรวจสเปกระดับโลกเพื่อให้การ implement สอดคล้องกัน และรักษาการตัดสินใจด้านผลิตภัณฑ์ได้ดีกว่าเวิร์กโฟลว์ของมนุษย์
  • นักพัฒนาสามารถดึงข้อมูลสเปกที่เกี่ยวข้องออกมาผ่านการคุยกับ AI ได้โดยไม่ต้องอ่านทั้งหมด และสามารถปักธงความไม่สอดคล้องได้ในขั้นกำหนดขอบเขตงาน
  • เมื่อโค้ดเปลี่ยน ให้ทริกเกอร์การอัปเดตสเปก: เปรียบเทียบและแก้ไขการเปลี่ยนแปลงกับสเปกเดิม และรวมการเปลี่ยนแปลงของสเปกไว้ใน PR
• ข้อดี: วิศวกรเข้าใจผลกระทบของการเปลี่ยนแปลงได้ง่ายขึ้น ผู้จัดการผลิตภัณฑ์มีส่วนร่วมมากขึ้นเพราะแก้ไขสเปกที่อ่านง่ายได้ และผู้บริหารสามารถสอบถามวิวัฒนาการของผลิตภัณฑ์ได้ AI จะช่วยทำงานอัตโนมัติในจุดที่เอกสารแบบดั้งเดิมมักไม่ถูกอัปเดต

บทสรุปและข้อเสนอแนะ

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

[raykim]

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