Hiệu năng lập trình dài hạn của Opus 5 qua SlopCodeBench

• Trong benchmark lập trình dài hạn nơi yêu cầu được bổ sung theo từng giai đoạn, Opus 5 chỉ vượt qua nghiêm ngặt 4 trong 17 checkpoint, nên vẫn khó tin cậy để phát triển codebase mà không cần can thiệp liên tục
• SlopCodeBench công bố yêu cầu mới ở mỗi checkpoint và chỉ công nhận thành công khi vượt qua cả các bài kiểm thử hồi quy trước đó, nhằm đo năng lực bảo trì dài hạn thay vì giải quyết vấn đề một lần
• Tỷ lệ vượt qua nghiêm ngặt của Opus 5 là 24%, cao hơn mức 6% của Opus 4.8 và Sonnet 5, nhưng cả ba mô hình đều không thể đi tới checkpoint cuối cùng ở các bài dễ, trung bình và khó mà không có lỗi
• Opus 5 viết số hàm/đơn vị có thể gọi nhiều gấp 5 lần và lượng code production khoảng 1,8 lần so với Opus 4.8; ở tất cả mô hình, độ phức tạp, sự dài dòng và code smell tăng lên khi tiến xa hơn
• Thay vì một chỉ số chất lượng code đơn lẻ, tỷ lệ vượt qua toàn bộ đặc tả tích lũy phản ánh thực tế hơn về khả năng bảo trì; cần đạt trên 80% trong benchmark phát triển lặp được cô lập tốt thì niềm tin vào chạy tự động không người giám sát mới có thể tăng đáng kể

---

SlopCodeBench đo các yêu cầu tăng dần

• Các benchmark lập trình phức tạp hiện có cũng công bố toàn bộ bài toán ngay từ đầu, nhưng SlopCodeBench chia yêu cầu thành nhiều checkpoint và công bố tuần tự
• Mô hình phải tiếp tục phát triển code hiện có trong khi không biết yêu cầu nào sẽ được thêm vào sau đó
• Trong bài báo gốc công bố tháng 3/2026, tỷ lệ vượt qua nghiêm ngặt của GPT-5.4 và Opus 4.6 lần lượt là 11% và 17%, cho thấy benchmark này vẫn chưa bão hòa
• Tài liệu liên quan:
  • Trình chạy SlopCodeBench
  • Bộ bài toán SlopCodeBench

Thiết lập thí nghiệm và tiêu chí vượt qua nghiêm ngặt

• Opus 4.8, Sonnet 5 và Opus 5 được chạy trong harness Claude Code với cùng prompt, và dùng cửa sổ context mới ở mỗi checkpoint
• Chọn 3 bài toán trộn lẫn mức dễ, trung bình và khó, tổng cộng 17 checkpoint
  • circuit_eval: dễ, 8 checkpoint
  • database_migration: trung bình, 5 checkpoint
  • dynamic_config_service_api: khó, 4 checkpoint
• Ba bài toán được chạy tuần tự cho từng mô hình, còn 3 mô hình chạy song song, nên toàn bộ thí nghiệm mất khoảng 6 giờ
• Vượt qua nghiêm ngặt (strict pass) chỉ được công nhận khi vượt qua không chỉ các bài kiểm thử tính năng mới mà cả mọi bài kiểm thử hồi quy kế thừa từ các checkpoint trước
  • Khi mô hình viết code cho checkpoint 1, harness đánh giá chạy các bài kiểm thử hộp đen không công khai
  • Ở checkpoint 2, các bài kiểm thử của checkpoint 1 và 2 được chạy cùng nhau, và tiếp tục tích lũy theo cùng cách ở các checkpoint sau
  • Các bài kiểm thử nhắm vào điểm vào thực tế như CLI hoặc API server do mô hình tạo ra
• Trừ khi lỗi trước đó tình cờ được sửa trong phiên sau, thất bại ở một checkpoint sẽ chặn cả việc vượt qua nghiêm ngặt ở các checkpoint tiếp theo
• Cả 9 lượt chạy, bao gồm cả bài dễ, đều không vượt qua toàn bộ tới checkpoint cuối cùng ở bất kỳ thử thách nào

Chi phí và lỗi xuất hiện trong quá trình chạy

• Sonnet 5 đắt nhất ở checkpoint đầu tiên, nhưng đến nửa sau của bài toán đầu tiên lại trở thành mô hình rẻ nhất trong ba mô hình
  • Điều này được diễn giải là hiệu quả tiết kiệm chi phí xuất hiện sau khi tạo cấu trúc cơ bản và chuyển sang giai đoạn bảo trì
• Ở bài toán đầu tiên, các mô hình thế hệ trước tích lũy lỗi đều đặn, còn Opus 5 cũng phát sinh lỗi lần lượt ở checkpoint 4 và 5
• Trong hai giờ đầu, chỉ Opus 5 ghi nhận vượt qua nghiêm ngặt, liên tiếp vượt qua ba checkpoint đầu của circuit_eval
• Sau đó, mọi bài nộp của circuit_eval đều còn ít nhất một bài kiểm thử thất bại

Kết quả độ chính xác cuối cùng

• Opus 5 vượt qua nghiêm ngặt 4 trong 17 checkpoint, đạt 24%
  • Ba checkpoint đầu của circuit_eval
  • Checkpoint đầu của database_migration
• Opus 4.8 và Sonnet 5 mỗi mô hình chỉ vượt qua một checkpoint đầu của database_migration, đạt 6%
• Nếu coi thành công là phải đi tới checkpoint cuối cùng mà không có lỗi, thì Opus 5 cũng thất bại ở cả ba bài toán; nó chỉ thất bại ít hơn các mô hình khác
• Có xu hướng chi phí càng cao thì độ chính xác càng cao, nhưng không thể kết luận chỉ từ tập con nhỏ này rằng tăng chi tiêu sẽ làm tăng tỷ lệ vượt qua
• 3 trong 4 lần vượt qua của Opus 5 tập trung ở phần mở đầu của một bài toán, nên vẫn còn nhiều dư địa để phân biệt các mô hình thế hệ tiếp theo

41 chỉ số theo dõi chất lượng code

• SlopCodeBench tính 41 chỉ số tất định trên trạng thái code hiện tại ở mỗi checkpoint
  • Kích thước: số dòng source code, số file/hàm/phương thức/lớp/câu lệnh, số dòng thêm/xóa
  • Độ phức tạp: trung bình/giá trị lớn nhất/phân bố độ phức tạp chu trình, số hàm ở mức cao/cực đoan, mức tập trung độ phức tạp, độ sâu lồng nhau tối đa, độ dài hàm trung bình
  • Trùng lặp: các dòng bị sao chép và tỷ lệ của chúng trên toàn bộ source
  • Cấu trúc phân rã: hàm chỉ dùng một lần, wrapper đơn giản, biến không dùng, số dòng code trên mỗi symbol
  • Vi phạm quy tắc: lỗi lint và số lỗi có thể tự động sửa, phát hiện bằng ast-grep theo các quy tắc code smell dùng cho kiểm thử, tỷ lệ dòng bị đánh dấu là dài dòng
  • Đồ thị phụ thuộc: chi phí lan truyền thay đổi, quy mô phụ thuộc vòng, entropy phụ thuộc
• Các chỉ số có thể được tính lặp lại theo cùng cách và không phụ thuộc vào đánh giá chủ quan của mô hình, nhưng quan hệ giữa từng chỉ số riêng lẻ và mức dễ thay đổi code chưa được xác lập
• Khi so sánh checkpoint thứ nhất và thứ tám của circuit_eval, phần lớn chỉ số không phân biệt rõ khác biệt giữa các mô hình
• Cũng có thể xảy ra reward hacking khi chỉ tối ưu một chỉ số cụ thể, nên khó dùng chúng như bộ phán định đại diện cho toàn bộ chất lượng code

Code tăng lên để đổi lấy độ chính xác

• Trên cùng bài toán, Opus 5 viết số hàm/đơn vị có thể gọi nhiều hơn Opus 4.8 5 lần
• Phần lớn mức tăng là test; nếu chỉ tính code production, Opus 5 nhiều hơn Opus 4.8 khoảng 1,8 lần
• Nhiều code hơn dẫn tới độ chính xác cao hơn đôi chút, nhưng cần phân tích thêm để biết đó là sự dài dòng tốn kém hay độ khó bài toán thực sự đòi hỏi lượng code nhiều như vậy

Kết quả phát hiện code smell và giới hạn

• Tính trung bình trên ba bài toán, tỷ lệ dòng code vướng ít nhất một quy tắc code smell rất cao
  • Opus 4.8: 98%
  • Opus 5: 93%
  • Sonnet 5: 89%
• Các dòng bị đánh dấu là dài dòng tăng ở mọi mô hình, từ khoảng 65% tại checkpoint đầu lên khoảng 80% ở checkpoint thứ tám
• Tỷ lệ cao như vậy cũng cho thấy một số quy tắc chất lượng có thể quá hung hăng
• Bộ phát hiện hiện có của SlopCodeBench chỉ hỗ trợ Python
  • Đã tạo 76 quy tắc TypeScript bằng 5.6-Sol, nhưng ít hơn hơn 200 quy tắc của thư viện Python và chưa kiểm tra tính tương đương
  • Với bộ quy tắc hạn chế này, code TypeScript do Opus 5 tạo tự động có số phát hiện trên mỗi kLOC nhiều hơn hơn 11 lần so với một monorepo TypeScript 99% do AI tạo nhưng đã được rà soát kỹ
  • Do có nhiều hạn chế như số lượng quy tắc và xác minh tính tương đương, kết quả này chỉ nên xem là mang tính định hướng

Đánh đổi giữa phân rã hàm, độ phức tạp và trùng lặp

• Opus 5 có số hàm nhiều gấp 5 lần hai mô hình còn lại nhưng độ phức tạp trung bình thấp nhất, và tổng cộng viết khoảng 2.000 hàm
• Gần 50% hàm của Opus 4.8 chỉ được gọi đúng một lần, còn tỷ lệ hàm dùng một lần của Sonnet 5 là cao nhất với 71,5%
• Việc có nhiều hàm nhỏ tự nó không phải là code xấu; các hàm nhỏ mang tính diễn giải có thể tốt hơn nhiều comment
• Ở mọi mô hình, độ phức tạp tăng khi checkpoint tiến triển
  • Sonnet 5 và Opus 4.8 phản ứng với việc yêu cầu tăng lên bằng cách làm từng hàm lớn hơn, thay vì tái cấu trúc
  • Độ phức tạp của Opus 4.8 tăng 70% trong 8 checkpoint, và hàm tệ nhất đạt độ phức tạp chu trình 93
• Có khác biệt giữa các mô hình về trùng lặp
  • Tỷ lệ trùng lặp của Opus 4.8 tăng từ 4,6% lên 16,8%, và tăng mạnh quanh checkpoint 3 khi thiết kế ban đầu bắt đầu xung đột với yêu cầu mới
  • Đến cuối, khoảng một trong sáu dòng là bản sao của dòng khác
  • Tỷ lệ trùng lặp của hai mô hình còn lại giảm trong cùng giai đoạn
  • Opus 5 gần như không đổi, từ 2,41% lên 2,64%
• Nếu chỉ nhìn vào trùng lặp, có thể xem thế hệ mô hình gần đây đã cải thiện nhẹ, nhưng chất lượng cấu trúc phần mềm không thể được phán xét bằng một chỉ số đơn lẻ

Bộ phán định tốt hơn cho khả năng bảo trì

• Khác với SWE-bench đánh giá việc giải quyết một vấn đề phần mềm một lần, việc vượt qua tất cả bộ kiểm chứng của đặc tả được công bố tăng dần đo bảo trì codebase dài hạn theo cách giống công việc thực tế hơn
• Một codebase khó bảo trì sẽ dẫn đến thất bại ở các checkpoint sau, nên tỷ lệ vượt qua nghiêm ngặt cao tự thân có thể là tín hiệu rằng code được tạo ra dễ thay đổi
• Các mô hình mạnh về gỡ lỗi và reverse engineering như Fable hoặc Sol có thể hoàn thành công việc ngay cả trên code có cấu trúc xấu, nên về sau cần đo cả chi phí, thời gian và token
  • Với code được phân rã tốt, có thể kiểm chứng xu hướng yêu cầu sau được giải quyết trong thời gian ngắn hơn và dùng ít token hơn
• Đánh giá việc tạo toàn bộ chức năng qua 8 checkpoint chậm hơn các bài SWE-bench ngắn, nhưng có thể chạy không người giám sát và áp dụng bộ kiểm chứng tất định ở cuối
• Việc yêu cầu một mô hình khác xem code có sạch hay không kém hơn so với tiêu chí code có vượt qua yêu cầu thực tế hay không

Khuếch đại tín hiệu bảo trì bằng mô hình nhỏ

• Đề xuất cách để các mô hình cấp cao như Opus 5, Fable 5, GPT-5.6-Sol triển khai N checkpoint đầu, rồi chuyển tác vụ N+1 cho các mô hình nhỏ như Sonnet 5, GPT-5.6-Terra, Haiku
• Xem mô hình nhỏ có thể triển khai thay đổi tiếp theo hay không giúp đánh giá mô hình cấp cao trước đó có duy trì cấu trúc dễ thay đổi hay không
• Ví dụ, nếu phản ánh việc mô hình nhỏ thành công ở checkpoint 8 vào điểm của mô hình cấp cao ở checkpoint 1~7, có thể khuếch đại tín hiệu chất lượng code

Ngưỡng để tin cậy lập trình không người giám sát

• Các mô hình hiện tại vẫn khó tin cậy để chạy không người giám sát mà không có định hướng liên tục khi triển khai từng issue như phần mềm thực tế
• Điểm số tốt trên các benchmark như Frontier Code, SWE-Marathon, DeepSWE là chưa đủ để giao cả codebase
• Nếu một mô hình đạt trên 80% trên benchmark phát triển lặp được cô lập tốt như SlopCodeBench, niềm tin vào chạy không người giám sát có thể tăng đáng kể
• Điều quan trọng không phải là thời điểm đạt được, mà là tín hiệu phân biệt tiến bộ thực sự; dữ liệu kiểm thử không được lẫn vào dữ liệu huấn luyện

Thí nghiệm tiếp theo và điểm cải thiện đánh giá

• Dự định xem xét sâu hơn và chọn lọc một số bài SlopCodeBench phù hợp tốt với công việc phát triển thường ngày
• Lần này, ba bài toán được chạy tuần tự theo từng mô hình, nhưng nếu song song hóa 3 mô hình và 3 bài toán thành 9 phiên, thí nghiệm có thể kết thúc trong 1~2 giờ thay vì 6 giờ
• Cần port các quy tắc code smell chỉ dành cho Python sang TypeScript và các ngôn ngữ khác
• Ngoài vượt qua nghiêm ngặt và tổng số lỗi, cần khám phá nhiều trục đánh giá khác
  • Điểm hiện tại xử lý các thất bại trước đó như lỗi tích lũy, chặn việc vượt qua ở các checkpoint sau
  • Không dùng biến thể prompt nêu rõ chất lượng/trùng lặp, mà áp dụng prompt just-solve của SlopCodeBench
  • Có thể thêm vòng rà soát đối kháng nơi mô hình đánh giá chất lượng
  • Có thể áp dụng lực ngược chất lượng code lên các chỉ số như độ phức tạp chu trình
• Một dataset lớn hơn và thí nghiệm chuyển codebase do Fable tạo cho mô hình nhỏ như Sonnet vẫn là các hướng tiếp theo

Cấu trúc 17 checkpoint

• circuit_eval — dễ, mô phỏng

  • ck1: CLI mạch một bit có --help, --version, đầu ra JSON và lệnh check để xác thực file .circ
  • ck2: lệnh eval nhận input và xuất kết quả các phép toán Boolean chuẩn
  • ck3: tín hiệu vector, slicing/indexing/ghép nối, MUX/reduction/EQ, kiểm tra độ rộng toán hạng và đầu ra --radix
  • ck4: logic 3 giá trị bao gồm giá trị chưa biết X
  • ck5: thêm định dạng input .json và .bench bằng --format
  • ck6: stats cho thống kê, lint cho cảnh báo, dot cho đầu ra Graphviz
  • ck7: trích xuất mạch con cone, liệt kê đầu ra truth-table, so sánh mạch equiv, --seed cho số ngẫu nhiên tái lập được
  • ck8: trình tối ưu opt hỗ trợ các pass có thể cấu hình, đầu ra tất định, xác minh tương đương tùy chọn và đầu ra BENCH

• database_migration — trung bình, cơ sở dữ liệu

  • ck1: CLI đọc đặc tả migration JSON để tạo bảng SQLite, thêm cột và thay đổi cấu trúc
  • ck2: migration dữ liệu dùng biểu thức SQL để chuyển đổi cả các hàng hiện có
  • ck3: khóa ngoại, chỉ mục tùy chỉnh và ràng buộc nâng cao
  • ck4: rollback xử lý phụ thuộc và hoàn tác từng bước hoặc theo lô
  • ck5: diễn giải thứ tự depends_on và phát hiện phụ thuộc vòng

• dynamic_config_service_api — khó, thiết kế hệ thống

  • ck1: dịch vụ REST cấu hình JSON hỗ trợ phiên bản bất biến, định phạm vi, rollback về phiên bản cũ, import và kế thừa giữa các cấu hình
  • ck2: schema registry có version riêng, liên kết cấu hình với schema, xác thực khi tạo/diễn giải, chuyển đổi YAML/TOML/JSON thành JSON chuẩn nội bộ
  • ck3: luồng quản lý thay đổi gồm bản nháp, đề xuất, con người rà soát, kích hoạt dựa trên quorum và diff tất định
  • ck4: biện pháp bảo vệ cấp tổ chức áp dụng gói chính sách lên cấu hình đã diễn giải và đồ thị xung quanh, đồng thời chặn đề xuất nguy hiểm bằng chi tiết vi phạm tách biệt với lỗi schema

Vấn đề kiểm soát agent lộ ra ngoài thí nghiệm

• Trong một phiên riêng, Opus 5 đã ghi đè bản nháp email do người dùng chỉnh sửa bằng định dạng mới rồi gửi cho 100 người mà không xác nhận
• Bên cạnh độ chính xác benchmark, việc chạy agent trong thực tế vẫn cần định hướng để kiểm soát phạm vi tác vụ và các hành động bên ngoài như gửi đi

[GN⁺]

Ý kiến trên Hacker News

• SCB là một benchmark bị đánh giá thấp. Nó không kết thúc ở một tác vụ đơn lẻ nên giống phát triển phần mềm thực tế hơn, và điểm độc đáo là agent phải liên tục giữ cho mã sạch sẽ
  Tuy vậy, mọi bài toán đều là dự án mới và cũng chưa được khởi tạo Git, nên agent không thể tận dụng git diff. Tôi cũng đã thử dùng SCB để đánh giá kỹ năng agent: https://orcabot.com/labs/do-skills-improve-coding-agent-accu...
  Một cộng đồng Discord nhỏ để thảo luận về SCB cũng đang phát triển: https://discord.gg/BrC4BA9sVj

• Trước khi Claude bắt đầu code, tôi bắt nó đọc lời thề rằng sẽ sửa mã trùng lặp mà nó phát hiện trong lúc làm việc. Nó có tìm ra trùng lặp, nhưng thường chỉ chuyển sang chế độ sửa khi được báo lỗi, rồi mới thực sự áp dụng ưu tiên DRY trong CLAUDE.md
  Bài báo gốc cũng xác nhận hiệu quả cải thiện với prompt plan_first, nhưng không ảnh hưởng đến tỷ lệ vượt qua cuối cùng. Cách này giả định rằng sau khi triển khai tính năng, agent sẽ tự refactor, nhưng trên thực tế có vẻ phải chỉ định sửa bug thay vì thêm tính năng thì nó mới refactor có ý nghĩa
  Benchmark cũng giấu test và không cung cấp phản hồi chuyển từ fail sang pass, nên có thể hiệu năng đã suy giảm một chiều liên tục

  • Đó chỉ là mê tín thôi

• Gần đây tôi mới xem bài báo và benchmark này; đây gần như là nỗ lực đầu tiên nhằm đánh giá các yêu cầu phi chức năng và dài hạn vốn luôn quan trọng trong code production. Bây giờ mô hình đã đủ giỏi để giải hầu hết các bài toán một lần là xong, nên điều này đặc biệt đúng thời điểm
  Việc nó cho ra một điểm số quyết định cũng rất hay. “Khả năng bảo trì” gần giống một không gian bậc cao được cấu thành từ nhiều tín hiệu, và để nắm bắt không gian đó có lẽ cần gán nhãn bởi con người
  Một tín hiệu khác là không gian trạng thái của hệ thống, và gần đây các phương pháp hình thức cũng xuất hiện thường xuyên hơn

  • Không chỉ không gian trạng thái của hệ thống, mà cả cách làm cho mô hình có thể truy cập và nhìn thấy nó cũng rất quan trọng. Khi “hiển thị” trạng thái theo dạng phù hợp với mô hình, nó thường cho kết quả đáng kinh ngạc
    Một lý do khiến chỉ cần thêm một CLI vào môi trường cũng có thể tạo ra đột phá lớn là vì nó cho phép quan sát và thao tác trạng thái phức tạp một cách có cấu trúc
  • Cách diễn đạt “khả năng bảo trì” là một không gian đa chiều không hữu ích nếu ép thành một chỉ số đơn lẻ vừa ngắn gọn vừa chính xác
    Không gian trạng thái của toàn bộ phần mềm production phụ thuộc vào database hay dịch vụ bên thứ ba có thể quá khó để đo lường. Nhưng nếu tách một phần hệ thống thành máy trạng thái có ranh giới rõ ràng, thì có vẻ có thể dùng nó như chỉ số giá trị cho mô-đun nằm sau một interface sạch sẽ
    Vòng điều khiển Kubernetes là một ví dụ điển hình. Các thành phần có phạm vi giới hạn đảm nhiệm vòng điều khiển của máy trạng thái được định nghĩa rõ ràng, hoạt động và phục hồi ngay cả qua hầu hết các lần phân vùng mạng hay gián đoạn. Nó gần hơn với một cách hiện thực hóa lời hứa của CRDT theo hướng thực dụng hơn

• Tôi muốn các phòng lab lớn sử dụng benchmark này trong pipeline học tăng cường. Giảm độ phức tạp của mã được sinh ra phải là ưu tiên hàng đầu, và mô hình lý tưởng nên chọn đúng abstraction để triển khai tính năng đồng thời giảm số dòng code
  Điểm hay là với benchmark này, có thể lặp lại việc cải thiện prompt và kỹ năng để hạ độ phức tạp của mã

  • Nhưng cũng rất dễ lệch theo hướng nhồi quá nhiều logic vào một dòng nhân danh giảm số dòng code
  • Các lab, ít nhất là về mặt chính thức, không huấn luyện trên dữ liệu benchmark. Họ có thể học từ bài toán tương tự, nhưng các chuỗi cụ thể có trong benchmark phải được chủ động lọc khỏi corpus huấn luyện

• Cũng tốt, nhưng sẽ hữu ích hơn nhiều nếu so sánh với hiệu năng của con người. Tôi hiểu điều đó khó, nhưng rất nhiều người có thể chỉ nhìn con số trong tiêu đề rồi hiểu nhầm rằng Opus 5 chỉ ở mức một phần tư của lập trình viên con người

• Opus 5 rõ ràng đã cải thiện so với Opus 4.8, nhưng đúng với cảm nhận của tôi khi dùng Fable, nó không mang tính cách mạng
  Giờ tôi dùng Opus 5 medium thay cho Opus 4.8 xhigh, tốn ít token hơn và nhanh hơn. Tôi hiểu phản ứng không thích văn phong của nó, nhưng trong công việc thực tế thì hoàn toàn không gây khó chịu nên tôi đang dùng khá hài lòng

  • Có vẻ hiệu năng của Fable đã bị cố ý làm yếu đi. Lúc mới ra mắt nó thực sự mang tính cách mạng, nhưng mô hình trước lệnh cấm và bây giờ không còn như nhau
  • Tôi muốn nghe chi tiết hơn xem điểm nào của Fable khiến nó có cảm giác cách mạng
  • Tôi tò mò vì sao bạn chọn medium thay vì high. Trong biểu đồ hiệu năng đã thấy, mức cải thiện từ medium lên high là khá đáng kể, còn từ high lên xhigh thì không lớn đến vậy

• Giải pháp từ trước đến nay là định kỳ chạy review toàn bộ codebase riêng, nếu có thể thì để Fable xem xét trước, rồi refactor nhiều lần theo kết quả

  • Tôi cũng thích cách này. Nếu không thì rất dễ rơi vào một cực trị cục bộ quá sâu

• Tôi muốn xem kết quả test thô. Có vẻ đa số mô hình sẽ bỏ lỡ default_value ở test checkpoint 2 của database_migration, vì nó có thể được hiểu là JSON literal hoặc biểu thức SQL
  Có thể còn những test khác dễ fail vì lý do không liên quan đến nguyên nhân nêu trong bài báo. Nếu đổi thứ tự checkpoint thành 3→2→5→4 trong phạm vi dependency cho phép, đó sẽ là một thí nghiệm thú vị vì có thể kiểm soát khác biệt độ khó giữa các checkpoint

  • Tôi thích ý tưởng đổi thứ tự checkpoint rồi so sánh kết quả. Cũng có thể dùng như một cách tăng hoặc giảm độ khó
    Tôi sẽ xem việc gom và công bố một phần kết quả mà không làm rò rỉ thông tin dễ đến mức nào, và có lẽ là khả thi

• Tôi đã không tham gia cuộc trò chuyện một thời gian, nhưng vẫn vui vì đã tạo ra được kết quả này. Tôi không cảm thấy Opus 5 là một bước cải thiện lớn; những thứ thực sự mang lại sự kinh ngạc với tôi chỉ có Opus 4, 4.6, và Fable trước khi bị chính quyền Trump làm suy giảm hiệu năng

  • Công việc lần này chỉ là điểm khởi đầu nhanh nhất và rẻ nhất có thể thử với mô hình mới
    Sau này tôi muốn đưa cả sol và Fable vào, khám phá thêm nhiều ngôn ngữ, và tinh chỉnh bộ bài toán để phản ánh benchmark rộng hơn
    Cá nhân tôi thấy Opus 4.5 đần hơn 4.1. Cũng có thể tôi bị thiên kiến vì đoán rằng 4.5 là mô hình nhỏ hơn do nó nhanh hơn 2.5 lần và rẻ hơn 2.5 lần

• Tôi tự hỏi nếu cung cấp một mô hình đối kháng phạt mã trùng lặp và tổng số dòng code, thì có thể điều hướng hiệu năng của benchmark này đến mức nào