Code review trong thời đại AI

• AI không làm biến mất code review; ngược lại, nó còn làm rõ trách nhiệm chứng minh
• Thay đổi nên được triển khai kèm theo bằng chứng như xác minh thủ công hoặc kiểm thử tự động; sau đó cần review để xác định rủi ro, chủ đích và trách nhiệm
• Trong khi lập trình viên cá nhân dựa vào tự động hóa để bắt kịp tốc độ của AI, team xây dựng ngữ cảnh chung và tinh thần trách nhiệm thông qua review
• Nếu PR không có bằng chứng chạy được thì đó không phải triển khai nhanh, mà chỉ là đẩy việc xuống khâu sau; chỉ những lập trình viên có hệ thống xác minh mới thành công với phát triển tốc độ cao bằng AI
• Điểm nghẽn của code review đã chuyển từ việc viết code sang quá trình chứng minh là nó hoạt động; AI tăng tốc phần việc cơ học nhưng trách nhiệm vẫn thuộc về con người

Thay đổi của code review trong thời đại AI

• Tính đến đầu năm 2026, hơn 30% senior developer đang triển khai chủ yếu mã do AI tạo ra; AI rất giỏi phác thảo tính năng nhưng dễ lộ điểm yếu ở logic, bảo mật và edge case, với mức tăng 75% lỗi logic chẳng hạn
• Lập trình viên solo triển khai nhanh nhờ tốc độ suy luận (inference speed) và dùng test suite làm lưới an toàn, còn team vẫn giữ human review để đảm bảo ngữ cảnh và tuân thủ
• Nếu làm đúng, cả hai đều có thể dùng AI như bộ tăng tốc, nhưng khác biệt nằm ở việc ai xác minh cái gì và khi nào
• Nếu bạn chưa tự mình xác nhận code hoạt động đúng, thì nó chưa thực sự hoạt động đúng
  • AI chỉ làm quy tắc này nghiêm ngặt hơn, chứ không miễn trừ nó

Cách các lập trình viên review khi dùng AI

• Ad-hoc LLM check: trước khi commit, dán diff vào Claude, Gemini hoặc GPT để kiểm tra nhanh bug hay vấn đề style
• Tích hợp IDE: dùng các công cụ như Cursor, Claude Code, Gemini CLI để nhận gợi ý inline và refactor ngay trong lúc code
• PR bot và scanner: dùng GitHub Copilot hoặc agent tùy chỉnh để tự động đánh dấu vấn đề tiềm ẩn trong PR, đồng thời kết hợp công cụ phân tích tĩnh/động như Snyk để kiểm tra bảo mật
• Vòng lặp test tự động: dùng AI để tạo và chạy test, đồng thời đặt coverage trên 70% làm điều kiện để merge
• Review đa mô hình: dùng nhiều LLM để kiểm tra code nhằm bắt được thiên lệch riêng của từng mô hình (ví dụ: tạo bằng Claude, audit bằng mô hình chuyên về bảo mật)

Lập trình viên solo vs team: so sánh

• Lập trình viên solo
  • Trọng tâm review: test tự động + spot check có giới hạn
  • Đánh đổi về tốc độ: tốc độ thời gian suy luận, sửa vấn đề qua vòng lặp lặp đi lặp lại
  • Công cụ cốt lõi: agentic testing (ví dụ: vòng lặp Claude Code)
  • Nguyên tắc: Tự mình chứng minh (Prove it yourself)
• Team
  • Trọng tâm review: dùng phán đoán của con người để xem xét ngữ cảnh và bảo mật
  • Đánh đổi về tốc độ: giữ PR nhỏ để tránh nút thắt review
  • Công cụ cốt lõi: kết hợp bot + policy (ví dụ: gắn nhãn PR do AI tạo)
  • Nguyên tắc: Chia sẻ bằng chứng với team (Share the Proof)

Lập trình viên solo: triển khai bằng “tốc độ suy luận”

• Lập trình viên solo thường 'tin vào cảm giác' của code do AI tạo ra, chỉ kiểm tra các phần cốt lõi rồi để test bắt lỗi, nhờ đó triển khai tính năng rất nhanh
• Họ có xu hướng coi coding agent như một thực tập sinh cực kỳ mạnh mẽ có thể tự xử lý refactor quy mô lớn
• Phát biểu của Peter Steinberger: “Giờ tôi không còn đọc nhiều code nữa. Tôi xem stream, thỉnh thoảng chỉ kiểm tra những phần cốt lõi”
• Điểm nghẽn của phát triển đã chuyển từ việc gõ code sang thời gian suy luận (chờ AI trả kết quả)
• Lưu ý: nếu không có testing đủ mạnh, cảm giác tăng tốc sẽ biến mất
  • Bỏ qua review không phải là loại bỏ công việc mà là trì hoãn nó về phía sau
  • Yếu tố then chốt để thành công với phát triển tốc độ cao bằng AI không phải là tin mù quáng, mà là xây dựng hệ thống xác minh
• Lập trình viên solo có trách nhiệm dùng test tự động diện rộng như lưới an toàn, đặt mục tiêu coverage trên 70%
• Test độc lập ngôn ngữ và dựa trên dữ liệu đóng vai trò quyết định
  • Khi test đủ tốt, agent có thể tạo/sửa phần triển khai và xác minh nó bất kể ngôn ngữ nào
  • Khi bắt đầu dự án, AI có thể viết bản nháp spec.md, sau khi được phê duyệt thì lặp lại chu trình viết → test → sửa
• Ngay cả lập trình viên solo cũng thực hiện test thủ công và phán đoán phản biện ở giai đoạn cuối
  • Tự chạy ứng dụng, click UI và trực tiếp dùng tính năng
  • Với trường hợp rủi ro cao, đọc thêm code và kiểm chứng thêm
  • Dù phát triển nhanh, vẫn dọn dẹp code bẩn ngay khi phát hiện
• Nguyên tắc cốt lõi: nhiệm vụ của lập trình viên là 'bàn giao code mà chính mình đã chứng minh là hoạt động'

Team: AI chuyển dịch điểm nghẽn của review

• Trong môi trường team, AI là trợ thủ rất mạnh cho code review nhưng không thể thay thế phán đoán của con người cần thiết cho chất lượng, bảo mật và khả năng bảo trì
• Trong môi trường có nhiều kỹ sư cộng tác, chi phí của sai sót và vòng đời của code là yếu tố quan trọng hơn nhiều
• Nhiều team dùng bot review AI ở giai đoạn đầu của PR, nhưng phê duyệt cuối cùng vẫn cần con người
• Phát biểu của Greg Foster từ Graphite: “Sẽ không có chuyện AI agent thay thế phê duyệt PR của kỹ sư con người thực sự”
• Vấn đề thực tế lớn nhất không phải là AI reviewer bỏ sót lỗi style, mà là AI làm tăng khối lượng code và chuyển gánh nặng kiểm tra sang con người
  • Cùng với việc mở rộng áp dụng AI, kích thước PR tăng khoảng 18%
  • Số incident trên mỗi PR tăng khoảng 24%
  • Tỷ lệ thay đổi thất bại tăng khoảng 30%
• Khi tốc độ sinh output vượt quá năng lực xác minh, quy trình review trở thành yếu tố giới hạn tốc độ của toàn bộ luồng phát triển
• Foster nói: “Triển khai code mà đồng nghiệp con người không thể đọc hoặc hiểu là một rủi ro lớn”
• Trong môi trường team, do AI tạo ra lượng output lớn, cần áp dụng cách phát triển tăng dần, chia output của agent thành các commit đủ nhỏ để review được
• Phê duyệt cuối cùng của con người không biến mất, mà thay vào đó tiến hóa để tập trung vào những phần AI bỏ sót
  (sự phù hợp với roadmap, ngữ cảnh tổ chức và thể chế mà AI không nắm được)

Bảo mật: những lỗ hổng có thể đoán trước của AI

• Bảo mật là lĩnh vực tuyệt đối cần phán đoán của con người
• Khoảng 45% code do AI tạo ra bị phát hiện có lỗi bảo mật
• Tỷ lệ xảy ra lỗi logic cao hơn 1,75 lần so với code do con người viết
• Tần suất xuất hiện lỗ hổng XSS cao hơn 2,74 lần
• Ngoài vấn đề trong bản thân code, công cụ dạng agent và IDE tích hợp AI còn tạo ra đường tấn công mới
  • Prompt injection, rò rỉ dữ liệu, lỗ hổng RCE
• Khi AI mở rộng bề mặt tấn công, cách tiếp cận hybrid là hiệu quả
  • AI gắn cờ vấn đề, con người xác minh cuối cùng
• Quy tắc: với code xử lý xác thực, thanh toán, secret hoặc input không đáng tin cậy,
  hãy coi AI như một thực tập sinh tốc độ cao và bắt buộc phải có human review theo threat model cùng kiểm tra bằng công cụ bảo mật trước khi merge

Truyền đạt tri thức qua review

• Code review là phương tiện cốt lõi để team chia sẻ ngữ cảnh hệ thống
• Nếu AI viết code nhưng không ai giải thích được thì chi phí on-call sẽ tăng
• Nếu nộp code do AI tạo mà không hiểu đầy đủ, cơ chế truyền đạt tri thức giúp team duy trì khả năng phục hồi sẽ sụp đổ
• Nếu tác giả không thể giải thích vì sao code hoạt động, kỹ sư on-call sẽ không thể debug lúc 2 giờ sáng
• Trường hợp maintainer OCaml từ chối một PR 13.000 dòng do AI tạo
  • Chất lượng code không nhất thiết tệ, nhưng không có đủ băng thông review để xem xét thay đổi ở quy mô đó
  • Review code do AI tạo đòi hỏi gánh nặng nhận thức lớn hơn so với code do con người viết
• Bài học: AI có thể tạo ra lượng code rất lớn, nhưng team phải quản lý quy mô thay đổi để tránh nút thắt review

Cách tận dụng công cụ review AI

• Trải nghiệm người dùng với công cụ review AI rất phân hóa
• Mặt tích cực: trong một số trường hợp, nó bắt được hơn 95% bug như null pointer exception, thiếu coverage test và anti-pattern
• Mặt tiêu cực: một số lập trình viên coi comment review của AI là 'nhiễu văn bản' với những nhận xét chung chung vô giá trị
• Bài học: công cụ review AI cần được cấu hình cẩn thận
  • Điều chỉnh độ nhạy, tắt các loại comment không hữu ích, thiết lập chính sách opt-in/opt-out rõ ràng
• Khi được cấu hình phù hợp, AI reviewer có thể bắt 70–80% các vấn đề dễ, để con người tập trung vào kiến trúc và business logic
• Nhiều team vẫn khuyến khích PR nhỏ và có thể xếp chồng, dù AI có thể tạo ra thay đổi khổng lồ trong một lần
• Nên commit thường xuyên, và quản lý từng thay đổi thành đơn vị tự hoàn chỉnh với thông điệp rõ ràng trong các commit/PR riêng biệt
• Team phải duy trì ranh giới rõ ràng về trách nhiệm của con người
• Bất kể mức độ đóng góp của AI ra sao, trách nhiệm cuối cùng vẫn thuộc về con người
• Châm ngôn đào tạo của IBM: “Máy tính không bao giờ có thể chịu trách nhiệm. Trách nhiệm là phần việc của con người trong vòng lặp”

Hợp đồng PR: nghĩa vụ của tác giả với reviewer

• Dù là solo hay team, thông lệ tốt đang nổi lên là coi code do AI tạo ra như một bản nháp hữu ích cần được xác minh
• Có một framework đơn giản mà những team thành công nhất cùng sử dụng

• Các thành phần của hợp đồng PR

  1/. What/Why: tóm tắt chủ đích và lý do của thay đổi trong 1–2 câu
  2/. Bằng chứng hoạt động: kết quả test pass và các bước xác minh thủ công (ảnh chụp màn hình/log)
  3/. Rủi ro + vai trò của AI: nêu mức độ rủi ro của thay đổi và phần nào do AI tạo ra (ví dụ: chức năng thanh toán là rủi ro cao)
  4/. Trọng tâm review: chỉ ra 1–2 khu vực cần con người kiểm tra (ví dụ: kiến trúc)
• Đây không phải quan liêu, mà là cơ chế để tôn trọng thời gian của reviewer và làm rõ trách nhiệm của tác giả
• Nếu bạn không thể viết ra những điều này, thì nghĩa là bạn chưa hiểu đủ thay đổi của mình để xin người khác phê duyệt

Những nguyên tắc cốt lõi

• Yêu cầu bằng chứng chứ không phải lời hứa: lấy “code hoạt động” làm chuẩn cơ sở, yêu cầu AI agent chạy code hoặc chạy unit test sau khi tạo code, kiểm tra bằng chứng như log/ảnh chụp màn hình/kết quả, và không mở PR nếu không có test mới hoặc demo hoạt động
• Dùng AI như reviewer vòng một, không phải trọng tài cuối cùng: coi output review của AI là tư vấn, để một AI viết code và AI khác kiểm tra, còn con người điều phối hướng chỉnh sửa; dùng AI review ở mức kiểm tra chính tả chứ không phải biên tập viên
• Human review tập trung vào phần AI bỏ sót: như việc có đưa vào lỗ hổng bảo mật hay không, trùng lặp với code hiện có (một lỗi phổ biến của AI), khả năng bảo trì của cách tiếp cận; AI lọc vấn đề dễ còn con người xử lý phán đoán khó
• Thực hiện phát triển tăng dần: chia công việc thành các phần nhỏ để AI dễ tạo và con người dễ review, dùng các commit nhỏ với thông điệp rõ ràng làm checkpoint, và không bao giờ commit code mà bạn không thể giải thích
• Duy trì tiêu chuẩn testing cao: những lập trình viên tận dụng coding agent hiệu quả đều giữ thực hành testing mạnh, yêu cầu AI phác thảo test để tạo ra các edge case test mà con người dễ bỏ sót

Triển vọng tương lai: điểm nghẽn đang dịch chuyển

• AI đang chuyển code review từ gác cổng theo từng dòng sang kiểm soát chất lượng ở mức cao hơn, nhưng phán đoán của con người vẫn là yếu tố an toàn thiết yếu
• Đây là sự tiến hóa của workflow, không phải sự xóa bỏ code review
• Phạm vi của code review không chỉ gồm diff code mà còn có thể bao gồm cuộc hội thoại hoặc kế hoạch giữa AI và tác giả
• Vai trò của reviewer con người ngày càng giống editor hoặc architect hơn, tập trung vào quyết định quan trọng và giao phần kiểm tra thường nhật cho tự động hóa
• Với lập trình viên solo, con đường phía trước rất thú vị, nhưng dù công cụ mới có nhiều đến đâu, người giỏi vẫn sẽ giữ nguyên tắc 'tin nhưng phải kiểm chứng'
• Ở các team quy mô lớn, dự kiến quản trị AI sẽ được tăng cường
  • Chính thức hóa policy về đóng góp của AI và yêu cầu xác nhận đã được nhân viên tự review trực tiếp
  • Xuất hiện các vai trò như 'kiểm toán viên code AI'
  • Các nền tảng enterprise sẽ tiến hóa theo hướng hỗ trợ tốt hơn ngữ cảnh đa repository và thực thi policy tùy chỉnh
• Nguyên tắc cốt lõi không đổi: code review phải bảo đảm phần mềm đáp ứng yêu cầu, an toàn, vững chắc và có thể bảo trì
• AI không thay đổi nền tảng đó, mà chỉ thay đổi cách đạt tới nó
• Điểm nghẽn của phát triển đang chuyển từ viết code sang quá trình chứng minh là nó hoạt động
• Reviewer giỏi trong thời đại AI là người chấp nhận thay đổi này nhưng vẫn giữ nguyên ranh giới trách nhiệm, trong khi cho phép AI tăng tốc phần việc cơ học
• AI có thể tăng tốc (accelerate) quy trình, nhưng không được phép khiến con người thoái thác trách nhiệm (abdicate)
• Các kỹ sư sẽ ngày càng coi trọng 'bằng chứng hơn cảm giác (proof over vibes)'
• Code review không biến mất, mà đang chuyển sang một vai trò mang tính chiến lược hơn
• Dù là lập trình viên solo triển khai lúc 2 giờ sáng hay team lead phê duyệt thay đổi quan trọng của hệ thống, sự thật chung vẫn là trách nhiệm cuối cùng với kết quả do AI tạo ra thuộc về con người
• Hãy đón nhận AI, nhưng vẫn giữ thói quen kiểm tra lại công việc

[tested]

https://www.coderabbit.ai/
Có ai đã dùng CodeRabbit chưa? Giá khá đắt nên tôi không biết nó có đáng tiền đến vậy không.

[developerjhp]

Nếu bạn dùng tiện ích mở rộng Chrome bên dưới thì có thể tiện lợi nhận review từ GPT dựa trên GitHub PR Diff~!
https://github.com/developerjhp/Diffinity