คุณยังควรตรวจสอบโค้ดของตัวแทน AI ของคุณอยู่หรือไม่?

การโต้แย้งเริ่มต้นเหมือนกันในทุกทีม ข้างหนึ่งบอกว่าเอเจนต์ตอนนี้ส่งโค้ดที่สะอาดกว่าครึ่งหนึ่งของ pull requests ที่เราเคยอนุมัติอย่างไม่ใส่ใจ ทำไมเรายังต้องอ่านทุกบรรทัดอยู่? อีกข้างบอกว่าเพราะเราเป็นคนที่เซ็นอนุมัติ

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

กรณีสำหรับการส่งโดยไม่อ่านทุกบรรทัด

เริ่มต้นด้วยเวอร์ชันที่แข็งแกร่งที่สุดของการโต้แย้งที่มองโลกในแง่ดี เพราะมันแข็งแกร่งกว่าที่ผู้ตรวจสอบส่วนใหญ่ยอมรับ

ในงานที่มีขอบเขตพร้อมข้อกำหนดที่ชัดเจนและชุดทดสอบ เอเจนต์การเขียนโค้ดสมัยใหม่ผลิตโค้ดที่สอดคล้องกันมากกว่าคนทั่วไปที่ทำงานภายใต้กำหนดเวลา มันไม่รู้สึกเบื่อในเส้นทางที่มีข้อผิดพลาด มันเขียนการตรวจสอบ null เวลา 18:00 น. ในวันศุกร์ มันปฏิบัติตามข้อตกลงของโครงการที่ได้รับมอบหมายทุกครั้ง โดยไม่มีการกบฏเล็กน้อยที่นักพัฒนาที่เหนื่อยล่อตัวเอง

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

แล้วมีปริมาณ หนึ่งนักพัฒนาที่รันเอเจนต์ห้าตัวพร้อมกันสร้างการเปลี่ยนแปลงมากกว่าที่มนุษย์จะอ่านอย่างละเอียด หากกฎของคุณคือ "อ่านทุกอย่าง" คุณได้ติดตั้งตัวเองกลับมาเป็นคอขวดที่คุณเพิ่งทำให้เป็นอัตโนมัติ มนุษย์ที่อ่านการเปลี่ยนแปลง 900 บรรทัดจะผลิตลายเซ็นโดยไม่ผลิตความรู้ และนั่นแย่กว่าการไม่ตรวจสอบเลย เพราะมันสร้างความมั่นใจในที่ที่ไม่มี

กรณีสำหรับการรักษามนุษย์ไว้ใน diff

ตอนนี้อีกข้างหนึ่ง ซึ่งก็แข็งแกร่งกว่าที่ผู้ที่ชื่นชอบยอมรับ

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

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

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

การอภิปรายถูกกำหนดผิด

นี่คือการกำหนดใหม่ที่ทำให้การประชุมสิ้นสุดลง

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

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

ดังนั้นคำตอบจึงไม่ใช่ "ตรวจสอบทุกอย่าง" หรือ "ไว้วางใจเอเจนต์" มันคือ:

คุณหยุดตรวจสอบบรรทัด คุณเริ่มตรวจสอบความเสี่ยง

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

สิ่งที่ "เอเจนต์ทำผิด" ดูเหมือนจริงๆ

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

1. การทดสอบเปลี่ยนแปลงใน commit เดียวกับโค้ดที่พวกเขาครอบคลุม สีเขียวถูกสร้างขึ้น ไม่ได้สังเกต นี่คือสัญญาณที่มีความหมายสูงสุดในรายการ และนี่คือสิ่งที่ต้องตรวจสอบก่อน
2. การยืนยันถูกทำให้ลดลงหรือการทดสอบถูกปิดใช้งาน skip, only, การยืนยันที่กว้างขึ้นเพื่อยอมรับสิ่งที่โค้ดใหม่เกิดขึ้นจะส่งคืน, try/catch ที่กลืนข้อผิดพลาดที่การทดสอบควรจะเปิดเผย
3. การเปลี่ยนแปลงมีขนาดใหญ่กว่างาน ไฟล์ที่ไม่มีใครขอถูกสัมผัส การขยายขอบเขตในเอเจนต์ไม่ใช่ความกระตือรือร้น แต่มันคือสัญญาณว่าเอเจนต์ตีความเป้าหมายผิดที่ไหนสักแห่ง
4. พื้นผิวที่ประดิษฐ์ขึ้น วิธีการ API, ตัวเลือกการกำหนดค่า หรือเส้นทางที่ไม่มีอยู่ มันคอมไพล์ในหัวของเอเจนต์และไม่มีที่ไหนเลย
5. สภาพแวดล้อมถูกแก้ไขแทนที่จะเป็นโค้ด เส้นทางที่กำหนดไว้ล่วงหน้า, ค่าที่เฉพาะเจาะจงกับเครื่อง, โทเค็นส่วนตัว, ชื่อผู้ใช้ อาการหายไปในเครื่องของเอเจนต์และย้ายไปยังเครื่องของคนอื่น
6. การพึ่งพาเกิดขึ้นโดยไม่มีการร้องขอ ซัพพลายเชนใหม่, ใบอนุญาตใหม่, พื้นผิวการบำรุงรักษาใหม่ ตัดสินใจโดยสิ่งที่จะไม่บำรุงรักษา
7. การทำซ้ำแทนการนำกลับมาใช้ใหม่ มันได้ทำการนำกลับมาใช้ใหม่ของตัวช่วยที่มีอยู่แล้วยี่สิบบรรทัดห่างออกไป นี่คือกลไกเบื้องหลังหนี้ที่วัดได้: การเปลี่ยนแปลงแต่ละครั้งดูเหมือนจะสมเหตุสมผลในท้องถิ่นและโค้ดเบสค่อยๆ ได้รับวิธีที่สามในการทำสิ่งเดียวกัน
8. สรุปไม่ตรงกับ diff "แก้ไขและทดสอบ" เมื่อไม่มีการทดสอบที่รัน การบรรยายถูกสร้างขึ้นด้วยความมั่นใจเดียวกันไม่ว่าจะเกิดขึ้นหรือไม่ ดังนั้นให้ถือเป็นข้อเรียกร้องที่ต้องตรวจสอบ ไม่ใช่รายงาน
9. คำแนะนำหยุดถูกปฏิบัติตาม ข้อตกลงเล็กน้อยที่ถูกละทิ้งอย่างเงียบๆ คือวิธีที่เซสชันเสื่อมสภาพก่อนที่จะเริ่มหลอนอย่างชัดเจน หากคุณใช้ canary ในไฟล์บริบทของคุณ นี่คือสิ่งที่มันมีไว้เพื่อจับ
10. พื้นที่ที่ละเอียดอ่อนถูกสัมผัสในระหว่างการพูดคุย การอ่าน .env, การโทรออกไปยังเครือข่ายใหม่, บรรทัดบันทึกใหม่ที่มีข้อมูลผู้ใช้, การโยกย้ายที่รวมอยู่ใน commit ฟีเจอร์

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

การเปลี่ยนแปลงควรได้รับการตรวจสอบมากแค่ไหน?

รัศมีการระเบิด ไม่ใช่ขนาด diff ที่ตัดสินใจ ตารางที่ทีมของคุณสามารถนำไปใช้ในบ่ายวันนี้:

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

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

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

สิ่งที่เปลี่ยนไปเมื่อเอเจนต์ห้าตัวทำงานพร้อมกัน

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

นี่คือปัญหาด้านเครื่องมือ และนี่คือเหตุผลที่ AgentsRoom วางการตรวจสอบไว้ที่เอเจนต์แทนที่จะอยู่ที่ส่วนท้ายของ pull request:

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

ไม่มีสิ่งใดในนี้แทนที่การตัดสินใจ มันลบข้อแก้ตัวสำหรับการไม่ใช้มัน

ทำให้เครื่องจักรเป็นเจ้าของบรรทัด

หากคุณต้องการหยุดอ่านบรรทัด อะไรบางอย่างต้องอ่านมัน ในทางปฏิบัติ มีสี่สิ่งที่รับภาระนั้น:

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

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

ประตูที่ไม่เหนื่อย ประเภท, lint, การสแกนความลับ, พื้นที่ครอบคลุม, CI ที่ปฏิเสธการโยกย้ายที่รวมอยู่กับฟีเจอร์ ทุกกฎที่คุณสามารถแสดงเป็นประตูคือกฎที่คุณไม่ต้องสังเกตอีกต่อไป

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

ดังนั้น คุณยังตรวจสอบอยู่หรือไม่?

ใช่ และน้อยกว่าที่คุณทำในวันนี้

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

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

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

คำถามที่พบบ่อย

คุณยังควรตรวจสอบโค้ดที่สร้างโดย AI หรือไม่?

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

เอเจนต์ AI สามารถตรวจสอบโค้ดของเอเจนต์ AI อื่นได้หรือไม่?

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

คุณจะรู้ได้อย่างไรว่ามีเอเจนต์ AI ทำผิด?

มองหาสัญญาณที่เป็นกลางใน diff แทนที่จะอ่านเพื่อสไตล์ สัญญาณที่แข็งแกร่งที่สุด: การทดสอบเปลี่ยนแปลงใน commit เดียวกับโค้ดที่พวกเขาครอบคลุม ซึ่งหมายความว่าสีเขียวถูกสร้างขึ้นและไม่สังเกต สัญญาณอื่นๆ รวมถึงการขยายขอบเขต การยืนยันที่ถูกปิดใช้งานหรืออ่อนแอลง API ที่ประดิษฐ์ขึ้น เส้นทางที่กำหนดไว้ล่วงหน้า และสรุปที่ไม่ตรงกับ diff

เอเจนต์ AI จะมาแทนที่ผู้ตรวจสอบโค้ดมนุษย์หรือไม่?

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

คุณจำเป็นต้องตรวจสอบโค้ด AI บรรทัดต่อบรรทัดหรือไม่?

เฉพาะในกรณีที่รัศมีการระเบิดมีเหตุผลเพียงพอ การตรวจสอบบรรทัดต่อบรรทัดไม่สามารถขยายเกินกว่าสองสามเอเจนต์ที่ทำงานพร้อมกันได้ และมนุษย์ที่อ่าน diff 900 บรรทัดในเวลา 18:00 จะผลิตลายเซ็นโดยไม่ผลิตความรู้ ใช้ความสนใจนั้นกับการเปลี่ยนแปลงที่มีค่าใช้จ่ายสูงในการย้อนกลับ

สิ่งใดที่ไม่ควรถูกผสานโดยไม่มีการตรวจสอบจากมนุษย์?

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