- Để thành thạo việc sử dụng AI agent, kỹ năng review code là rất quan trọng
- Mô hình ngôn ngữ lớn rất giỏi sinh mã, nhưng thiếu khả năng phán đoán sâu, nên thường lãng phí thời gian theo hướng sai
- Những kiểu review vặt vãnh chỉ soi cú pháp chi tiết, hoặc kiểu đóng dấu cho qua mà không phê phán, đều không giúp ích cho việc tận dụng AI
- Một buổi review code tốt sẽ xem xét góc nhìn cấu trúc, cân nhắc liệu có cách tốt hơn hay không, và giúp tránh các thiết kế quá phức tạp
- Cuối cùng, lập trình với AI là một mô hình kết hợp giữa phán đoán của con người và năng suất của máy, giống như “cờ nhân mã”, và năng lực review code sẽ trực tiếp chuyển hóa thành năng lực khai thác AI
Mối quan hệ giữa AI agent và review code
- Sử dụng AI agent đúng cách thực chất chính là quy trình review code
- Người review code giỏi cũng sẽ tận dụng hiệu quả các công cụ AI cho code như Claude Code, Codex và Copilot
Vì sao kỹ năng review code lại quan trọng
- Mô hình ngôn ngữ lớn rất giỏi tạo ra lượng lớn mã nguồn, nhưng vẫn thiếu khả năng phán đoán của một kỹ sư phần mềm lành nghề
- Vì vậy, nếu để không có giám sát, chúng có xu hướng lãng phí nhiều tài nguyên vào các thiết kế không cần thiết hoặc tồi
Giới hạn của AI agent và lỗi thiết kế
- Ví dụ, trong quá trình phát triển dự án VicFlora Offline, Codex đã dồn rất nhiều công sức vào việc reverse-engineer mã frontend
- Thực tế lại có một cách tiếp cận dữ liệu đơn giản hơn
- Khi dùng AI agent, thỉnh thoảng khoảng mỗi giờ lại thấy nó thực hiện một tác vụ gì đó đáng ngờ
- Nếu phát hiện vấn đề như vậy và tự đổi hướng ngay, có thể tiết kiệm được nhiều giờ làm việc
- Trong một trải nghiệm phát triển ứng dụng khác, AI còn đề xuất dựng hạ tầng nền quá mức cho cả những tác vụ xử lý song song đơn giản
- Dù chỉ cần xử lý non-blocking ở frontend là đủ, nó vẫn cố đưa vào một kiến trúc phức tạp
- Để giữ được tính đơn giản, việc liên tục kiểm soát AI là rất quan trọng
- Nếu người không chuyên chỉ tin vào AI để phát triển, độ phức tạp và sự kém hiệu quả của codebase sẽ tích lũy, khiến khả năng giải quyết vấn đề còn suy giảm nhanh chóng
Bản chất và hiệu quả của review code
- Hợp tác với AI giống như làm việc với một lập trình viên junior rất nhiệt tình nhưng thiếu kinh nghiệm
- AI không tự cải thiện khả năng phán đoán theo thời gian, nên cần được quan sát liên tục
- Sai lầm lớn nhất trong review code là chỉ nhìn vào đoạn mã đã viết mà không nghĩ xem có phương án tốt hơn hay không
- Review code tốt nhất phải nhìn từ góc độ cấu trúc, tích hợp và cân nhắc toàn bộ ngữ cảnh của hệ thống
- Thay vì tạo ra một hệ thống mới không cần thiết, nên ưu tiên phương án tái sử dụng hệ thống hiện có
- Reviewer kiểu 'nitpicky' chỉ chăm chăm vào style chi tiết có thể bỏ lỡ cách tận dụng thực sự của công cụ AI
- Nếu là reviewer kiểu 'rubber-stamp' và cho qua mà không phản biện, sẽ rất khó cộng tác hiệu quả với AI hoặc lập trình viên junior
Suy nghĩ về kỹ năng sử dụng công cụ AI
- Các công cụ truyền thống như git có cấu trúc và cách thao tác rõ ràng, còn cấu trúc nền tảng của AI thì thiếu minh bạch
- AI có thể thực hiện gần như mọi loại tác vụ tính toán
- Một số người cho rằng khả năng khai thác AI là biết dùng công cụ AI theo mọi hướng có thể
- Thực tế, người dùng thành thạo mới kéo được nhiều khả năng hơn từ nó
- Ở thời điểm hiện tại, AI code agent có thể hỗ trợ nhiều loại công việc nhưng vẫn cần sự giám sát chặt chẽ
- Giống mô hình "cờ nhân mã", khi định hướng của con người lành nghề kết hợp với các đề xuất của AI, có thể đạt năng suất tối ưu
- Năng lực sử dụng AI rốt cuộc phụ thuộc vào kỹ năng review code và khả năng phán đoán thiết kế có tính phản biện
- Kỹ năng review code càng tốt thì hiệu quả khai thác các công cụ agentic AI càng được tối đa hóa
Suy nghĩ cuối cùng và triển vọng
- AI agent có thể tạo cảm giác như đang dần trở nên giống một kỹ sư ngày càng lành nghề theo thời gian
- Trong vài năm tới, trải nghiệm cộng tác với AI có thể tiến hóa đến mức tương đương hợp tác với một kỹ sư tầm trung
- Ở hiện tại, điều nên làm là thử nghiệm với nhiều công cụ AI khác nhau như Codex, Claude Code, Copilot..., và năng lực giám sát phản biện mới là điểm khác biệt quan trọng nhất
Ý kiến bổ sung
- Trên Hacker News và các nơi khác đã có thảo luận về việc “AI agent hữu ích đến mức nào”
- Tác giả không cho rằng chỉ với review code, AI đã có thể đóng góp ở mức độ Linux kernel
- Một số người cũng cho rằng các cách review code như style và đặt tên vẫn rất quan trọng
- Có góc nhìn phê phán việc đưa thảo luận thiết kế vào review code, nhưng tác giả không xem đó là điều tiêu cực
1 bình luận
Ý kiến trên Hacker News
Tôi khá nghi ngờ ý tưởng rằng dù quy trình tệ nhưng nếu kiểm soát chất lượng tốt thì vẫn cho ra kết quả tốt, kiểu như “cứ liên tục thải ra đồ linh tinh, miễn có ai đó kiểm tra là ổn”, nhưng thực tế tôi chưa từng thấy cách đó hoạt động hiệu quả, ngành ô tô Mỹ từng thử theo hướng này nhưng tôi không nghĩ ra được ví dụ thành công nào, thử tưởng tượng sếp nói với tôi, một trưởng nhóm, rằng “thay vì 5 người giỏi, tôi sẽ đưa cho anh 25 người hoàn toàn mới vào nghề, rồi chờ may ra có thứ gì đó chạy được, anh cứ đi review hết đi” thì rõ ràng là vô lý, thế mà khi AI bước vào kịch bản này thì rất nhiều người lại nghĩ “hửm? biết đâu lại được?” mới lạ
Review code của những người ít kinh nghiệm hoặc thiếu động lực cũng cực kỳ mệt, tiêu tốn rất nhiều năng lượng cả về tinh thần lẫn cảm xúc, đến khi phải review cùng một tính năng tới 4 lần thì sẽ chán ngán và bỏ cuộc ở mức mà chất lượng không thể cải thiện thêm nữa
Điều này hoàn toàn ngược với hình mẫu quản lý chất lượng mà Edward Deming phát triển ở Nhật và truyền bá sang phương Tây, chất lượng không đến từ con người mà đến từ quy trình, chọn một công đoạn đầy lỗi rồi kỳ vọng con người sẽ bắt được sai sót không phải là cách hay nếu mục tiêu là chất lượng, LLM có thể được dùng theo nhiều cách nhưng chỉ một số cách trong đó mới có lợi thế, giới quản lý đang rơi vào ảo tưởng rằng AI có thể giải quyết mọi vấn đề, và có vẻ họ либо không hiểu đúng ưu nhược điểm của AI, либо đã quên mất bài học của Deming
Tiến hóa là một ví dụ của đột biến ngẫu nhiên và chọn lọc, hay chính sự tồn tại của mọi dạng sống phức tạp cũng vậy, đây không phải cách tôi ưa thích nhưng con người có xu hướng mê mẩn buzzword đang thịnh hành rồi thử bừa cả ở những chỗ không phù hợp, trong sản xuất một số linh kiện nhựa của đồ dùng nhà bếp vẫn còn kiểu làm chất lượng kém ngay từ đầu rồi thuê lao động thời vụ dùng dao gọt sửa thủ công trước khi đóng gói, tôi cũng từng làm việc thời vụ kiểu đó, chip binning/yield management trong bán dẫn cũng có thể xem là ví dụ có tỷ lệ lỗi rất cao, chỉ cần nhìn quanh thực tế là thấy những quy trình đáng ngờ không hề hiếm mà gần như là chuyện thường ngày
Khi bắt đầu tự đánh giá rằng mình “giỏi sử dụng AI”, bạn sẽ dễ ảo tưởng rằng “phạm vi vấn đề mình có thể giải quyết đã rộng ra khủng khiếp”, hiện tượng này xuất hiện với mọi công nghệ đa dụng, trước đây thời bùng nổ genetic algorithm cũng tương tự, ai cũng đi tìm một công cụ “đa năng” rồi lầm tưởng có thể dùng nó cho mọi thứ, trong thực tế lại cố tối ưu hóa trong tình huống chẳng có ngữ cảnh nào cả, AI là ví dụ đẩy hiện tượng này lên mức cực đoan hơn
Dù quy trình có tốt đến đâu thì bạn cũng không thể học được bản thân cách tạo ra một hệ thống thực sự hoạt động ổn, mô thức lặp đi lặp lại mà tôi thấy là đội ngũ loay hoay rất lâu, rồi cuối cùng một kỹ sư biết cách giải bài toán mới phải trực tiếp ra tay để đưa mọi thứ về đúng hướng
Bắt AI tuân thủ đúng các tham số yêu cầu thực sự rất khó, nó luôn ngẫu nhiên lệch sang hướng kỳ quặc nào đó, khi làm phần highlight cho nftables thì có 230 token, 2.500 trạng thái và hơn 50.000 chuyển trạng thái, dù tôi đưa cho AI 5 quy tắc rất rõ ràng thì nó vẫn lệch ở những điểm ngẫu nhiên, không chỉ kết quả code mà ngay cả Vimscript rất đơn giản cũng làm không ra hồn, rốt cuộc tôi chỉ dùng AI cho mục đích tài liệu hóa, dù vậy AI bắt đầu làm khá ổn ở việc giải thích theo từng mảnh như
rule,chain_block stmt,map_stmt_expr, tôi chỉ cần copy-paste đúng mẫu cú pháp mình muốn dùng là đượcSinh code bằng AI khá hữu ích ở giai đoạn đầu của dự án, nhưng với dự án đã trưởng thành thì có điểm đáng lo, gần đây parser Postgres hơn 280 nghìn LOC đã được merge vào Multigres mà không có review công khai, đây là điều đáng cảnh giác trong hệ sinh thái mã nguồn mở, rất nhiều người phụ thuộc vào các dự án như vậy để học hỏi và tham khảo, nếu code AI được đưa vào mà không có review đúng nghĩa thì giá trị giáo dục và độ tin cậy của phần phụ thuộc sẽ suy yếu, code review không chỉ để bắt bug mà còn là cốt lõi để cộng tác viên học hỏi, hiểu lý do thiết kế và tích lũy tri thức tập thể, vấn đề không phải tốc độ mà là quy trình truyền đạt tri thức, còn về thời gian cho đến lúc PR được công khai thì xem liên kết này
Quy trình của tôi đại khái như sau
Trong quá trình thực hiện tôi cũng thỉnh thoảng chụp snapshot để có thể quay lui
Làm vậy thì dù chưa đạt mức xuất sắc, ít nhất tôi cũng có được một kết quả đủ để làm mốc tham chiếu cho phần triển khai của mình
Điểm trừ là cực kỳ tốn thời gian, và trong 80% trường hợp tôi vẫn cảm thấy nếu tự làm từ đầu một mình thì có lẽ còn nhanh hơn
Có vẻ còn chậm hơn cả tự làm, khi code với AI tôi có cảm giác như đang xem sản phẩm của một dev tầm trung kiểu “tôi vừa nhấp chút rượu rồi làm đại theo mấy ghi chú anh đưa, thấy sao?” sau một cuối tuần thức đêm ứng biến, chỉ cần nói một câu “NO, tôi không thích” rồi nếu hướng đi đại thể đúng thì mình refactor nó và cảm giác vẫn nhanh hơn đôi chút so với việc bắt đầu lại từ sáng thứ Hai
Mỗi lần đọc các hướng dẫn theo từng bước kiểu này thì cuối cùng thấy như chỉ đang cộng thêm một đống phiền toái, đến mức hiệu quả mà ban đầu người ta kỳ vọng AI mang lại gần như biến mất, trong trải nghiệm thực tế của tôi thì điều này hầu như đúng, dĩ nhiên cũng có lúc AI hữu ích, nhưng theo tôi việc biết khi nào và ở đâu nó thực sự có ích cũng là một kỹ năng quan trọng
Tôi làm ở tầng thấp hơn một chút và thường theo kiểu này:
Nói chung khi đưa một mục tiêu quá rộng và dài ngay từ đầu thì agent thường đánh giá sai thời điểm công việc đã hoàn thành
Tôi dùng một quy trình tương tự nhưng đơn giản hơn, vẫn đưa PRD, tôi cũng nói luôn kiến trúc tổng quát, rồi bảo nó triển khai từng component theo cách tôi muốn, vẫn rất tốn thời gian và tự làm chắc nhanh hơn, nhưng giờ tôi ngại phải ngồi gõ từng dòng nên đang nghĩ hay là giao cho LLM làm ở mức từng hàm
Nếu tôi chỉ dùng AI để hỏi về cách tiếp cận tổng quát, thư viện, đặc điểm ngôn ngữ v.v. thì có lẽ tôi sẽ hoàn thành công việc chính nhanh hơn rất nhiều nếu cứ tự tay làm
Nếu bạn giỏi code review, có lẽ tốt hơn là đừng dùng AI agent ngay từ đầu
Điều tôi rút ra khi trực tiếp review code và sửa bug cho các đồng nghiệp đang mê mẩn agent như Claude Code là code thường kỳ quặc như thể được viết trong trạng thái ảo giác, và người viết nhiều khi hoàn toàn không giải thích nổi về chính đoạn code đó, dĩ nhiên tôi tin là cũng có người tạo ra được code thực sự tốt, nhưng những gì tôi tận mắt thấy thì toàn đáng thất vọng, may là một vài người đã tự nhận ra và quay lại cách làm bài bản hơn, nếu nhìn kết quả từ workflow dựa trên agent hiện nay với con mắt phê phán thì đáp án khá rõ ràng, ai review code giỏi sẽ đi đến kết luận này nhanh hơn nhiều
Nếu tôi review code giỏi, tôi muốn tiếp tục nâng trình của mình hơn nữa
Code review cũng là một phần công việc, nhưng là phần ít vui nhất, vì lập trình viên thấy thỏa mãn ở khoảnh khắc tự tay code, công cụ AI đúng là có ích nhưng vì nó khó đoán mà lại trông có vẻ thuyết phục nên mình phải review kỹ hơn nữa, thành ra gánh nặng còn tăng, tại sao chúng ta lại tạo ra một công cụ lấy mất phần vui và chỉ tăng thêm phần không vui, tôi tự hỏi agent “code review” chuyên trách đang ở đâu
Thật ra bản thân việc 'viết' code không phải điều tôi thấy vui lắm, giải bài toán, tạo ra cái mới, rồi tách hệ thống ra và tái tổ hợp thành cấu trúc tốt hơn mới là thứ thú vị hơn, khi dùng LLM để code tôi có cảm giác tốc độ biến ý tưởng thành thứ gì đó có thể chạm vào được nhanh hơn rất nhiều, code hiện có cũng trở nên type-safe hơn, được tài liệu hóa tốt hơn, và refactor phức tạp dễ hơn, tôi không kỳ vọng LLM giải quyết vấn đề thay mình mà kỳ vọng nó ở việc gom ngữ cảnh, tái áp dụng pattern, tự động hóa mã lặp lại, đặc biệt khi có code rải trên nhiều file thì để AI sinh ra sẵn giúp tôi khỏi phải gõ tay từng chỗ, tôi chỉ cần kiểm tra từng thay đổi là cực kỳ tiện
OpenAI Codex Cloud đã bổ sung tính năng code review, và model GPT-5-Codex mới được huấn luyện chuyên cho code review [Giới thiệu các nâng cấp của Codex], Gemini và Claude cũng đã có tính năng code review tích hợp GitHub Actions hoặc tích hợp GitHub cho Claude, GitHub cũng ra mắt chính thức Copilot Code Review, ngoài ra còn có nhiều startup chuyên biệt như CodeRabbit, Greptile, Qodo Merge
Khoảnh khắc khiến tôi thực sự thấy phấn khích là khi trong lúc triển khai tôi phát hiện ra một cấu trúc cực kỳ thanh nhã ẩn bên dưới, đến mức thay đổi cả cách tôi lập trình trước đây hay thậm chí cách tôi sống (dù chuyện này cực kỳ hiếm)
Dev mới vào nghề thường thích tự tay viết code hơn, còn senior lại yêu việc giảm bớt code, cá nhân tôi thấy code review là phần thú vị nhất trong công việc của mình (khi deadline chưa dí), nên tôi không đồng ý với nhận định rằng code review là việc không vui
Ở phần mở đầu có nói rằng “đa số dev thích tạo mới”, nhưng thực tế cũng có nhiều người thích làm trên codebase người khác đã xây, rồi nhận diện pattern và cấu trúc để cải thiện nó, cũng cần tính đến chuyện có người thấy quá trình làm ra thứ hoàn toàn mới (thiết kế ban đầu - lặp vô hạn) còn khó hơn, còn với câu hỏi “tại sao lại bỏ phần vui và chỉ tăng phần không vui” thì có lẽ vì người ta tập trung vào những chỗ cảm nhận được năng suất tăng rõ nhất, còn AI review thì đã có nhiều lựa chọn như CodeRabbit, GitLab Duo, thậm chí dùng kiểu như RooCode để nạp Git diff rồi giao nó review code cũng hoàn toàn khả thi
Tiêu đề bài này có vẻ quá đơn giản, code review và design review là hai việc khác nhau, và những gì người ta thử với AI cũng không chỉ có mỗi hai việc đó, muốn tận dụng AI thì vẫn cần kiến thức chuyên môn về lĩnh vực đó, ngay cả nếu chỉ nhìn vào coding thì chỉ có năng lực review thôi vẫn chưa đủ, bạn cần khả năng xác minh công việc đã giao cho AI bất kể nó thuộc lĩnh vực nào, nghịch lý là AI lại hữu ích nhất khi tôi chạm vào ngôn ngữ hay framework mình không rành, nhưng lúc đó tôi cũng không thể review code đủ sâu, cũng thú vị khi từ “coding” lại phổ biến trở lại trong thời đại AI/LLM, dạo này các công ty có vẻ thích những kỹ sư làm được từ kiến trúc, phân tích yêu cầu, full-stack đến vận hành hơn là chỉ coder đơn thuần
Chức danh chính thức của tôi là “Software Engineer”, nhưng trong 5 năm gần đây tôi đã
Tôi rất thích ý tưởng rằng qua quá trình code review với đồng nghiệp thì tri thức chung và tiêu chuẩn của cả nhóm cùng được nâng lên, nhưng nghĩ đến việc phải review code của một AI cứng đầu và thiếu hợp tác thôi cũng thấy dễ burnout
Nếu tôi trở nên rất giỏi ở phần nhàm chán nhất của công việc, liệu có phải tôi sẽ phải làm đúng phần đó cả đời không, thành thật mà nói tôi ghét điều đó, và như bài viết đã nói, bug tốt nhất là đừng để lọt vào ngay từ đầu, bắt được sau khi đã chui vào rồi lúc nào cũng đi kèm rủi ro