Khi AI viết code đã giỏi: Làm sao đo được độ "cẩu thả" của mã nguồn?

Các mô hình ngôn ngữ lớn (LLM) ngày càng viết code gần như hoàn hảo về mặt cú pháp, nhưng điều đó không đồng nghĩa với việc mã nguồn tốt. Một bài viết mới từ kỹ sư Sebastian của Earendil đặt ra câu hỏi hóc búa: làm sao đo lường được độ "cẩu thả" của code do AI tạo ra, và liệu các agent lập trình có thể tự giải quyết vấn đề này không? Câu trả lời, theo tác giả, là không hề đơn giản.

Code đúng chưa chắc đã tốt

Khi LLM ngày càng viết code chuẩn xác, người ta dễ lầm tưởng rằng bài toán lập trình đã được giải quyết. Nhưng theo Sebastian, việc code "đúng về mặt hình thức" không có nghĩa nó không tạo ra những lớp trừu tượng thừa thãi, các đoạn trùng lặp, hay đơn giản là những quyết định thiết kế tồi.

Đây không phải là quan sát mới mẻ. Bất kỳ ai từng "vibe-code" một dự án đều nhận ra rằng mỗi tính năng thêm vào đôi khi khiến số dòng code (LOC) bùng nổ. Vấn đề nằm ở chỗ: trong các dự án thêm hàng triệu dòng code mỗi tháng, con người khó có thể theo kịp, dẫn đến mất quyền kiểm soát.

Nhiều người biện luận rằng điều đó không đáng lo vì họ tin tưởng agent của mình sẽ xử lý được. Tác giả thẳng thắn phản bác:

"Tôi có tin xấu cho bạn: các agent thực sự không thể xử lý được đống code rác đó."

Ngành công nghiệp đang đánh giá code dựa trên... cảm giác?

Xuất thân từ ngành vật lý, Sebastian mang tư duy thực nghiệm và định lượng vào bài toán này. Khi bắt đầu làm việc tại Earendil với nhiệm vụ đo lường độ cẩu thả của code, phản xạ tự nhiên của anh là nghiên cứu tài liệu học thuật và xem các công ty khác đang làm gì.

Kết quả khá thất vọng. Ngoài một vài bài báo nghiên cứu giá trị, anh nhận thấy ngành này hiện đang đánh giá chất lượng code chủ yếu dựa trên "cảm giác" (vibes). Trên mạng xã hội, những thông điệp như "agent lập trình end-to-end", "AI không chỉ gợi ý code mà còn ship nó", hay "đánh giá ngang tầm con người mà không tốn chi phí con người" liên tục xuất hiện — và như mọi câu chuyện hay, chúng đều chứa một hạt sự thật nào đó.

Lý do LLM viết code chuẩn xác đến vậy nằm ở khả năng mở rộng và tính kiểm chứng của code. Rất dễ để cho LLM sinh code rồi để các bài test ẩn kiểm tra, tạo ra tín hiệu thưởng rõ ràng. Nhưng ngược lại, việc đánh giá độ "cẩu thả" của code thường đòi hỏi trực giác và gu thẩm mỹ của con người — một bài toán cực kỳ khó.

Các phương pháp đo độ "cẩu thả" của code

Tác giả điểm qua những cách tiếp cận phổ biến:

• Dùng AI làm giám khảo: Đây có lẽ là cách phổ biến nhất trong ngành, nhưng theo quan sát của tác giả, nó hiếm khi hiệu quả. Cách ngây thơ nhất — hỏi mô hình xem code tốt đến mức nào trên thang 1-10 — về cơ bản tương đương với một máy sinh số ngẫu nhiên. Cách tinh vi hơn là đưa cho mô hình hai phương án A và B để nó chọn cái tốt hơn, nhưng nhược điểm là mô hình có thể đổi ý chỉ vì ta đổi tên các phương án. Nói cách khác, để LLM tự chấm code do chính nó viết không thể thay thế cho một đánh giá nghiêm túc.

• Con người chấm AI: Bỏ qua thực tế rằng chất lượng lập trình viên rất đa dạng, đây sẽ là giải pháp tốt nhất để đảm bảo code dễ đọc với con người. Nhược điểm là nó không thể mở rộng quy mô cho việc huấn luyện AI hay xây dựng benchmark lớn với nhiều nhà cung cấp mô hình.

• Cách đơn giản nhất: Chỉ cần đo sự thay đổi số dòng code (LOC) hóa ra lại là một chỉ số khá hiệu quả để đánh giá độ cẩu thả. Trớ trêu thay, nếu ta bắt đầu tối ưu hóa theo chỉ số này, nó sẽ mất đi ý nghĩa.

Hai chỉ số đáng chú ý: Verbosity và Erosion

Hai chỉ số tiếp theo được giới thiệu qua bài báo SlopCodeBench, tỏ ra hứa hẹn khi phân biệt được các codebase cũ với "rác LLM":

• Verbosity (độ dài dòng): Đo lượng dòng trùng lặp và dài dòng không cần thiết, dựa trên tỷ lệ giữa số dòng bị công cụ AST-Grep gắn cờ cùng các dòng bị nhân bản, chia cho tổng số dòng code.

• Erosion (độ xói mòn): Đo mức độ tập trung khối lượng của codebase vào một vài hàm lớn và phức tạp. Chỉ số này tính tỷ lệ giữa "khối lượng" của các hàm có độ phức tạp cyclomatic lớn hơn 10 so với tổng khối lượng tất cả các hàm.

Kết quả thực nghiệm khá ấn tượng. Nếu so sánh code sinh ra trong đánh giá SlopCodeBench với một tập hợp các repo lâu đời:

• Verbosity: Trung bình ở các repo là 0,15 ± 0,06, trong khi ở code do agent tạo là 0,33 ± 0,10.
• Erosion: Các repo đạt 0,31 ± 0,17, còn agent là 0,68 ± 0,20.

Tức là code của agent trung bình dài dòng và xói mòn gấp đôi code con người viết. Tác giả còn kiểm tra một số dự án "vibe-code" của chính mình và thấy nhiều dự án có verbosity lên tới 0,4 và erosion lên tới 0,75 — cho thấy kết quả không phải là hiện tượng cá biệt của bài đánh giá.

Vì sao agent không thể tự dọn đống rác của mình?

Quay lại câu hỏi trọng tâm: tại sao agent không thể tự xử lý độ cẩu thả? Câu trả lời nằm ở cách SlopCodeBench được thiết kế. Khác với các benchmark lập trình khác — nơi agent nhận trọn bộ hướng dẫn ngay từ đầu rồi phải vượt qua các bài test ẩn — benchmark này làm ngược lại. Nó tạo ra nhiều vòng lặp hướng dẫn và kiểm tra, trong đó ngữ cảnh của mô hình bị xóa giữa các checkpoint, mô phỏng sát hơn cách con người thực sự dùng agent lập trình.

Hệ quả là các quyết định lập trình tồi tích lũy dần theo thời gian. Với tỷ lệ giải nghiêm ngặt — yêu cầu vượt qua mọi bài test ở mọi checkpoint — ngay cả các mô hình tiên tiến nhất cũng đạt tỷ lệ thành công 0%.

Đây là một dấu hiệu cảnh báo đối với bất kỳ ai đang vui vẻ thêm hàng chục nghìn, thậm chí hàng trăm nghìn dòng code mỗi ngày. Tất nhiên vẫn có những lưu ý thường lệ về bài test quá khắt khe hay đề bài đôi chút mơ hồ, nhưng xu hướng chung vẫn đúng.

Trực giác con người vẫn không thể thay thế

Qua việc khám phá các chỉ số này, tác giả hy vọng người đọc hiểu rõ hơn vì sao đánh giá độ cẩu thả của code lại khó khăn, và vì sao trực giác cùng gu thẩm mỹ của con người vẫn hiện diện — dù ngầm hay rõ ràng — trong quá trình đánh giá.

Sebastian cũng chia sẻ thêm một câu nói tâm đắc: "Đo lường tiến độ lập trình bằng số dòng code cũng giống như đo tiến độ chế tạo máy bay bằng trọng lượng."

Anh cũng đang tìm hiểu những hướng đi hứa hẹn khác như độ ghép nối giữa các hàm (coupledness), tỷ lệ thay đổi code (code churn), và độ gắn kết (cohesion).

Ý nghĩa cho lập trình viên Việt Nam

Với cộng đồng lập trình Việt Nam, nơi làn sóng dùng AI để hỗ trợ code đang bùng nổ, bài viết này là lời nhắc nhở quan trọng. Việc AI giúp tăng tốc phát triển là thật, nhưng số dòng code tăng nhanh không đồng nghĩa với tiến bộ. Nếu không kiểm soát, các dự án dễ rơi vào tình trạng nợ kỹ thuật chồng chất mà chính AI cũng không thể dọn dẹp.

Bài học thực tế: hãy quan tâm đến các chỉ số chất lượng code — không chỉ là code có chạy đúng hay không, mà còn là nó có dễ đọc, dễ bảo trì và ít trùng lặp hay không. Trong kỷ nguyên AI viết code, gu thẩm mỹ và tư duy kiến trúc của con người vẫn là tài sản quý giá nhất.