การตรวจสอบผลลัพธ์ในระดับใหญ่

นี่คือปัญหาที่ต้องยอมรับตรงๆ: เมื่อเอเจนต์กำลังเขียนโค้ดหลายร้อยบรรทัดในหลายงานพร้อมกัน คุณไม่สามารถอ่านทุกบรรทัดแบบที่คุณตรวจสอบ diff สิบบรรทัดได้ การเสแสร้งว่าคุณทำได้จะนำไปสู่การประทับตราอนุมัติโดยไม่ดู (rubber-stamping) หรือไม่ก็อัมพาต (paralysis — ไม่เคยไว้ใจอะไรเลย) ไม่มีทางไหนที่จะส่งมอบงานได้จริง

ทางออกคือการตั้งด่านตรวจ (gate) เป็นชั้นๆ แทนการอ่านทุกอย่าง:

• ชุดทดสอบคือพื้นฐานขั้นต่ำ ผลลัพธ์ของเอเจนต์จะไม่ถูกรวมเข้ากับโค้ดหลักโดยไม่มีชุดทดสอบที่เกี่ยวข้องเป็นสีเขียวและตัวตรวจสอบชนิดข้อมูล (type-checker) สะอาด นี่คือสิ่งที่ต่อรองไม่ได้ และมันเป็นแบบอัตโนมัติ — เครื่องจักรทำส่วนนี้ให้
• ตรวจสอบจุดเสี่ยงอย่างละเอียด คุณอ่านทั้งหมดไม่ได้ ดังนั้นให้อ่านส่วนที่รัศมีความเสียหายสูง: อะไรก็ตามที่แตะการยืนยันตัวตน เงิน การลบข้อมูล หรือการเรียกใช้ระบบภายนอก ให้กวาดตาดูส่วนที่เหลือเพื่อหาสัญญาณเตือนจากบทเรื่องการสร้างฟีเจอร์ — ไฟล์ที่ไม่ควรถูกแตะ สิ่งที่ถูกลบไปเงียบๆ คำขอเล็กๆ ที่กลับสร้าง diff ขนาดใหญ่
• อ่าน diff ไม่ใช่โค้ดเบสทั้งหมด git diff --stat บอกคุณได้ในไม่กี่วินาทีว่า อะไร เปลี่ยนไปและเปลี่ยนมากแค่ไหน งานที่กำหนดขอบเขตไว้แค่โมดูลเดียวแต่แสดงการเปลี่ยนแปลงในหกโมดูลคือสัญญาณให้ดูให้ละเอียดขึ้น ก่อนที่คุณจะอ่านแม้แต่บรรทัดเดียว
• รันมันดู ชุดทดสอบสีเขียวไม่ใช่แอปที่ใช้งานได้จริง คลิกดูสิ่งนั้น การตรวจสอบขั้นสุดท้ายเป็นอันเดียวกับทุกบทอื่นเสมอ: มันทำในสิ่งที่คุณขอจริงๆ หรือไม่ ต่อหน้าคุณ?

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