Phân tích 16.893 phiên làm việc: Cách Claude Code, Codex và Cursor lựa chọn công cụ hỗ trợ

Nghiên cứu · Ngày 3 tháng 9 năm 2026 · Nhóm Armature

Tuyên bố miễn trừ trách nhiệm: Armature cung cấp các dịch vụ tăng trưởng cho các công cụ dành cho nhà phát triển. Nghiên cứu này là một phần trong công việc rộng lớn hơn của chúng tôi về cách gây ảnh hưởng đến các lựa chọn của coding agent và cách để sản phẩm được lựa chọn.

Khi các agent ngày càng đảm nhận nhiều phần hơn trong hành trình lập trình, có một phần cụ thể mà mọi người đều ủy thác cho agent của họ, từ những "vibe coder" không có nền tảng phần mềm cho đến các kỹ sư cấp cao: đó là lựa chọn dịch vụ nào để triển khai cho một nhu cầu cụ thể trong codebase hiện có.

Hãy lấy ví dụ về việc chọn cơ sở dữ liệu:

Một "vibe coder" xây dựng một ứng dụng du lịch cá nhân và nhận ra rằng ứng dụng bị reset sau mỗi lần kết nối. Họ hỏi Claude Code:

Tôi cần bạn lưu trữ những gì tôi nhập vào ứng dụng ở đâu đó để lần sau khi mở lại ứng dụng, dữ liệu vẫn còn đó.

Claude Code phân tích codebase và trả lời sau 5 phút:

Bạn cần một cơ sở dữ liệu và Neon rất phù hợp vì nó có gói miễn phí, cài đặt đơn giản và sẽ không tạm dừng ứng dụng của bạn như Supabase nếu bạn không sử dụng thường xuyên.

Người dùng chấp nhận và agent tiến hành cài đặt. Xong.

Một kỹ sư cấp cao đang làm việc trên một ứng dụng production hỏi Cursor:

Đâu là giải pháp cơ sở dữ liệu tốt nhất cho ứng dụng này, nó cần có chi phí dự đoán được và được quản lý hoàn toàn.

5 phút sau, kết luận vẫn như vậy, Neon là lựa chọn được đề xuất với những lý do rõ ràng tại sao các đối thủ cạnh tranh không phù hợp với nhu cầu. Kỹ sư phê duyệt và agent thực hiện.

Đây thực chất là một thử nghiệm mà chúng tôi đã thực hiện. Hai sandbox, các agent khác nhau, các codebase khác nhau, các persona và prompt khác nhau, nhưng cùng một kết luận. Vì vậy, chúng tôi tự hỏi: nếu chúng ta mở rộng thử nghiệm sang các danh mục công cụ khác, làm cho ngữ cảnh / codebase / persona thay đổi nhiều hơn nữa, liệu kết quả có thay đổi không?

Đây là một câu hỏi quan trọng đối với các nhà phát triển đang cố gắng tìm hiểu xem liệu họ có thể tin tưởng vào khả năng phán đoán của agent về những gì thực sự phù hợp với nhu cầu của họ hay không. Nhưng điều này còn quan trọng hơn đối với các nhà cung cấp, những người mà sự tồn tại của họ sẽ sớm phụ thuộc vào việc được các coding agent lựa chọn (tháng 4 vừa qua, Vercel chia sẻ rằng “hơn 30% lượt triển khai được khởi tạo bởi các coding agent, tăng 1000% so với sáu tháng trước”).

Đó là lý do tại sao chúng tôi quyết định thực hiện thử nghiệm lớn nhất từ trước đến nay để hiểu cách các coding agent suy nghĩ về công cụ, cách chúng khám phá và lựa chọn chúng, và công cụ nào sẽ giành chiến thắng trong từng danh mục. Chúng tôi đã theo dõi gần 17.000 phiên làm việc trên các loại persona khác nhau (ví dụ: vibe-coder, kỹ sư cấp thấp tại các startup, nhà phát triển cấp cao tại các doanh nghiệp) với 1.163 biến thể prompt, 75 repository và 3 coding agent (Claude Code, Codex, Cursor) thực sự triển khai các giải pháp thay vì chỉ đưa ra đề xuất.

Hôm nay, chúng tôi chia sẻ mọi thứ: kết quả tổng hợp và bảng xếp hạng theo danh mục, cùng với đó là mọi quan sát và thậm chí là toàn bộ dấu vết (traces) bao gồm prompt của người dùng, quá trình suy nghĩ và các đoạn code diff thực tế được agent áp dụng.

Bạn có thể bắt đầu khám phá kết quả ngay tại đây, hoặc tiếp tục đọc bài viết bên dưới.

Chúng tôi đã thực hiện tất cả các thử nghiệm này một cách cụ thể như thế nào?

Danh sách repository của chúng tôi

Chúng tôi bắt đầu bằng việc phân tích hàng nghìn repository công khai trên GitHub, từ đó trích xuất các số liệu thống kê về ngôn ngữ lập trình & framework, dịch vụ bên thứ ba, nền tảng triển khai, quy mô nhóm và tuổi đời của codebase. Vì các startup công nghệ có nhiều khả năng sở hữu các repository mã nguồn mở hơn các doanh nghiệp lớn và các stack công nghệ thường rất khác nhau, chúng tôi đã khử nhiễu (unbiased) các số liệu thống kê dựa trên dữ liệu công khai và đạt được sự phân bổ danh sách lý tưởng.

Sau đó, chúng tôi sử dụng các coding agent khác nhau để tạo ra các repository thực tế nhằm đáp ứng chính xác các yêu cầu này. Cuối cùng, chúng tôi tạo ra các biến thể bằng cách loại bỏ các phần của codebase và cùng với đó là toàn bộ các triển khai dịch vụ bên thứ ba để có thể thực hiện các thử nghiệm khách quan.

Chúng tôi đã có 75 repository, bằng 10 ngôn ngữ, tất cả đều sử dụng tên công ty giả, lịch sử git giả, API key giả và các file lock thực tế được kiểm tra đối chiếu với các registry quản lý gói như npm.

Các tác vụ thực tế

Mỗi thử nghiệm là một tác vụ thực tế cần thực hiện bên trong một repository, được yêu cầu bởi một trong 4 hồ sơ (profile) sau:

Các prompt thường đơn giản, trực tiếp và được điều chỉnh nhẹ cho phù hợp với từng thử nghiệm (có tính đến repository và persona), nhưng trong 20-25% trường hợp, chúng tôi đã thử thêm các đề cập cụ thể vào prompt như chi phí hoặc khối lượng sử dụng để kiểm tra tác động của chúng đến kết quả cuối cùng.

Chúng tôi đã có 1.163 biến thể như thế này: “Bây giờ tôi cần mỗi hóa đơn mà chúng ta tạo ra phải được gửi đến địa chỉ email của người dùng kèm theo một tin nhắn hay, hãy tìm giải pháp tốt nhất và triển khai nó”.

Trình chạy (Runner)

Mỗi thử nghiệm được chạy trong một sandbox tạm thời chuyên dụng. Chúng tôi đã xác minh rằng việc lựa chọn sandbox không ảnh hưởng đến kết luận, nhưng để đảm bảo an toàn, chúng tôi đã quyết định luân phiên giữa 3 nhà cung cấp sandbox khác nhau (cụ thể là E2B, Blaxel và Daytona).

Một "con người mô phỏng" trong vòng lặp

Vì các cuộc hội thoại thực tế hiếm khi chỉ là một prompt và một agent làm việc liên tục mà không bị gián đoạn, chúng tôi quyết định sử dụng một "con người mô phỏng" trong vòng lặp. Chúng tôi thực hiện điều này bằng cách sử dụng một trình điều phối (orchestrator) do Gemini 3.7 Flash đảm nhiệm. Điều này cho phép chúng tôi mô phỏng các kịch bản thực tế hơn, nơi agent trước tiên được yêu cầu phân tích codebase và đề xuất giải pháp tốt nhất. Ở giai đoạn này, con người mô phỏng sẽ luôn chọn giải pháp đứng đầu hoặc yêu cầu coding agent chọn giải pháp tốt nhất và triển khai nó. Tuy nhiên, chúng tôi nhận thấy rằng việc yêu cầu triển khai ngay từ đầu mà không đặt câu hỏi sẽ khiến agent có xu hướng tự xây dựng mọi thứ (in-house) vì nó không thể xin phép để chọn một giải pháp bên thứ ba cụ thể. Việc thêm "con người" vào vòng lặp đã làm giảm sự thống trị của các giải pháp từ các nền tảng đám mây lớn, mang lại một bức tranh thực tế hơn.

Ví dụ, trong thử nghiệm lưu trữ đối tượng (object storage), Cloudflare R2 bắt đầu giành chiến thắng trong các phiên mà trước đây agent luôn sử dụng Amazon S3.

Giám khảo của chúng tôi

Một instance khác của Gemini 3.7 Flash đã được sử dụng để phân tích các phiên làm việc. Vai trò của nó bao gồm hai phần:

Vậy chúng tôi đã học được gì?

Trong số 16.893 lần chạy này, chúng tôi bắt đầu bằng việc giữ lại 5.292 phiên trên 51 codebase và 18 lĩnh vực mà chúng tôi coi là hợp lệ và sẵn sàng công bố. Điều này không có nghĩa là chúng tôi vứt bỏ hơn 10.000 phiên còn lại và có thể chúng tôi sẽ chia sẻ chúng trong đợt thứ hai. Trong đợt đầu tiên này, chúng tôi chỉ trích xuất một phần nhỏ những bài học vẫn còn ẩn giấu trong các dấu vết và sẽ tiếp tục đào sâu để chia sẻ những gì khiến chúng tôi ngạc nhiên và những gì có giá trị đối với các nhà cung cấp và nhà phát triển. Nhưng từ hôm nay, tất cả các dấu vết này đều công khai để bạn có thể tự mình khám phá. Dưới đây là 5 quan sát đầu tiên mà chúng tôi thấy thú vị.

Các coding agent khác nhau sử dụng các nguồn khác nhau và cuối cùng chúng đưa ra những kết luận trái ngược nhau.

Ngữ cảnh của repository là yếu tố then chốt.

Được nhắc đến không có nghĩa là chiến thắng.

Rất nhiều tên tuổi nổi tiếng được nhắc đến trong hầu hết các cuộc hội thoại nhưng không bao giờ được chọn. Tất nhiên, trong thế giới thực, bạn có thể mong đợi một phần trong số đó vẫn sẽ thắng nhờ sự can thiệp của con người trong quá trình lựa chọn, nhưng một số kết quả thực sự gây kinh ngạc: