ทดลอง 26 เทคนิคเทสต์กับ coding agent ครั้งละ 160 รัน แล้วพบว่า "ไม่สั่งอะไรเลย" ชนะเกือบทุกเทคนิค — และสกิลเทสต์ยอดฮิต 250k ดาวทำผลแย่ลง

Dan Luu เผยแพร่ผลการทดลองชุดใหญ่เมื่อ 7 ก.ย. 2026 ที่ตอบคำถามซึ่งนักพัฒนาถามกันมานาน: ถ้าเราบอก coding agent ให้ “ใช้ property-based testing” หรือ “ใช้ TDD” หรือ “ใช้ Lean 4” มันจะเขียนโค้ดถูกต้องขึ้นจริงไหม คำตอบสั้น ๆ คือ ไม่ — และในหลายกรณีการสั่งทำให้ผลแย่ลงกว่าการไม่สั่งอะไรเลย

โจทย์คือให้เอเจนต์เขียน Zstd (อัลกอริทึมบีบอัด) ใน Rust จาก RFC โดยไม่ให้ชุดเทสต์ แล้ววัดว่ากี่เปอร์เซ็นต์ของรันผ่านเทสต์ที่ซ่อนไว้ครบ 100% เทียบกับต้นทุนโทเคน ตัวเอเจนต์คือ codex กับ GPT-5.6 Sol ที่ระดับ effort สองแบบ (medium และ xhigh) เฉลี่ย 80 รันต่อเงื่อนไขต่อระดับ effort — รวมเป็น 160 รันต่อเงื่อนไข ซึ่งเป็นจำนวนที่สูงกว่าที่คนทั่วไปทำกันมากเมื่อรีวิวสกิลหรือเทคนิคใหม่

26 เงื่อนไข + 4 สกิล และผลที่ออกมาแบนราบผิดคาด

เงื่อนไขที่ทดสอบครอบคลุมตั้งแต่ formal methods (ACL2, Alloy, Creusot, Kani, Lean 4, SMT solvers ที่ติดตั้ง Z3/cvc5/Yices ครบ, Spin, TLA+, Verus) ไปจนถึงไลบรารีเทสต์ (Insta, Proptest, QuickCheck, rstest, Rust built-in test framework) เทคนิค (differential testing, fuzzing, metamorphic testing, mutation testing, property-based testing, TDD) และคำสั่งเชิงพฤติกรรม (“Audit first”, “Audit and fuzz risky areas”, “Make no mistakes”, “Judgement” ที่ให้เอเจนต์เลือกเทคนิคเอง) รวมถึง Default ที่ไม่ใส่คำสั่งเพิ่มเลย

อีก 4 เงื่อนไขเป็น สกิล: สกิลทางการของ Hegel, สกิลเทสต์ Rust จาก ECC (คอลเลกชันสกิลที่มี 250,000 ดาวและ 38,000 fork บน GitHub), สกิล property test ของ Trail of Bits และสกิลที่ Dan Luu เขียนเองแบบเร็ว ๆ — สามตัวแรกถูกเลือกเพราะเป็นสกิลที่ codex ค้นเจอเป็นอันดับต้นเมื่อถูกสั่งให้หาสกิลเทสต์

ผลรวมคือ “ไม่มีอะไรชนะขาดเลย” และประโยคที่ควรทำให้คนเขียน AGENTS.md ทั่วโลกหยุดคิด: Default (ไม่สั่งอะไรเพิ่ม) ทำได้สูงกว่าค่าเฉลี่ยอย่างชัดเจน ที่ระดับ xhigh กลุ่ม fuzzing และ property-based testing ทำได้ดีกว่า formal methods อยู่เล็กน้อย ส่วนที่ระดับ medium ผลปนกันมาก และ TDD ทำได้ไม่ดีตามที่ผู้เขียนทายไว้ล่วงหน้า (ที่ความมั่นใจ 55%)

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

หลักฐานรายเงื่อนไข: พิสูจน์สิ่งที่ไม่มีบั๊ก ใต้เสาไฟที่สว่าง

รายละเอียดต่อเงื่อนไขคือส่วนที่มีประโยชน์ที่สุดสำหรับคนเขียนพรอมต์จริง:

• Verus — เอเจนต์ไม่ได้พิสูจน์ว่าโค้ดตรงสเปกเลย แต่ไปพิสูจน์คุณสมบัตินามธรรมแทน และหลายครั้งเขียน proof แบบวนเปล่า A => A ตัวอย่างจริงที่พบคือบล็อกที่ requires ว่า 0 < a <= window, 0 < b <= window, 0 < c <= window แล้ว ensures ทั้งสามข้อเดิมกลับมา ที่น่าสนใจกว่านั้นคือฟีเจอร์ jump table สี่สตรีมที่เอเจนต์มักพลาด — เอเจนต์ฝั่ง Verus เขียนเทสต์ให้มัน 89 จาก 160 รัน ซึ่งเท่ากับฝั่ง Default พอดี แต่เขียนเทสต์ที่แย่กว่า เช่นให้ทั้งสี่สตรีมเหมือนกันหมด
• Alloy — ได้คะแนนความถูกต้องแย่เป็นอันดับสอง มีเคสหนึ่งที่ Alloy หา counterexample เจอจริงและเอเจนต์ไปแก้โค้ด Rust ตาม แต่ counterexample นั้นอาศัย overflow 8 บิตซึ่งเกิดไม่ได้ในโค้ดจริงที่ใช้ usize 64 บิต ผลคือโค้ดซับซ้อนขึ้นโดยไม่ได้กันบั๊กอะไร
• Differential testing — แย่เป็นอันดับสาม ไม่มีเอเจนต์รันไหนเลยที่สร้าง implementation สองชุดเต็ม ๆ มาเทียบกัน จาก 160 รันมี 135 รันที่ทำอะไรที่พอเรียกว่า differential ได้ แต่ในเคสที่มันน่าจะจับบั๊กได้ เอเจนต์กลับเขียนของเดิมซ้ำสองรอบและฝังบั๊กเดียวกันลงไปทั้งสองชุด
• QuickCheck — 63 จาก 160 รันเช็กคุณสมบัติเพียงข้อเดียว และใช้อินพุตสุ่มล้วนซึ่งสำหรับ Zstd แทบทั้งหมดตกลงไปในเส้นทาง reject ไม่กี่เส้น
• TLA+ — 159 จาก 160 รันสร้างโมเดลจริง และ 30 รันโมเดลส่วน Huffman/FSE/entropy ซึ่งเป็นจุดที่มีบั๊กบ่อย แต่ผู้เขียน ไม่พบสักเคสเดียวที่ปัญหาซึ่งเจอใน TLA+ นำไปสู่การแก้โค้ด Rust จริง
• SMT solvers — มีการคำนวณที่ควรเป็น byte1 + (byte2 << 8) + 0x7F00 แต่เอเจนต์จำนวนมากเขียน byte1 + (byte2 << 8) | 0x7F00 แทน และถึงจะใช้ SMT พิสูจน์คุณสมบัติรอบ ๆ การคำนวณนั้นแล้วก็ยังเขียนโค้ดผิดอยู่ดี
• Kani — เป็นตัวเดียวที่ถูกใช้กับโค้ดที่รันจริงได้ดีที่สุด แต่ มีเพียง 1 จาก 160 รัน ที่ใช้ Kani จนจับบั๊กที่ไม่ใช่เรื่องเล็กได้ และต้นทุนสูงกว่าเงื่อนไขอื่นชัดเจนเพราะการอ่านเอาต์พุตของ Kani ซ้ำ ๆ กินโทเคนขาเข้ามาก
• ACL2 — OOM ที่เพดาน 192 GiB ในหลายเคส รันที่ OOM ถูกตัดออก ซึ่งผู้เขียนระบุเองว่าทำให้ผลลัพธ์เอนเอียงในทางที่มองไม่เห็น

คำอธิบายที่ผู้เขียนใช้คือมุกไฟถนน: คนเมาทำกุญแจหายในสวน แต่มาหาใต้เสาไฟเพราะ “ตรงนี้มันสว่าง” เอเจนต์เลือกพิสูจน์และเทสต์สิ่งที่เทสต์ง่าย ไม่ใช่สิ่งที่มีบั๊ก

ส่วนที่กระทบ AGENTS.md และตลาดสกิลโดยตรง

ผลฝั่งสกิลคือส่วนที่แหลมที่สุด สกิลเทสต์ ECC ที่มี 250k ดาว ถูกเอเจนต์เปิดอ่าน 153 จาก 160 รัน และการอ่านทำให้มันเขียนเทสต์เยอะขึ้น — แต่เมื่อแยกดูตามว่าเอเจนต์อ่านสกิลเร็วหรือช้า กลับพบ gradient ที่ชัดเจนในทางกลับกัน: ยิ่งอ่านเร็ว ผลความถูกต้องยิ่งแย่ คะแนนรวมของ ECC ที่ดูพอ ๆ กับ Default นั้นมาจาก 7 รันที่เอเจนต์ไม่อ่านสกิลเลยแล้วได้ 100% กับอีก 9 รันที่อ่านตอนท้ายจนแทบไม่มีผลแล้วได้ 100% เช่นกัน เมื่อตัดเหลือเฉพาะเคสที่สกิลมีผลจริง ECC ได้ต่ำกว่าค่าเฉลี่ย สาเหตุที่ผู้เขียนชี้คือสกิลสั่งให้ทำ red-green TDD ซึ่งทำให้เอเจนต์ผลิตเทสต์เล็ก ๆ จำนวนมากที่ไม่มีความหมาย

สกิลของ Hegel และของ Trail of Bits ก็ไม่ชนะ Default เช่นกัน และผู้เขียนระบุว่าได้ทดลองแยกอีกสองชุดกับ สกิล “ทางการ” ของบริษัท — ชุดหนึ่งจาก AI lab ใหญ่ อีกชุดจากบริษัทระดับพันล้านดอลลาร์ — ทั้งสองชุดทำให้ผลแย่ลง เช่นกัน ข้อสังเกตของเขาคือสกิลเหล่านี้เขียนเหมือน “ทูโทเรียลสำหรับมนุษย์” คืออธิบายว่าเทคนิคทำงานอย่างไร ทั้งที่โมเดลรู้เรื่องนั้นอยู่แล้ว สิ่งที่ควรเขียนคือข้อความที่ ดัดพฤติกรรมเริ่มต้น ของโมเดลให้เบนออกจากค่า default ไม่ใช่สอนตั้งแต่ศูนย์

สกิลที่ได้คะแนนสูงสุดคือสกิลที่ Dan Luu เขียนเองในเวลาไม่กี่นาที ซึ่งเป็นชุดคำสั่งห้าข้อในทำนอง “ก่อนเขียนโค้ด ให้ระบุจุดที่น่าจะมีบั๊กละเอียดอ่อน แล้วบอกความเข้าใจผิดที่เป็นไปได้ และหาการตรวจที่ผลลัพธ์ต่างกัน”, “หลังเขียนเสร็จ ให้อนุมานผลลัพธ์ใหม่อย่างอิสระด้วย context สดโดยห้ามใช้ helper เดิม”, “เวลาสุ่มอินพุต ให้เอนไปทางอินพุตที่พาไปสู่ state และเส้นทางที่น่าสนใจ ไม่ใช่สุ่มแบบตกลงเส้นทาง error เหมือนกันหมด” — แต่ผู้เขียนย้ำเองว่า มันไม่ได้ทำงานอย่างที่ตั้งใจ: ส่วน “fresh context” แทบไม่เคยถูกทำจริงเลย เขาจึงเรียกมันว่าดราฟต์แรกที่ยังไม่พร้อมใช้

ผลเสริมจากอีกโจทย์หนึ่ง (IMAP RFC, 40 รันต่อเงื่อนไข) ยืนยันภาพเดิม และมีเพียง รันเดียว ที่ได้คะแนนเต็ม — บังเอิญเป็นเงื่อนไข “Make no mistakes” ที่ระดับ medium ซึ่งผู้เขียนบอกตรง ๆ ว่าเป็นการสุ่ม

มุมมอง AI Curator

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

สำหรับทีมพัฒนาไทยที่กำลังเขียน AGENTS.md, CLAUDE.md หรือติดตั้งสกิลจาก marketplace ข้อสรุปที่ใช้ได้ทันทีมีสองข้อ หนึ่ง — การเพิ่มคำสั่งไม่ใช่การเพิ่มคุณภาพ ทุกบรรทัดที่ใส่เข้าไปมีต้นทุนโทเคนและมีโอกาสผลักเอเจนต์ไปทำงานที่ไร้ผล ถ้าไม่ได้วัด ให้สันนิษฐานว่าไฟล์คำสั่งยาว ๆ ของคุณกำลังทำให้แย่ลง ไม่ใช่ดีขึ้น สอง — การสั่งด้วยชื่อเทคนิคไม่ได้ผล บอกว่า “ใช้ property-based testing” ได้ผลต่างจาก “อย่าสุ่มอินพุตแบบที่ตกลงเส้นทาง error เดียวกันหมด” อย่างสิ้นเชิง เพราะอย่างแรกคือชื่อ อย่างหลังคือการดัดพฤติกรรมที่โมเดลทำผิดจริง

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

สุดท้าย ข้อค้นพบที่ควรทำให้สบายใจขึ้นคือคำแนะนำเชิงปฏิบัติของผู้เขียน: ถ้าคุณ วางโครงสร้างเทสต์และการ triage ที่สมเหตุสมผลไว้ให้ก่อน แล้วให้เอเจนต์เติมเข้าไป มันทำได้พอใช้โดยไม่ต้องคุมมาก ปัญหาไม่ได้อยู่ที่โมเดลไม่มีความรู้ แต่อยู่ที่ความรู้นั้นไม่ใช่พฤติกรรมเริ่มต้น และการเรียกชื่อเทคนิคยังไม่ใกล้พอที่จะดึงมันออกมา — ต้อง prime ให้ถูกทาง ซึ่งการดูผลลัพธ์แล้วพิมพ์เพิ่มอีกไม่กี่ประโยคยังได้ผลดีกว่าการยัดทุกอย่างไว้ล่วงหน้าในไฟล์สกิล

แหล่งข่าว

• Dan Luu — How well do agents use test/verification techniques?
• Dan Luu — What’s the best programming language for coding agents? (การทดลอง Zstd ชุดเดิมที่งานนี้นำมาใช้ต่อ)
• Hacker News — การพูดคุยเกี่ยวกับงานชิ้นนี้ (8 ก.ย. 2026)