หัวใจของปัญหา: ตรวจสอบโค้ด AI ที่อยู่ในวงจรปิดเดียวกัน
การตรวจสอบโค้ด AI คือกระบวนการที่ใช้เครื่องมืออัตโนมัติและโมเดลภาษาเพื่อตรวจทานโค้ดที่สร้างโดย AI แทนมนุษย์ โดยมักผูกเข้ากับการตรวจสอบอัตโนมัติและ Pull request workflow เพื่อเร่งการส่งมอบซอฟต์แวร์ แต่เมื่อโค้ดและรีวิวมาจากตระกูลโมเดลเดียวกัน ช่องโหว่เชิงตรรกะและความเข้าใจบริบทเดียวกันจะถูกทำซ้ำ จนเกิด “วงจรปิด” ที่ดูเหมือนปลอดภัยแต่ซ่อนความเสี่ยงไว้ใต้พื้นผิว ตั้งแต่บั๊กที่ผ่าน CI ไปถึงโปรดักชัน ไปจนถึงการทดสอบที่ช้ากว่าความเร็วการสร้างโค้ดอย่างมีนัยสำคัญ.
เครื่องมือ ตรวจสอบโค้ด AI เช่นตัวช่วยรีวิวที่อ่าน Pull request ทั้งชุดและรันกับ CI ช่วยลดเวลารอมนุษย์ได้จริง. แต่ตัวเลขจากรายงานหลายชุดชี้ว่าการนำ AI เข้ามาไม่ได้ลดความไม่เสถียรของการดีพลอย กลับทำให้ความเร็วและความเสี่ยงเพิ่มขึ้นพร้อมกัน นี่คือสัญญาณชัดเจนว่าการเพิ่มความเร็วให้ “ประตูรีวิว” อย่างเดียวไม่พอ ถ้าเราไม่เปลี่ยนวิธีคิดเรื่องคุณภาพโค้ดและโครงสร้างการตรวจสอบอัตโนมัติ เรากำลังสร้างระบบที่เร็วแต่เปราะบางโดยออกแบบเอง.
AI blind spots: เมื่อผู้เขียนและผู้รีวิวคิดแบบเดียวกัน
ปัญหาใหญ่ของการให้ AI ตรวจสอบโค้ด AI คือ AI blind spots หรือจุดบอดเชิงตรรกะที่ถูกฝึกมาเหมือนกันในทั้งผู้เขียนและผู้รีวิว เมื่อมีการทดสอบให้โมเดลตระกูลเดียวกันรีวิวโค้ดที่ตัวเองสร้าง พบว่ามันพกจุดบอดชุดเดิมไปทั้งสองบทบาท ทำให้รีวิวกลายเป็นการตรวจโค้ดกับ “ความเห็นของโมเดลต่อผลงานของตัวเอง” มากกว่าการตรวจกับความตั้งใจดั้งเดิมของระบบ. ผลคือแพทเทิร์นบั๊กบางแบบถูกมองข้ามซ้ำแล้วซ้ำเล่า.
ที่น่ากังวลคือวงจรตรวจสอบโค้ดแบบนี้มีลักษณะ “วงกลม” อย่างชัดเจน เมื่อทั้งโค้ด เทสต์ และรีวิวถูกสร้างจากฐานความรู้และอคติเดียวกัน การตรวจสอบอัตโนมัติที่ตั้งใจให้เป็นเกราะป้องกัน กลายเป็นการตอกย้ำข้อผิดพลาดเดิม ๆ แทน ตามหลักฐานเชิงโครงสร้าง การยืนยันคุณภาพที่ประกอบจาก AI อย่างเดียวมีแนวโน้มคงอยู่ในวงจรปิดของตัวเอง.
กรณีศึกษา Rootly: ทิ้งกฎ PR เล็ก แล้วย้ายไปคิดที่ blast radius
เมื่อ AI สร้างโค้ดเป็นฟีเจอร์ครบชุด กฎ Pull request workflow แบบเดิมเริ่มไม่เข้าท่า Rootly ตัดสินใจเลิกกฎ “PR ต้องเล็ก” ที่ใช้มานาน เพราะไม่ตอบโจทย์เมื่อส่วนใหญ่ของโค้ดถูกสร้างโดยเอเจนต์ AI แล้ว. เดิมทีการจำกัดขนาด diff เหมาะกับยุคที่มนุษย์เขียนโค้ดทีละชิ้น เล็กลงก็รีวิวง่าย ย้อนกลับง่าย แต่เมื่อ AI คิดเป็นฟีเจอร์ การบังคับแบ่ง PR ให้เล็กกลับสร้างความสับสน ทั้งคอมเมนต์ที่ข้ามไฟล์และ PR หลายชุดที่ต้องเปิดเทียบกัน.
Rootly จึงหยุดรีวิวโค้ด AI แบบเดียวกับโค้ดมนุษย์ แล้วสร้าง AI code reviewer ภายในองค์กร ที่รีวิวทุก PR เทียบกับมาตรฐานวิศวกรรมและให้คะแนนความเสี่ยง ความสอดคล้อง และความเชื่อมั่น พร้อมจัดกลุ่มข้อค้นพบตามระดับความรุนแรง. ที่สำคัญ เครื่องมือนี้ตอบคำถามเดียวคือ “ถ้า PR นี้มีบั๊ก พฤติกรรมที่ผู้ใช้เห็นจะเสียอะไร” และย้ายจุดปลอดภัยจากตอน merge ไปที่การ rollout แบบมี feature flag ทำให้ขนาด diff ไม่ใช่สัญญาณสำคัญอีกต่อไป สิ่งที่นับคือ blast radius หรือวงผลกระทบของการเปลี่ยนแปลง.
ออกแบบ Pull request workflow ใหม่ในยุค agent speed
เมื่อ AI agent เข้ามาอยู่กลางทุกขั้นของการพัฒนา ซอฟต์แวร์เริ่มเดินที่ “agent speed” มากกว่าความเร็วมนุษย์ วงการจึงเริ่มตั้งคำถามกับ Pull request workflow เดิม ๆ ว่ามีต้นทุนสูงเกินไปหรือไม่ มีการถกกันอย่างจริงจังว่าการใช้ PR เป็นเกตหลักภายในองค์กรอาจกลายเป็น anti-pattern เมื่อทุกคนในทีมมีบริบทใกล้เคียงกันแต่ต้องรอรอบรีวิวที่กินเวลา. แนวโน้มใหม่คือให้การตรวจสอบอัตโนมัติคัดกรองเปลี่ยนแปลงเสี่ยงต่ำผ่าน CI ไปก่อน แล้วเก็บแรงมนุษย์ไว้กับเคสที่ข้ามเกณฑ์ที่กำหนด.
อย่างไรก็ตาม การเร่งประตูรีวิวให้เร็วขึ้นโดยไม่เปลี่ยนโครงสร้างการยืนยันความถูกต้องยังไม่พอ เพราะตัวเลขหลายชุดชี้ว่าการใช้ AI มากขึ้นทำให้ throughput และความไม่เสถียรของการดีพลอยเพิ่มขึ้นพร้อมกัน. นั่นหมายถึงทีมต้องออกแบบ Pull request workflow ใหม่ให้แยกบทบาทชัดเจน: ชั้น deterministic สำหรับการตรวจเชิงกลไก, ชั้นตรวจสอบโค้ด AI เพื่อจับประเด็นเชิง judgement และชั้น human oversight ที่โฟกัสกับประเด็นบริบทและผลกระทบธุรกิจ ไม่ใช่ให้ทุกอย่างรวมตัวอยู่ใน PR เดียวแล้วหวังว่าผู้รีวิวจะมองทันทั้งหมด.
สร้างระบบความเชื่อใจใหม่: deterministic, มนุษย์ และ AI อยู่คนละชั้น
ประเด็นสำคัญที่สุดไม่ใช่ “ใช้ AI หรือไม่” แต่คือเราวาง AI ไว้ตรงไหนในสายการตรวจสอบคุณภาพโค้ด หากปล่อยให้การตรวจสอบโค้ด AI ทั้งหมดเกิดจาก AI เอง วงจรตรวจสอบจะยังคงเป็นวงปิดและเสี่ยงทวนซ้ำจุดบอดเดิม ๆ. สิ่งที่ขาดหายคือจุดอ้างอิงภายนอก ไม่ว่าจะเป็นสเปกเขียนชัด ๆ หรือเครื่องมือ deterministic ที่ไม่เดา แต่คำนวณคุณสมบัติของโค้ดอย่างตรงไปตรงมา และไม่แชร์ชุดการฝึกกับโมเดล.
สถาปัตยกรรมที่เริ่มชัดขึ้นคือ “หลายชั้น หลายบทบาท”: สเปกกำหนดเจตนารมณ์, pipeline deterministic ตรวจโครงสร้างและคุณสมบัติที่วัดได้, AI ใช้สำหรับ judgement call ที่เหลือ, และมนุษย์คอยดูภาพรวมและบริบท. การตรวจสอบโค้ด AI จึงควรออกแบบให้การตรวจสอบอัตโนมัติเป็นชั้นฐานที่เชื่อถือได้ แล้วเสริมด้วย human oversight ที่ไม่ถูกฮิญักไปกับจังหวะของเครื่องมือ การเชื่อใจระบบในยุคที่ทั้งผู้เขียนและผู้รีวิวเป็น AI จึงไม่ใช่การเพิ่มความเร็วรีวิว แต่คือการออกแบบวงจรความเชื่อใจใหม่ตั้งแต่ต้นทางถึงปลายทาง.
