FrontierCode Diamond: 13.4% bản vá có thể gộp trên 50 tác vụ khó (tháng 6 năm 2026)

Tài liệu bổ sung về cấu hình công cụ có trong tài liệu Ailoot.

FrontierCode là gì, và tại sao nó quan trọng?#

Cognition là công ty đứng sau Devin (kỹ sư AI tự hành đầu tiên, tháng 3 năm 2024) và Windsurf (được mua lại vào tháng 7 năm 2025). Họ cũng đang phát triển dòng mô hình SWE-1.x của riêng mình. Benchmark được công bố trên blog công khai tại cognition.com/blog/frontier-code.

Thay đổi then chốt không nằm ở những con số mới. Đó là thang đo hiện được dùng để đánh giá mọi thứ.

Benchmark có ba cấp độ khó: Extended (150 nhiệm vụ, toàn bộ tập), Main (100 nhiệm vụ khó nhất, gồm cả Diamond) và Diamond (50 nhiệm vụ cực khó). Cognition cố tình để Diamond “phần lớn chưa bão hòa”—ngay cả mô hình tốt nhất cũng giải được chưa đến 15%. Mục tiêu là để benchmark còn dư địa phát triển trong một năm và không bị bão hòa chỉ trong một tháng như HumanEval.

FrontierCode đo điều gì: “Người bảo trì có gộp PR này không?”#

Sáu tiêu chí đánh giá (theo blog chính thức của Cognition):

1. Tính đúng đắn về hành vi — bản vá có giải quyết nhiệm vụ không?
2. An toàn hồi quy — bản vá có tránh làm hỏng mã hiện có không?
3. Tính sạch về mặt cơ học — bản vá có vượt qua kiểm tra build, lint và phong cách không?
4. Tính đúng đắn của kiểm thử — các bài kiểm thử do tác nhân viết có hợp lệ không (bài kiểm thử vượt qua với bất kỳ mã nào thì không được tính)?
5. Phạm vi — bản vá có tránh đụng đến các tệp không được yêu cầu không?
6. Chất lượng mã — mã có tuân theo quy ước của dự án và dễ đọc không?

Để được xem là có thể gộp, bản vá phải vượt qua cả sáu tiêu chí. Chỉ cần trượt một tiêu chí, bản vá sẽ không được gộp.

Đó là thay đổi chính trong cách nhìn. “Tính đúng đắn giờ là điều kiện tối thiểu,” như Cognition diễn đạt. Trước đây, benchmark hỏi: “Mã có vượt qua các bài kiểm thử không?” Giờ đây, câu hỏi là: “Một trưởng nhóm kỹ thuật thực sự có đưa mã này vào dự án không?”

Cognition đưa ra ba kỹ thuật chấm điểm mới:

• Reverse-Classical: một bài kiểm thử do tác nhân viết phải thất bại trên phiên bản mã bị hỏng. Nếu không, bài kiểm thử đó chỉ là giả.
• Code Scope: trình kiểm tra tự động xác minh bản vá chỉ nằm trong các tệp và giới hạn số dòng đã thống nhất cho nhiệm vụ.
• Adaptive Classical Grading: công cụ LLM “mutagent” điều chỉnh các bài kiểm thử nghiêm ngặt cho những biến thể giải pháp hợp lệ.

Vì sao các benchmark cũ không còn hiệu quả?#

Đến năm 2024, các tác nhân AI đã đạt kết quả rất cao trên HumanEval. SWE-bench Verified cũng tương tự: tháng 8 năm 2025, OpenAI công khai thừa nhận vấn đề nhiễm dữ liệu (các mô hình đã “thấy” tập dữ liệu trong quá trình huấn luyện). Benchmark mất khả năng phân biệt giữa những mô hình hàng đầu.

Nghiên cứu then chốt làm lung lay thước đo cũ được công bố vào tháng 3 năm 2026.

Họ đã làm gì:

• Chọn 4 người bảo trì đang hoạt động từ 3 kho mã (scikit-learn, Sphinx, pytest).
• Yêu cầu họ đánh giá 296 PR do AI tạo từ SWE-bench Verified—tất cả các PR này đều vượt qua kiểm thử tự động.
• So sánh quyết định của người bảo trì với trình đánh giá tự động.

Nói cách khác, benchmark nói “đã vượt qua”, còn người bảo trì nói “không gộp”—và điều đó xảy ra trung bình trong một phần tư số trường hợp. Ba lý do từ chối hàng đầu, xếp từ ít nghiêm trọng đến nghiêm trọng nhất:

1. Chất lượng mã — không phù hợp với phong cách của kho mã.
2. Làm hỏng mã khác — làm hỏng mã lân cận.
3. Lỗi chức năng cốt lõi — không giải quyết đầy đủ nhiệm vụ dù bài kiểm thử đã đạt.

FrontierCode chính thức hóa đúng vấn đề này. Cognition lấy ý tưởng này và mở rộng nó thành một benchmark hoàn chỉnh với hơn 20 người bảo trì thay vì 4.

Một bằng chứng nữa là nghiên cứu tháng 12 năm 2025 về độ an toàn của các bản vá do AI tạo ra.

Trong nghiên cứu này, 61% giải pháp của SWE-Agent với Claude 4 Sonnet đúng về mặt chức năng, nhưng chỉ 10.5% trong số đó an toàn.

Mã vượt qua bài kiểm thử, nhưng cứ hai bản vá thì có một bản tạo ra lỗ hổng bảo mật. Bạn hoàn toàn không thể thấy điều này qua benchmark SWE-bench—chúng không đo lường bảo mật. Ít nhất FrontierCode cũng cố gắng phát hiện vấn đề qua các tiêu chí “tính sạch về mặt cơ học” và chất lượng mã.

Xếp hạng mô hình: Opus 4.8 đạt 13.4%, GPT-5.5 đạt 6.3%#

Những điểm nổi bật từ bảng:

• Một người dẫn đầu rõ ràng. Opus 4.8 của Anthropic đạt điểm cao gần gấp đôi đối thủ đứng gần nhất. Khoảng cách khó nhận ra trên SWE-bench lại hiện rõ trên FrontierCode.
• Các mô hình mở vẫn chưa bắt kịp. Kimi K2.6—mô hình mã mở tốt nhất—đạt 3.8% trên Diamond. Điểm này thấp hơn Opus 4.8 từ 3–4 lần. Cognition chưa công bố đầy đủ kết quả Kimi K2.6 cho Main và Extended, nên hiện chưa thể so sánh trên toàn bộ tập.
• Cognition trung thực xếp mô hình của mình ở phần thấp của bảng.

Tập con Diamond được cố tình để “chưa bão hòa”. Cognition tạo dư địa an toàn cho những năm tới. Nếu các benchmark trước đây bão hòa trong 12–18 tháng, FrontierCode được thiết kế với mức trần cao hơn.

“Có thể gộp 13%” nghĩa là gì với người làm Vibe Coding bằng Claude Code?#

Trước tiên, cần nhìn nhận lại một điểm quan trọng: tập Diamond của FrontierCode cố tình cực kỳ khó. Với các nhiệm vụ thông thường trong một dự án startup mới không có bốn mươi mô-đun phụ thuộc lẫn nhau, tác nhân AI làm tốt hơn đáng kể. Cùng Opus 4.8 đạt 51.8% mã có thể gộp trên Extended (150 nhiệm vụ, toàn bộ tập). Đó là một bức tranh hoàn toàn khác.

Kết quả 51.8% áp dụng tập Extended 150 tác vụ của benchmark. Nó cao hơn Diamond, nhưng cả hai không ước tính khả năng gộp bản vá mọi mô hình trên việc của bạn. Thiếu điểm Main hoặc Extended của mô hình khác không cho phép tự điền hiệu năng.

Điều này có nghĩa gì với người làm vibe coding và đưa mã vào môi trường sản xuất:

• Kiểm thử thành công không còn có nghĩa là “sẵn sàng gộp”. Các bài kiểm thử do chính AI viết có thể vô dụng—chúng vượt qua với bất kỳ đoạn mã nào. FrontierCode đo trực tiếp điều này bằng Reverse-Classical: nếu bài kiểm thử không thất bại trên phiên bản bị lỗi, bài kiểm thử đó không được tính.
• Phong cách và quy ước của kho mã rất quan trọng. Nếu dự án đã có một mẫu chuẩn nhưng AI không làm theo, cộng tác viên thực sự sẽ không chấp nhận thay đổi đó. Với dự án cá nhân không có quy tắc, đây không phải vấn đề lớn. Trong một nhóm, đây là vấn đề số một.
• Kiểm thử không giải quyết được vấn đề bảo mật. Hãy nhớ số liệu ở trên: chỉ 10.5% bản vá an toàn dù 61% đúng. Việc này cần được kiểm tra riêng bằng các công cụ phát hiện token, tệp .env và mật khẩu mặc định.
• Vượt quá phạm vi nhiệm vụ là lỗi AI thường gặp. Bạn yêu cầu sửa một hàm phân quyền nhưng nhận được bản vá viết lại cả tầng nội bộ và phần ghi nhật ký. Đây là một trong 6 tiêu chí của FrontierCode.

AI mắc 6 loại lỗi nào trong các nhiệm vụ khó?#

Hãy cùng xem từng tiêu chí bằng ngôn ngữ đơn giản:

1. Tính đúng đắn về hành vi — bản vá có giải quyết nhiệm vụ không?

Đây là tiêu chí cơ bản nhất. AI thường viết mã trông giống giải pháp nhưng lại giải quyết sai vấn đề. Tôi yêu cầu “thêm xác nhận đã đọc vào tin nhắn” và nhận được hàm markAsRead, nhưng hàm này chưa được kết nối với chính thành phần chat. Kiểm thử hàm thành công. Nhiệm vụ kinh doanh vẫn chưa được giải quyết.

2. An toàn hồi quy — có tránh làm hỏng mã lân cận không?

AI thay đổi một mô-đun, và một mô-đun khác không còn hoạt động. Trường hợp phổ biến nhất: tác nhân AI đổi chữ ký hàm mà quên rằng hàm được gọi ở 17 vị trí khác. Bạn không thể thấy điều này trên SWE-bench—họ chỉ chạy kiểm thử cho một tệp. Trên FrontierCode, họ chạy toàn bộ bộ kiểm thử của kho mã.

3. Tính sạch về mặt cơ học — có vượt qua kiểm tra build, lint và phong cách không?

AI có thể tạo mã biên dịch được trên máy cục bộ nhưng thất bại trong CI: thiếu import, dùng tab thay vì dấu cách, có hai dấu cách cuối dòng, hoặc mắc lỗi trong eslint.config.js. Trong một dự án đang hoạt động, phong cách không phải sở thích tùy ý; đó là quy tắc của nhóm.

4. Tính đúng đắn của kiểm thử — các bài kiểm thử AI viết có hợp lệ không?

Đây là tiêu chí khó nhất. AI viết một bài kiểm thử và bài đó thành công. Nhưng nó thành công với mọi đoạn mã, kể cả mã bị lỗi. Tôi đã thấy điều này nhiều lần: bài kiểm thử kiểm tra “tập lệnh có bị lỗi không?” chứ không kiểm tra “nó có trả về kết quả đúng không?” Reverse-Classical của FrontierCode phát hiện chính xác trường hợp này.

5. Phạm vi — bản vá có tránh đụng đến các tệp không liên quan không?

Tôi yêu cầu sửa một hàm nhưng nhận được bản vá cho 12 tệp, bao gồm cả những tệp không liên quan đến nhiệm vụ. Đó chính là sự “chủ động” của AI làm hỏng một dự án sản xuất bằng cách thay đổi những điều tôi không yêu cầu. Tiêu chí này là điều kiện chặn cứng trong FrontierCode.

6. Chất lượng mã — mã có tuân theo quy ước của kho mã không?

AI tự viết một hàm “từ đầu” thay vì dùng các hàm trợ giúp đã có trong lib/. Hoặc nó đặt tên biến không phù hợp với phong cách của dự án. Hoặc nó đặt logic vào sai tầng kiến trúc. Theo góc nhìn của bài kiểm thử, mọi thứ đều hoạt động. Theo góc nhìn của trưởng nhóm kỹ thuật, mã sẽ không được gộp.

Cách kiểm tra mã AI trước khi push: 5 bước#

1. Chạy toàn bộ bộ kiểm thử, không chỉ các bài kiểm thử liên quan đến thay đổi

   AI thường thay đổi mã ngoài phạm vi nhiệm vụ. Vấn đề sẽ xuất hiện trong các bài kiểm thử lân cận. Tôi chạy toàn bộ bộ kiểm thử (bằng lệnh duy nhất npm test, không kèm đường dẫn), chứ không chỉ kiểm thử một tệp cụ thể. Với dự án lớn, có thể chạy song song thuận tiện bằng git worktree (xem Git worktree trong Claude Code).

2. Chạy kiểm tra lint, phong cách và kiểu dữ liệu

   Ba lệnh theo thứ tự: eslint ., prettier --check ., tsc --noEmit. Tác nhân AI có thể bỏ sót cả tab lẫn dấu cách thừa cuối dòng. Nếu dự án có các bước kiểm tra nghiêm ngặt, hãy chạy chúng trên máy cục bộ trước khi phát hành.

3. Kiểm tra chính bài kiểm thử

   Đây là bước quan trọng nhất trong 5 bước. Tôi tạo một thay đổi nhỏ để “làm hỏng” mã (đổi return true thành return false). Bài kiểm thử phải thất bại. Nếu bài kiểm thử không thất bại, AI chỉ viết nó cho có và nó vô dụng. Tôi xóa bài kiểm thử rồi yêu cầu AI viết lại với điều kiện bắt buộc: bài kiểm thử phải thất bại trên phiên bản bị hỏng.

4. Kiểm tra những tệp AI đã động đến

   Lệnh git diff --stat cho biết những tệp nào đã thay đổi và có bao nhiêu dòng. Nếu AI động đến 12 tệp khi được yêu cầu “sửa biểu mẫu liên hệ”, nó đã vượt quá phạm vi nhiệm vụ. Tôi hoàn tác các thay đổi thừa bằng một lệnh cho tệp đó.

5. Kiểm tra bảo mật bằng một skill có sẵn

   Kiểm thử không phát hiện SQL injection hoặc mật khẩu được viết cố định trong mã. Tôi dùng một skill bảo mật có sẵn cho Claude Code (xem 754 skill bảo mật có sẵn). Tối thiểu, hãy tự tìm trong mã dự án các từ “password,” “secret,” và “key”, rồi kiểm tra xem .env.example đã đầy đủ chưa.

Cả 5 bước bao quát 5 trong 6 tiêu chí của FrontierCode (1–5). Tiêu chí thứ sáu—chất lượng mã—được kiểm tra tự động thông qua lint và một lượt đánh giá của con người.

Điều gì thực sự cải thiện cơ hội tạo ra mã có thể gộp?#

Một tác nhân AI trong dự án chưa được chuẩn bị chỉ thấy tệp bạn mở cho nó. Nó không có lịch sử quyết định của bạn, không biết quy ước của bạn và không có sơ đồ các mô-đun. Với những thay đổi đơn giản, điều này không đáng ngại. Với thay đổi khó, thiếu ngữ cảnh dự án là rủi ro cần xử lý. Con số 13.4% của benchmark không tách chất lượng ngữ cảnh làm nguyên nhân.

Bạn cần làm gì để biến 13% đó thành thứ thực sự có thể đưa vào môi trường sản xuất:

1. Quy tắc dự án — để AI tái tạo cách suy luận của bạn thay vì mức trung bình trên internet.

Đây là tập hợp các giải pháp có sẵn, thói quen và quy tắc đã học của bạn, được lưu ở định dạng mà tác nhân AI đọc trong mỗi yêu cầu. Khi có 30+ quy tắc, AI ngừng bịa ra “mức trung bình của ngành” và bắt đầu đưa ra đề xuất theo phong cách của bạn. Có thể xử lý việc vượt phạm vi nhiệm vụ bằng một dòng trong các quy tắc: “đừng chạm vào tệp nào ngoài những tệp được nêu rõ trong yêu cầu.”

2. Bản đồ dự án — một thư mục mô tả dự án.

Đây là nơi bạn đặt thông tin về sản phẩm, đối tượng, kinh tế, chỉ số và cấu hình. Trước mỗi yêu cầu, tác nhân AI đọc mục lục và hiểu nó đang làm việc với phần nào của doanh nghiệp. Điều này tự động giải quyết hai trong số các lý do từ chối nêu ở trên: phong cách và làm hỏng mã khác.

3. Context Engineering — quản lý những gì AI nhìn thấy trước yêu cầu.

Không phải “cách diễn đạt prompt”, mà là “đưa gì vào cửa sổ ngữ cảnh TRƯỚC prompt”. CLAUDE.md, các điều kiện tiên quyết và liên kết có mục tiêu đến các tệp. Cách này xử lý các lỗi về tính đúng đắn hành vi và chất lượng mã.

Dùng tổ hợp này để chuẩn bị kiểm tra, không coi là bằng chứng năm tiêu chí đã đạt. Xác minh hành vi, hồi quy, test, phạm vi và chất lượng trên bản vá thực trước chấp nhận.

Một lớp bổ sung là các tác nhân đánh giá:

• Cursor Bugbot — đánh giá mọi PR. Theo Cursor, công cụ xử lý khoảng 2 triệu PR mỗi tháng.
• Các subagent lồng nhau trong Claude Code v2.1.172 — một tác nhân viết mã, tác nhân thứ hai đánh giá, tác nhân thứ ba chạy kiểm thử. Đó cũng là ý tưởng của FrontierCode: tách biệt vai trò “người viết” và “trưởng nhóm kỹ thuật”.

Xem thêm: Bảo mật trong Vibe Coding, Cách cấu hình Claude Code để nó không làm hỏng dự án của bạn vào ban đêm, và khái niệm Context Engineering.

Để xem thêm tài liệu về cách làm việc với các công cụ, hãy xem tài liệu Ailoot.