Tóm tắt
SlopCodeBench được thiết kế để đo một vấn đề mà benchmark coding ngắn thường bỏ sót: model có giữ được chất lượng codebase khi requirement thay đổi nhiều vòng hay không. Thay vì đưa toàn bộ bài toán ngay từ đầu, benchmark mở dần yêu cầu qua các checkpoint, buộc model phải tiến hóa thiết kế mà không làm hỏng phần đã chạy.
Tác giả chạy Opus 4.8, Sonnet 5 và Opus 5 trên 3 bài với tổng cộng 17 checkpoint. Opus 5 thắng, nhưng thắng ở mức 4/17 strict pass, tương đương 24%. Opus 4.8 và Sonnet 5 mỗi model chỉ đạt 1/17.
Cách benchmark hoạt động
Mỗi challenge bắt đầu với một spec ban đầu, sau đó thêm requirement ở các checkpoint tiếp theo. Model không biết toàn bộ đề bài từ đầu, nên nó phải vừa implement tính năng mới vừa giữ những thứ cũ không regression.
Metric chính là strict pass: mọi test mới phải xanh và mọi regression test từ checkpoint trước cũng phải xanh. Nếu model làm hỏng checkpoint 4, lỗi đó sẽ kéo điểm các checkpoint sau xuống, trừ khi model vô tình hoặc chủ động sửa lại ở vòng sau.
Cách đo này gần với maintenance hơn SWE-bench một bước. Trong dự án thật, phần khó không chỉ là sửa bug hôm nay, mà là sửa bug hôm nay theo cách không biến task tuần sau thành bãi mìn.
Kết quả chính
Opus 5 đạt 4 strict pass trên 17 checkpoint. Ba pass đầu đến từ các checkpoint mở màn của một bài, và pass còn lại là checkpoint đầu của bài database migration.
Opus 4.8 và Sonnet 5 mỗi model chỉ đạt một strict pass. Không model nào hoàn thành toàn bộ một challenge với mọi checkpoint sạch lỗi, kể cả bài được gắn nhãn easy.
Tác giả cũng thấy code smell tăng theo thời gian. Opus 5 viết nhiều function hơn đáng kể, có lúc gấp 5 lần Opus 4.8, và mọi model đều tăng độ verbose qua trajectory. Một phần trong đó là thêm test, nhưng phần production code cũng phình ra.
Ý nghĩa với Dev
Nếu bạn dùng coding agent trong repo thật, đừng chỉ đo bằng một task demo. Hãy đo qua chuỗi thay đổi: thêm feature, đổi requirement, sửa regression, rồi xem codebase còn dễ sửa không.
Một agent có thể tạo pull request đầu tiên rất đẹp nhưng vẫn làm kiến trúc kém dần qua nhiều vòng. SlopCodeBench gợi ý một thước đo tốt hơn: model có để lại code đủ sạch để chính nó hoặc model nhỏ hơn tiếp tục sửa ở checkpoint sau không.
Cách áp dụng trong team
- Chạy eval nội bộ theo chuỗi requirement, không chỉ một issue độc lập.
- Giữ regression test từ vòng trước và bắt agent chạy lại sau mỗi thay đổi.
- Theo dõi tín hiệu chất lượng như duplication, cyclomatic complexity, số file touched và số function single-use.
- Thêm review loop hoặc quality backpressure nếu agent có xu hướng giải bằng cách phình code.
Kết luận
Opus 5 rõ ràng tốt hơn các model được so trong bài, nhưng 24% strict pass chưa phải mức để tắt đèn giao repo. Kết quả này không chống AI coding; nó chống cách đo quá dễ khiến team tưởng model đã sẵn sàng chạy một mình.