AI เขียนโค้ดเร็ว 3.4 เท่า แต่ทีมเข้าใจน้อยลง เจาะหนี้ 2 แบบก่อน Merge

บทนำ: เร็วขึ้นจริง แต่เข้าใจน้อยลงจริงหรือ

ถ้าคุณเป็นหัวหน้าทีม โปรแกรมเมอร์ หรือคนที่ต้องรีวิว Pull Request ในทีมไทย คุณอาจเคยรู้สึกแบบนี้ โค้ดมาเร็วมาก PR เต็มกระดาน งานที่เคยใช้เวลาหลายวันจบในไม่กี่ชั่วโมง แต่พอถึงตอนต้องแก้บั๊ก เปลี่ยนฟีเจอร์ หรือตอบคำถามว่า โค้ดส่วนนี้ทำงานอย่างไร กลับไม่มีใครตอบได้เต็มปาก

บทความนี้จะพาคุณเข้าใจภาพรวมทั้งหมดโดยไม่ต้องมีพื้นฐานเชิงวิชาการมาก่อน คุณจะได้รู้จักหนี้สองแบบที่มากับยุค AI Coding คือ Comprehension Debt หรือหนี้ความเข้าใจ และ Verification Debt หรือหนี้การตรวจสอบ จากนั้นจะเห็นว่าทำไม Vibe Coding ที่เน้นพิมพ์พรอมต์แล้วให้ AI สร้างโค้ดเลย จึงเสี่ยงในงานจริง และทำไม Spec-Driven Development ถึงเป็นทางออกที่หลายทีมเริ่มใช้ก่อนกด Merge

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

Vibe Coding คืออะไร และทำไมมันถึงติดง่าย

จากพิมพ์พรอมต์สู่โค้ดที่ใช้งานได้

Vibe Coding คือวิธีทำงานที่นักพัฒนาอธิบายสิ่งที่อยากได้ด้วยภาษาธรรมชาติ แล้วให้ AI สร้างโค้ดให้เกือบทั้งหมด คนเขียนอาจไม่ได้ออกแบบโครงสร้างเอง ไม่ได้เขียนโค้ดทีละบรรทัด และบางครั้งก็ไม่ได้อ่านโค้ดทั้งหมดก่อนนำไปใช้ วิธีนี้เหมาะมากกับการทำต้นแบบ ทดลองไอเดีย หรือสร้างงานเล็ก ๆ ที่พังได้โดยไม่เสียหายมาก

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

สัญญาณเตือนที่ทีมไทยเจอบ่อย

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

ถ้าทีมของคุณเจอ 2-3 ข้อจากรายการนี้พร้อมกัน แปลว่าปัญหาไม่ได้อยู่ที่ AI ไม่เก่ง แต่คือกระบวนการทำงานยังไม่ทันความเร็วของ AI

Comprehension Debt: หนี้ความเข้าใจ

นิยามแบบเข้าใจง่าย

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

แนวคิดนี้ถูกพูดถึงอย่างกว้างขวางโดย Addy Osmani วิศวกรจากทีม Claude Code ของ Anthropic โดยใจความสำคัญคือ การเขียนโค้ดด้วยตัวเองเคยทำให้เราได้แบบจำลองในหัวมาฟรี ๆ เรารู้ว่าโครงสร้างเป็นอย่างไร ข้อมูลไหลไปทางไหน และจุดเปราะบางอยู่ตรงไหน แต่เมื่อให้ AI เขียนแทน เราอาจได้โค้ดมาโดยไม่ได้สร้างแบบจำลองนั้นเลย

ทำไมหนี้ก้อนนี้ถึงอันตราย

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

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

ตัวอย่างในงานจริง

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

Verification Debt: หนี้การตรวจสอบ

นิยามแบบเข้าใจง่าย

Verification Debt คือหลักฐานการตรวจสอบที่เรายังไม่ได้ทำ แต่เรายอมรับงานนั้นเข้ามาก่อน เพราะมันดูสมเหตุสมผล เทสต์ผ่าน หรือเดโมดูดี แนวคิดนี้ถูกพูดถึงในวงกว้างหลังจาก Werner Vogels ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีของ Amazon หยิบยกขึ้นมาพูดถึงต้นทุนของการตรวจสอบผลลัพธ์จาก AI ที่ไม่เพียงพอ

พูดง่าย ๆ คือ Comprehension Debt ถามว่า เราเข้าใจโค้ดนี้ไหม ส่วน Verification Debt ถามว่า เราพิสูจน์แล้วหรือยังว่าโค้ดนี้ถูกต้องและปลอดภัยจริง

ความต่างที่ต้องแยกให้ออก

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

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

ทำไมเทสต์ผ่านแล้วยังไว้ใจไม่ได้

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

ตัวเลขความเร็วต้องอ่านอย่างไร ไม่ให้หลงทาง

งานวิจัยให้ภาพที่ไม่ตรงกัน

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

ส่วนงานวิจัยเชิงสนามขนาดใหญ่ที่วิเคราะห์ข้อมูลการทำงานของวิศวกรจำนวนมาก พบแนวโน้มว่า ปริมาณโค้ดและจำนวน Pull Request เพิ่มขึ้น แต่เวลารีวิวจนกว่าจะ Merge ก็เพิ่มขึ้นเช่นกัน นั่นแปลว่า ความเร็วในการสร้างโค้ดไม่ได้แปลงเป็นความเร็วในการส่งมอบงานที่พร้อมใช้งานเสมอไป คอขวดแค่ย้ายจากตอนเขียนโค้ด ไปอยู่ที่ตอนรีวิวและตรวจสอบแทน

วิธีอ่านตัวเลข 3.4 เท่าให้ถูกต้อง

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

คำถามที่ทีมควรใช้แทนการถามว่า AI เร็วแค่ไหน คือ

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

ถ้าทีมวัดแค่ความเร็วตอนสร้างโค้ด ทีมจะเห็นแต่ด้านที่สวยงาม แต่ถ้าวัดตั้งแต่สร้างจนถึงใช้งานจริง ทีมจะเห็นต้นทุนทั้งหมด

Spec-Driven คืออะไร และต่างจาก Vibe Coding อย่างไร

หลักการสำคัญ

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

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

ตารางเปรียบเทียบแบบเห็นภาพ

ประเด็น	Vibe Coding	Spec-Driven
จุดเริ่มต้น	พรอมต์สั้น ๆ	สเปกที่ระบุเป้าหมาย ขอบเขต และเกณฑ์สำเร็จ
สิ่งที่รีวิวได้	โค้ดที่เสร็จแล้ว	สเปก แผน และงานย่อยก่อนเริ่มเขียนโค้ด
การตัดสินใจ	AI เดาเองเมื่อสเปกไม่ชัด	มนุษย์ตัดสินใจเรื่องสำคัญก่อน
การตรวจสอบ	มักตรวจตอนท้าย	มีเกณฑ์ตรวจสอบตั้งแต่ต้น
เหมาะกับงาน	ต้นแบบ งานทดลอง งานเล็ก	ฟีเจอร์จริง งานที่กระทบเงิน ข้อมูล หรือสิทธิ์

Spec-Driven ไม่ได้แปลว่าห้ามใช้ AI หรือทำให้ช้าลงเสมอไป แต่มันย้ายการคิดไปไว้ตอนต้น เพื่อไม่ให้ทีมต้องมาเสียเวลาแก้โค้ดจำนวนมากตอนท้าย

สเปกที่ดีต้องมีอะไรบ้าง

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

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

ขั้นตอนเปลี่ยนทีมจาก Vibe Coding เป็น Spec-Driven ก่อนกด Merge

ขั้นที่ 1: แยกงานให้ชัดว่างานไหนใช้สเปก

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

ขั้นที่ 2: เขียนสเปกสั้นแต่ครบก่อนให้ AI เขียนโค้ด

ใช้เวลา 15-45 นาทีในการเขียนสเปกให้ชัดก่อนเริ่มงาน อย่าเขียนสเปกเป็นเรียงความยาว แต่เขียนเป็นหัวข้อสั้น ๆ ที่รีวิวได้ ถ้าทีมถกเถียงกันเรื่องสเปก นั่นคือสัญญาณที่ดี เพราะแปลว่าทีมกำลังแก้ความเข้าใจผิดตั้งแต่ตอนที่แก้ถูกที่สุด

ขั้นที่ 3: ให้ AI วางแผนและแตกงานย่อยก่อนลงมือ

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

ขั้นที่ 4: จำกัดขนาด Pull Request

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

ขั้นที่ 5: บังคับให้มีคำอธิบายที่พิสูจน์ความเข้าใจ

ก่อนกด Merge ผู้ส่ง PR ต้องตอบคำถามเหล่านี้ได้ด้วยภาษาของตัวเอง

• โค้ดนี้เปลี่ยนอะไร และทำไมถึงต้องเปลี่ยน
• ข้อมูลไหลจากจุดไหนไปจุดไหน
• กรณีขอบเขตที่เสี่ยงที่สุดคืออะไร และจัดการอย่างไร
• ถ้าต้องย้อนกลับ จะย้อนอย่างไร และกระทบผู้ใช้แค่ไหน
• มีเทสต์อะไรยืนยันกรณีสำคัญบ้าง

ถ้าตอบไม่ได้ อย่าเพิ่ง Merge ไม่ว่าจะรีบแค่ไหน เพราะการ Merge โค้ดที่ไม่มีใครเข้าใจคือการกู้หนี้ก้อนใหม่

ขั้นที่ 6: ตรวจสอบด้วยหลักฐาน ไม่ใช่ความรู้สึก

กำหนดรายการตรวจสอบก่อน Merge ให้เป็นมาตรฐานของทีม เช่น

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

การตรวจสอบแบบนี้ช่วยลด Verification Debt เพราะทีมไม่ได้เชื่อแค่คำว่า เทสต์ผ่าน แต่มีหลักฐานว่าเทสต์นั้นตรงกับความต้องการจริง

กฎ Merge ใหม่ที่ทีมไทยเริ่มใช้ได้ทันที

กฎ 1: ไม่มีสเปก ไม่มี Merge สำหรับงานเสี่ยง

งานที่กระทบเงิน ข้อมูล หรือสิทธิ์ ต้องมีสเปกสั้น ๆ แนบมากับ PR เสมอ สเปกไม่ต้องสมบูรณ์แบบ แต่ต้องพอให้คนอื่นเข้าใจว่า ทำไมถึงทำแบบนี้

กฎ 2: ผู้ส่ง PR ต้องอธิบายได้ ไม่ใช่แค่ส่งโค้ด

การรีวิวที่ดีไม่ใช่การดูว่าโค้ดสวยหรือไม่ แต่คือการถามว่า คนส่งเข้าใจโค้ดนี้จริงหรือเปล่า ถ้าต้องอธิบายให้เพื่อนร่วมทีมฟังใน 3 นาทีแล้วยังอธิบายไม่ได้ แปลว่ายังไม่พร้อม Merge

กฎ 3: PR ใหญ่ต้องแยกก่อน

ถ้า PR ใหญ่เกินกว่าจะอ่านให้เข้าใจในเวลาที่เหมาะสม ให้แยกออกเป็นส่วนเล็ก ๆ การแยก PR ไม่ใช่การทำให้ช้า แต่คือการทำให้รีวิวมีคุณภาพจริง

กฎ 4: เทสต์ต้องมาจากความต้องการ ไม่ใช่มาจากโค้ด

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

กฎ 5: มีเจ้าของโค้ดทุกส่วน

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

ข้อควรระวัง: อย่าเปลี่ยน Spec-Driven ให้กลายเป็นเอกสารที่ไม่มีใครอ่าน

Spec-Driven จะล้มเหลวถ้าทีมเขียนสเปกยาวเกินไปจนไม่มีใครอ่าน หรือเขียนสเปกแล้วไม่ยอมปรับเมื่อเรียนรู้สิ่งใหม่ สเปกที่ดีคือเอกสารที่มีชีวิต เปลี่ยนได้เมื่อความเข้าใจเปลี่ยน แต่ต้องเปลี่ยนอย่างมีเหตุผลและมีร่องรอยให้ตรวจสอบได้

ข้อควรระวังอื่น ๆ ได้แก่

• อย่าให้ AI เขียนสเปกทั้งหมดโดยไม่มีมนุษย์ตรวจสอบ เพราะ AI อาจสร้างข้อกำหนดที่ดูดีแต่ไม่ตรงกับธุรกิจจริง
• อย่าวัดความสำเร็จจากจำนวนสเปก แต่วัดจากจำนวนงานที่ Merge แล้วทีมยังเข้าใจและดูแลได้
• อย่าใช้ Spec-Driven เป็นข้ออ้างในการทำงานช้าลงโดยไม่จำเป็น งานเล็กที่ไม่เสี่ยงยังใช้วิธีเบา ๆ ได้
• อย่าลืมว่าความเข้าใจของทีมสำคัญกว่าความสมบูรณ์ของเอกสาร

เป้าหมายไม่ใช่การมีเอกสารสวย แต่คือการมีทีมที่เข้าใจระบบของตัวเอง

สรุป: ความเร็วที่แท้จริงวัดตอนดูแล ไม่ใช่ตอนสร้าง

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

ทางออกไม่ใช่การเลิกใช้ AI แต่คือการเปลี่ยนวิธีใช้ จาก Vibe Coding ที่เน้นให้ AI สร้างโค้ดเลย ไปเป็น Spec-Driven ที่เริ่มจากข้อกำหนดชัด ๆ แผนที่รีวิวได้ PR เล็กพอที่จะเข้าใจ และกฎ Merge ที่บังคับให้มีหลักฐานก่อนปล่อยงาน

ถ้าทีมไทยเริ่มจากสิ่งเล็ก ๆ ได้ในสัปดาห์นี้ ให้เริ่มจาก 3 อย่างนี้ก่อน คือ เขียนสเปกสั้น ๆ สำหรับงานเสี่ยงหนึ่งงาน แยก PR ใหญ่ให้เล็กลง และถามคำถาม 5 ข้อก่อนกด Merge ทุกครั้ง เมื่อทีมทำได้สม่ำเสมอ ทีมจะไม่ได้แค่เร็วขึ้น แต่จะเร็วแบบที่ดูแลต่อได้จริง

แหล่งข้อมูลอ้างอิง

• GitHub Spec Kit: Spec-Driven Development - ชุดเครื่องมือโอเพนซอร์สสำหรับ Spec-Driven Development ตั้งแต่การเขียนสเปก วางแผน แตกงานย่อย จนถึงการลงมือทำ
• GitHub Spec Kit Documentation - เอกสารอธิบายขั้นตอน Specify, Plan, Tasks, Implement และ Converge
• METR: Measuring AI Ability to Complete Long Tasks - งานวิจัยและรายงานเกี่ยวกับการประเมินความสามารถของ AI ในการทำงานจริง ซึ่งชี้ให้เห็นว่าผลลัพธ์ด้านความเร็วขึ้นอยู่กับงานและบริบทอย่างมาก