Review code thời AI agent: mô hình cây Trunk–Leaf, Blast Radius và Agentic Validation

Khi AI agent sinh code với tốc độ bùng nổ, việc đọc kỹ từng dòng code theo cách truyền thống trở nên bất khả thi. Bài tổng hợp của Lữ Minh Khương, dựa trên chia sẻ thực chiến của John Kim — Senior Staff Software Engineer tại Meta — đề xuất chiến lược review theo gradient: mức độ review phụ thuộc vào độ an toàn và phạm vi ảnh hưởng (Blast Radius) của đoạn code.

Trả lời nhanh: Khối lượng code do AI agent sinh ra khiến việc đọc từng dòng trở nên bất khả thi; thay vào đó cần review theo gradient dựa trên Blast Radius. Codebase được phân loại theo mô hình cây: Trunk Code (lõi, hạ tầng, shared state) phải review sâu, Leaf Code (component cô lập, endpoint mới sau Feature Gate) chỉ cần đọc lướt kèm bằng chứng. Agent viết code phải đính kèm bằng chứng xác thực trong mỗi PR: test, runtime log, visual proof và mức độ tự tin. Agent review phải là agent mới với ngữ cảnh mới, không dùng chính agent vừa viết code để tự review. Merge-ready mới đạt 80% quãng đường; 20% cuối cùng là audit toàn bộ tính năng và mở cổng dần bằng Canary Deployment.

Review theo gradient (gradient review) là chiến lược kiểm duyệt code do AI sinh ra theo mức độ ưu tiên: thay vì đọc kỹ mọi dòng như nhau, người review tập trung sâu vào những phần có phạm vi ảnh hưởng lớn và rủi ro cao, đồng thời đọc lướt những phần cô lập, đã được bọc trong feature gate và có đầy đủ bằng chứng xác thực.

Hai thái cực về review code trong kỷ nguyên AI

Khi nói về code review trong kỷ nguyên AI, cộng đồng kỹ thuật chia thành hai thái cực rõ rệt. Một bên cho rằng nếu vẫn ngồi đọc từng dòng code do AI viết thì đang đi quá chậm, vì bản thân các AI agent hiện tại đã bắt lỗi tốt hơn con người. Bên còn lại cực kỳ cảnh giác vì tình trạng AI slop — code rác do AI sinh ra từ việc vibe coding vô tội vạ — dẫn đến những lỗi ngớ ngẩn và nợ kỹ thuật chồng chất trên production.

Cách tiếp cận của John Kim không đứng hẳn về phe nào: mức độ review phụ thuộc hoàn toàn vào độ an toàn và phạm vi ảnh hưởng của đoạn code đó. Bài viết này tổng hợp các đúc kết từ chia sẻ của ông, kết hợp một vài góc nhìn thực chiến của tác giả bài tổng hợp.

Mô hình cây: Trunk Code và Leaf Code khác nhau thế nào?

Khi một kỹ sư có thể bật cùng lúc nhiều AI agent để viết tính năng, lượng pull request (PR) đổ về mỗi ngày là khổng lồ. Nếu giữ thói quen đọc kỹ từng dòng như nhau cho mọi file, người review sẽ trở thành nút thắt cổ chai của chính mình. Giải pháp là nhìn codebase như một cấu trúc cây:

	Trunk Code (thân và rễ)	Leaf Code (nhánh lá)
Ví dụ	Main entry point, hạ tầng, networking, image processing, shared state lớn (Reducer, core service)	UI component đơn lẻ, API endpoint mới chưa đấu nối vào luồng chính
Rủi ro	One-way door, nhiều downstream dependency; sai một ly có thể sập toàn bộ ứng dụng	Cô lập, ảnh hưởng hẹp
Cách review	Đọc kỹ từng dòng, phân tích side effect, kiểm duyệt kiến trúc chặt	Đọc lướt, miễn là có đủ bằng chứng và bọc sau Feature Gate

Vì sao phải thiết kế Feature Gating ngay từ bước Planning?

Để dám đọc lướt Leaf Code mà vẫn yên tâm, nguyên tắc sống còn là áp dụng Feature Gating (Feature Toggling qua LaunchDarkly hay đơn giản là một boolean flag trong cấu hình) ngay từ lúc lên kế hoạch. Khi tách bạch rõ phần code mới nằm sau feature flag và phần integration layer chạm vào hệ thống cũ, câu hỏi quan trọng nhất khi review trở thành: nếu đoạn code này chạy sai trên production, trải nghiệm hiện tại có bị ảnh hưởng không, và có thể rollback ngay bằng cách tắt flag không? Nếu câu trả lời là có, áp lực review từng dòng giảm đi đáng kể.

Agentic Validation: ép AI đưa ra bằng chứng trong mỗi PR

Thay vì tự kéo branch về chạy thử từng trường hợp, hãy cấu hình skill để buộc AI agent tự kiểm chứng và đính kèm bằng chứng ngay trong PR:

• Unit test và integration test: nhìn nhanh tên hàm test và các lệnh assert giúp nắm logic rất nhanh. Cần rèn cho agent một skill riêng để tránh việc AI viết ra hàng tá useless test — test chỉ để lấy coverage chứ không kiểm tra đúng logic nghiệp vụ.
• Runtime evidence: cho agent khả năng đọc runtime log để tự chạy, tự đọc log lỗi và tự sửa trước khi báo cáo.
• Visual proof: với thay đổi giao diện, bắt buộc agent chụp UI screenshot hoặc quay video màn hình chứng minh tính năng đã hoạt động.
• Confidence level: yêu cầu agent tự đánh giá mức độ tự tin với code vừa viết và mức độ an toàn của các feature gate.

Một điểm thực tế: hãy tạo sẵn một PR template gọn gàng cho agent. Nếu không có khuôn mẫu, AI rất hay viết phần mô tả PR và test plan dài như tiểu thuyết — đôi khi phần chữ còn dài hơn cả code diff.

Vì sao phải khai tử văn hóa bắt lỗi nits và dùng Adversarial Review Agent?

Thời kỳ ngồi comment từng dòng trên PR kiểu "đặt tên biến thế này đẹp hơn" hay "chỗ này mình thích viết theo style kia hơn" (nits) đã qua. Khi code sinh ra nhanh hơn và refactor trở nên cực kỳ rẻ nhờ AI, các vấn đề về code style, formatting hay type checking nên giao toàn bộ cho Static Analysis và Linter xử lý tự động.

Đặc biệt, khi dùng AI để review code của AI (qua Claude Code hay Codex GitHub integration), có một cái bẫy lớn: dùng chính agent vừa viết code để tự review lại code của nó. Vì nắm toàn bộ context cuộc hội thoại trước đó, nó sẽ có xu hướng "ăn gian" và thiên vị cho hướng giải quyết vừa làm. Kinh nghiệm chuẩn là khởi tạo một sub-agent mới hoàn toàn — Adversarial Review Agent (agent phản biện) — không biết gì về lịch sử chat, chỉ nhìn vào đúng code diff và bộ quy chuẩn kỹ thuật để tìm lỗ hổng khách quan nhất. Ngoài ra, để tránh cảnh người và máy ping-pong sửa qua sửa lại các comment lặt vặt trên GitHub, có thể thiết lập cơ chế định kỳ (ví dụ mỗi giờ một lần) để một agent tự kiểm tra PR, tự sửa theo comment của reviewer agent, chạy lại local validation và cập nhật PR.

Merge-ready và Launch-ready khác nhau thế nào?

Đây là phần tác giả bài tổng hợp tâm đắc nhất. Nhiều người dùng AI viết xong một loạt PR, thấy test xanh hết, merge vào nhánh chính xong là nghĩ đã hoàn thành 100% công việc. Thực tế, theo cách làm broad strokes (đi nét lớn), khi code đạt trạng thái merge-ready, mới chỉ đi được 80% quãng đường.

20% cuối cùng để biến code đó thành launch-ready mới là nơi tiêu tốn nhiều chất xám và định hình đẳng cấp của một kỹ sư, thường mất thời gian ngang ngửa 80% đầu tiên. Ở giai đoạn chuẩn bị mở cổng cho người dùng thật, cần thực hiện một đợt tổng kiểm toán toàn bộ tính năng ở góc độ bức tranh tổng thể:

• Rà soát performance, security và các edge-case bug.
• Đánh giá sản phẩm có chạy đúng spec ban đầu và đảm bảo human taste (độ mượt mà, trải nghiệm thực tế) hay không.
• Refactoring và dọn dẹp cấu trúc codebase để tránh rác tích tụ.
• Luôn mở tính năng qua A/B Testing hoặc Canary Deployment — nhả từng chút traffic qua Feature Gate để theo dõi crash rate, metrics và alert trước khi mở 100%.

Tóm lại, AI agent giúp đi những bước đầu cực kỳ nhanh, nhưng trách nhiệm giữ hệ thống ổn định vẫn nằm ở tư duy thiết kế safeguard và con mắt thẩm định của người kỹ sư ở những điểm trọng yếu.

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

1. Có nên đọc kỹ mọi dòng code do AI viết không? Không. Theo cách tiếp cận này, chỉ Trunk Code mới cần đọc kỹ từng dòng; Leaf Code đã bọc sau Feature Gate và có đủ bằng chứng thì chỉ cần đọc lướt.

2. Blast Radius là gì? Là phạm vi ảnh hưởng nếu đoạn code chạy sai: thay đổi ở Trunk Code có blast radius lớn vì ảnh hưởng toàn bộ ứng dụng, còn Leaf Code cô lập có blast radius nhỏ.

3. Agentic Validation gồm những bằng chứng nào? Unit test và integration test, runtime log, visual proof (screenshot/video UI) và mức độ tự tin do agent tự đánh giá.

4. Vì sao không để agent tự review code của chính nó? Vì agent nắm toàn bộ context trước đó nên dễ thiên vị cho hướng giải quyết vừa làm. Cần một Adversarial Review Agent mới, chỉ nhìn code diff và quy chuẩn kỹ thuật.

5. Merge-ready đã đủ để launch chưa? Chưa. Merge-ready mới đạt khoảng 80% quãng đường; 20% còn lại là audit toàn bộ tính năng, kiểm tra performance, security, spec và mở cổng dần bằng Canary Deployment.

Nguồn: bài tổng hợp của Lữ Minh Khương trong nhóm VGU Tech Alumni, đăng ngày 12/11/2026, dựa trên chia sẻ của John Kim, Senior Staff Software Engineer tại Meta. Nội dung bài viết trên được viết lại và bổ sung cấu trúc từ bài tổng hợp gốc; các đúc kết trong bài là của tác giả bài tổng hợp và người chia sẻ gốc.