- Câu hỏi thú vị về việc AI viết code rồi được AI review có hợp lý hay không
- Các bot như Devin AI đang tạo ra nhiều PR nhất, và các trường hợp review cũng do AI thực hiện đang ngày càng tăng
- Cũng có lập luận rằng LLM không có trạng thái (stateless), và cấu trúc nội bộ khi review và khi viết là khác nhau nên có thể phân tách vai trò
- Code do AI tạo ra gây ra những kiểu bug khác với con người, và AI hiệu quả hơn trong việc tìm ra các bug đó
- Kết quả là review bằng AI có lợi thế hơn review của con người trong việc phát hiện lỗi thực tế, nhưng khả năng phán đoán kiến trúc và guideline về style của con người vẫn rất quan trọng
AI có nên tự review code của chính mình?
- Hầu hết công ty đều giữ nguyên tắc tác giả ≠ reviewer
- Tuy nhiên AI dựa trên LLM không có trạng thái và đánh giá lại từ đầu ở mỗi yêu cầu
- Nói cách khác, dù dùng cùng một engine thì viết và review có thể được xem là hai “chiếc xe” khác nhau
Scaffolding: Cấu trúc của review bằng AI
- AI dùng cho review thực hiện các workflow cụ thể như sau:
- phân tích code diff
- phát hiện bug
- viết comment và đánh giá mức độ nghiêm trọng
- tham chiếu tài liệu của codebase và các file liên quan
- Trong khi đó, AI sinh code hoạt động trong một ngữ cảnh hoàn toàn khác, nên review và tạo sinh là hai chức năng khác nhau
Con người thực ra cũng là "cùng một engine"
- Dù tác giả PR và reviewer khác nhau, họ vẫn xuất phát từ cùng một loại trí tuệ con người
- Họ chia sẻ kiến thức và kinh nghiệm tương tự nhau, được đào tạo trong cùng công ty
- Cuối cùng, cả AI lẫn con người đều tương tự ở điểm “cùng engine, khác trường hợp”
Code AI cần review kỹ hơn
-
Chất lượng code AI thấp hơn một chút
- AI nhanh, nhưng do giới hạn của prompt, việc truyền đạt yêu cầu thường thiếu chính xác
- Ngay cả lập trình viên giỏi cũng không review code AI kỹ như code của chính mình
- Kết quả là chất lượng tổng thể bị kéo xuống mặt bằng thấp hơn, và hội tụ về mức trung bình
-
Bug do AI tạo ra khó để con người tìm thấy
- Những bug AI tạo ra thuộc kiểu mà con người bình thường không hay tạo ra
- Ví dụ: sửa dòng ngoài dự kiến, lỗi điều kiện rất nhỏ, v.v.
- Theo thử nghiệm nội bộ của Greptile:
- AI(Sonnet) phát hiện 32 trong số 209 bug mức “Hard”
- Lập trình viên con người trung bình chỉ tìm được 5~7 bug
Kết luận
- Việc AI tự review code của mình về mặt kỹ thuật là khả thi và có ý nghĩa
- AI giỏi hơn con người trong việc phát hiện bug, và thực sự hữu ích trong review
- Tuy nhiên, diễn giải ý đồ, phán đoán thiết kế và đánh giá style code của con người vẫn rất quan trọng
- Tiêu chuẩn truyền thống tác giả ≠ reviewer có thể cần được diễn giải lại theo cách mới đối với AI
3 bình luận
Có lẽ cũng đáng thử việc đổi qua lại các mô hình LLM để review. Ví dụ code được viết bằng mô hình A thì để các mô hình B, C, D review.
À, công ty mình đang làm như thế này: khi tạo PR cho đoạn code viết bằng Cursor (Claude), bọn mình dùng ChatGPT để review. Kiểu như bảo từ giờ hai bên cứ đấu nhau đi vậy. Từ o4-mini trở đi thì mọi người bắt đầu trầm trồ luôn. Cũng có thể thử ngay trong Cursor bằng cách đổi model rồi gửi yêu cầu.
Ý kiến trên Hacker News
Tôi muốn nhấn mạnh điểm này: các kỹ sư không rà soát kỹ mã do AI tạo ra bằng mức độ họ rà soát mã do chính mình viết. Lý do là vì LLM tạo mã nhanh hơn rất nhiều so với tốc độ gõ. Vì thế khi tự viết mã, họ tự nhiên sẽ xem lại, còn khi AI tạo ra thì bước đó bị bỏ qua. Điều thú vị là với các kỹ sư bình thường, AI đôi khi lại giúp nâng chất lượng mã. Càng dùng AI nhiều, kỹ sư giỏi và kỹ sư kém sẽ càng tạo ra mã ở mức tương tự nhau. Mỗi giai đoạn như review code, thiết kế và viết code đều đòi hỏi cách tư duy khác nhau, nên lúc nào cũng thú vị
Mỗi người có cách tương tác khác nhau nên ai cũng có phương pháp hợp với mình hơn. Tôi thấy review dễ hơn viết code. Khi tự viết thì phải nghĩ nhiều về bối cảnh ngoài codebase, còn khi review thì có thể tập trung bối cảnh vào chính codebase nên pattern matching nhanh hơn. Không may là trình độ của LLM mới ở mức kỹ sư junior nên việc review PR lại tốn thêm nhiều công sức và năng lượng
Kỹ sư giỏi không nhất thiết là coder giỏi
Nếu dùng bot và prompt khác nhau cho việc review code bằng AI và viết code bằng AI, có thể phát hiện được nhiều lỗi hơn hẳn. Ngay cả khi lặp lại nhiều lần với cùng một công cụ, đôi khi vẫn tìm ra vấn đề mới. Cả con người lẫn AI đều không thể tạo ra mã hoàn hảo ngay trong một lần. Công cụ AI ngày càng tiến bộ, đã đến mức có thể tự kiểm thử và pre-review chính mã của nó, nhưng tôi tin rằng cả con người lẫn AI cùng review mã PR thì chưa bao giờ là có hại. Ngay cả với công cụ Kamara do chính tôi tạo ra, tôi cũng thường phát hiện vấn đề trong chính đoạn mã nó viết. Cũng từng có vấn đề như ví dụ của greptile, nơi nó đưa ra đề xuất sai hoàn toàn về vị trí code, nhưng chúng tôi đang dần kiểm soát được. Vẫn chưa có công cụ nào hoàn hảo 100%, và tôi cảm thấy vẫn cần thêm thời gian trước khi AI takeover mọi thứ
Khi chúng tôi bắt đầu OpenHands (tên cũ là OpenDevin), các PR do AI tạo ra được gửi lên dưới tên tài khoản AI. Điều này gây ra hai vấn đề nghiêm trọng: 1) người gọi AI có thể merge ngay mà không review code, khiến mã chưa được kiểm tra bị triển khai, 2) PR không có người chịu trách nhiệm rõ ràng nên nếu không được merge hoặc có sự cố thì cũng không rõ phải quy trách nhiệm cho ai. Vì vậy chúng tôi đổi chiến lược để mọi PR đều có người làm owner, còn chỉ commit mới mang tên AI. Bản thân PR hoàn toàn là trách nhiệm của con người
Tôi thấy phần nói rằng LLM giỏi tìm bug rất thú vị. Tôi tò mò không biết đã có bao nhiêu false positive để đạt được tỷ lệ phát hiện bug thực tế cao như vậy. Theo kinh nghiệm của tôi, LLM thường nói "có bug" ngay cả khi không có
Quá đồng cảm. Khi tôi hỏi ChatGPT điều gì đó mà không thích đề xuất của nó, chỉ cần nói "đoạn đó tôi không chắc lắm?" là nó lập tức đổi câu trả lời. Có thể ban đầu nó đúng, nhưng nếu người dùng không tỏ ra chắc chắn thì nó rất dễ dao động. Vì vậy việc kiểm chứng công cụ cho tử tế không hề dễ
Trong trường hợp này, mỗi file chỉ có đúng một bug và bot được yêu cầu phải tìm chính xác một bug đó. Tất cả đều là false positive, nó bịa ra bug ở những chỗ hoàn toàn không có vấn đề gì
Khác biệt giữa các công cụ review code AI trên thị trường nằm ở việc tinh chỉnh tỷ lệ tín hiệu/nhiễu. Có công cụ chính xác hơn rất nhiều và có ít false positive hơn
Trách nhiệm quan trọng nhất của một lập trình viên là tạo ra mã mà bản thân họ tin tưởng và hoạt động đúng. Việc có dùng LLM hay không không quan trọng. Điều quan trọng là khi mở PR, bạn phải có thái độ kiểu như "tôi tin chắc thay đổi này giải quyết được vấn đề và tôi sẵn sàng đặt uy tín của mình vào đó". Vì vậy, dù là người hay AI, PR vẫn luôn cần một người review thứ hai
Theo tôi, uy tín là cốt lõi. Điều này không chỉ áp dụng cho code mà cả văn bản ngôn ngữ tự nhiên cũng vậy. Trong tương lai, không phải tác giả mà là người công khai phát hành, tức người đăng, sẽ phải chịu trách nhiệm cho nội dung. Dù chatbot chỉ can thiệp 5% hay 95%, nếu có vấn đề thì người bị trách là tôi, người đã đăng nó. Không thể biện hộ kiểu "là chatbot làm đó" được
Đây chỉ là ví dụ về một kỹ sư tự động hóa hoàn toàn như Devin, nên có phần khác với kỹ sư thông thường
Dạo này có rất nhiều kỹ sư vô trách nhiệm ném lên những đoạn mã tệ do AI tạo ra rồi mong đồng đội khác sẽ bắt lỗi giúp. Trước đây vì việc sinh code tự nó đã khó hơn nên chuyện này ít xảy ra hơn
Tôi rất đồng cảm với ý rằng trách nhiệm của bạn là tạo ra mã đáng tin cậy. Nhưng ngay cả trước thời AI, code tốt cũng đã không được coi trọng đúng mức. Chúng ta đã xem việc lập trình chỉ như một phương tiện hay cách kiếm tiền. Vốn dĩ nó từng có niềm vui của việc 'giải quyết vấn đề và thay đổi thế giới'. Nhưng giờ đây chúng ta tập trung vào 'kiếm tiền nhanh hoặc xây hào lũy'. Điều quan trọng không phải là code có đẹp hay không, mà là nó có giải quyết vấn đề một cách tinh tế hay không. AI có thể khiến văn hóa này tệ đi, nhưng rốt cuộc mọi thứ vẫn phụ thuộc vào cách ta sử dụng nó
Tôi có điều thắc mắc. Nếu một PR giải quyết được toàn bộ vấn đề nhưng chỉ chứa vài bug nhỏ, thì có ví dụ nào cho thấy PR đó bị xem là lãng phí thời gian không?
Code review là bước chậm nhất trong kỹ thuật phần mềm. Tôi cũng có thể viết code nhanh mà không cần AI, nhưng code review thì không nhanh lên được. Vì vậy tôi cho AI review trước để tiết kiệm thời gian cho đồng nghiệp và bắt bug sớm hơn, nhờ đó rút ngắn vài ngày thời gian đến lúc triển khai. AI đã bắt được cả bug hiển nhiên lẫn sai sót ẩn, và thực sự từng tìm ra bug sâu. Tôi dùng workflow copy diff bằng git cli và xclip rồi dán vào một logic model như o3 để nhận review
Một trong những ưu điểm của AI là nó có thể viết rất nhiều unit test nhanh hơn con người rất nhiều. Và nó cũng có thể tự sửa các vấn đề mà chính nó phát hiện. Workflow lý tưởng không chỉ là review code mà còn là để AI tự động chạy test, rồi xác minh mọi thứ có đáp ứng một spec cụ thể hay không. Quá nhiều test về sau có thể khiến việc refactor trở nên khó hơn (ví dụ: test phụ thuộc vào chi tiết triển khai), và khi thấy phiền thì cũng có thể bỏ riêng các test do AI viết
Tôi rất thích việc có thể tái tạo unit test bất cứ khi nào cần. Khi mở review, tôi thấy cực kỳ hài lòng với kích thước của diff, và tôi tiết kiệm được thời gian viết test nhàm chán để làm được nhiều việc hơn
Hiện tại lập trình vẫn còn nhiều công việc tẻ nhạt, nhưng về lý tưởng AI phải giúp giảm những sự kém hiệu quả này để con người tập trung vào phần sáng tạo. Tuy nhiên trên thực tế, AI đang ngày càng nhắm tới cả những công việc sáng tạo ở cấp độ cao hơn
Thật ra ngay cả không có AI, bạn vẫn có thể dùng framework property-based testing để tự động tạo test với vô số giá trị đầu vào
Tôi có một quy tắc khi review code: nếu sau này tôi không tự tin có thể trực tiếp bảo trì nó, thì tôi sẽ không phê duyệt. Nếu dùng LLM cho cả viết code lẫn review, có thể xem như đang áp dụng cùng nguyên tắc trách nhiệm đó cho công cụ. Nhưng thực sự tôi không nghĩ mình có thể ở lâu trong một tình huống như vậy
Tôi muốn biết có ai đã thử dùng một LLM để tạo script Gherkin từ yêu cầu, rồi dùng một LLM khác để sinh code từ script đó, sau đó dùng Cucumber để kiểm tra kết quả hay chưa. Dù sao thì cả script Gherkin lẫn code đều vẫn cần review, nhưng tôi muốn biết có những loại code nào không thể tạo được theo cách này. Tôi đang xem AI như một developer, và giống như developer con người, chắc hẳn cũng có những lĩnh vực mà nó làm không tốt
Cuối cùng thì tác giả mở PR phải chịu trách nhiệm về tác động và kết quả của chính mã của mình. Khi AI coding trở nên phổ biến và số lượng kỹ sư junior cũng nhiều hơn, trách nhiệm này càng quan trọng hơn. Để AI đảm nhận vòng review đầu tiên là hợp lý, nhưng vẫn cần reviewer là con người để xây dựng hiểu biết về codebase từ góc nhìn bên ngoài và phát hiện các vấn đề ở cấp độ cao hơn. Kết luận là cấu trúc lý tưởng sẽ là AI làm review vòng 1, một kỹ sư khác review code ở khía cạnh ngữ cảnh hoặc cộng tác, và cuối cùng tác giả chịu trách nhiệm cho mọi kết quả