AI เร่งการเขียนโค้ด แต่ไม่ได้เร่งระบบส่งมอบซอฟต์แวร์
หัวข้อ AI Speeds Up Coding But Slows Down Delivery คือการอธิบายปรากฏการณ์ที่เครื่องมือ AI ช่วยเขียนโค้ดทำให้ขั้นตอนการพัฒนาเร็วขึ้น แต่ความเร็วนี้กลับผลักคอขวดไปอยู่ในช่วงรีวิว ทดสอบ และดีพลอย ส่งผลให้วงจรส่งมอบซอฟต์แวร์โดยรวมอาจช้าลงหรือเต็มไปด้วยบั๊กและช่องโหว่ด้านความปลอดภัย แนวคิดนี้เน้นให้ผู้นำวิศวกรรมเปลี่ยนจากการวัดเพียงความเร็วในการเขียนโค้ด ไปสู่การวัดคุณภาพและประสิทธิภาพของการส่งมอบตั้งแต่ต้นน้ำถึงปลายน้ำ สิ่งที่เห็นชัดคือรูปแบบการเขียนซอฟต์แวร์เปลี่ยนไปอย่างเป็นโครงสร้าง เมื่อมีเอเจนต์ AI ที่สามารถวางแผนงานหลายขั้นตอนแล้วสร้าง pull request สำเร็จรูปได้มากกว่าหนึ่งล้านครั้งในช่วงเดือนพฤษภาคมถึงกันยายนปี 2025 แต่ในทีมจำนวนมากนโยบายและการกำกับดูแลยังยึดกับโลกเก่า ทำให้รู้สึกว่าเร็วขึ้นในระดับบุคคล แต่ระบบโดยรวมกลับติดค้างที่ขั้นรีวิวและทดสอบ ตัวเลขจากงานศึกษาที่ตามมาบอกเล่าเรื่องนี้ชัดเจน การเขียนโค้ดอาจดีขึ้น 30–40 เปอร์เซ็นต์ หากขั้นวางแผน การทดสอบ และการปล่อยยังทำด้วยมือ ผลผลิตรวมของทีมกลับเพิ่มไม่ถึง 10 เปอร์เซ็นต์ ดังนั้นคำถามสำคัญไม่ใช่ “เราเขียนโค้ดเร็วแค่ไหน” แต่คือ “คอขวดของระบบอยู่ตรงไหน และ AI ขยับมันไปที่ใด”
คุณภาพโค้ดจาก AI และคอขวดใหม่ในรีวิว ทดสอบ ดีพลอย
ทีมที่กระโดดใช้ AI coding tools ส่วนใหญ่สัมผัสเหมือนกัน การเขียนฟีเจอร์ใช้เวลาแค่ครึ่งวัน แต่การไล่จับบั๊กกินเวลาไปอีกหลายวัน เพราะคุณภาพโค้ดจาก AI ยัง “เกือบดีแต่ไม่ดีพอ” ซึ่งเป็นความผิดแบบแพงที่สุดเพราะมักรอดผ่านรีวิวแบบผ่านตา งานวิเคราะห์ล่าสุดพบว่าขณะที่เวลารีวิวเริ่มยืดออก อัตรา code churn ขยับจากประมาณ 3 เปอร์เซ็นต์ไปใกล้ 6 เปอร์เซ็นต์ และโค้ดที่สร้างโดย AI มีช่องโหว่ด้านความปลอดภัยมากขึ้นเกือบสามเท่าเมื่อเทียบกับโค้ดของมนุษย์ แปลว่าความเร็วช่วงเขียนโค้ดกำลังถูกชดเชยด้วยรอบแก้ไขที่ตามมาและเหตุการณ์ในโปรดักชัน นอกจากนี้ยังมีหลักฐานว่าคุณภาพโค้ด AI ที่ผ่านชุดทดสอบอัตโนมัติอย่าง SWE-bench Verified ไม่ได้หมายความว่าพร้อมรวมเข้าซอร์สจริง ผู้ดูแลโปรเจกต์โอเพนซอร์สใหญ่สามโครงการรีวิว pull request ที่ผ่านเทสแล้ว 296 ชุด และพบว่าราวครึ่งหนึ่งไม่อยู่ในระดับที่ควร merge เข้าซอร์ส นี่สะท้อนว่าการวัดคุณภาพจากการผ่านเทสอย่างเดียวยังไม่พอสำหรับ AI code generation quality
จาก OpenSpec สู่ AIDLC ทำไมเวิร์กโฟลว์แบบไดนามิกจึงสำคัญ
เมื่อทีมหนึ่งทดลองใช้เฟรมเวิร์ก Spec Driven Development และ OpenSpec เพื่อคุมคุณภาพโค้ดจาก AI พบว่ามันพอใช้ได้กับโปรเจกต์เล็ก แต่พอโครงการใหญ่ขึ้นหลายปีและมีหลายทีมร่วมงาน ความซับซ้อนของคำสั่งและเวิร์กโฟลว์ทำให้ทุกคนใช้เครื่องมือต่างกัน บางคนถึงขั้นแค่เปิดใช้ตอนต้นแล้วกลับไปเขียนโค้ดแบบตามความรู้สึกในภายหลัง สิ่งที่ขาดหายคือเวิร์กโฟลว์ที่เก็บเจตนาเดิมของผู้เขียนสเปก และออกแบบให้การร่วมมือของทีมเกิดขึ้นในทุกเฟสไม่ใช่เฉพาะตอนสุดท้าย นั่นคือเหตุผลที่เวิร์กโฟลว์ AIDLC ถูกนำมาแทน โดยใช้กระบวนการพัฒนาซอฟต์แวร์ละเอียดขึ้นและเน้นการทำงานร่วมกัน ทำให้คุณภาพโค้ดกระโดดดีขึ้นอย่างชัดเจนหลังปรับใช้มากกว่าหนึ่งเดือน AIDLC เพิ่มสองความสามารถสำคัญคือ dynamic workflows และ dynamic team collaboration เช่น การส่งเอกสารแต่ละเฟสให้เพื่อนร่วมทีมอนุมัติก่อนขยับไปขั้นต่อไป ซึ่งสอดคล้องกับข่าวแนวปฏิบัติขององค์กรใหญ่ที่กำหนดให้โค้ดของวิศวกรระดับจูเนียร์และมิดต้องผ่านการรีวิวและอนุมัติโดยคนอื่นในทีมเสมอ นี่คือแกนของ AI governance workflow ที่ช่วยให้ทีมดึงความเร็วกลับมาโดยไม่ทิ้งคุณภาพ
| Spec | AIDLC | เวิร์กโฟลว์เดิม |
|---|---|---|
| การเก็บเจตนา | เก็บบทสนทนาและข้อกำหนดตลอดเฟส | สเปกกระจัดกระจาย เจตนาเดิมหายไปง่าย |
| การร่วมมือทีม | มีจุดอนุมัติแบบไดนามิกหลายระดับ | มักรีวิวเฉพาะตอนปลายทาง |
| ผลต่อคุณภาพโค้ด | คุณภาพดีขึ้นชัดหลังปรับใช้เดือนแรก | โค้ดหยาบ ต้องไล่บั๊กหลายวัน |
ส่งโค้ด AI อย่างปลอดภัย ต้องมากกว่าคอมไพล์ให้ผ่าน
การปล่อยให้เอเจนต์ AI แก้ไฟล์ รันเทส และเปิด pull request เองโดยหวังแค่ “รีวิว diff ให้ดี” เป็นกลยุทธ์กำกับดูแลที่ไม่พออีกต่อไป เพราะเราไม่ได้รีวิวแค่คำแนะนำ แต่รีวิวผลของกระบวนการอัตโนมัติหลายขั้นที่เราไม่ได้เห็น แนวทางที่ปลอดภัยต้องมี verification ที่ชัดเจน เช่น ใช้ชุดทดสอบอัตโนมัติเป็น merge gate แบบห้ามข้าม ต้องผ่านทั้งเทสเดิมและเทสใหม่สำหรับพฤติกรรมที่เพิ่ม รวมถึงรัน static analysis และการสแกนช่องโหว่ไลบรารีเช่นเดียวกับโค้ดมนุษย์ สำคัญไม่แพ้กันคือการรีวิวโดยมนุษย์ก่อน merge เสมอ เพราะในเชิงฟังก์ชัน เอเจนต์ AI ก็เหมือน contributor ใหม่ที่เร็วแต่ไม่คงเส้นคงวา ต้องมีคนดูงานก่อนให้สิทธิส่งโค้ดเข้าซอร์ส นอกจากนี้ การจำกัดสิทธิ์การเข้าถึงระบบ เช่น IAM และการจำกัดโทเคน เป็นด่านความปลอดภัยจริง ไม่สามารถหวังให้คำสั่งใน prompt แทน boundary ด้านความมั่นคงได้ เมื่อรวมเข้ากับเวิร์กโฟลว์อนุมัติแบบ AIDLC ทีมจึงสามารถเพิ่มความเร็วของ AI โดยรักษามาตรฐานคุณภาพและความปลอดภัยพร้อมกัน
ผู้นำวิศวกรรมควรเลิกหมกมุ่นกับความเร็วการเขียนโค้ด
เมื่อ AI ทำให้ขั้นตอน coding เร็วขึ้นมาก เรามักถูกล่อให้รายงานตัวเลข productivity ของนักพัฒนาแต่ละคนและ deployment frequency ว่าเป็นชัยชนะ แต่ตัวเลขเหล่านี้เป็นแค่การปรับให้ดีในขั้นตอนเดียว ไม่ได้บอกเลยว่าระบบโดยรวมส่งงานไปถึง “เสร็จจริง” เร็วขึ้นหรือไม่ สิ่งที่ผู้นำวิศวกรรมควรหันไปวัดคือ flow efficiency ของทั้งสายงานตั้งแต่เก็บ requirement เขียนโค้ด รีวิว ทดสอบ ไปจนถึงดีพลอย และควรแยก telemetry change failure rate สำหรับงานที่ใช้ AI ออกจากงานธรรมดา เพื่อเห็นต้นทุน defect จริงก่อนมันระเบิดในโปรดักชันหลังผ่านไปหลายสิบวัน ในทางปฏิบัติ ตัวชี้วัดที่น่าให้ความสำคัญคือเวลารวมของวงจรส่งมอบ การยืดของคิวรีวิว และจำนวน incident ในโปรดักชัน มากกว่าจำนวน pull request หรือความเร็วการเขียนโค้ด ในโลกที่ AI เพิ่ม arrival rate เข้าสู่ขั้นต่อไป การมองภาพระบบทั้งเส้นและคอขวดใหม่คือเงื่อนไขเดียวที่จะทำให้ AI code generation quality แปลเป็นคุณค่าจริงให้ผู้ใช้ ไม่ใช่แค่สถิติสวยหรูบนสไลด์ “Coding might improve 30 to 40%, but if planning, testing, and release stay manual, overall throughput often rises less than 10%” เป็นคำเตือนที่ควรถูกแปะไว้บนแดชบอร์ดทุกทีม
