AI coding agents คืออะไร และทำไมการส่งมอบซอฟต์แวร์ถึงช้าลง
AI coding agents คือระบบปัญญาประดิษฐ์ที่รับเป้าหมายการพัฒนาเช่นแก้บั๊กหรือเพิ่มฟีเจอร์แล้ววางแผน รันเทสต์ อ่านไฟล์ แก้โค้ด และสร้าง pull request ให้เสร็จในขั้นตอนเดียวโดยไม่ต้องให้มนุษย์กดอนุมัติทุกสเต็ประหว่างทาง การเปลี่ยนจากเครื่องมือช่วยเติมโค้ดมาเป็นเอเจนต์ที่แตะทั้ง toolchain ทำให้ความเร็วในขั้นการเขียนโค้ดเพิ่มขึ้นมาก แต่กลับผลักภาระไปกองที่ขั้นรีวิว ทดสอบ และตัดสินใจปล่อยขึ้น production เพราะทีมยังใช้กระบวนการเดิมกับเครื่องมือคนละยุค ผลคือภาพลวงตาเรื่องความเร็วส่วนบุคคลแต่การส่งมอบจริงทั้งระบบกลับช้าลง และคอขวดใหม่เกิดในที่ที่ผู้บริหารวิศวกรรมไม่ค่อยวัด
วันนี้มี pull request แบบใหม่เกิดขึ้นจริง สาขาฟีเจอร์เปิด เทสต์อัตโนมัติรัน จากนั้นบ็อตลงมือเขียนโค้ด มนุษย์แค่คลิกอนุมัติแล้วโค้ดก็ถูกส่งขึ้นโปรดักชัน โดยคนไม่ได้พิมพ์แม้แต่บรรทัดเดียวของ diff ตามรายงาน Octoverse นักพัฒนาใช้ Copilot coding agent สร้าง pull request กว่า 1 ล้านครั้งระหว่างเดือนพฤษภาคมถึงกันยายน และทั้งปีมีการ merge pull request บนแพลตฟอร์มถึง 518.7 ล้านครั้ง เพิ่มขึ้น 29 เปอร์เซ็นต์จากปีก่อน โครงสร้างวิธีเขียนซอฟต์แวร์จึงเปลี่ยนไปแล้ว แต่หลายองค์กรยังวัดผลงานด้วยความเร็วการเขียนโค้ดเหมือนเดิม นี่คือจุดเริ่มต้นของคอขวดใหม่ใน software delivery bottleneck
เร็วขึ้นเฉพาะตอนเขียน แต่ช้าลงทั้งระบบ เมื่อคอขวดย้ายไปรีวิวและดีบัก
ประเด็นที่ทำให้หลายทีมหลงทางคือการโฟกัสที่ความเร็วการเขียนโค้ดแบบแยกส่วน ในทางปฏิบัติ AI coding agents ลด time-to-code อย่างชัดเจน แต่สิ่งที่เพิ่มขึ้นคือปริมาณงานที่ทะลักไปยังขั้นถัดไป ไม่ว่าจะเป็น human review การดีบัก เทสต์เชิงลึก หรือการตัดสินใจปล่อยขึ้นโปรดักชัน AI made the coding stage faster It raises the arrival rate at whatever stage comes next และสำหรับทีมส่วนใหญ่ ขั้นถัดไปนั้นคือ human review เมื่อเราเร่งขั้นที่ไม่ใช่คอขวด เราไม่ได้ทำให้ระบบเร็วขึ้น เราแค่สร้างคิวที่ยาวขึ้นตามหลักคิวอิงทฤษฎีที่รู้มานานแล้ว
งานศึกษากับนักพัฒนาโอเพนซอร์สที่มีประสบการณ์พบว่าพวกเขาทำงานช้าลงราว 19 เปอร์เซ็นต์เมื่ิอใช้ AI บนโค้ดเบสที่คุ้นเคย ทั้งที่ก่อนทดลองคาดว่าจะเร็วขึ้น 24 เปอร์เซ็นต์ และหลังจบงานยังรู้สึกว่าตัวเองเร็วขึ้นประมาณ 20 เปอร์เซ็นต์ ช่องว่างระหว่างความรู้สึกและตัวเลขจริงสะท้อนว่าภาระที่หนักขึ้นไม่ใช่การพิมพ์ แต่คือการตรวจสอบและวาลิเดตผลลัพธ์ โค้ดจาก AI มักจะ “เกือบถูกแต่ไม่ถึง” ทำให้ผ่านการมองผ่านตาแบบผิวเผินแล้วไปสร้างบั๊กแพงในขั้นดีบักและเทสต์ downsteam software delivery bottleneck จึงไม่ได้เกิดจาก AI โดยตรง แต่มาจากการเร่งผิดขั้นในกระบวนการส่งมอบ
AI coding agents production กับความเสี่ยงด้าน code quality และ AI generated code safety
การปล่อยโค้ดจาก AI coding agents production โดยใช้เกณฑ์เดิมแบบยุคคนเขียนทุกบรรทัดคือการเล่นเกมเสี่ยงสูง โดยเฉพาะเมื่อทีมใช้เพียงเทสต์อัตโนมัติพื้นฐานเป็นด่านเดียวของ code quality testing gates แม้เทสต์ที่ผ่านจะเป็นเงื่อนไขเบื้องต้นที่ห้ามละเลย แต่ก็ไม่เคยเพียงพออยู่แล้ว และในยุค agentic tooling ช่องว่างระหว่าง “เทสต์ผ่าน” กับ “มนุษย์จะยอมรับให้ขึ้นโปรดักชัน” ยิ่งกว้างและอันตรายกว่าตอนมีแต่คนเขียนโค้ด ผลคือโค้ดคุณภาพปานกลางจำนวนมากทะลุเข้าคิวรีวิว เพิ่ม code churn และกดดันทีมทดสอบอย่างหนัก
ข้อมูลล่าสุดแสดงให้เห็นว่าการใช้ AI ทำให้เวลารีวิวยืดออก โค้ด churn จากประมาณ 3 เปอร์เซ็นต์ขึ้นไปใกล้ 6 เปอร์เซ็นต์ และโค้ดที่ AI สร้างมีช่องโหว่ด้านความปลอดภัยมากขึ้นอย่างมีนัย โดยหนึ่งการวิเคราะห์พบอัตราช่องโหว่สูงเกือบสามเท่า AI generated code safety จึงไม่ใช่เรื่องความกลัวแบบเลื่อนลอย แต่เป็นความเสี่ยงจริงที่ต้องวัดและควบคุม เครื่องมือ static analysis และการสแกน dependency ยังจำเป็นเพราะเอเจนต์มีพฤติกรรมใหม่อย่าง dependency hallucination อ้างแพ็กเกจที่ไม่มีตัวตน ซึ่งเปิดทางให้ผู้ไม่หวังดีจดทะเบียนแพ็กเกจนั้นแบบมุ่งร้ายได้โดยตรง ถ้าไม่มี testing gates และมาตรการความปลอดภัยที่เข้มงวด การปล่อยโค้ดจาก AI เข้าสู่โปรดักชันคือการเพิ่มโอกาสผิดพลาดในระดับระบบ
ทำไมผู้นำวิศวกรรมต้องเลิกวัดความเร็วการเขียน และหันไปวัดความน่าเชื่อถือการส่งมอบ
การวัดเฉพาะ coding velocity กลายเป็นดัชนีที่หลอกให้ผู้บริหารชะล่าใจ เพราะมันบอกเพียงความเร็วในหนึ่งขั้น ไม่ได้บอกว่าระบบทั้งหมดเคลื่อนงานไปถึงคำว่า done เร็วขึ้นแค่ไหน Deployment frequency และความเร็วการเขียนเป็น local optimizations มันไม่มีทางตอบคำถามว่าทั้งระบบส่งมอบซอฟต์แวร์ได้ดีขึ้นหรือแย่ลง สิ่งที่ควรดูคือ flow efficiency และ change failure rate ของงานที่ใช้ AI โดยเฉพาะ การแยก telemetry สำหรับโค้ดที่ AI ช่วยเขียนทำให้เราเห็นต้นทุนข้อบกพร่องจริงก่อนมันระเบิดในโปรดักชันอีกหลายเดือน
ข้อเท็จจริงที่ตรงไปตรงมาคือ AI ทำให้ส่วนที่ถูกลงอยู่แล้วถูกลงไปอีก นั่นคือการพิมพ์โค้ด ขณะที่มูลค่าและความเสี่ยงย้ายไปอยู่ที่สองส่วนที่ยากที่สุดเสมอมา คือการตัดสินใจว่าจะสร้างอะไร และการตรวจสอบว่าของที่สร้างขึ้นถูกต้องหรือไม่ เมื่อการ implement กลายเป็นงานเร็ว ทีมไม่สามารถพึ่ง “ความช้า” เพื่อซ่อนความคลุมเครือของ requirement ได้อีก ความผิดพลาดด้านสเปกจะวิ่งเข้าผลิตภัณฑ์อย่างรวดเร็ว ดังนั้นผู้นำวิศวกรรมที่ยังตั้งโบนัสจากจำนวนบรรทัดโค้ดหรือจำนวน ticket ที่ปิดได้กำลังให้รางวัลกับการสร้างคิวในคอขวดใหม่ แทนที่จะให้รางวัลกับ delivery reliability และ code quality ซึ่งเป็นตัวชี้วัดที่สะท้อนความสำเร็จระดับองค์กรจริง
ออกแบบ human gates และ approval workflow แบบไดนามิก เพื่อให้ AI เป็นตัวช่วยไม่ใช่ตัวสร้างบั๊ก
คำตอบไม่ใช่การหยุดใช้ AI แต่คือการเปลี่ยนวิธีผูกมันเข้ากับ workflow การพัฒนา Dynamic approval workflows และ human gates คือหัวใจของการทำให้ AI coding agents production ปลอดภัย มนุษย์ต้องรีวิวก่อน merge เสมอ ไม่ใช่เพราะไม่ไว้ใจโมเดลตัวใดตัวหนึ่ง แต่เพราะเราควรรีวิวทุก contributor ใหม่ไม่ว่าจะเป็นคนหรือเอเจนต์ และเอเจนต์ก็มีลักษณะเหมือนนักพัฒนาคนใหม่ที่เร็วมากและไม่สม่ำเสมอ การให้สิทธิ์แบบ scoped permissions ผ่านระบบ credential จึงจำเป็น เอเจนต์ควรเขียนได้แค่บน branch งานของตัวเอง ไม่ควรแตะ infra โปรดักชัน ซีเคร็ต หรือ repo อื่นใด
ในทางปฏิบัติทีมควรตั้ง testing gates ให้โค้ดจาก AI เข้มกว่าโค้ดจากคนในบางกรณี ทั้งเทสต์เชิงหน่วย เทสต์เชิงระบบ และการสแกนความปลอดภัย ต้องถูกยกเป็นสถานะ check บังคับใน CI ไม่ใช่คำขอสุภาพใน document นอกจากนี้การออกแบบ approval workflow ให้ไดนามิกตามความเสี่ยงของแต่ละเปลี่ยนแปลงช่วยให้ทีมไม่จมอยู่กับคิวรีวิวอย่างไร้ทิศทาง งานที่ซับซ้อนหรือแตะส่วนสำคัญของระบบควรมี reviewer ที่มีบริบทลึก ส่วนงานเล็กหรือ refactor ที่ผ่านเทสต์เข้มงวดอาจใช้ reviewer ชั้นกลางได้ แนวโน้มของทีมที่ประสบความสำเร็จคือการสอนให้เด็กรุ่นใหม่มีทักษะรีวิวก่อนฝึกให้ใช้ AI เขียน และให้รุ่นพี่ใช้อุปกรณ์ AI ในระดับสถาปัตยกรรม ซึ่งวิจารณญาณของพวกเขาจะดักข้อผิดพลาดได้ตั้งแต่ต้น สุดท้ายองค์กรที่กล้าเปลี่ยนวิธีวัดผลและตั้ง human gate อย่างมีสติคือองค์กรที่จะทำให้ AI เป็นตัวเร่งนวัตกรรม ไม่ใช่ตัวเร่งเหตุ production incident
