Google เผย TODO ในโค้ดทำ AI วอกแวก เพิ่มต้นทุน Token และเวลา

6 พ.ย. 2026

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

เมื่อเอเจนต์มีความสามารถผ่านเครื่องมือและทักษะเพิ่มขึ้น โอกาสที่จะทำภารกิจเสริม (side-quests) ก็ขยายตัวตามสัดส่วน ข้อกำหนดที่ล้าสมัย บั๊กที่แก้ไขไปนานแล้ว และเอกสารที่ไม่อัปเดต ไม่ได้วางอยู่อย่างสงบในมุมที่ถูกลืมของ codebase อีกต่อไป แต่กลับถูกนำเข้าไปเป็นบริบทโดยไม่ตั้งใจ ซึ่งเป็นการชี้นำที่ผิดทางให้กับเหล่าเอเจนต์รุ่นถัดไป

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

การตรวจสอบด้วยมนุษย์เพื่อวัดว่าเอเจนต์ตกหลุมพรางเหล่านี้บ่อยเพียงใดจากเซสชันนับล้านในแต่ละเดือนนั้นเป็นเรื่องที่เป็นไปไม่ได้ เราจึงต้องการสัญญาณที่เป็นรูปธรรมจากตัวโค้ดเอง ซึ่งความคิดเห็นแบบ inline ที่เป็น TODO(bug/...) คือตัวแทนที่สมบูรณ์แบบ โดยปกติ TODO มักถูกทิ้งไว้หลังจากบั๊กได้รับการแก้ไขไปนานแล้ว การใช้ระบบตรวจสอบไขว้ระหว่างทุก TODO ที่เอเจนต์พบ กับสถานะบั๊กจริงและ prompt ของผู้ใช้ ทำให้เราสามารถแยกแยะงานที่ถูกต้องออกจากการเสียเวลาออกนอกลู่นอกทางได้อย่างอัตโนมัติในระดับกว้าง

จากการวิเคราะห์ผ่าน distributed traces ของวิศวกรหลายพันคนและขั้นตอนของเอเจนต์รวมกว่าร้อยล้านขั้นตอน เราสามารถวัดผลกระทบของความวอกแวกจาก TODO ใน codebase ได้ดังนี้:

• เกือบ 1 ใน 7 เซสชันมีการสัมผัสกับสิ่งรบกวน (13%): จากการอ่านไฟล์หลายล้านครั้ง พบว่า 13% ของเซสชันทำให้เอเจนต์เผชิญกับการอ้างอิงบั๊กแบบ inline เช่น TODO(bug/...) หรือ FIXME(bug/...)
• 6% กระตุ้นให้เกิดการกระทำต่อ และ 83% ในนั้นเกิดขึ้นโดยไม่ได้ถูกสั่ง: แม้เอเจนต์จะเพิกเฉยต่อคอมเมนต์ใน 94% ของกรณีที่พบ แต่ใน 6% ที่เหลือ เอเจนต์กลับดำเนินการต่อโดยมุ่งเป้าไปที่ ID บั๊กนั้น ซึ่งกว่า 4 ใน 5 ของการดำเนินการดังกล่าวเป็นการทำโดยที่นักพัฒนาไม่ได้สั่ง
• 41% ไล่ตามทางตันที่ปิดไปแล้ว และ 57% ทำให้ขอบเขตงานบานปลาย (scope creep): การออกนอกลู่นอกทางที่ไม่ได้ถูกสั่งมีโหมดความล้มเหลว 2 รูปแบบ คือกว่า 40% เป็นการไล่ตามตั๋วบั๊กที่ปิดหรือตรวจสอบเสร็จสิ้นไปแล้ว ส่วนอีกกว่าครึ่งเป็นการเข้าไปขยายขอบเขตงานเพื่อตรวจสอบหรือแก้ไขปัญหาที่นักพัฒนาไม่เคยสั่งให้แตะต้อง

เมื่อควบคุมตัวแปรด้านความซับซ้อนและประเภทงาน เราพบว่าการออกนอกลู่นอกทางไปยังบั๊กที่ไม่ได้สั่งนั้น เพิ่มภาระงานต่อเซสชันอย่างมีนัยสำคัญ (p<0.0001) ดังนี้:

• ขั้นตอนเพิ่มขึ้น 70%
• token เพิ่มขึ้น 77%
• เวลาที่ต้องรอเพิ่มขึ้น 105%

ตัวอย่างความวอกแวกที่พบ เช่น การออกนอกลู่นอกทางที่ล้าสมัย โดยในระหว่างการตรวจสอบบั๊กที่ไม่เกี่ยวข้องกัน เอเจนต์เปิดดูไฟล์ SurfaceControlTest.java และเห็น // TODO(bug/XXX) ซึ่งเป็นบั๊กที่แก้ไขไปแล้วตั้งแต่ปี 2023 แต่เอเจนต์กลับทำการเจาะลึกเข้าไปเพื่อเรียนรู้เพิ่มเติมจนเสียเวลาหลายขั้นตอน

อีกกรณีคือ เอเจนต์ที่กระตือรือร้นเกินเหตุ ซึ่งพบ TODO ในบั๊กและตัดสินใจ "แก้ไข" โค้ดในส่วน ModelDownloaderV1 โดยพลการ จนมนุษย์ต้องทักท้วงเรื่องขอบเขตงานที่บานปลาย แม้ทั้งสองกรณีจะเป็นเพียงการออกนอกลู่นอกทางเล็กน้อย แต่มันคือความวอกแวกที่เกิดขึ้นจริงซึ่งทำให้เสียทรัพยากรและต้องอาศัยการแทรกแซงจากมนุษย์ เพื่อแก้ไขปัญหานี้ในวงกว้าง เราได้สร้างเอเจนต์สำหรับกวาดล้าง codebase เพื่อค้นหาการอ้างอิงบั๊กที่ล้าสมัย อย่างไรก็ตาม เอเจนต์ต้องลงลึกไปถึงประวัติของบั๊กและไฟล์เพื่อให้แน่ใจว่าเจตนาเบื้องหลัง TODO นั้นหมดความจำเป็นแล้วจริงๆ ก่อนจะส่งรายการแก้ไข (change) ให้มนุษย์ตรวจสอบ ซึ่งในช่วง 6 เดือนที่ผ่านมา เครื่องมือนี้สามารถลบการอ้างอิงล้าสมัยได้หลายพันรายการ โดยได้รับการยอมรับจากผู้ตรวจสอบที่เป็นมนุษย์สูงถึง 95% โดยสรุป เมื่อเรามอบหมายงานที่ซับซ้อนให้เอเจนต์มากขึ้น "codebase ที่เป็นมิตรกับเอเจนต์" จึงต้องการมากกว่าแค่โค้ดที่ทำงานได้ แต่ต้องไม่มีภาระทางเทคนิคที่ค้างคา เครื่องมืออย่างตัววิเคราะห์ก่อนส่งโค้ด (presubmit analyzers) หรือเอเจนต์ทำความสะอาดอัตโนมัติ คือโซลูชันที่จะช่วยให้ codebase มีสุขภาพดีและช่วยให้เอเจนต์ทำงานได้อย่างเต็มประสิทธิภาพ