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