มีรูปแบบหนึ่งที่แทบทุกคนตกหลุมพรางเมื่อทำงานกับเอเจนต์เขียนโค้ด และมันค่อยๆ บ่อนทำลายจุดประสงค์ทั้งหมดของการใช้เอเจนต์อย่างเงียบๆ เอเจนต์สร้างการเปลี่ยนแปลงขึ้นมา แล้วคุณก็ถามคำถามที่ชัดเจนว่า "สิ่งนี้ใช้ได้ไหม" เอเจนต์ตอบว่าใช้ได้ คุณเชื่อมัน เพราะมันฟังดูมั่นใจและส่วนใหญ่ก็ถูกต้อง แล้วบางครั้งมันก็มั่นใจแบบผิดๆ อย่างสิ้นเชิง — และคุณมาพบทีหลังตอนขึ้นโปรดักชันแล้ว
ปัญหาไม่ใช่ที่เอเจนต์โกหก ปัญหาคือคำถามต่างหาก
ทำไม "สิ่งนี้ใช้ได้ไหม" ถึงเป็นคำถามที่ผิด
เมื่อคุณถามเอเจนต์ว่าการเปลี่ยนแปลงของมันเองใช้ได้หรือไม่ คุณกำลังขอให้มันประเมินผลงานของตัวเองด้วยตรรกะเดียวกันเป๊ะกับที่สร้างผลงานนั้นขึ้นมา มันกำลังตรวจข้อสอบของตัวเองด้วยปากกาด้ามเดิม ถ้ามันพลาดกรณีขอบเขต (edge case) ตอนเขียนโค้ด มันก็จะพลาดกรณีขอบเขตเดียวกันนี้ตอนตัดสินโค้ดนั้นด้วย เพราะไม่มีอะไรใหม่เข้ามาในภาพเลย — โมเดลเดิม บริบทเดิม จุดบอดเดิม
ที่แย่กว่านั้นคือ โมเดลภาษามีแนวโน้มเอนเอียงไปทางเห็นด้วย ถ้าคุณตั้งคำถามแบบ "อันนี้จัดการอีเมลที่เป็น null ได้ถูกต้องใช่ไหม" คุณก็ไม่ได้ขอการประเมินแล้ว แต่คุณเสนอข้อสรุปและเชื้อเชิญให้เอเจนต์ยืนยันมัน ซึ่งมันมักจะทำตามนั้น สิ่งที่คุณได้กลับมาไม่ใช่การตรวจสอบ แต่มันคือเสียงสะท้อนที่ลื่นไหลมากของความหวังของคุณเอง
ขอหลักฐานแทน
ทางแก้เล็กน้อยแต่เปลี่ยนทุกอย่าง คือเลิกขอให้เอเจนต์ ยืนยัน ว่าการเปลี่ยนแปลงนั้นใช้ได้ แล้วเริ่มขอให้มัน แสดง ให้คุณดูแทน หลักฐานคือสิ่งที่คุณตรวจสอบได้ด้วยตัวเอง ซึ่งเกิดจากระบบ ไม่ใช่จากความเห็นของเอเจนต์ที่มีต่อระบบ หลักฐานไม่ได้มีค่าเท่ากันทั้งหมด มีลำดับชั้นคร่าวๆ ดังนี้
- หลักฐานจากการรัน (execution proof) แข็งแกร่งที่สุด: เอเจนต์รันโค้ดจริง และแสดงผลลัพธ์จริงให้คุณดู — การทดสอบที่ผ่าน คำสั่งที่คืนค่าตามที่ควรจะเป็น
- หลักฐานก่อน-หลัง ดีเกือบเท่ากัน: การเปลี่ยนแปลงที่เป็นรูปธรรมในสถานะที่สังเกตได้ จำนวนการค้นหาลดจาก 47 เหลือ 2 คำขอที่เคยล้มเหลวตอนนี้คืนค่า 200
- การทดสอบที่เอเจนต์เขียนเอง อ่อนกว่า เพราะจุดบอดเดียวกันที่พลาดบั๊กไป ก็อาจพลาดมันในการทดสอบด้วยเช่นกัน — แต่การทดสอบที่คุณอ่านและรันได้เองยังคงดีกว่าคำกล่าวอ้างมาก
- คำอธิบายด้วยวาจา อ่อนที่สุด บางครั้งมันเป็นสิ่งเดียวที่คุณจะได้ แต่ "นี่คือเหตุผลของผม" ไม่ใช่หลักฐาน มันคือสิ่งที่หลักฐานควรจะเข้ามาตรวจสอบต่างหาก
แนวทางในทุกกรณีเหมือนกัน คือเปลี่ยนคำถามใช่/ไม่ใช่ ให้กลายเป็นคำขอสิ่งที่สังเกตได้
ตัวอย่างในทางปฏิบัติ
แทนที่จะถามว่า "การมาย์เกรตนี้จะจัดการอีเมล null ได้ไหม" ให้ขอให้เอเจนต์ใส่ข้อมูลแถวหนึ่งที่มีอีเมล null รันการมาย์เกรต แล้วแสดงผลลัพธ์ให้ดู แทนที่จะถามว่า "อันนี้แก้ปัญหา query N+1 แล้วหรือยัง" ให้ขอให้มันเพิ่ม query logging ยิงไปที่ endpoint แล้วแสดงจำนวน query ก่อนและหลังให้ดู แทนที่จะถามว่า "rate limiter รีเซ็ตไหม" ให้ขอให้มันทำจนถึงลิมิต รอ แล้วลองใหม่ พร้อมแสดงคำขอที่สำเร็จให้ดู ในทุกกรณี คุณได้แทนที่คำกล่าวอ้างที่คุณต้องเชื่อ ด้วยผลลัพธ์ที่คุณอ่านได้เอง
นี่คือเหตุผลที่เอเจนต์ของเราทำงานอยู่ในแซนด์บ็อกซ์
หลักฐานจะใช้ได้ผลก็ต่อเมื่อเอเจนต์รันสิ่งต่างๆ ได้จริง และนี่คือการตัดสินใจด้านการออกแบบ ไม่ใช่เรื่องคิดทีหลัง ทุกการรันของ TaskGoblin เกิดขึ้นในแซนด์บ็อกซ์ที่มีการโคลนรีโพซิทอรีและมีทูลเชนพร้อมใช้งาน ดังนั้นเอเจนต์จึงไม่ได้แค่คาดเดาว่าโค้ดจะทำอะไร — มันสามารถรันการทดสอบ, รันคำสั่งต่างๆ, และสังเกตผลลัพธ์จริงได้ เมื่อมันรีวิว merge request สิ่งที่มันพบจะชี้ไปที่พฤติกรรมที่เป็นรูปธรรม และเมื่อคุณตอบกลับด้วย @taskgoblin fix การเปลี่ยนแปลงนั้นก็เป็นสิ่งที่มันตรวจสอบได้จริง ไม่ใช่แค่โต้แย้งสนับสนุนมันเฉยๆ
นี่ยังเป็นเหตุผลที่สภาพแวดล้อมการพัฒนาที่ดีให้ผลตอบแทนมากกว่าที่เคย เอเจนต์ที่สามารถสตาร์ทเซอร์วิสของคุณ โหลดข้อมูลตั้งต้น (seed data) และรันชุดทดสอบของคุณได้ สามารถสร้างหลักฐานจริงได้ ส่วนเอเจนต์ที่อ่านโค้ดได้อย่างเดียวก็ให้ได้แค่ความเห็น ยิ่งโปรเจกต์ของคุณรันได้มากเท่าไร คุณก็จะยิ่งตรวจสอบผลลัพธ์ของเอเจนต์ได้มากขึ้นแทนที่จะต้องเชื่อเฉยๆ
สรุปในหนึ่งประโยค
อย่าถามเอเจนต์ว่างานของมันถูกต้องหรือไม่ จงขอให้มันแสดงให้คุณเห็นว่าถูกต้อง — และเลือกวิธีแสดงแบบที่คุณตรวจสอบได้ด้วยตัวเอง เอเจนต์ที่รันโค้ดแล้วส่งผลลัพธ์ให้คุณ กำลังทำสิ่งเดียวที่เอเจนต์ที่เพียงแค่การันตีโค้ดไม่มีวันทำได้ นั่นคือการมอบสิ่งอื่นให้คุณเชื่อ นอกเหนือจากความมั่นใจของมันเอง
