Công cụ AI Coding

AI code review tự động: bắt bug trước khi merge (2026)

Aug 14, 202613 phút đọc

AI code review là dùng mô hình ngôn ngữ đọc diff của bạn, phát hiện bug, lỗ hổng và anti-pattern rồi để lại comment theo từng dòng như một reviewer người. Để bắt bug trước khi merge, làm 3 bước: (1) review diff cục bộ bằng lệnh /review trong Claude Code, (2) đọc finding và sửa nhanh bằng /fix, (3) chặn merge nếu vẫn còn finding nghiêm trọng - chạy tay trước PR hoặc đưa vào CI. AI lọc phần lớn lỗi cơ học để bạn dồn sức cho logic và kiến trúc.

Jasmine, dev dùng /review của Claude Code hằng ngày trong quy trình PR.

AI code review là gì?

AI code review là quy trình dùng một mô hình ngôn ngữ lớn (LLM) đọc phần code thay đổi - thường là diff giữa nhánh của bạn và nhánh gốc - để phát hiện bug, lỗ hổng bảo mật và anti-pattern, rồi để lại nhận xét theo từng dòng giống như một reviewer người. Điểm khác biệt so với review code bằng AI kiểu hỏi-đáp là ở chỗ tự động hoá: bạn không dán từng đoạn vào chat, mà công cụ tự gom diff, tự chấm mức độ nghiêm trọng và trả về danh sách finding có ngữ cảnh.

Khác với con người, AI không mệt ở PR thứ mười trong ngày, không bỏ sót vì "nhìn quen mắt", và đọc được cả những file bạn ngại mở. Nó đặc biệt mạnh ở lớp lỗi lặp đi lặp lại: quên kiểm tra null, sai điều kiện biên, để lộ secret, xử lý lỗi hời hợt. Ngược lại, nó vẫn cần bạn cung cấp ngữ cảnh (coding standard, ý định của thay đổi) thì mới đánh giá đúng - đây là lý do phần cấu hình phía dưới quan trọng.

Trong bài này mình tập trung vào cách làm thực chiến với Claude Code, vì đó là công cụ mình dùng hằng ngày. Nhưng nguyên tắc - review trên diff, chấm theo severity, chặn merge khi cần - áp dụng cho hầu hết công cụ AI review hiện nay.

AI code review khác gì linter/SonarQube?

Nhiều người nghĩ "đã có ESLint/SonarQube rồi thì cần gì AI". Thực ra hai lớp này bắt hai loại lỗi khác nhau và bổ sung cho nhau, không thay thế. Linter và static analysis chạy theo luật cố định: chúng bắt lỗi cú pháp, style, biến không dùng, kiểu dữ liệu - những thứ mô tả được bằng rule. AI review đọc *ý định* của code, nên bắt được lỗi đúng cú pháp nhưng sai logic mà không rule nào phát hiện nổi.

Tiêu chíLinter / SonarQube (static analysis)AI code review
Cơ chếRule cố định, phân tích cú phápLLM hiểu ngữ nghĩa và ý định code
Bắt tốtSyntax, style, code smell, biến thừaSai logic, off-by-one, thiếu null check, hardcode secret
Điểm yếuKhông hiểu ý định; bỏ qua lỗi logic đúng cú phápCó false positive; phụ thuộc ngữ cảnh bạn cấp
Tốc độRất nhanh, xác địnhChậm hơn, cần diff + context
Vai tròCổng chất lượng cơ bảnLớp review sâu về logic và bảo mật

Cấu hình lý tưởng cho một team là chạy cả hai: linter làm cổng nhanh ở mọi commit, AI review làm lớp sâu trên diff của PR. So sánh này (static analysis vs AI review) không phải để chọn một - mà để biết mỗi công cụ chịu trách nhiệm phần nào.

Vì sao nên review TRƯỚC khi merge?

Nguyên tắc kinh điển của kỹ thuật phần mềm: chi phí sửa một bug tăng mạnh theo từng giai đoạn nó lọt qua. Một lỗi bắt được ngay trên diff, khi bạn vẫn còn nhớ rõ mình vừa viết gì, chỉ mất vài phút. Cũng lỗi đó lọt vào nhánh chính rồi mới phát hiện, bạn phải mở lại ngữ cảnh, dò lại lịch sử commit, viết hotfix, có khi kéo theo rollback. Nếu nó ra tới production, thêm chi phí sự cố, dữ liệu hỏng và niềm tin của người dùng.

Đó là lý do đặt AI review ở cổng trước merge có lợi kép: bắt sớm khi sửa còn rẻ, và giữ nhánh chính luôn sạch. Cách đặt kỳ vọng hợp lý: AI lo phần lớn lỗi cơ học - khoảng 80-90% các finding lặp lại kiểu null check, boundary, error handling - để reviewer người dồn sức vào cái AI làm dở: logic nghiệp vụ, quyết định kiến trúc, đánh đổi thiết kế.

Nói cách khác, review trước merge không phải để thay con người, mà để con người không còn phải soi những lỗi máy soi tốt hơn. Anthropic cũng đưa code review tự động thành một hướng chính của Claude Code từ đầu 2026 (Claude Code docs, truy cập 08/2026), đúng với xu hướng dịch review về sớm trong vòng đời code.

Cách bật AI code review tự động (3 bước)

Đây là quy trình mình chạy mỗi ngày. Ba bước, làm từ máy cá nhân trước khi mở PR, rồi mới nghĩ tới CI.

Bước 1 - Review diff cục bộ trước khi tạo PR

Trong Claude Code, sau khi code xong một feature, gõ lệnh review trước khi commit hay mở PR:

# Review toàn bộ thay đổi so với nhánh gốc
/review

# Hoặc chỉ định nhánh base để gom diff cho đúng
/review main

Lệnh /review gom diff giữa nhánh hiện tại và nhánh base, đọc từng file thay đổi rồi trả về danh sách finding kèm mức độ nghiêm trọng (critical / high / medium / low) và vị trí dòng cụ thể. Vì nó chỉ đọc diff chứ không quét cả repo, kết quả tập trung và ít nhiễu hơn nhiều.

Bước 2 - Đọc finding và sửa nhanh

Đọc từ finding severity cao xuống thấp. Với lỗi rõ ràng, dùng lệnh fix để AI đề xuất bản vá ngay tại chỗ, rồi bạn review lại thay đổi đó:

# Áp bản vá cho finding cụ thể
/fix

# Sau khi sửa, review lại phần thay đổi mới (incremental)
/review

Mẹo quan trọng: đừng "apply all" mù quáng. Với mỗi bản vá /fix đề xuất, đọc kỹ diff - AI có thể sửa đúng triệu chứng nhưng lệch ý định của bạn. Sửa xong thì chạy lại /review theo kiểu incremental để chắc bản vá không đẻ ra finding mới. Nếu bạn muốn đi sâu hơn khi AI báo lỗi mà bạn không chắc nguyên nhân, xem thêm cách debug với AI khi review báo lỗi.

Bước 3 - Chặn merge nếu còn finding nghiêm trọng

Đây là phần biến review thành một cái cổng thật sự. Quy tắc đơn giản: chỉ merge khi 0 finding severity cao. Ở mức cá nhân, đó là kỷ luật của bạn trước khi bấm merge. Ở mức team, đưa nó vào CI để tự động chặn:

# Ví dụ bước trong GitHub Actions cho mỗi pull request
- name: AI code review
 run: ak review --base=origin/main --fail-on=high

Ý tưởng: chạy review trên diff của PR, nếu có finding từ mức high trở lên thì job fail và branch protection không cho merge. Bạn tinh chỉnh ngưỡng --fail-on cho hợp team - thường bắt đầu ở critical để tránh chặn oan, rồi siết dần khi tin tưởng hơn. Kết hợp cùng git workflow với Claude Code để cả vòng commit → review → merge diễn ra mượt.

Ví dụ finding thật AI bắt được

Lý thuyết là vậy, còn đây là loại bug AI review bắt tốt mà linter thường bỏ qua - vì tất cả đều đúng cú pháp. Mỗi ví dụ kèm code và comment reviewer.

1. Off-by-one / lỗi biên. Vòng lặp chạy quá một phần tử, đọc ngoài mảng.

// Trước - bỏ sót phần tử cuối? Không, chạy LỐ 1 phần tử
for (let i = 0; i <= items.length; i++) {
 process(items[i]); // items[items.length] === undefined
}

// Sau
for (let i = 0; i < items.length; i++) {
 process(items[i]);
}

Reviewer: "Điều kiện <= khiến vòng lặp truy cập items[items.length] (undefined). Dùng <."

2. Thiếu null / undefined check. Truy cập thuộc tính trên giá trị có thể rỗng.

// Trước
const city = user.address.city; // vỡ nếu address null

// Sau
const city = user.address?.city ?? "N/A";

Reviewer: "user.address có thể là null với tài khoản chưa nhập địa chỉ - dùng optional chaining."

3. Hardcode secret / credential. Lỗi đúng cú pháp nhưng nguy hiểm về bảo mật.

// Trước
const apiKey = "sk_live_9f8a7b6c5d4e3f2a1b0c";

// Sau
const apiKey = process.env.STRIPE_API_KEY;

Reviewer: "Secret bị hardcode và sẽ lọt vào lịch sử git. Chuyển sang biến môi trường và rotate key này." Đây cũng là lúc nên chạy sâu hơn một lượt security audit code bằng Claude Code.

4. N+1 query. Đúng cú pháp, chạy được, nhưng gọi DB trong vòng lặp.

// Trước - 1 query lấy list + N query trong loop
const orders = await Order.findAll();
for (const o of orders) {
 o.user = await User.findById(o.userId); // N truy vấn
}

// Sau - eager load 1 lần
const orders = await Order.findAll({ include: [User] });

Reviewer: "Vòng lặp tạo N truy vấn phụ; dùng eager loading để gộp còn một truy vấn." Không rule linter nào bắt được lỗi này, nhưng nó là thủ phạm chậm phổ biến nhất mình từng thấy trong review.

Review chạy thế nào bên trong (nhiều lens song song)

Vì sao AI review chất lượng lại bắt được nhiều loại lỗi khác nhau trong một lần chạy? Bí quyết là chia theo lens (góc soi) và chạy song song. Thay vì một prompt chung chung "review giúp mình", công cụ tốt tách thành nhiều reviewer chuyên biệt, mỗi cái soi một khía cạnh:

  • Logic - điều kiện biên, off-by-one, nhánh xử lý thiếu.
  • Security - hardcode secret, injection, kiểm soát truy cập.
  • Performance - N+1 query, vòng lặp tốn kém, thiếu cache.
  • Error handling - nuốt exception, thiếu retry, promise chưa await.
  • Test coverage - nhánh mới chưa có test tương ứng.

Mỗi lens chạy như một subagent riêng, đồng thời, nên tổng thời gian không cộng dồn. Sau đó kết quả được dedupe (gộp finding trùng mà nhiều lens cùng chỉ ra) và xếp theo severity để bạn thấy cái nghiêm trọng nhất trước. Cơ chế parallel review agent này là lý do một lượt review có thể vừa bắt lỗi logic vừa cảnh báo bảo mật mà không phải chạy nhiều lần. Muốn hiểu kỹ cách nhiều agent chạy đồng thời, xem subagents chạy song song trong Claude Code.

Giảm false positive và khi AI review "lệch nhịp"

AI review không hoàn hảo. Thêm một công cụ AI cấu hình sai đôi khi còn khiến review tệ hơn - ngập trong cảnh báo độ tin thấp đến mức team bắt đầu bỏ qua tất cả. Đây là những cách mình dùng để giữ tín hiệu cao, nhiễu thấp:

  • Chỉ review diff, không review cả repo. Quét toàn bộ codebase sinh ra hàng loạt cảnh báo về code cũ mà PR này không đụng tới. Gói phạm vi vào diff giúp finding sát và ít oan.
  • Đặt severity gate. Chỉ chặn merge ở mức high/critical; các gợi ý style để dạng khuyến nghị. Đừng để một nit làm đỏ cả pipeline.
  • Cấp ngữ cảnh và coding standard. Cho AI biết convention của team (qua file hướng dẫn của dự án) để nó không "phát minh" quy tắc riêng và báo nhầm.
  • Bỏ qua comment độ tin thấp. Công cụ tốt có gắn mức tin cậy; lọc phần thấp để chỉ còn cái đáng đọc.

Và đây là phần trung thực bắt buộc phải nói: AI review KHÔNG thay human approve. Nó không hiểu ràng buộc nghiệp vụ ("khách VIP được miễn phí ship"), không đánh giá được quyết định kiến trúc lớn, và không chịu trách nhiệm cuối cùng. Hãy coi nó là lớp lọc đầu tiên giúp buổi review của con người ngắn và tập trung hơn - chứ không phải con dấu duyệt. Một AI review lệch nhịp thường là do thiếu ngữ cảnh, không phải do "AI kém".

Tăng tốc code review bằng AgentKit

Claude Code đã có /review/fix ngay trong hộp, đủ dùng cho cá nhân. Khi cần review sâu và chuẩn hơn cho cả team, bộ kit AgentKit cho Claude Code đóng gói sẵn skill code-review cùng các agent kỹ thuật chuyên trách - trong đó có agent review nằm trong nhóm 17 Engineer agent - để chạy đúng mô hình nhiều lens song song mô tả ở trên mà không phải tự cấu hình từ đầu. Nếu quan tâm mảng review, Engineer Kit có agent review chuyên sâu đáng xem trước.

Nói rõ để tránh nhầm: AgentKit ở đây là bộ kit cho Claude Code (agentkit.best, CLI ak), KHÁC OpenAI AgentKit (Agent Builder / ChatKit). Engineer Kit có giá 99$ (trang không nêu phí định kỳ), kèm cập nhật trọn đời và money-back guarantee.

Muốn review sâu hơn cho cả team? AgentKit gói sẵn skill code-review và agent chuyên review cho Claude Code, chạy nhiều lens song song. Xem giá AgentKit (giảm 20% qua link) →

Câu hỏi thường gặp (FAQ)

AI code review có thay thế reviewer người không?

Không. AI lọc phần lớn lỗi cơ học (null, boundary, secret, N+1) để rút ngắn buổi review, nhưng con người vẫn phải duyệt cuối cùng vì AI không hiểu ràng buộc nghiệp vụ và quyết định kiến trúc. Hãy coi nó là lớp lọc đầu tiên, không phải con dấu approve.

AI code review có bắt được lỗi logic không?

Có, đây chính là thế mạnh của nó so với linter. Vì đọc ngữ nghĩa và ý định code, AI bắt được lỗi đúng cú pháp nhưng sai logic như off-by-one, điều kiện biên sai, hay xử lý lỗi hời hợt - những thứ static analysis bỏ qua. Với logic nghiệp vụ phức tạp thì vẫn cần người xác nhận.

Có chạy AI code review trong CI/CD được không?

Được. Bạn chạy lệnh review trên diff của pull request trong CI (ví dụ GitHub Actions) và cho job fail nếu có finding từ mức high trở lên. Kết hợp branch protection để chặn merge tự động khi còn lỗi nghiêm trọng.

Code của tôi có bị gửi lên cloud không?

Có, vì mô hình chạy trên hạ tầng nhà cung cấp nên diff cần gửi đi để phân tích - giống như khi bạn dùng Claude Code bình thường. Với code nhạy cảm, hãy kiểm tra chính sách xử lý dữ liệu của nhà cung cấp, giới hạn phạm vi review vào diff, và tránh để secret trong code (đó cũng là một loại finding AI sẽ cảnh báo).

AI code review có miễn phí không?

Tuỳ công cụ. Với Claude Code, /review/fix nằm trong gói bạn đang dùng (Pro 20$/tháng, Max 5x 100$/tháng...) chứ không tính phí riêng theo lượt review. Các nền tảng khác có thể tính theo credit hoặc theo user.

AI code review khác linter thế nào?

Linter chạy theo rule cố định, bắt lỗi cú pháp và style rất nhanh nhưng không hiểu ý định code. AI review hiểu ngữ nghĩa nên bắt được lỗi logic đúng cú pháp. Tốt nhất là dùng cả hai: linter làm cổng nhanh, AI review làm lớp sâu trên diff.

Kết luận + bước tiếp theo

Tóm lại, để bắt bug trước khi merge: chạy /review trên diff cục bộ, dùng /fix xử lý finding severity cao, và chỉ merge khi cổng review sạch - đưa vào CI khi làm team. Nhớ ba nguyên tắc giữ tín hiệu sạch: review trên diff, đặt severity gate, cấp đủ ngữ cảnh; và đừng quên AI không thay con người approve. Nếu muốn nâng cấp lớp review cho team mà không cấu hình từ đầu, bộ kit AgentKit cho Claude Code (giảm 20% qua link) là bước hợp lý. Đọc tiếp: debug với AI, security audit code bằng Claude Code, và quy trình AI dev từ brainstorm tới ship.

J

Jasmine

Tác giả · Jasmine Daily

Người viết nên Jasmine Daily - ghi lại những suy nghĩ, trải nghiệm và những khoảnh khắc đời thường. Thật lòng, không vội vàng, không hoàn hảo.

Jasmine Daily

Vẫn còn nhiều điều đang chờ được đọc.

Nếu bài viết này chạm đến bạn, hãy ghé xem thêm vài trang khác trong cuốn nhật ký này.

Đọc tiếp

Bài viết liên quan