Benchmark Claude Code: Ngôn ngữ động như Ruby, Python vượt trội hơn về tốc độ và chi phí

Một bài kiểm tra chuẩn (benchmark) mới do Yusuke Endoh — một thành viên đóng góp chính cho dự án Ruby — thực hiện đã kiểm tra khả năng tạo mã làm việc của Claude Code trên 13 ngôn ngữ lập trình. Với tổng số 600 lần chạy, các ngôn ngữ động, cụ thể là Ruby, Python và JavaScript, đã cho thấy hiệu suất vượt trội về mặt tốc độ, chi phí và sự ổn định. Ngược lại, các ngôn ngữ tĩnh (statically typed languages) tỏ ra chậm hơn và đắt đỏ hơn từ 1,4 đến 2,6 lần.

Kết quả thí nghiệm đã được công bố trên DEV Community và toàn bộ mã nguồn cũng như dữ liệu đều có sẵn trên GitHub. Nhiệm vụ được đề ra cho Claude Code (sử dụng mô hình Opus 4.6) là triển khai một phiên bản Git đơn giản trên từng ngôn ngữ. Công việc được chia thành hai giai đoạn: phiên bản v1 yêu cầu triển khai các lệnh init, add, commit và log từ một thư mục trống; phiên bản v2 mở rộng dự án với các lệnh status, diff, checkout và reset. Mỗi ngôn ngữ được chạy 20 lần và tác giả đã sử dụng thuật toán băm tùy chỉnh thay vì SHA-256 để loại bỏ sự khác biệt về phụ thuộc thư viện giữa các ngôn ngữ.

Kết quả chi tiết: Ruby dẫn đầu

Trong số các ngôn ngữ được thử nghiệm, Ruby là ngôn ngữ có hiệu suất tốt nhất với chi phí trung bình chỉ 0,36 USD cho mỗi lần chạy và thời gian trung bình là 73,1 giây. Python xếp ngay sau với 0,38 USD và 74,6 giây, tiếp theo là JavaScript với 0,39 USD và 81,1 giây. Cả ba ngôn ngữ này đều có độ biến thiên thấp và vượt qua tất cả các bài kiểm tra trong 40 lần chạy (20 lần cho mỗi giai đoạn).

Từ vị trí thứ tư trở đi, chi phí tăng lên và độ biến thiên cũng tăng mạnh. Go có chi phí trung bình là 0,50 USD với thời gian 101,6 giây, nhưng độ lệch chuẩn lên tới 37 giây. Rust có chi phí trung bình là 0,54 USD nhưng có độ dao động lớn nhất (54,8 giây) và là một trong hai ngôn ngữ gặp lỗi kiểm tra. Ngôn ngữ C là ngôn ngữ phổ thông đắt đỏ nhất với mức 0,74 USD, một phần do Claude Code tạo ra tới 517 dòng code so với chỉ 219 dòng của Ruby.

Tác động của hệ thống kiểu dữ liệu (Type System)

Phát hiện quan trọng nhất đối với các nhóm đang đánh giá quy trình viết code hỗ trợ bằng AI nằm ở phần hệ thống kiểu dữ liệu. Việc thêm kiểm tra kiểu nghiêm ngặt (strict type checking) vào các ngôn ngữ động đã làm tăng đáng kể thời gian và chi phí:

• Thêm mypy (kiểm tra kiểu cho Python) khiến quá trình chậm hơn 1,6 đến 1,7 lần.
• Thêm Steep (kiểm tra kiểu cho Ruby) gây ra mức phạt lớn hơn, khiến nó chậm hơn từ 2,0 đến 3,2 lần so với Ruby thuần túy.
• TypeScript đắt hơn nhiều so với JavaScript, trung bình là 0,62 USD so với 0,39 USD, mặc dù số lượng dòng code tạo ra tương đương.

Tác giả lưu ý rằng mức giảm hiệu suất này không chỉ đến từ việc tạo ra chú thích kiểu (type annotations), mà chủ yếu là do việc mô hình AI sử dụng nhiều "thinking-token" hơn để suy luận về các ràng buộc kiểu dữ liệu.

Hạn chế và phản ứng từ cộng đồng

Endoh rất minh bạch về những hạn chế của nghiên cứu. Ông thừa nhận thiên kiến vì là người đóng góp cho Ruby và chỉ ra các chương trình được tạo ra chỉ có khoảng 200 dòng code, thuộc quy mô tạo mẫu (prototyping). Ông đồng ý rằng kiểu tĩnh có thể chứng minh được lợi thế trong các cơ sở mã lớn hơn. Thí nghiệm này chỉ đo lường chi phí và tốc độ tạo mã, không đánh giá chất lượng code, khả năng bảo trì hay hiệu suất thời gian chạy.

Cộng đồng trên Lobsters đã đặt câu hỏi về việc liệu có thể rút ra kết luận cho quy mô tạo mẫu từ các đầu ra chỉ 200 dòng hay không, vì rất ít nguyên mẫu có ích lại nhỏ đến thế. Những người khác chỉ ra rằng bài kiểm tra không tính đến lợi thế của hệ sinh thái, nơi các ngôn ngữ có hệ sinh thái gói mạnh mẽ sẽ cần ít code được tạo hơn cho các nhiệm vụ thực tế. Một ý kiến quan trọng cho rằng việc tăng tốc gấp đôi có thể trở nên vô nghĩa nếu code được tạo ra khó sửa đổi hơn sau này, và các lỗi kiểm tra ở Rust hay Haskell thực chất là đặc tính giúp bắt lỗi sớm chứ không hẳn là lỗi (bug) của mô hình.

Endoh giải thích rằng ông đã loại bỏ các phụ thuộc thư viện để cô lập sự khác biệt ở cấp độ ngôn ngữ, do đó ông sử dụng hàm băm tùy chỉnh. Về chênh lệch tốc độ 2 lần, ông lập luận rằng trong quá trình phát triển lặp đi lặp lại có sự hỗ trợ của AI, khoảng cách giữa việc chờ 30 giây và 60 giây rất quan trọng đến trạng thái luồng làm việc của nhà phát triển, mặc dù ông thừa nhận sự khác biệt này sẽ không còn ý nghĩa nếu các mô hình trong tương lai giảm thời gian tạo mã xuống dưới một giây.

Trong tổng số 600 lần chạy, chỉ có 3 lần chạy thất bại: hai lần trong Rust và một lần trong Haskell. Trong một nhật ký thất bại của Rust, tác nhân AI đã tuyên bố các bài kiểm tra sai, mà tác giả xác định là một ảo giác (hallucination) vì tất cả các thử nghiệm Rust khác đều thành công.

Toàn bộ dữ liệu, bao gồm kết quả từng lần chạy, nhật ký thực thi và tất cả mã nguồn được tạo, đều có sẵn trong kho lưu trữ benchmark.