AI code review: checklist MONA dùng để duyệt code do AI viết

AI code review là bước dùng máy rà code vòng đầu, rồi để dev senior kiểm nghiệp vụ, bảo mật và khả năng vận hành trước khi đưa lên máy chủ. Code AI viết thường sạch mắt, đặt tên đều và chạy qua ca thử đẹp; lỗi của nó nằm ở chỗ sâu hơn, như gọi một hàm không tồn tại hoặc mở quyền quá rộng. Tại MONA, quy trình đã đi qua hơn 14.000 dự án và giữ 2 lần duyệt cho code AI. Người giữ cửa cuối.

Code AI chạy được vẫn còn 8 chỗ senior phải soi

Màn hình hiện đúng, nút bấm phản hồi, kiểm thử mẫu chuyển sang màu xanh. Cảnh này rất dễ làm người viết yên tâm sớm. AI giỏi tạo một đáp án trông hoàn chỉnh, kể cả lúc nó hiểu sai quy tắc giảm giá hoặc bỏ qua người dùng không có quyền. Chạy được chưa đủ.

Tụi em tách bước duyệt thành 2 cửa. Cửa đầu dùng AI và công cụ tự động để bắt lỗi lặp; cửa cuối do dev senior chịu trách nhiệm với 8 điểm: nghiệp vụ, hàm và thư viện, trường hợp rỗng, đầu vào, quyền, hiệu năng, log, chuẩn code dự án. Cách này bám nguyên tắc của mô hình phát triển phần mềm AI-Native: người ra đề, kiểm soát, chịu trách nhiệm; AI làm tay chân.

Mỗi thay đổi đi qua 8 lượt kiểm trong checklist và 2 lượt duyệt tách vai trước khi qua cửa máy chủ.

Một đội đang dùng vibe coding cho bản thử nhỏ vẫn hưởng lợi từ checklist này. Hãy rà 8 điểm trước mỗi lần ghép code, đừng đợi đến cuối tuần mới đọc một khối thay đổi quá lớn.

4 kiểu sai của AI mà nhìn qua vẫn thấy code rất sạch

Người viết code vội thường để lại dấu dễ thấy: tên biến lộn xộn, đoạn chép dở, nhánh xử lý thiếu. AI lại sai theo 4 kiểu khác. Nó viết trơn tru quanh một giả định sai, bịa ra API nghe rất hợp lý, bỏ qua dữ liệu rỗng, hoặc lặp một thao tác tốn tài nguyên bên trong vòng lặp. Sạch mắt vẫn sai.

Spec-Driven Development cho người duyệt đáp án để bắt kiểu sai đầu tiên. Khóa phiên bản thư viện và chạy kiểm thử giúp bắt 3 kiểu còn lại. Thiếu spec, người đọc code chỉ còn tranh luận bằng cảm giác.

Đội đọc code qua 4 lượt đối chiếu theo 4 kiểu sai, rồi chạy thêm 2 lần với dữ liệu và quyền khác để xem lỗi có đổi mặt hay không.

Nhìn tận tay: checklist 8 điểm mở ra là soát được

Đây là bản rút gọn tụi em dùng khi review code AI viết. Anh chị đưa nguyên khối cho đội dev, đánh dấu từng dòng và ghi link tới bằng chứng kiểm thử bên cạnh. Đủ 8 dấu kiểm rồi mới qua cửa kế tiếp. Đừng duyệt bằng mắt.

1. Đúng nghiệp vụ: đầu vào, đầu ra và quy tắc có khớp bản spec viết cho AI?
2. Hàm và thư viện có thật: tên gói, API, tham số có nằm trong phiên bản dự án đang dùng?
3. Trường hợp rỗng và lỗi: dữ liệu thiếu, trùng, sai định dạng hoặc dịch vụ ngoài ngừng phản hồi được xử lý ra sao?
4. An toàn đầu vào: dữ liệu người dùng có được kiểm kiểu, giới hạn độ dài và tách khỏi câu lệnh?
5. Đúng quyền: người đang đăng nhập chỉ đọc và sửa phần họ được phép?
6. Hiệu năng: có truy vấn, gọi mạng hoặc đọc file lặp vô ích bên trong vòng lặp?
7. Log vận hành: khi lỗi xảy ra, log có mã sự kiện, thời điểm và ngữ cảnh đủ để tìm nguyên nhân?
8. Khớp chuẩn dự án: tên, cấu trúc thư mục, cách báo lỗi và cách viết kiểm thử có đồng bộ với code đang sống?

Checklist 8 điểm không thay cho việc chạy code. Nó buộc người duyệt nhìn đúng 8 hướng trước khi bấm đồng ý, rồi ca thử xác nhận phán đoán đó. Với phần liên quan dữ liệu và quyền, tụi em mở thêm checklist bảo mật code AI thay vì nhét hết vào một dòng.

Senior phải đi qua 8 lần kiểm có bằng chứng và ít nhất 2 lần chạy bằng tài khoản khác quyền, vì một màn hình xanh chưa nói được code sẽ phản ứng ra sao khi dữ liệu hoặc người dùng thay đổi.

Cho AI soi vòng đầu, để người chốt lỗi nghiệp vụ

AI rất hợp với vòng rà đầu vì nó đọc nhanh các mẫu lặp, đối chiếu chuẩn đặt tên và đề xuất ca thử còn thiếu. Đưa cho nó 1 đoạn thay đổi cùng spec liên quan, yêu cầu trả về 3 phần: lỗi chắc chắn, chỗ cần người xác nhận, ca thử cần chạy. Máy làm vòng đầu.

Người giữ vòng cuối vì 2 thứ AI không sở hữu: bối cảnh kinh doanh đã thống nhất với anh chị và trách nhiệm khi hệ thống hỏng. Một quy tắc “khách hạng vàng được giảm thêm” nghe đơn giản, nhưng người duyệt phải biết hạng vàng lấy từ đâu, thời điểm nào khóa hạng, hoàn đơn có trả lại quyền lợi hay không. Spec và cuộc trao đổi thật nằm ở tay người.

Máy giữ 1 lượt rà lỗi lặp trên mỗi thay đổi, người giữ 1 lượt chốt nghiệp vụ và quyền trước khi ký.

MONA cho code AI đi qua 2 cửa như thế nào

Cửa 1 chạy tự động ngay khi code thay đổi: định dạng, phân tích tĩnh, kiểm thử và AI rà theo spec. Kết quả đỏ quay về người viết, chưa tới senior. Cửa 2 bắt đầu khi vòng máy đã xanh; dev senior đọc phần thay đổi, chạy ca nghiệp vụ và chốt quyền đưa lên máy chủ. Đúng 2 cửa.

Mọi code AI viết ở MONA đi qua cả 2 cửa trước khi lên máy chủ. Tụi em dùng máy để bớt thời gian đọc lỗi lặp, rồi dành đầu óc người cho chỗ khó: tiền, quyền, dữ liệu, kiến trúc. Cách chia này chạy trong AI-DLC, nơi AI tham gia nhiều khâu nhưng quyền quyết vẫn ở dev senior.

Tụi em giữ kết quả của cả 2 cửa cạnh yêu cầu thay đổi, để lần sửa sau biết điểm nào đã được kiểm và ai đã chốt.

Từ 2016 qua hơn 14.000 dự án, tụi em không xem code là món giao xong rồi thôi. 85% khách tiếp tục đồng hành khiến log, khả năng sửa và chuẩn code trở thành phần bắt buộc của lần duyệt đầu; 1 tính năng chạy hôm nay mà không ai tìm được lỗi tháng sau vẫn là một lần duyệt kém.

Chạy 4 bài thử quanh chỗ code vừa đổi

Đọc khác với chạy. Sau checklist 8 điểm, dev senior chạy ít nhất 4 lần quanh đúng phần vừa sửa: ca đúng, dữ liệu rỗng, dữ liệu sai, người không đủ quyền. Nếu code gọi dịch vụ ngoài, thay 1 lần bằng tình huống hết thời gian chờ. Phải làm nó hỏng.

1. Ca đúng: dữ liệu hợp lệ, quyền đúng, kết quả khớp spec.
2. Ca rỗng: bỏ trường bắt buộc, hệ thống giữ dữ liệu và báo đúng chỗ.
3. Ca sai: gửi định dạng hoặc giá trị ngoài miền cho phép.
4. Ca quyền: dùng tài khoản không được phép đọc hoặc sửa tài nguyên.

Khối 4 bài thử này dùng được cho chức năng website, chatbot AI lẫn phần mềm quản trị. Với chatbot, “ca sai” còn gồm câu hỏi nằm ngoài kho kiến thức; với chức năng thanh toán, “ca quyền” phải soi cả người dùng và dịch vụ gọi phía sau. Tụi em khuyên đừng lấy 1 ca thành công làm bằng chứng bàn giao.

Code chạy thật mới lộ 3 chỗ: log, quyền và hiệu năng

Code AI thường tối ưu cho đề bài trước mắt. Khi thiếu yêu cầu vận hành, nó vẫn trả kết quả nhưng không ghi log đủ, dùng một tài khoản dịch vụ có quyền quá lớn, hoặc đặt truy vấn trong vòng lặp. Dữ liệu thử nhỏ không làm 3 lỗi này lộ ra. Vận hành mới lộ.

Tụi em rà log bằng 3 câu: lỗi nào đã xảy ra, xảy ra lúc nào, gắn với yêu cầu nào. Rà quyền bằng 2 chiều: người này được làm gì và tài nguyên này cho ai đụng. Rà hiệu năng bằng cách tìm mọi thao tác I/O, tức gọi mạng, đọc file hoặc truy vấn dữ liệu, rồi kiểm xem nó có lặp theo từng bản ghi hay không.

Đội rà log qua 3 lượt ứng với ca đúng, sai và hết quyền, rồi giữ 2 lượt đo cho đoạn có gọi mạng hoặc truy vấn lặp.

Phần mềm cần sống sau bàn giao nên bước này nối thẳng sang dịch vụ quản trị website và vận hành hệ thống. Đội chỉ làm bản demo 2 ngày có quyền lược bớt log; hệ thống kinh doanh chạy mỗi ngày thì đừng tiết kiệm ở đúng 3 chỗ này.

AI có soi thêm 1 vòng, đội vẫn phải giữ đủ 4 trụ

AI code review không đứng riêng. SDD cung cấp spec để biết code đúng hay sai; AI-DLC đưa máy vào vòng soát; Kanban giữ mỗi thay đổi đủ nhỏ để đọc; Agentic SDLC cho agent tự chạy nhiều bước nhưng vẫn dừng ở cửa người duyệt. Đó là 4 trụ, cùng 1 nguyên tắc. Người chịu trách nhiệm.

Trong mô hình phát triển phần mềm AI-Native, tụi em không đợi cuối dự án mới gom code ra xem. Mỗi thẻ Kanban đi qua bước người kiểm trước khi bàn giao; việc xong được duyệt ngay, không nằm chờ hết một đợt 2 tuần. Anh chị có đội dev đang bị nghẽn ở khâu duyệt thì đọc thêm so sánh Kanban và Scrum.

Bản whitepaper 14 trang phát hành ngày 19/08/2026 mô tả trọn 4 trụ và 2 cửa. Tụi em dựng chính tài liệu đó trong 1 buổi chiều bằng AI, người vẫn bắt 3 lỗi bố cục trước khi phát hành. Quy trình tự chứng minh trên sản phẩm của MONA trước khi đem áp cho khách.

Tụi em giữ cùng cách chia việc đó khi code: máy làm nhanh phần lặp, người ký phần ảnh hưởng tới khách và máy chủ.

Câu hỏi thường gặp về AI code review

AI code review có tự soi code do chính nó viết được không?

Được ở vòng đầu. Hãy đưa spec, đoạn thay đổi và chuẩn dự án để AI rà lỗi lặp, rồi dev senior giữ cửa cuối. Tại MONA, quy trình luôn có 2 cửa và checklist 8 điểm.

Code đã có kiểm thử tự động còn cần người đọc không?

Cần, vì kiểm thử chỉ chứng minh những ca đã được viết. Người đọc tìm giả định sai, quyền quá rộng và ca nghiệp vụ còn thiếu. Chạy thêm 4 hướng thử quanh chỗ vừa đổi giúp lộ phần đó.

Review code AI viết nên bắt đầu từ đâu?

Bắt đầu từ spec, rồi đi đúng 8 dòng của checklist. Nếu chưa có spec, dừng và viết lại đầu vào, đầu ra, luồng lỗi cùng cách nghiệm thu; đọc code trước lúc biết đáp án sẽ tốn nhiều vòng.

Đội nhỏ có cần quy trình 2 cửa không?

Có, nhưng 1 người được phép đổi vai giữa 2 lượt. Lượt đầu dùng máy và checklist; lượt sau rời màn hình một nhịp rồi đọc như người chịu vận hành. Hệ thống chạm tiền hoặc dữ liệu nhạy cảm cần 2 người tách biệt.

Giữ checklist 8 điểm và đừng bỏ cửa người duyệt

Một lần bàn giao chỉ được chấp nhận khi 8 lượt kiểm có bằng chứng, 4 lần chạy thử đã đi qua dữ liệu xấu và 2 lần duyệt còn giữ được người chịu trách nhiệm ở cửa cuối. Thiếu là quay lại.

AI code review giúp dev senior bớt đọc lỗi lặp, chứ không chuyển trách nhiệm sang máy. Gắn checklist 8 điểm vào mỗi yêu cầu ghép code, chạy 4 bài thử quanh phần vừa đổi và giữ 2 cửa trước máy chủ. Làm đều 3 việc đó, code AI viết mới đi từ “trông sạch” sang “có bằng chứng để tin”. Người vẫn chốt.

Tụi em áp cách này cho dự án phần mềm theo yêu cầu và các luồng AI agent viết riêng. Anh chị muốn rà một thay đổi đang chuẩn bị lên máy chủ, gọi 1900 636 648 và gửi kèm spec. Tụi em sẽ trả đúng 8 mục đạt hoặc thiếu, không duyệt bằng câu “nhìn ổn rồi”.