ประสิทธิภาพการเขียนโค้ดระยะยาวของ Opus 5 ผ่าน SlopCodeBench

• ใน เบนช์มาร์กการเขียนโค้ดระยะยาว ที่มีการเพิ่มข้อกำหนดเป็นลำดับขั้น Opus 5 ผ่านแบบเข้มงวดได้เพียง 4 จาก 17 เช็กพอยต์ จึงยังยากจะเชื่อถือได้สำหรับการพัฒนาโค้ดเบสต่อเนื่องโดยไม่ต้องมีการแทรกแซงตลอดเวลา
• SlopCodeBench จะเปิดเผยข้อกำหนดใหม่ในแต่ละเช็กพอยต์ และจะนับว่าสำเร็จก็ต่อเมื่อผ่านทั้งข้อกำหนดใหม่และ regression test ก่อนหน้าทั้งหมด จึงวัด ความสามารถในการบำรุงรักษาระยะยาว ได้มากกว่าการแก้ปัญหาแบบครั้งเดียวจบ
• อัตราผ่านแบบเข้มงวดของ Opus 5 อยู่ที่ 24% สูงกว่า Opus 4.8 และ Sonnet 5 ที่ 6% แต่ทั้งสามโมเดลก็ยังไปไม่ถึงเช็กพอยต์สุดท้ายของโจทย์ง่าย กลาง และยากโดยไม่มีข้อบกพร่อง
• Opus 5 เขียนฟังก์ชันและหน่วยที่เรียกใช้งานได้มากกว่า Opus 4.8 ถึง 5 เท่า และเขียน production code มากกว่าราว 1.8 เท่า โดยเมื่อดำเนินไปทุกโมเดลต่างมี ความซับซ้อน ความยืดยาว และ code smell เพิ่มขึ้น
• เมื่อเทียบกับตัวชี้วัดคุณภาพโค้ดแบบเดี่ยว อัตราการผ่านของสเปกสะสมทั้งหมด สะท้อนความสามารถในการบำรุงรักษาได้สมจริงกว่า และหากทำได้เกิน 80% ในเบนช์มาร์กการพัฒนาแบบทำซ้ำที่แยกสภาพแวดล้อมได้ดี ก็อาจเพิ่มความเชื่อมั่นต่อการรันแบบไร้คนควบคุมได้มาก

---

SlopCodeBench ที่วัดข้อกำหนดแบบค่อยเป็นค่อยไป

• แม้เบนช์มาร์กการเขียนโค้ดแบบซับซ้อนเดิมก็เปิดโจทย์ทั้งหมดตั้งแต่แรก แต่ SlopCodeBench จะแบ่งข้อกำหนดเป็นหลาย เช็กพอยต์ และเปิดเผยตามลำดับ
• โมเดลต้องพัฒนาโค้ดเดิมต่อไปเรื่อย ๆ โดยไม่รู้ว่าหลังจากนี้จะมีการเพิ่มข้อกำหนดอะไร
• ในงานวิจัยต้นฉบับที่เผยแพร่เดือนมีนาคม 2026 GPT-5.4 และ Opus 4.6 มีอัตราผ่านแบบเข้มงวดที่ 11% และ 17% ตามลำดับ แสดงว่าเบนช์มาร์กนี้ยังไม่อิ่มตัว
• เอกสารที่เกี่ยวข้อง:
  • ตัวรัน SlopCodeBench
  • ชุดโจทย์ SlopCodeBench

การตั้งค่าการทดลองและเกณฑ์ผ่านแบบเข้มงวด

• รัน Opus 4.8, Sonnet 5 และ Opus 5 บน Claude Code harness ด้วยพรอมป์ต์เดียวกัน และใช้ หน้าต่างคอนเท็กซ์ใหม่ ในทุกเช็กพอยต์
• เลือก 3 โจทย์ที่มีทั้งง่าย กลาง และยาก รวม 17 เช็กพอยต์
  • circuit_eval: ง่าย, 8 จุด
  • database_migration: กลาง, 5 จุด
  • dynamic_config_service_api: ยาก, 4 จุด
• สำหรับแต่ละโมเดล รันทั้งสามโจทย์ตามลำดับ และรัน 3 โมเดลแบบขนาน ใช้เวลาทดลองรวมราว 6 ชั่วโมง
• ผ่านแบบเข้มงวด (strict pass) ต้องผ่านไม่ใช่แค่การทดสอบฟีเจอร์ใหม่ แต่รวมถึง regression test ทั้งหมดที่สืบทอดมาจากเช็กพอยต์ก่อนหน้าด้วย
  • เมื่อโมเดลเขียนโค้ดของเช็กพอยต์ 1 เสร็จ evaluation harness จะรันการทดสอบ black-box แบบปิด
  • ในเช็กพอยต์ 2 จะรันการทดสอบของเช็กพอยต์ 1 และ 2 พร้อมกัน และจะสะสมแบบเดียวกันต่อไป
  • การทดสอบจะทำกับจุดเข้าใช้งานจริงที่โมเดลสร้างขึ้น เช่น CLI หรือ API server
• หากไม่ได้แก้ข้อบกพร่องเก่าโดยบังเอิญในเซสชันถัดไป ความล้มเหลวที่เช็กพอยต์หนึ่งจะขวางไม่ให้ผ่านแบบเข้มงวดในจุดถัดไป
• ทั้ง 9 การรัน ไม่มีความท้าทายใดเลยที่ ผ่านครบจนถึงเช็กพอยต์สุดท้าย แม้กระทั่งโจทย์ง่าย

ต้นทุนและข้อบกพร่องที่พบระหว่างการรัน

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

ผลความแม่นยำสุดท้าย

• Opus 5 ผ่านแบบเข้มงวด 4 จาก 17 จุด คิดเป็น 24%
  • สามเช็กพอยต์แรกของ circuit_eval
  • เช็กพอยต์แรกของ database_migration
• Opus 4.8 และ Sonnet 5 ต่างผ่านเพียงเช็กพอยต์แรกของ database_migration อย่างละหนึ่งจุด คิดเป็น 6%
• หากนิยามว่าต้องไปถึงเช็กพอยต์สุดท้ายโดยไม่มีข้อบกพร่องจึงจะถือว่าสำเร็จ Opus 5 ก็ยังล้มเหลวทั้งสามโจทย์ เพียงแต่ล้มเหลวน้อยกว่าโมเดลอื่น
• แม้จะเห็นแนวโน้มว่าต้นทุนสูงขึ้นแล้วความแม่นยำก็ดีขึ้น แต่จากชุดย่อยขนาดเล็กนี้ยังสรุปไม่ได้ว่า การใช้จ่ายที่เพิ่มขึ้นทำให้อัตราผ่านสูงขึ้น
• จากการผ่าน 4 จุดของ Opus 5 มีถึง 3 จุดที่กระจุกอยู่ช่วงต้นของโจทย์เดียว จึงยังมีพื้นที่ให้ใช้แยกความสามารถของโมเดลรุ่นถัดไปได้อีกมาก

ตัวชี้วัด 41 รายการสำหรับติดตามคุณภาพโค้ด

• SlopCodeBench คำนวณ ตัวชี้วัดแบบกำหนดแน่นอน 41 รายการ จากสถานะโค้ดปัจจุบันในแต่ละเช็กพอยต์
  • ขนาด: จำนวนบรรทัดซอร์สโค้ด จำนวนไฟล์ ฟังก์ชัน เมธอด คลาส และคำสั่ง รวมถึงจำนวนบรรทัดที่เพิ่มและลบ
  • ความซับซ้อน: ค่าเฉลี่ย ค่าสูงสุด และการกระจายของ cyclomatic complexity จำนวนฟังก์ชันในช่วงสูงและสูงมาก ความเข้มข้นของความซับซ้อน ความลึกซ้อนกันสูงสุด และความยาวฟังก์ชันเฉลี่ย
  • ความซ้ำซ้อน: บรรทัดที่ซ้ำและสัดส่วนเมื่อเทียบกับซอร์สทั้งหมด
  • โครงสร้างการแยกย่อย: ฟังก์ชันที่ถูกใช้เพียงครั้งเดียว simple wrapper ตัวแปรที่ไม่ได้ใช้ และจำนวนบรรทัดโค้ดต่อสัญลักษณ์
  • การละเมิดกฎ: จำนวน lint error และจำนวนที่แก้อัตโนมัติได้ การตรวจจับกฎ code smell สำหรับโค้ดทดสอบด้วย ast-grep และสัดส่วนของบรรทัดที่ถูกทำเครื่องหมายว่ายืดยาวเกินไป
  • กราฟการพึ่งพา: ค่า change propagation cost ขนาดของ circular dependency และ dependency entropy
• ตัวชี้วัดเหล่านี้คำนวณซ้ำได้ในรูปแบบเดียวกัน และไม่พึ่งการตัดสินเชิงอัตวิสัยของโมเดล แต่ความสัมพันธ์ระหว่างตัวชี้วัดแต่ละตัวกับ ความง่ายในการเปลี่ยนโค้ด ยังไม่ได้รับการยืนยัน
• เมื่อเทียบเช็กพอยต์แรกกับเช็กพอยต์ที่แปดของ circuit_eval ตัวชี้วัดส่วนใหญ่ยังแยกความแตกต่างระหว่างโมเดลได้ไม่ชัด
• ยังสามารถเกิด reward hacking โดยปรับให้ดีขึ้นเฉพาะบางตัวชี้วัด จึงยากจะใช้เป็นตัวตัดสินแทนคุณภาพโค้ดโดยรวม

โค้ดที่เพิ่มขึ้นเพื่อแลกกับความแม่นยำ

• Opus 5 เขียนฟังก์ชันและหน่วยที่เรียกใช้งานได้ มากกว่า Opus 4.8 ถึง 5 เท่า ในโจทย์เดียวกัน
• ส่วนเพิ่มจำนวนมากเป็นโค้ดทดสอบ และเมื่อดูเฉพาะ production code Opus 5 เขียนมากกว่า Opus 4.8 ราว 1.8 เท่า
• โค้ดที่มากขึ้นสัมพันธ์กับความแม่นยำที่ดีขึ้นเล็กน้อย แต่ยังต้องวิเคราะห์เพิ่มเติมว่าเป็นเพียงความยืดยาวที่มีต้นทุนสูง หรือความยากของโจทย์ต้องการโค้ดมากขึ้นจริง

ผลการตรวจจับ code smell และข้อจำกัด

• เมื่อเฉลี่ยทั้งสามโจทย์ สัดส่วนของบรรทัดโค้ดที่ติดอย่างน้อยหนึ่งกฎ code smell สูงมาก
  • Opus 4.8: 98%
  • Opus 5: 93%
  • Sonnet 5: 89%
• บรรทัดที่ถูกทำเครื่องหมายว่ายืดยาวเกินไปเพิ่มขึ้นในทุกโมเดล จากราว 65% ในเช็กพอยต์แรกไปเป็นราว 80% ในเช็กพอยต์ที่แปด
• สัดส่วนที่สูงมากนี้ยังชี้ว่ากฎคุณภาพบางข้ออาจก้าวร้าวเกินไป
• ตัวตรวจจับ SlopCodeBench เดิมรองรับเฉพาะ Python
  • แม้จะสร้างกฎ TypeScript 76 ข้อด้วย 5.6-Sol แต่ก็ยังน้อยกว่าไลบรารี Python ที่มีมากกว่า 200 ข้อ และไม่ได้ตรวจสอบความเท่าเทียมกันของกฎ
  • ภายใต้กฎชุดจำกัดนี้ โค้ด TypeScript ที่ Opus 5 สร้างแบบไร้คนควบคุมมีการตรวจจับต่อ kLOC มากกว่า 11 เท่า เมื่อเทียบกับ monorepo TypeScript ที่มีการตรวจทานอย่างละเอียดและมีโค้ดจาก AI 99%
  • ด้วยข้อจำกัดหลายอย่าง เช่น จำนวนกฎและการตรวจสอบความเท่าเทียมกัน จึงควรมองเป็นเพียงผลเชิงทิศทาง

สมดุลระหว่างการแยกฟังก์ชันกับความซับซ้อนและความซ้ำซ้อน

• Opus 5 มีจำนวนฟังก์ชันมากกว่าอีกสองโมเดลถึง 5 เท่า แต่มีค่าเฉลี่ยความซับซ้อนต่ำที่สุด และโดยรวมเขียนฟังก์ชันไปประมาณ 2,000 ฟังก์ชัน
• Opus 4.8 มีฟังก์ชันเกือบ 50% ที่ถูกเรียกใช้งานเพียงครั้งเดียว ส่วนสัดส่วนฟังก์ชันใช้ครั้งเดียวของ Sonnet 5 สูงสุดที่ 71.5%
• การมีฟังก์ชันเล็กจำนวนมากไม่ได้แปลว่าเป็นโค้ดที่แย่เสมอไป เพราะฟังก์ชันเล็กที่สื่อความหมายอาจดีกว่าคอมเมนต์จำนวนมาก
• ทุกโมเดลมีความซับซ้อนเพิ่มขึ้นเมื่อเช็กพอยต์ดำเนินไป
  • Sonnet 5 และ Opus 4.8 รับมือกับข้อกำหนดที่เพิ่มขึ้นด้วยการทำให้ฟังก์ชันแต่ละตัวใหญ่ขึ้น แทนที่จะจัดวางโครงสร้างใหม่
  • ความซับซ้อนของ Opus 4.8 เพิ่มขึ้น 70% ตลอด 8 เช็กพอยต์ และฟังก์ชันที่แย่ที่สุดมี cyclomatic complexity สูงถึง 93
• ในด้านความซ้ำซ้อน มีความแตกต่างระหว่างโมเดลอย่างชัดเจน
  • อัตราความซ้ำซ้อนของ Opus 4.8 เพิ่มจาก 4.6% เป็น 16.8% และพุ่งขึ้นอย่างรวดเร็วราวเช็กพอยต์ 3 ซึ่งเป็นช่วงที่การออกแบบเริ่มต้นเริ่มชนกับข้อกำหนดใหม่
  • ในช่วงท้าย โค้ดประมาณหนึ่งในหกบรรทัดเป็นสำเนาของบรรทัดอื่น
  • อัตราความซ้ำซ้อนของอีกสองโมเดลกลับลดลงในช่วงเดียวกัน
  • Opus 5 แทบไม่เปลี่ยน จาก 2.41% เป็น 2.64%
• หากดูเฉพาะความซ้ำซ้อนก็อาจบอกได้ว่าโมเดลรุ่นใหม่ปรับดีขึ้นเล็กน้อย แต่คุณภาพของโครงสร้างซอฟต์แวร์ไม่อาจตัดสินจากตัวชี้วัดเดียว

ตัวตัดสินที่ดีกว่าสำหรับวัดความสามารถในการบำรุงรักษา

• ต่างจาก SWE-bench ที่ประเมินการแก้ปัญหาซอฟต์แวร์ครั้งเดียว การ ผ่านตัวตรวจสอบทั้งหมดของสเปกที่เปิดเผยเพิ่มทีละส่วน วัดการบำรุงรักษาโค้ดเบสระยะยาวได้ใกล้กับงานจริงมากกว่า
• โค้ดเบสที่บำรุงรักษายากจะนำไปสู่ความล้มเหลวในเช็กพอยต์ท้าย ๆ ดังนั้นอัตราผ่านแบบเข้มงวดที่สูงเองก็อาจเป็นสัญญาณว่ามีการสร้างโค้ดที่แก้ไขเปลี่ยนแปลงได้ง่าย
• โมเดลอย่าง Fable หรือ Sol ที่เก่งด้านดีบักและ reverse engineering อาจทำงานจนจบได้แม้บนโค้ดที่โครงสร้างไม่ดี ดังนั้นในอนาคตควรวัดต้นทุน เวลา และโทเคนร่วมด้วย
  • หากโค้ดถูกแยกโครงสร้างมาดี ข้อกำหนดถัดไปก็มักจะแก้ได้ในเวลาสั้นลงและใช้โทเคนน้อยลง
• การประเมินที่ต้องสร้างฟังก์ชันครบทั้ง 8 เช็กพอยต์ช้ากว่าโจทย์ SWE-bench แบบสั้น แต่สามารถรันแบบไร้คนควบคุมได้และใช้ ตัวตรวจสอบแบบกำหนดแน่นอน ได้ในตอนท้าย
• เมื่อเทียบกับวิธีให้โมเดลอื่นดูโค้ดแล้วตัดสินว่าสะอาดหรือไม่ เกณฑ์ที่ดีกว่าคือผ่านข้อกำหนดจริงหรือไม่

ขยายสัญญาณความสามารถในการบำรุงรักษาด้วยโมเดลเล็ก

• มีข้อเสนอให้โมเดลชั้นนำอย่าง Opus 5, Fable 5 และ GPT-5.6-Sol ลงมือทำเช็กพอยต์แรก ๆ จำนวน N จุดก่อน แล้วส่งต่อ งานลำดับ N+1 ให้โมเดลเล็กอย่าง Sonnet 5, GPT-5.6-Terra หรือ Haiku
• หากโมเดลเล็กสามารถทำการแก้ไขต่อได้ ก็เป็นตัวชี้ว่าช่วงก่อนหน้านั้นโมเดลชั้นนำยังรักษาโครงสร้างที่แก้ไขง่ายไว้ได้
• ตัวอย่างเช่น หากนำความสำเร็จของโมเดลเล็กในเช็กพอยต์ 8 มาสะท้อนในคะแนนของโมเดลชั้นนำสำหรับเช็กพอยต์ 1~7 ก็อาจขยายสัญญาณคุณภาพโค้ดได้

เกณฑ์สำหรับเชื่อถือการเขียนโค้ดแบบไร้คนควบคุม

• โมเดลในปัจจุบันยังยากจะเชื่อถือได้สำหรับการ รันแบบไร้คนควบคุมโดยไม่มีการกำกับต่อเนื่อง ในงานที่ต้องลงมือทำ issue ทีละรายการเหมือนซอฟต์แวร์จริง
• คะแนนที่ดีจากเบนช์มาร์กอย่าง Frontier Code, SWE-Marathon หรือ DeepSWE เพียงอย่างเดียว ยังไม่พอสำหรับมอบหมายทั้งโค้ดเบส
• หากโมเดลทำได้ เกิน 80% ในเบนช์มาร์กการพัฒนาแบบทำซ้ำที่แยกสภาพแวดล้อมได้ดีอย่าง SlopCodeBench ก็อาจเพิ่มความเชื่อมั่นต่อการรันแบบไร้คนควบคุมได้อย่างมาก
• สิ่งสำคัญไม่ใช่แค่จะไปถึงจุดนั้นเมื่อไร แต่คือต้องมีสัญญาณที่ใช้แยกแยะความก้าวหน้าจริงได้ และข้อมูลทดสอบต้องไม่ปะปนในข้อมูลฝึก

การทดลองต่อเนื่องและจุดปรับปรุงการประเมิน

• มีแผนจะทบทวนโจทย์ SlopCodeBench ที่รองรับงานพัฒนาทั่วไปในชีวิตจริงได้ดีให้ลึกขึ้น และคัดเลือกบางส่วนมาใช้
• ครั้งนี้รันสามโจทย์ตามลำดับสำหรับแต่ละโมเดล แต่ถ้าทำ 9 เซสชันแบบขนาน สำหรับ 3 โมเดลและ 3 โจทย์ ก็อาจจบได้ใน 1~2 ชั่วโมงแทน 6 ชั่วโมง
• จำเป็นต้องย้ายกฎ code smell ที่ใช้ได้เฉพาะ Python ไปยัง TypeScript และภาษาอื่น
• นอกจาก strict pass และจำนวนข้อบกพร่องรวมแล้ว ยังควรสำรวจแกนการประเมินอื่นเพิ่มเติม
  • คะแนนปัจจุบันนับความล้มเหลวก่อนหน้าเป็นข้อบกพร่องสะสม และใช้ปิดกั้นการผ่านในเช็กพอยต์ถัดไป
  • ไม่ได้ใช้พรอมป์ต์แปรผันที่ระบุคุณภาพหรือความซ้ำซ้อนอย่างชัดเจน แต่ใช้พรอมป์ต์ just-solve ของ SlopCodeBench
  • อาจเพิ่ม ลูปรีวิวเชิงปฏิปักษ์ ที่ให้โมเดลตัดสินคุณภาพ
  • อาจใส่แรงต้านเชิงคุณภาพโค้ดให้กับตัวชี้วัดอย่าง cyclomatic complexity
• การทดลองกับชุดข้อมูลที่ใหญ่ขึ้น และการส่งต่อโค้ดเบสที่ Fable สร้างให้โมเดลเล็กอย่าง Sonnet ดูแลต่อ ก็ยังเป็นงานถัดไป

โครงสร้าง 17 เช็กพอยต์

• circuit_eval — ง่าย, การจำลอง

  • ck1: CLI ของวงจร 1 บิตที่มี --help, --version, เอาต์พุต JSON และคำสั่ง check สำหรับตรวจสอบไฟล์ .circ
  • ck2: คำสั่ง eval ที่รับอินพุตแล้วให้ผลลัพธ์ของ Boolean operation มาตรฐาน
  • ck3: สัญญาณเวกเตอร์ การ slice/index/concatenate, MUX, reduction, EQ, การตรวจสอบความกว้างของ operand และเอาต์พุต --radix
  • ck4: ตรรกะสามค่า ที่มีค่าไม่ทราบค่า X
  • ck5: เพิ่มรูปแบบอินพุต .json และ .bench ด้วย --format
  • ck6: stats สำหรับสถิติ, lint สำหรับคำเตือน, dot สำหรับเอาต์พุต Graphviz
  • ck7: การแยก subcircuit ด้วย cone, การแสดงผลลัพธ์ทั้งหมดด้วย truth-table, การเปรียบเทียบวงจรด้วย equiv, และ --seed สำหรับสุ่มที่ทำซ้ำได้
  • ck8: ตัวปรับแต่ง opt ที่รองรับ pass แบบกำหนดค่าได้ เอาต์พุตแบบกำหนดแน่นอน และการตรวจสอบความเท่าเทียมแบบเลือกได้พร้อมเอาต์พุต BENCH

• database_migration — กลาง, ฐานข้อมูล

  • ck1: CLI ที่อ่านสเปก migration แบบ JSON แล้วสร้างตาราง SQLite เพิ่มคอลัมน์ และเปลี่ยนโครงสร้าง
  • ck2: data migration ที่แปลงแถวเดิมด้วย SQL expression
  • ck3: foreign key, ดัชนีที่ผู้ใช้กำหนดเอง และข้อกำหนดขั้นสูง
  • ck4: rollback แบบทีละรายการหรือเป็นชุด พร้อมจัดการ dependency
  • ck5: การตีความลำดับ depends_on และการตรวจจับ circular dependency

• dynamic_config_service_api — ยาก, การออกแบบระบบ

  • ck1: บริการ REST สำหรับการตั้งค่าแบบ JSON ที่รองรับเวอร์ชันไม่เปลี่ยนแปลง การกำหนดขอบเขต การย้อนกลับไปใช้เวอร์ชันเก่า และการนำเข้า/สืบทอดระหว่างการตั้งค่า
  • ck2: schema registry ที่มีเวอร์ชันของตัวเอง การเชื่อมโยงสคีมากับการตั้งค่า การตรวจสอบตอนสร้างและตอนตีความ และการแปลง YAML, TOML, JSON ไปเป็น JSON มาตรฐานภายใน
  • ck3: โฟลว์จัดการการเปลี่ยนแปลงที่มี draft, proposal, การตรวจทานโดยมนุษย์, การเปิดใช้งานแบบ quorum และความต่างแบบกำหนดแน่นอน
  • ck4: กลไกป้องกันระดับองค์กรที่บังคับใช้นโยบายกับการตั้งค่าที่ตีความแล้วและกราฟแวดล้อมใกล้เคียง พร้อมรายละเอียดการละเมิดที่แยกจาก schema error เพื่อบล็อก proposal ที่เสี่ยง

ปัญหาการควบคุมเอเจนต์ที่พบภายนอกการทดลอง

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

[GN⁺]

ความคิดเห็นบน Hacker News

• SCB เป็น benchmark ที่ถูกประเมินค่าต่ำไป มันไม่จบในงานเดียว จึงคล้ายกับการพัฒนาซอฟต์แวร์จริงมากกว่า และจุดที่ไม่เหมือนใครคือ agent ต้องรักษาโค้ดให้สะอาดอย่างต่อเนื่อง
  อย่างไรก็ดี ทุกโจทย์เป็นโปรเจกต์ใหม่และยังไม่ได้ initialize Git ทำให้ agent ใช้ git diff ไม่ได้ ผมเคยลองใช้ SCB ตอนประเมินทักษะของ agent ด้วย: https://orcabot.com/labs/do-skills-improve-coding-agent-accu...
  ยังมีชุมชน Discord เล็ก ๆ ที่คุยเรื่อง SCB กำลังเติบโตอยู่ด้วย: https://discord.gg/BrC4BA9sVj

• ก่อนให้ Claude เริ่มเขียนโค้ด ผมให้มันอ่านคำปฏิญาณว่าจะถ้าเจอ โค้ดซ้ำซ้อน ระหว่างทำงานก็จะแก้ให้ มันหาโค้ดซ้ำเจอ แต่ส่วนใหญ่มักเข้าสู่โหมดแก้ไขก็ต่อเมื่อเราบอกว่ามีบั๊ก แล้วจึงค่อยนำความชอบแบบ DRY ใน CLAUDE.md ไปใช้จริง
  paper ต้นฉบับก็พบว่า prompt แบบ plan_first ช่วยให้ดีขึ้น แต่ไม่ได้มีผลต่ออัตราผ่านสุดท้าย วิธีนี้ตั้งสมมติฐานว่า agent จะ refactor เองหลัง implement ฟีเจอร์ แต่ในทางปฏิบัติ ดูเหมือนต้องสั่งให้แก้บั๊ก ไม่ใช่แค่เพิ่มฟีเจอร์ จึงจะเกิด refactoring ที่มีนัยสำคัญ
  benchmark ซ่อน test ไว้ และไม่ให้ feedback ว่าจากที่ fail กลายเป็น pass ด้วย ดังนั้น performance อาจลดลงต่อเนื่องแบบ monotonic ได้

  • นั่นก็แค่ ความเชื่อไสยศาสตร์ น่ะ

• เพิ่งได้อ่าน paper และ benchmark นี้เมื่อไม่นานมานี้ และมันใกล้เคียงกับความพยายามครั้งแรก ๆ ในการประเมิน requirements ระยะยาวและ non-functional ที่สำคัญเสมอในโค้ด production ตอนนี้โมเดลดีพอจะแก้ปัญหาแบบครั้งเดียวจบส่วนใหญ่ได้แล้ว จึงยิ่งเหมาะกับเวลาเป็นพิเศษ
  อีกจุดที่ดีคือได้คะแนนที่ชี้ขาดได้ด้วย ‘maintainability’ น่าจะใกล้กับพื้นที่มิติสูงที่ประกอบจากสัญญาณหลายอย่าง และการทำความเข้าใจพื้นที่นั้นอาจต้องอาศัยการ label จากมนุษย์
  อีกสัญญาณหนึ่งคือ state space ของระบบ และช่วงนี้ formal methods ก็โผล่มาบ่อยขึ้นด้วย

  • ไม่ใช่แค่ state space ของระบบ เท่านั้น วิธีทำให้โมเดลเข้าถึงและมองเห็นมันได้ก็สำคัญเช่นกัน ถ้า ‘แสดง’ state ในรูปแบบที่เหมาะกับโมเดล มักได้ผลลัพธ์ที่น่าทึ่ง
    เหตุผลที่แค่เพิ่ม CLI หนึ่งตัวใน environment ก็สร้าง breakthrough ใหญ่ได้ ก็เพราะมันทำให้สังเกตและจัดการ state ที่ซับซ้อนได้อย่างมีโครงสร้าง
  • การอธิบาย ‘maintainability’ ว่าเป็น พื้นที่หลายมิติ ที่ไม่เหมาะจะเป็น metric เดียว เป็นคำอธิบายที่กระชับและถูกต้อง
    state space ของซอฟต์แวร์ production ทั้งระบบที่พึ่งพา database หรือบริการ third-party อาจวัดได้ยากเกินไป แต่ถ้าแยกบางส่วนของระบบออกมาเป็น state machine ที่มีขอบเขตชัดเจน ก็น่าจะใช้เป็นตัวชี้วัดคุณค่าของ module ที่อยู่หลัง interface ที่สะอาดได้
    Kubernetes control loop เป็นตัวอย่างที่ดี component ขอบเขตจำกัดรับหน้าที่ control loop ของ state machine ที่นิยามไว้อย่างดี ทำงานและกู้คืนได้แม้เจอ network partition หรือ outage ส่วนใหญ่ เป็นแนวทางที่ใกล้กับการทำให้คำมั่นของ CRDT ใช้งานได้จริงมากขึ้น

• หวังว่าแล็บวิจัยใหญ่ ๆ จะนำ benchmark นี้ไปใช้ใน reinforcement learning pipeline การลดความซับซ้อนของโค้ดที่สร้างออกมาควรเป็นลำดับความสำคัญสูงสุด และโมเดลในอุดมคติควรเลือก abstraction ที่ถูกต้องเพื่อ implement ฟีเจอร์ พร้อมกับลดจำนวนบรรทัดของโค้ดได้ด้วย
  อีกอย่างที่ดีคือ benchmark นี้น่าจะใช้ปรับปรุง prompt และ skill เพื่อลด code complexity แบบวนซ้ำได้

  • ในชื่อของการลดจำนวนบรรทัดโค้ด ก็ง่ายที่จะเอนเอียงไปทาง ยัด logic จำนวนมากไว้ในบรรทัดเดียว มากเกินไป
  • อย่างน้อยในทางการ แล็บวิจัย ไม่ได้ train ด้วยข้อมูล benchmark อาจ train กับปัญหาคล้าย ๆ กันได้ แต่ string เฉพาะที่อยู่ใน benchmark ควรถูกกรองออกจาก training corpus อย่างจริงจัง

• ก็ดีอยู่ แต่ถ้า เทียบกับ performance ของมนุษย์ จะมีประโยชน์กว่านี้มาก เข้าใจว่าทำยาก แต่หลายคนน่าจะดูแค่ตัวเลขในหัวข้อแล้วเข้าใจผิดว่า Opus 5 อยู่ที่ระดับหนึ่งในสี่ของนักพัฒนามนุษย์

• Opus 5 ดีขึ้นจาก Opus 4.8 อย่างชัดเจน แต่สอดคล้องกับความรู้สึกของผมว่าไม่ได้ปฏิวัติวงการเหมือนที่รู้สึกกับ Fable
  ตอนนี้ผมใช้ Opus 5 medium แทน Opus 4.8 xhigh ใช้ token น้อยกว่าและเร็วกว่า เข้าใจว่าบางคนไม่ชอบสำนวนการเขียนของมัน แต่กับงานจริงผมไม่รู้สึกรำคาญเลย และใช้อยู่ด้วยความพอใจ

  • Fable ดูเหมือน ถูกลดทอนความสามารถโดยตั้งใจ ตอนออกมาแรก ๆ มันปฏิวัติวงการจริง ๆ แต่โมเดลก่อนมาตรการแบนกับโมเดลตอนนี้ไม่ใช่ตัวเดียวกัน
  • อยากฟังรายละเอียดเพิ่มว่าอะไรของ Fable ที่ทำให้รู้สึกว่า ปฏิวัติวงการ
  • สงสัยว่าทำไมถึงเลือก medium แทน high ในกราฟ performance ที่เห็น การขยับจาก medium ไป high ดีขึ้นค่อนข้างมาก ส่วนจาก high ไป xhigh ไม่ได้เพิ่มมากเท่านั้น

• วิธีแก้เท่าที่ผ่านมาคือรัน review โค้ดเบสทั้งหมด แยกต่างหากเป็นระยะ ๆ และถ้าเป็นไปได้ให้ Fable review แล้ว refactor หลายรอบตามผลที่ได้

  • ผมก็ชอบวิธีนี้เหมือนกัน ไม่อย่างนั้นมีความเสี่ยงจะติดอยู่ใน local optimum ที่ลึกเกินไป

• อยากเห็น ผล test ดิบ ผมคิดว่าโมเดลส่วนใหญ่น่าจะพลาด default_value ใน checkpoint 2 test ของ database_migration เพราะมันตีความได้ทั้งเป็น JSON literal และ SQL expression
  อาจมี test อื่น ๆ ที่ fail ได้ง่ายด้วยเหตุผลที่ไม่เกี่ยวกับสาเหตุที่ paper ยกมา ถ้าเปลี่ยนลำดับ checkpoint ภายในขอบเขตที่ dependency อนุญาต เช่น 3→2→5→4 ก็น่าจะเป็นการทดลองที่น่าสนใจ เพราะควบคุมความต่างของความยากในแต่ละ checkpoint ได้

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

• ไม่ได้ร่วมบทสนทนามาพักหนึ่งแล้ว แต่ดีใจที่ได้สร้างผลลัพธ์นี้ขึ้นมา ผมรู้สึกว่า Opus 5 ไม่ใช่การปรับปรุงครั้งใหญ่ และสิ่งที่ทำให้ ประหลาดใจ จริง ๆ มีแค่ Opus 4, 4.6 และ Fable ก่อนมาตรการลดทอน performance ของรัฐบาล Trump เท่านั้น

  • งานนี้เป็นแค่ จุดเริ่มต้น ที่เร็วและถูกที่สุดสำหรับลองกับโมเดลใหม่
    ต่อไปอยากรวม sol กับ Fable ด้วย สำรวจภาษามากขึ้น และปรับชุดโจทย์ให้สะท้อน benchmark ได้กว้างขึ้น
    โดยส่วนตัว Opus 4.5 ให้ความรู้สึกเชื่องช้ากว่า 4.1 ผมอาจลำเอียงเพราะเดาว่า 4.5 เป็นโมเดลที่เล็กกว่า จากข้อเท็จจริงที่ว่ามันเร็วกว่า 2.5 เท่าและถูกกว่า 2.5 เท่า

• สงสัยว่าถ้าให้ adversarial model ที่ลงโทษ code duplication และจำนวนบรรทัดโค้ดรวม จะชี้นำ performance บน benchmark นี้ได้มากแค่ไหน