เครื่องมือตรวจสอบโค้ดที่ขับเคลื่อนด้วย AI กำลังประสบปัญหาพื้นฐานที่ทำให้นักพัฒนาทั่วโลกรู้สึกหงุดหงิด แม้ว่าบริษัทอย่าง Cubic จะสามารถลดผลบวกเท็จได้ถึง 51% แต่ชุมชนนักพัฒนาโดยรวมยังคงสงสัยว่าเครื่องมือเหล่านี้ให้คุณค่าที่แท้จริงหรือเพียงแค่เพิ่มเสียงรบกวนในกระบวนการพัฒนา
การปรับปรุง AI Code Review ของ Cubic :
- ลดผลบวกเท็จลง 51%
- ลดจำนวนความคิดเห็นเฉลี่ยต่อ pull request ลง 50%
- สถาปัตยกรรมพัฒนาผ่าน 3 การปรับปรุงหลัก
- micro-agents เฉพาะทางสำหรับด้านการตรวจสอบที่แตกต่างกัน (Security, Duplication, Editorial)
ปัญหาหลัก: เสียงรบกวนมากเกินไป สัญญาณไม่เพียงพอ
ปัญหาหลักที่รบกวนเครื่องมือตรวจสอบโค้ดด้วย AI ไม่ใช่แค่เรื่องเทคนิค แต่เป็นเรื่องของความไว้วางใจ นักพัฒนารายงานว่า 90% ของความคิดเห็นที่ AI สร้างขึ้นนั้นผิดหรือไม่เกี่ยวข้อง โดยขาดบริบทสำคัญที่ผู้ตรวจสอบที่เป็นมนุษย์เข้าใจได้อย่างเป็นธรรมชาติ สิ่งนี้สร้างสถานการณ์ที่ข้อเสนอแนะที่มีประโยชน์จริงๆ ถูกฝังอยู่ใต้กองภูเขาของคำแนะนำที่ไร้ความหมาย
ปัญหานี้ลึกกว่าตัวชี้วัดความแม่นยำธรรมดา โมเดล AI ขาดสิ่งที่นักพัฒนาเรียกว่าความรู้เผ่าพันธุ์ คือกฎที่ไม่เป็นลายลักษณ์อักษร ประวัติโครงการ และบริบททางธุรกิจที่ช่วยในการตรวจสอบโค้ดที่ดี เมื่อ AI ตั้งค่าสถานะโค้ดที่ถูกคอมเมนต์ออกว่าเป็นปัญหา มันอาจจะจับประเด็นที่ถูกต้องได้จริง แต่นักพัฒนาได้เรียนรู้ที่จะเพิกเฉยต่อคำเตือนเหล่านี้เพราะคำเตือนอื่นๆ หลายตัวพิสูจน์แล้วว่าไร้ประโยชน์
สถิติการรีวิวโค้ดด้วย AI ที่รายงานโดยชุมชน:
- 90% ของความคิดเห็นจาก AI ถูกรายงานว่าผิดหรือไม่เกี่ยวข้อง
- 5-10% ของคำแนะนำจาก AI สามารถตรวจพบปัญหาที่แท้จริงได้
- ปัญหาหลัก: ขาดบริบท ความรู้เฉพาะกลุ่ม และกฎเกณฑ์คุณภาพโค้ด
เกมความมั่นใจ: เมื่อ AI แสร้งทำเป็นรู้
แนวโน้มหนึ่งที่น่ากังวลเป็นพิเศษคือเครื่องมือ AI ที่ให้คะแนนความมั่นใจสำหรับคำแนะนำของพวกมัน สมาชิกชุมชนชี้ให้เห็นว่าค่าความมั่นใจเชิงตัวเลขเหล่านี้นั้นไร้ความหมายโดยพื้นฐาน AI ไม่มีพื้นฐานที่แท้จริงในการกำหนดว่าควรจะมั่นใจแค่ไหนเกี่ยวกับคำแนะนำของตัวเอง ความแม่นยำเท็จนี้สามารถทำให้นักพัฒนาเข้าใจผิดและไว้วางใจคำแนะนำที่อาจจะผิดพลาดโดยสิ้นเชิง
แนวทางการให้เหตุผลแบบมีโครงสร้าง ที่ AI อธิบายกระบวนการตัดสินใจของตัวเอง เป็นความพยายามในการแก้ไขปัญหาความโปร่งใสนี้ อย่างไรก็ตาม นักวิจารณ์โต้แย้งว่าการบังคับให้ AI ให้เหตุผลสำหรับข้อสรุปของมันไม่ได้ปรับปรุงการให้เหตุผลพื้นฐานจริงๆ แต่เพียงแค่สร้างภาพลวงตาของการคิดเชิงตรรกะ
แนวทางที่แตกต่าง: คำแนะนำมากกว่าการตัดสิน
นักพัฒนาบางคนแนะนำว่าเครื่องมือตรวจสอบโค้ดด้วย AI ทำงานได้ดีกว่าเมื่อพวกมันมุ่งเน้นไปที่คำแนะนำมากกว่าการตัดสินแบบเด็ดขาด แทนที่จะตั้งค่าสถานะบั๊กที่อาจเกิดขึ้น เครื่องมือเหล่านี้สามารถให้ความสามารถในการค้นหาเชิงความหมาย โดยค้นหาปัญหาในอดีตที่เกี่ยวข้องหรือ pull request ที่อาจให้บริบทที่มีประโยชน์แก่ผู้ตรวจสอบที่เป็นมนุษย์
การตรวจสอบโค้ดไม่ใช่กรณีการใช้งานที่ดีสำหรับ LLM LLM เปล่งประกายในกรณีการใช้งานที่ผลลัพธ์ของพวกมันไม่ถูกประเมินจากความแม่นยำ เช่น คำแนะนำ การค้นหาเชิงความหมาย ตัวอย่างโค้ด
แนวทางนี้ยอมรับข้อจำกัดของ AI ในขณะที่ใช้ประโยชน์จากจุดแข็งในการจดจำรูปแบบและการดึงข้อมูล
วงจรการพัฒนาแบบลองผิดลองถูก
การสร้างตัวแทน AI ที่มีประสิทธิภาพต้องการแนวทางที่แตกต่างจากการพัฒนาซอฟต์แวร์แบบดั้งเดิมโดยพื้นฐาน แทนที่จะเป็นการเขียนโปรแกรมแบบกำหนดได้ นักพัฒนาพบว่าตัวเองอยู่ในวงจรของการทดลอง การทดสอบการปรับแต่ง และการวัดผลลัพธ์ กระบวนการนี้คล้ายกับวิธีการทางวิทยาศาสตร์มากกว่าวิศวกรรมแบบดั้งเดิม ทำให้เกิดคำถามเกี่ยวกับความน่าเชื่อถือและความสามารถในการคาดการณ์ของเครื่องมือที่ขับเคลื่อนด้วย AI
แนวทางตัวแทนจุลภาคเฉพาะทาง การแบ่งงานออกเป็นส่วนประกอบ AI ที่มุ่งเน้นและมีวัตถุประสงค์เดียว แสดงให้เห็นความหวังแต่มาพร้อมกับความซับซ้อนที่เพิ่มขึ้นและต้นทุนการใช้โทเค็น แม้ว่ากลยุทธ์นี้สามารถปรับปรุงความแม่นยำได้ แต่ก็เน้นย้ำให้เห็นว่าระบบ AI ปัจจุบันต่อสู้กับลักษณะหลากหลายของการตรวจสอบโค้ดอย่างไร
แนวทางเทคนิคหลัก:
- บันทึกการใช้เหตุผลอย่างชัดเจน: AI ต้องให้เหตุผลในการตัดสินใจก่อนให้ข้อเสนอแนะ
- ชุดเครื่องมือที่เรียบง่าย: ลดจากเครื่องมือหลายตัว ( LSP , การวิเคราะห์แบบคงที่, test runners ) เหลือเพียงส่วนประกอบที่จำเป็นเท่านั้น
- สถาปัตยกรรม Micro-Agent : เอเจนต์เฉพาะทางสำหรับขอบเขตแคบ เทียบกับ prompts ขนาดใหญ่ตัวเดียว
มองไปข้างหน้า: การจัดการความคาดหวัง
สถานะปัจจุบันของเครื่องมือตรวจสอบโค้ดด้วย AI สะท้อนถึงความท้าทายที่กว้างขวางในการประยุกต์ใช้โมเดลภาษาขนาดใหญ่กับงานที่ต้องการความแม่นยำสูง แม้ว่าการปรับปรุงอย่างการให้เหตุผลที่ชัดเจนและตัวแทนเฉพาะทางสามารถลดผลบวกเท็จได้ แต่ข้อจำกัดพื้นฐานยังคงอยู่ นักพัฒนาต้องการเครื่องมือที่เสริมมากกว่าทำให้เวิร์กโฟลว์ของพวกเขาซับซ้อน และยังไม่มีการตัดสินใจที่ชัดเจนว่าแนวทาง AI ปัจจุบันสามารถส่งมอบคุณค่านั้นได้อย่างสม่ำเสมอหรือไม่
เส้นทางไปข้างหน้าน่าจะเกี่ยวข้องกับการผสานรวมที่ดีกว่าเข้ากับเครื่องมือพัฒนาที่มีอยู่ การตระหนักรู้บริบทที่ซับซ้อนมากขึ้น และที่สำคัญที่สุดคือการสื่อสารที่ชัดเจนกว่าเกี่ยวกับสิ่งที่เครื่องมือเหล่านี้สามารถและไม่สามารถทำได้อย่างน่าเชื่อถือ
อ้างอิง: Learnings from building AI agents