งานวิจัยชื่อ AgentLens แกะบันทึกการทำงานของ AI coding agent ที่ลงมือแก้โค้ดเองตั้งแต่ต้นจนจบ แล้วพบว่างาน 10.7% ที่ผ่าน test ครบทุกข้อเป็นการผ่านแบบฟลุก โดย test คือชุดตรวจอัตโนมัติ

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

ฝั่งคนก็เจอเรื่องเดียวกัน องค์กรวิจัย METR ทดลองกับนักพัฒนา 16 คนที่อยู่กับโปรเจกต์ของตัวเองมาหลายปี แล้ววัดได้ว่าตอนที่อนุญาตให้ใช้ AI ช่วย พวกเขาใช้เวลาทำงานนานขึ้น 19% ที่หนักกว่าตัวเลขคือความรู้สึก เพราะหลังทำงานเสร็จ คนกลุ่มเดิมนี้ยังเชื่อว่า AI ทำให้ตัวเองเร็วขึ้น 20%

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

เมาแล้วขับกลับถึงบ้าน ไม่ได้แปลว่าตัดสินใจดี

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

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

คำนี้มาจากหนังสือ Thinking in Bets ที่ Sandeep Swadia หยิบมาเล่าไว้ในคลิป คนเขียนคือ Annie Duke นักโป๊กเกอร์อาชีพที่อยู่กับเกมนี้มายี่สิบปี จึงคุ้นเคยกับสถานการณ์ที่ตัดสินใจถูกทุกอย่างแล้วยังแพ้ และตัดสินใจมั่วแล้วยังชนะ

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

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

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

ความสำเร็จที่เกิดขึ้นเพราะฟลุก สอนบทเรียนที่อันตรายที่สุดให้เรา

METR วัดได้ว่ารู้สึกเร็วขึ้น 20% แต่เวลาจริงช้าลง 19%

การทดลองของ METR ไม่ได้ตั้งโจทย์ขึ้นเองในห้องแล็บ แต่ใช้งานจริงจากโปรเจกต์โอเพนซอร์ส ซึ่งเปิดโค้ดให้คนนอกเข้ามาช่วยพัฒนาได้ โปรเจกต์เหล่านี้อยู่บน GitHub ที่นักพัฒนาใช้เก็บและแชร์โค้ดกัน แต่ละโปรเจกต์มีโค้ดเกินหนึ่งล้านบรรทัด และมีคนกดดาวให้เฉลี่ยเกินสองหมื่นสองพันดวง ส่วนนักพัฒนาทั้ง 16 คนที่เข้าร่วมส่งโค้ดเข้าโปรเจกต์เหล่านั้นมาหลายปีแล้ว ไม่ใช่คนที่เพิ่งเปิดโค้ดวันแรก

วิธีทดลองตรงไปตรงมา โดยเอางานจริง 246 ชิ้นที่แต่ละคนต้องทำอยู่แล้ว งานละราวสองชั่วโมง มาสุ่มแบ่งว่าชิ้นไหนอนุญาตให้ใช้ AI ช่วยและชิ้นไหนห้ามใช้ แล้วจับเวลาเทียบกัน การสุ่มแบ่งคือหัวใจของการทดลองแบบนี้ เพราะช่วยกระจายงานยากงานง่ายไปทั้งสองฝั่งเท่าๆ กัน ผลที่ออกมาจึงไม่ใช่เรื่องบังเอิญว่าใครได้งานง่ายกว่ากัน ทุกคนได้ค่าตอบแทนชั่วโมงละ 150 ดอลลาร์ ส่วนเครื่องมือหลักที่ใช้คือ Cursor Pro กับโมเดล Claude 3.5 และ 3.7 Sonnet ซึ่งเป็นรุ่นแถวหน้าของช่วงนั้น

ตัวเลขที่ออกมามีสามชั้น ชั้นแรกคือความคาดหวังก่อนเริ่ม นักพัฒนากลุ่มนี้เดาไว้ว่า AI จะช่วยให้ตัวเองเร็วขึ้น 24% ชั้นที่สองคือสิ่งที่เกิดขึ้นจริง เวลาที่ใช้เพิ่มขึ้น 19% แปลว่าช้าลง ไม่ใช่เร็วขึ้น ส่วนชั้นที่สามทำให้เรื่องนี้ไม่จบแค่ข่าวงานวิจัยชิ้นหนึ่ง หลังทำงานเสร็จและเห็นงานของตัวเองกับตาแล้ว พวกเขายังประเมินว่า AI ช่วยให้เร็วขึ้น 20%

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

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

AgentLens แยกงานที่ผ่าน test ออกเป็นสามชั้น

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

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

ข้อมูลที่ใช้คือ 2,614 trajectory จาก OpenHands ซึ่งเป็นระบบโอเพนซอร์สที่ให้ AI ลงมือเขียนโค้ดเองได้ โดยให้โมเดลเบื้องหลัง 8 ตัวทำโจทย์ชุดเดียวกัน โจทย์มาจาก SWE-bench Verified 60 ข้อ ซึ่งเป็นชุดโจทย์ที่หยิบบั๊กจริงจากโปรเจกต์โอเพนซอร์สมาให้ agent แก้ แล้ววัดว่า test ของโปรเจกต์นั้นผ่านไหม

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

เมื่อแยกแต่ละขั้นตอนได้ละเอียดขนาดนี้ งานที่ผ่าน test เหมือนกันหมดก็แบ่งออกเป็นสามชั้น

• Lucky ผ่านทั้งที่กระบวนการระหว่างทางพัง
• Solid ผ่านด้วยกระบวนการที่ใช้ได้ ไม่มีอะไรน่าตกใจ
• Ideal ผ่านด้วยกระบวนการที่ใกล้เคียงกับวิธีแก้ที่เหมาะกับโจทย์นั้น

สัญญาณที่ทำให้รอบหนึ่งถูกจัดเป็น Lucky มีสี่แบบ ซึ่งเอาไปใช้ตรวจงานของตัวเองได้ทันที

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

ตัวเลขที่นำไปใช้ต่อได้จริงคือช่วงอัตราการผ่านแบบฟลุกที่พบ อัตรานี้ไม่ได้เท่ากันทุกโมเดล ในแปดตัวที่ทดสอบ ตัวที่ต่ำสุดอยู่ที่ 0.5% ส่วนตัวที่สูงสุดอยู่ที่ 23.2% แปลว่าโมเดลสองตัวที่มีอัตราผ่านเท่ากันบนกระดาษอาจทำงานคนละแบบกันโดยสิ้นเชิง

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

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

คำถามที่ดีกว่า “เก่งหรือฟลุก”

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

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

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

แนวคิดนี้ยังอธิบายได้ว่าทำไมคนที่ใช้ AI แล้วได้ผลลัพธ์ที่ทำซ้ำได้ มักพูดถึงวิธีทำงานของตัวเองมากกว่าโมเดลรุ่นล่าสุด เวิร์กโฟลว์ใช้ AI เขียนโค้ดของ Matt Pocock ก็ชี้ไปทางเดียวกัน

tilt เมื่อรอบที่พังลากรอบถัดไปให้พังตาม

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

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

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

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

สามอย่างที่เปลี่ยนได้ตั้งแต่งานชิ้นหน้า

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

สอง เขียนสิ่งที่คาดไว้ก่อนกดรัน สองสามบรรทัดก็พอว่าคาดว่ามันจะไปแก้ไฟล์ไหน น่าจะพลาดตรงไหน และอะไรคือสัญญาณว่ามันเดินผิดทางแล้ว จากนั้นค่อยกดรัน แล้วเอาสิ่งที่เกิดขึ้นจริงมาเทียบกับที่เขียนไว้ วิธีนี้กันไม่ให้ resulting เกิดขึ้น เพราะเราเขียนเกณฑ์ตัดสินไว้ก่อนที่ผลจะออกมา สมองจึงไม่มีโอกาสย้อนไปแก้เกณฑ์ให้เข้ากับผลอีก แนวคิดเดียวกันนี้คือสิ่งที่ Spec Kit ของ GitHub นำไปใช้เป็นขั้นตอนอย่างจริงจัง นั่นคือวางสเปกให้ชัดก่อน แล้วค่อยปล่อยให้ AI ลงมือ

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

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

งานที่ผ่านโดยที่อธิบายไม่ได้ว่าผ่านเพราะอะไร คืองานที่ทำซ้ำไม่ได้ และสิ่งที่ทำซ้ำไม่ได้ ยังไม่นับเป็นวิธีทำงาน

---

ที่มา:

• คลิป If You Only Read One Book This Year, Make It This จากช่อง Sandeep Swadia
• บทความ Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity จาก METR
• บทความ AgentLens: Revealing The Lucky Pass Problem in SWE-Agent Evaluation จาก arXiv