วิเคราะห์และรีวิว: Benchmarking Opus 5 บน SlopCodeBench

สรุปสั้น ๆ

• Opus 5 ทำได้ 24% strict pass rate บน SlopCodeBench (ผ่าน 4 จาก 17 checkpoints) เทียบกับ Opus 4.8 ที่ผ่านแค่ 1 checkpoint (6%) และ Sonnet 5 ที่ผ่าน 1 checkpoint (6%) เช่นกัน
• ตัวเลขจาก paper ต้นทางที่ทีม UW Madison ทำไว้ Opus 4.6 อยู่ที่ 17% ส่วน GPT-5.4 อยู่ที่ 11% แปลว่า Opus 5 ขยับขึ้นจากรุ่นก่อนจริงแต่ยังไม่ถึงขั้นปล่อยให้เขียนโค้ดเองแบบไร้คนดูได้
• จุดที่น่ากังวลคือ Opus 5 เขียนโค้ด 29,065 บรรทัด มากกว่ารุ่นอื่น 5 เท่า และยังโดน “slop meter” flag ไป 93% ของบรรทัด — เก่งขึ้นก็จริง แต่ยัง over-engineer หนักอยู่

SlopCodeBench คือเบนช์มาร์กแบบไหน ทำไมต่างจากตัวอื่น

SlopCodeBench เป็นเบนช์มาร์ก long-horizon coding ที่ทีม UW Madison นำโดย Gabe Orlanski เปิดตัวเมื่อมีนาคม 2026 (long-horizon = โจทย์ยาวหลายขั้นตอน ไม่ใช่โจทย์สั้นจบในไฟล์เดียว)

จุดต่างจาก HumanEval หรือ SWE-bench ที่คุ้นกันคือ SlopCodeBench ไม่ได้บอกโจทย์ทั้งหมดตั้งแต่ต้น แต่ทยอยเปิด requirement ทีละ checkpoint โมเดลต้องต่อยอด codebase เดิมที่ตัวเองเขียนไว้ ไม่ใช่เขียนใหม่ตั้งแต่ศูนย์ทุกครั้ง

พูดง่ายๆ เปรียบเหมือนการจ้าง dev มาทำ feature ในโปรเจกต์จริง — วันแรกได้ requirement A, วันที่สองลูกค้าเพิ่ม requirement B, วันที่สามเปลี่ยนใจเรื่อง A บางส่วน dev ที่เก่งต้องแก้ของเดิมโดยไม่ทำระบบพัง ไม่ใช่ rewrite ใหม่ทั้งหมดทุกรอบ

เบนช์มาร์กแบ่งโจทย์เป็น 3 แนว: Circuit_eval (ง่าย — เขียน circuit simulator ที่รองรับหลาย input format), Database_migration (กลาง — เครื่องมือ migrate schema พร้อม rollback), และ Dynamic_config_service_api (ยาก — config service ที่มี versioning และ policy guardrails) แต่ละโจทย์มี 17 checkpoint รวมกันในชุดทดสอบของผู้เขียน

Opus 5 บนกระดาน — ตัวเลขจริง

ผลจากการทดสอบของผู้เขียนบทวิเคราะห์ต้นทาง Opus 5 ผ่าน 4 จาก 17 checkpoint คิดเป็น 24% ซึ่งถือว่าดีที่สุดในกลุ่มที่เอามาเทียบ

ตัวเลขจาก paper ต้นทางของทีม UW Madison เองก็มีให้เทียบด้วย — Opus 4.6 ทำได้ 17% ส่วน GPT-5.4 ทำได้ 11% แปลว่าเทียบข้ามรุ่นข้ามค่าย Opus 5 ก็ยังนำ แต่นำแบบยังไปไม่ถึงเส้น “เชื่อใจให้เขียนเองได้”

สังเกตประเด็น “บรรทัดโค้ด 29,065” ให้ดี — มากกว่ารุ่นอื่น 5 เท่า และเขียน function มากกว่า 5 เท่าเช่นกัน อ่านคู่กับ slop rate ที่ 93% แล้วภาพชัดว่า Opus 5 มีแนวโน้ม over-engineer มากกว่ารุ่นก่อน แม้ pass rate จะสูงขึ้นก็ตาม

”Slop meter” วัดอะไรกันแน่

คำว่า “slop” ในชื่อเบนช์มาร์กมาจากชุดกฎ 41 metric ที่ทีมออกแบบไว้วัดคุณภาพโค้ดแบบ deterministic ไม่ใช้ LLM มาให้คะแนนซ้อนอีกที (deterministic = รันซ้ำแล้วได้ผลเดิมทุกครั้ง ไม่มี randomness)

หมวดกฎแบ่งได้ประมาณนี้:

Size metrics — จำนวนบรรทัด, จำนวน function, ตัวชี้ความซับซ้อน จุดนี้ Opus 5 โดนหนักเพราะเขียนเยอะกว่ารุ่นอื่นมาก

Complexity measures — cyclomatic complexity, ระดับ nesting, ความยาว function ปกติดัชนีพวกนี้พุ่งขึ้นเรื่อยๆ ทุก checkpoint สำหรับทุกโมเดล ไม่มีตัวไหนหลุด pattern นี้

Duplication tracking — โค้ดที่ copy-paste ซ้ำกันในไฟล์เดียวกัน

Decomposition issues — function ที่ใช้แค่ครั้งเดียวหรือ wrapper บางๆ ที่ไม่ได้ช่วยอะไร

Rule violations — lint errors, บรรทัดยาวเกินไป

Dependency patterns — propagation cost, cyclic dependency

ที่น่าคิดคือผู้เขียนต้นทางเองยอมรับว่ากฎ slop อาจ “aggressive เกินไป” เพราะโค้ดจากทุกโมเดลโดน flag 89–98% ของบรรทัด — ถ้าเข้มขนาดนี้ ต่อให้ dev มนุษย์ระดับ senior ก็คงโดน flag ยับเหมือนกัน ตัวเลข slop เดี่ยวๆ เลยต้องอ่านคู่กับบริบท ไม่ใช่ตัดสินแค่ % ผ่าน

ตอนโค้ดที่ AI เขียนให้พังตอนตีสาม

จำได้ว่าเคยใช้ AI generate โค้ด deploy จริง เดโมสวย ผ่าน test case ทุกอัน หน้าตา production-ready สุดๆ

แต่พอเจอ edge case จริง เช่น input ว่าง หรือ concurrent request เยอะๆ ระบบล่มกลางดึก ต้องตื่นมาแก้เอง ปัญหาคือ benchmark แบบเดิมวัดแค่ “ผ่านหรือไม่ผ่าน” ไม่ได้ดูว่าโค้ดนั้น maintain ได้ไหม อ่านง่ายไหม จัดการ error ครบไหม

นี่คือจุดที่ SlopCodeBench ต่างออกไป มันพยายามวัด “คุณภาพ” ของโค้ดที่ AI เขียน ไม่ใช่แค่ compile ผ่านหรือ test เขียวหมด เปรียบ SlopCodeBench เหมือนช่างตรวจสภาพรถก่อนออกทริปไกล ไม่ใช่แค่เช็คว่าสตาร์ทติดไหม แต่ดูว่าขับทางไกลจริงแล้วพังกลางทางหรือเปล่า

ตัวเลข 24% ของ Opus 5 บอกว่า 3 ใน 4 ครั้งของงานยาวๆ ยังไปไม่ถึงฝั่ง แปลตรงๆ คือถ้าปล่อยให้ Opus 5 นั่งเขียน feature ต่อเนื่องหลาย checkpoint โดยไม่มีคนดู มีโอกาสสูงมากที่ระบบจะพังกลางทาง

Opus 5 ยืนอยู่ตรงไหนในตระกูล Claude

ในตระกูล Claude ปัจจุบัน Opus 5 คือรุ่นบนสุด เหนือ Sonnet 5 และ Haiku ที่เน้นความเร็วกับต้นทุนต่ำกว่า พูดแบบเข้าใจง่ายคือ Opus เป็น “พี่ใหญ่” ของบ้าน แบกงานหนักที่สุด ส่วน Haiku คือ “น้องเล็ก” ที่ตัวเบา ตอบไว เอาไว้ใช้งานที่ไม่ต้องคิดลึก

Anthropic วาง Opus ไว้สำหรับงานที่ต้อง reasoning ลึก โดยเฉพาะ coding-heavy กับ agentic workflow (การให้ AI วางแผนและลงมือทำงานต่อเนื่องหลายขั้นตอนเองโดยไม่ต้องสั่งทีละสเต็ป) ที่ต้องวางแผนหลายขั้นตอนต่อเนื่อง ไม่ใช่แค่ตอบคำถามสั้นๆ

ผลจาก SlopCodeBench ยืนยันภาพนี้ — Opus 5 ทำได้ 24% ในขณะที่ Sonnet 5 ทำได้แค่ 6% ช่องว่างกว้างขนาดนี้ในโจทย์ long-horizon แปลว่าถ้าจ่ายเงินเพิ่มไปใช้ Opus จริงในงานที่ต้องต่อยอด codebase ยาวๆ ก็มีเหตุผลรองรับ ไม่ใช่จ่ายเพราะแบรนด์อย่างเดียว

แต่ถ้าเป็นงานถามตอบสั้นๆ หรือ generate snippet สั้นๆ ราคาที่ต่างกันกับ Sonnet ไม่คุ้ม เลือก Sonnet 5 หรือ Haiku ยังคุ้มกว่าเยอะ

ตัวเลขเบนช์มาร์กแปลว่าอะไรในงานเขียนโค้ดจริง

SlopCodeBench วัดหลายมิติ ไม่ใช่แค่ “ทำโจทย์ผ่านไหม” แต่ละมิติแปลงเป็นซีนงานจริงได้ตรงๆ

Hallucinated API — เรียกฟังก์ชันที่ไม่มีอยู่จริง สำคัญตอน debug legacy code เพราะโค้ดเก่ามักใช้ library เวอร์ชันเฉพาะ ถ้า AI สร้าง API มั่ว โปรเจกต์พังทันที

Over-engineering — ยัด abstraction เกินจำเป็น ชนตรงกับตอนเขียน feature ใหม่ใน production ที่ทีมต้องอ่านโค้ดต่อ ยิ่งซับซ้อนเกิน ยิ่งช้าตอน maintain ตัวเลข 29,065 บรรทัดของ Opus 5 คือสัญญาณเตือนหมวดนี้ตรงๆ

Test coverage — ครอบคลุม edge case แค่ไหน วัดผลตอนรีวิว PR ของ AI โดยตรง เพราะ reviewer ต้องเชื่อได้ว่าเทสจับบั๊กจริง

Refactor safety — แก้โค้ดแล้ว behavior เดิมยังอยู่ไหม จุดนี้ตัดสินว่าปล่อยให้ AI แตะโค้ด production ได้เลยหรือต้องรอคนตรวจก่อน SlopCodeBench วัดตรงจุดนี้ผ่าน checkpoint ต่อเนื่องที่ต้องรักษาโค้ดเดิม

มิตินี้แหละที่ทำให้เบนช์มาร์กใช้ตัดสินใจงานจริงได้ ไม่ใช่แค่ตัวเลขสวยๆ บนกระดาษ

ข้อสรุปที่ผู้เขียนต้นทางเน้น

ผู้เขียน paper ต้นทางสรุปประโยคหนึ่งไว้แรงมาก — “โมเดลยังพึ่งพาไม่ได้ให้เขียนเองแบบปิดไฟไม่มีคนดู” (lights-off) สำหรับงาน incremental แบบนี้

ตัวเลข 24% ของ Opus 5 ที่ขยับจาก 17% ของ Opus 4.6 คือหลักฐานว่ามีความคืบหน้า แต่ยังห่างเส้น “autonomous” ที่ต้องเข้าใกล้ 90%+ ก่อนถึงจะปล่อยได้จริง

สรุปแบบตรงๆ ถ้าเป็นผม ผมมองว่า Opus 5 บน SlopCodeBench คือหลักฐานว่า “โมเดลรุ่นบนสุดกำลังเก่งขึ้นในงานยาก แต่ยังไม่ถึงจุดที่ปล่อยให้ทำเองได้” — ตัวเลข 24% ที่นำคู่แข่งเท่าตัว ก็ยังแปลว่า 3 ใน 4 ครั้งจบไม่สวย และ 93% ของโค้ดยังโดน slop meter flag เพราะฉะนั้นถ้าจะใช้จริง เตรียมคน review PR ให้ครบ อย่าไว้ใจกราฟ pass rate สวยๆ แล้วปล่อยยาว