AI giúp tăng tốc phát triển nhưng số lỗi nhiều hơn gấp 1,7 lần

• Kết quả phân tích 470 PR mã nguồn mở cho thấy mã do AI viết chứa nhiều vấn đề hơn trung bình 1,7 lần so với mã do con người viết
• Các lỗi chính như lỗi logic, giảm khả năng đọc, lỗ hổng bảo mật xuất hiện nhiều hơn rõ rệt trong mã AI, đặc biệt vấn đề về khả năng đọc tăng hơn 3 lần
• Mã AI thường xuyên gặp thiếu xử lý lỗi, lỗi đồng thời, không nhất quán trong cách đặt tên, làm tăng gánh nặng review và rủi ro vận hành
• Nguyên nhân được phân tích là do thiếu hiểu biết về business logic, theo đuổi tính đúng đắn bề mặt, ưa chuộng các pattern kém hiệu quả
• Báo cáo nhấn mạnh sự cần thiết của việc tăng cường hệ thống quản lý chất lượng mã AI và áp dụng quy trình review mã, bảo mật và kiểm thử có nhận thức về AI

---

Tổng quan báo cáo AI vs Human Code Generation Report

• CodeRabbit đã thực hiện nghiên cứu nhằm phân tích thực nghiệm sự khác biệt về chất lượng giữa mã do AI và con người viết
  • Khảo sát 470 GitHub PR mã nguồn mở, trong đó 320 PR có AI đồng tác giả, 150 PR do con người tự viết
  • Tất cả kết quả được chuẩn hóa theo số lượng issue trên mỗi 100 PR, và đo tần suất phát sinh theo từng loại vấn đề bằng so sánh tỷ lệ thống kê
• Kết quả cho thấy AI làm tăng năng suất nhưng đồng thời cũng làm tăng tỷ lệ phát sinh lỗi
  • Trung bình mỗi PR do AI viết có 10,83 vấn đề, trong khi PR do con người viết là 6,45 vấn đề
  • Đặc biệt, các lỗi có mức độ nghiêm trọng cao được phát hiện trong mã AI thường xuyên hơn

Hạn chế của nghiên cứu

• Không thể xác nhận trực tiếp việc mã có do AI viết hay không, nên các PR có tín hiệu AI đồng tác giả (co-authored-by) được phân loại là PR do AI viết
  • Các PR không có tín hiệu này được xem là do con người viết, nhưng không thể phân biệt hoàn toàn chính xác
• Dù có hạn chế này, sự khác biệt có ý nghĩa thống kê trong mẫu hình vấn đề giữa hai nhóm vẫn thể hiện rõ
• Toàn bộ phương pháp luận được công bố ở cuối báo cáo

10 phát hiện chính

• Không phải mọi loại lỗi chỉ tồn tại ở AI, nhưng trong đa số hạng mục, tỷ lệ lỗi của mã AI cao hơn
  • Cả con người và AI đều mắc những kiểu lỗi giống nhau, nhưng AI xảy ra thường xuyên hơn và ở quy mô lớn hơn

• 1. Tổng số issue tăng 1,7 lần

  • Trung bình mỗi PR do AI viết có 10,83 issue, còn PR do con người viết là 6,45 issue
  • Các PR có issue tập trung bất thường (outlier) xuất hiện nhiều hơn hẳn trong mã AI, làm tăng gánh nặng review

• 2. Lỗi nghiêm trọng tăng

  • Các vấn đề mức cao và nghiêm trọng nhiều hơn 1,4~1,7 lần

• 3. Vấn đề logic và độ chính xác tăng 75%

  • Bao gồm lỗi business logic, dependency sai, lỗi control flow, lỗi cấu hình
  • Chi phí sửa cao và có khả năng dẫn đến sự cố vận hành lớn

• 4. Vấn đề về khả năng đọc tăng hơn 3 lần

  • Quy tắc đặt tên, cấu trúc mã, tính nhất quán trong biểu đạt giảm sút rõ rệt
  • Dù mã trông có vẻ gọn gàng, vi phạm pattern cục bộ vẫn xảy ra thường xuyên

• 5. Thiếu xử lý lỗi và nhánh ngoại lệ tăng 2 lần

  • Kiểm tra null, điều kiện guard, logic xử lý ngoại lệ thường bị bỏ sót
  • Đây là kiểu lỗi gắn trực tiếp với sự cố dịch vụ thực tế

• 6. Vấn đề bảo mật tăng tối đa 2,74 lần

  • Tiêu biểu là xử lý mật khẩu không phù hợp, lỗ hổng tham chiếu đối tượng
  • Không phải lỗ hổng hoàn toàn mới, nhưng đa số lỗi bảo mật đều bị khuếch đại

• 7. Vấn đề giảm hiệu năng ít hơn nhưng tập trung ở phía AI

  • Các lời gọi I/O quá mức nhiều hơn khoảng 8 lần
  • AI có xu hướng ưu tiên mã dễ hiểu nên hiệu quả kém hơn

• 8. Lỗi đồng thời và dependency tăng khoảng 2 lần

  • Lỗi thứ tự, luồng phụ thuộc sai, sử dụng sai cơ chế kiểm soát đồng thời xuất hiện thường xuyên

• 9. Vấn đề formatting tăng 2,66 lần

  • Có nhiều lỗi hình thức như thụt lề, khoảng trắng, không nhất quán về style
  • Ngay cả khi dùng formatter và linter tự động, noise trong mã AI vẫn tăng

• 10. Không nhất quán trong đặt tên tăng 2 lần

  • Tên không rõ nghĩa, thuật ngữ không nhất quán, dùng identifier quá chung chung làm tăng gánh nặng nhận thức cho reviewer

Nguyên nhân phát sinh vấn đề

• AI thiếu hiểu biết về business logic
  • Tạo mã dựa trên pattern thống kê nên bỏ sót các quy tắc của hệ thống
• Sinh mã thiên về tính đúng đắn bề mặt
  • Mã nhìn qua có vẻ đúng nhưng vẫn có lỗi bảo vệ control flow hoặc sai thứ tự phụ thuộc
• Không tuân thủ quy ước riêng của repository
  • Các quy tắc về đặt tên, cấu trúc, format bị biến thành dạng khái quát hóa
• Pattern bảo mật bị suy yếu
  • Nếu không có chỉ dẫn rõ ràng, AI sẽ tái tạo các pattern mã cũ hoặc dễ tổn thương
• Ưa sự đơn giản hơn hiệu quả
  • Có xu hướng dùng I/O lặp lại, cấu trúc chưa tối ưu

Cách ứng phó dành cho các nhóm kỹ sư

• Việc áp dụng AI không chỉ đòi hỏi tăng tốc độ mà còn cần thiết kế lại hệ thống đảm bảo chất lượng

• 1. Cung cấp đủ ngữ cảnh cho AI

  • Cần nêu rõ quy tắc nghiệp vụ, pattern cấu hình, ràng buộc kiến trúc để giảm lỗi
  • Bao gồm hướng dẫn riêng theo repository và schema trong prompt

• 2. Bắt buộc style mã dựa trên chính sách

  • Ngăn ngừa vấn đề về khả năng đọc bằng CI formatter, linter, style guide

• 3. Bổ sung các cơ chế an toàn cho độ chính xác

  • Bắt buộc test, kiểm tra null/type, chuẩn hóa xử lý ngoại lệ, nêu rõ điều kiện guard

• 4. Tăng cường mặc định bảo mật

  • Tập trung hóa credential, chặn dùng trực tiếp mật khẩu, chạy SAST và security linter tự động

• 5. Định hướng các pattern hiệu quả

  • Batch I/O, chọn cấu trúc dữ liệu phù hợp, cung cấp gợi ý hiệu năng

• 6. Áp dụng checklist PR có nhận thức về AI

  • Khi review, cần kiểm tra các mục sau:
    • Có bao phủ đường đi lỗi hay không
    • Tính chính xác của kiểm soát đồng thời
    • Có xác thực giá trị cấu hình hay không
    • Cách xử lý mật khẩu

• 7. Tự động hóa review mã AI

  • Để tránh bỏ sót bug do gia tăng mệt mỏi khi review, báo cáo đề xuất sử dụng công cụ review mã AI (CodeRabbit)
    • Chuẩn hóa chất lượng review và giảm thời gian kiểm tra cũng như gánh nặng nhận thức

Kết luận

• Công cụ lập trình AI là bộ tăng tốc mạnh mẽ, nhưng tăng tốc không có cơ chế bảo vệ là điều rủi ro
• Mã do AI sinh ra có mức biến động, tỷ lệ lỗi và mức độ nghiêm trọng đều cao hơn
• Cần sử dụng AI như công cụ bổ trợ chứ không phải thay thế, đồng thời tăng cường hệ thống chất lượng, bảo mật và kiểm thử là bắt buộc
• Muốn đảm bảo cả tốc độ lẫn chất lượng thì cần quản trị kỹ thuật có chủ đích
• Việc sử dụng công cụ review mã AI có thể giúp ích thực tế trong việc duy trì chất lượng

[cshj55]

Gấp 1,7 lần thì cũng ít hơn tưởng tượng nhỉ...?

[ds2ilz]

Tôi cũng cảm thấy khá giống như vậy khi lập trình bằng AI. Nhìn vào các nguyên nhân đã được sắp xếp lại thì có lẽ là vì khi con người code, những thứ như các pattern được mặc định từ kiến thức nền tảng, quy tắc đặt tên, xử lý edge case, guard condition, v.v. không được cung cấp đầy đủ trong context.
Vì vậy tôi tạo hẳn một file quy tắc gom riêng mấy thứ đó lại, rồi khi code thì ra lệnh phải обязательно đọc và tuân thủ file đó. Làm vậy thì chỉ cần cải thiện file rule thôi là chất lượng kết quả tốt lên đáng kể.

[princox]

Mình hơi sợ sẽ có ý kiến kiểu: "Làm ra nhiều khủng khiếp như vậy thì bug nhiều gấp 1,7 lần chẳng phải là quá hời sao..."

[kimjoin2]

Nhưng vẫn nhanh mà, đúng không? Làm tôi nhớ đến cái meme đó haha

[GN⁺]

Ý kiến trên Hacker News

• Tôi nghĩ "vibe coding" đã tồn tại từ trước cả AI

  • Tôi đã thấy nhiều lập trình viên không tìm hiểu vì sao object lại là null mà chỉ dán thêm null check khắp nơi
  • Cách tiếp cận này có ích trong một số trường hợp, nhưng nếu cả hệ thống đều được xây như vậy thì bảo trì sẽ là cơn ác mộng
  • Vibe coding dựa trên AI tạo cảm giác như đang tăng tốc kiểu làm việc “không biết vì sao nó chạy, chỉ cần thấy ra đúng thứ mình muốn trên màn hình”
  • Trước đây tôi từng làm ở một công ty như vậy, nơi null check nuốt luôn ngoại lệ nên lỗi thường bị chôn vùi một cách im lặng
    • Cả nhóm tự khen mình thông minh, nhưng thực ra hệ thống chỉ vận hành nhờ code copy-paste từ StackOverflow và một cấu trúc MVP đã lỗi thời
    • Trong môi trường như vậy, gần như không thể tư duy độc lập
    • Dù vậy, các công cụ như Claude Code vẫn có thể tăng năng suất rất nhiều trên một codebase được thiết kế tốt
  • Copy-paste từ StackOverflow rồi dừng ở mức “chạy tạm là được” chính là vibe coding
    • AI chỉ đơn giản là tự động hóa quá trình đó
  • Diễn đạt chính xác hơn không phải là “thấy thứ mình muốn thấy”, mà là “đưa bất cứ thứ gì lên màn hình”
    • Những null-check thêm vào vô thức về sau có thể gây ra lỗi dữ liệu tinh vi, khiến việc lần ra nguyên nhân cực kỳ khó
  • Tôi cũng đồng ý, nhưng vibe coding đang khiến kiểu lập trình viên phụ thuộc vào StackOverflow trở nên nhanh hơn
    • Số kiểu lập trình viên không tự giải quyết vấn đề sẽ còn tăng lên
    • Hơn nữa, độ tin cậy giờ còn thấp hơn trước
  • Điều khiến tôi bực nhất khi dùng AI là nó cứ sao chép nguyên phong cách code tầm trung của từng ngôn ngữ
    • Tôi theo nguyên tắc “đừng tạo ra dữ liệu sai thì sẽ không phải xử lý nó”, nhưng AI cứ liên tục vi phạm điều đó
    • Nó hầu như không định nghĩa type hay duy trì invariant, mà cứ muốn xử lý mọi thứ bằng string và integer
    • Vì thế tôi chỉ dùng AI theo kiểu tab-complete và tự sửa các lỗi cấu trúc
    • Sau khi sửa xong thì AI cũng đi theo đúng hướng, nên nếu tích hợp IDE và LSP tốt hơn nữa thì sẽ hữu ích hơn rất nhiều

• Những chỉ trích về vibe coding là hợp lý, nhưng thật ra chất lượng code đã tệ từ trước cả AI

  • Phần lớn code vốn đã được triển khai chậm và chất lượng cũng thấp
  • Nếu việc triển khai nhanh giúp kiểm chứng ý tưởng nhanh hơn, thì cũng có người cho rằng chấp nhận một mức lỗi nhất định là hợp lý
  • Dạo này nhiều lãnh đạo còn hỏi “sao từng này tính năng mà mất đến mấy tháng?”
  • Nhưng lý do khiến “một tính năng nhỏ mất nhiều thời gian” không nằm ở thuật toán mà ở hạ tầng và cấu trúc cộng tác
    • AI không giải quyết được những vấn đề gốc rễ đó
  • Chi phí bảo trì và độ phức tạp sẽ tích lũy như lãi kép theo thời gian
    • Vibe coding ổn cho dự án ngắn hạn, nhưng không phù hợp với hệ thống dài hạn
  • Tôi cho rằng sự cân bằng giữa lập trình viên có chủ đích và lập trình viên kiểu vibe là rất quan trọng
    • AI đang khuếch đại phía vibe quá mức và làm mất cân bằng hệ thống
  • Quan trọng hơn chất lượng code là sự thấu hiểu chung giữa bài toán kinh doanh và cách giải bằng công nghệ
    • Dù chất lượng thấp, điều quan trọng hơn là hiểu rõ lý do và trade-off đằng sau nó
  • Nhưng việc người không hiểu phần mềm nói với lập trình viên rằng họ “đang làm sai” thì khó có thể xem là tín hiệu tích cực

• Câu “code AI tạo ra có nhiều vấn đề hơn 1,7 lần” thực ra chỉ là số lượng bug được phát hiện

  • Trên thực tế, vì PR review không được làm tử tế nên rất nhiều vấn đề trong code AI cũng bị bỏ sót
  • Cũng có nghiên cứu cho rằng code review nên tập trung vào hiểu và chia sẻ cấu trúc hơn là chỉ tìm bug
  • Ngược lại, cũng có ý kiến cho rằng code AI có nhiều chú thích và dễ đọc hơn nên lại được review kỹ hơn
    • Trong code do người viết, các comment kiểu “không biết cái này là gì nhưng xóa đi thì hỏng” còn nhiều hơn

• Gần đây trong .NET, Copilot đã gợi ý cho tôi phần triển khai IComparable, giúp tiết kiệm được vài phút

  • Nhưng nó lại đổi tên biến thành x và y, khiến tôi phải debug suốt một tiếng
  • Nếu tự viết thì có lẽ tôi đã không mắc lỗi đó
  • Dù sao thì kết quả cuối cùng cũng gần như giống hệt đoạn code tôi sẽ tự viết

• Trước đây cũng từng có tình huống tương tự

  • Nếu bỏ qua xử lý lỗi và các edge case thì có thể triển khai nhanh hơn rất nhiều, nhưng cuối cùng sẽ thành quả bom bug
  • AI chỉ đang đẩy điều đó đến cực đoan
  • Thậm chí còn có câu đùa kiểu “nếu vậy thì chẳng phải nên chuyển sang Erlang hoặc Elixir sao?”

• Tôi thấy thú vị khi một công ty làm về LLM lại khẳng định rằng “AI không tệ như mọi người nghĩ”

  • Nhưng Coderabbit là công ty làm review code bằng LLM, nên ngược lại họ cũng có động cơ để nói “AI làm code lộn xộn, vì thế phải dùng AI để review”
  • Tôi cũng dùng Copilot như một công cụ review, và review bằng AI gần như lúc nào cũng chính xác, nên nó giúp ích rất nhiều trước khi đến lượt con người review

• Tôi dùng CodeRabbit khá thường xuyên, nhưng nó vẫn có nhiều false positive

  • Có lúc code đã được kiểm chứng rồi mà nó vẫn chỉ ra rằng “không có kiểm tra dữ liệu”
  • Dù vậy, nếu bạn nói cho công cụ biết là “nó sai”, thì nó cũng học và chấp nhận điều đó

• “nhiều hơn 1,7 lần” và “tăng thêm 1,7 lần” không phải là cùng một ý

  • Nhưng tranh cãi kiểu số liệu như vậy rốt cuộc cũng chỉ là một cuộc cãi vã vô nghĩa

• Agentic AI coding chỉ là một công cụ, dùng sai thì đương nhiên cho ra kết quả sai

  • Về ví dụ ứng dụng thành công, tôi khuyên xem thử trường hợp justhtml của Python
  • Tuy nhiên, kiểu tư duy trắng đen rằng “không biết dùng thì là kém cỏi” mới là vấn đề
    • Dù bạn thấy AI hữu ích hay không, suy cho cùng đó chỉ là khác biệt về trải nghiệm

• Cách đặt tiêu đề của bài là “code AI tạo ra gây ra nhiều vấn đề hơn 1,7 lần”, nhưng diễn đạt này không chính xác

  • Thực tế, “vấn đề” ở đây không chỉ là bug mà còn gồm cả lỗi formatting và naming
  • Bài báo cũng không nêu rõ con số bug thực tế