Team Claude Code review hơn 30.000 thay đổi mỗi ngày ra sao

1. Từ 2.500 lên hơn 30.000 thay đổi mỗi ngày

Owain Lewis mở đầu video (đăng ngày 26/10/2026) bằng chủ đề: team Anthropic làm code review ở quy mô lớn như thế nào trên những sản phẩm như Claude Code. Theo con số anh đưa ra, chỉ trong bốn tháng, team Anthropic đã đi từ việc merge 2.500 thay đổi mỗi ngày lên hơn 30.000, tức tăng 12 lần. Bài viết của Anthropic mà anh dùng làm nguồn ghi cụ thể hơn: số thay đổi được đưa vào monorepo của Anthropic mỗi ngày đi từ khoảng 2.500 vào tháng 5 lên hơn 30.000 vào tháng 9 năm 2026 (bài viết đọc ngày 26/10/2026).

Theo Owain (video đăng ngày 26/10/2026), những cách làm code review truyền thống rõ ràng sẽ rất khó theo kịp lượng code do AI tạo ra. Trong video, anh hứa sẽ cho người xem thấy sáu cấp độ AI code review mà team Anthropic đang dùng, kèm vài demo trực tiếp để người xem thấy chính xác cách áp dụng những ý tưởng này vào workflow của mình khi build bằng các công cụ như Claude Code hay Codex.

Với người mới biết kênh, Owain tự giới thiệu: anh đã làm software engineer suốt 20 năm, ngày nào cũng làm việc với hàng trăm engineer, và code review chắc chắn là một trong những thứ anh thấy các team đang rất vật lộn vào lúc này (theo anh, video đăng ngày 26/10/2026).

2. Bài viết của team Claude Code và chuyện code do AI viết

Bài viết Owain xem cùng người xem là "How the Claude Code team does code review" trên blog claude.dev, đăng ngày 15/10/2026, do Addy Osmani, Morgan Westlee Lunt và Qing Wang viết (đọc ngày 26/10/2026). Điều anh thấy rất thú vị là 90% codebase của chính Claude Code được viết bởi AI; bài viết mở đầu bằng câu Claude viết khoảng 90% code của chính Claude Code (đọc ngày 26/10/2026).

Owain đoán chuyện đó cũng không có gì bất ngờ. Nhưng ở quy mô mà Anthropic đang chạy, theo anh (video đăng ngày 26/10/2026), lượng code do AI tạo ra lớn như vậy rõ ràng gây ra vấn đề. Và anh cho rằng phần lớn chúng ta lúc này cũng gặp đúng vấn đề đó (video đăng ngày 26/10/2026), vì cái khó của code do AI tạo ra là chúng ta không tự viết nó. Do đó chúng ta không hiểu nó theo cách mình sẽ hiểu nếu đã tự tay viết.

Thế nên, theo Owain, chúng ta cần tìm cách xử lý hai chuyện cùng lúc: khối lượng code ngày càng tăng, và việc chúng ta ngày càng xa rời code hơn so với trước kia.

3. Theory of constraints: review là khâu chậm nhất

Một ý tưởng rất thú vị mà Owain nói anh đang thấy trong các team phần mềm, và chính anh cũng nghĩ nhiều về nó thời gian gần đây, là theory of constraints (lý thuyết về điểm nghẽn). Dù chúng ta đang dùng AI để tạo ra nhiều code hơn, điều anh thấy (video đăng ngày 26/10/2026) là các team phần mềm nói chung không thực sự làm ra nhiều output hơn hay chạy nhanh hơn chút nào. Đó chính là theory of constraints đang vận hành.

Theory of constraints nói rằng hệ thống của bạn chỉ chạy nhanh bằng phần chậm nhất của quy trình. Dù bạn tạo ra cả đống code, dù theo Owain AI agent viết code chỉ trong vài phút (video đăng ngày 26/10/2026), nếu bạn không review được đống code đó, hoặc phải mất rất lâu mới review xong, thì bạn sẽ chẳng được lợi bao nhiêu về năng suất hay tổng output. Anh nói gần đây anh thấy chuyện này rất nhiều.

Human code review xưa nay vẫn luôn rất chậm, theo Owain (video đăng ngày 26/10/2026). Theo anh, trong một team phần mềm truyền thống, một thay đổi nằm chờ review nhiều ngày không phải chuyện hiếm. Mọi người bận. Họ còn phải làm quen với thay đổi đó là gì, trong khi họ không có nhiều bối cảnh về nó. Nên nói chung là mất rất nhiều thời gian để review xong.

Còn bây giờ, nếu chúng ta làm ra còn nhiều code hơn nữa, vấn đề này sẽ chỉ tệ hơn nhiều. Vì thế, theo anh (video đăng ngày 26/10/2026), cứ dùng đúng những phương pháp như xưa nay thì không còn hợp lý nữa, vì chúng ta sẽ không thể theo kịp tốc độ của code do AI tạo ra.

4. Hai việc của code review

Owain nói code review xưa nay luôn có hai việc.

Việc thứ nhất là tìm và sửa bug trước khi chúng lọt ra production. Điều này hiển nhiên: mỗi lần bạn thay đổi code, gần như lúc nào cũng có thứ gì đó cải thiện được hoặc phải sửa. Con người mắc lỗi, AI agent cũng mắc lỗi (theo Owain, video đăng ngày 26/10/2026); bạn không bao giờ tin được output đầu tiên, và review thật sự nâng mức chuẩn chất lượng trong một team.

Việc thứ hai là xây dựng một sự hiểu biết chung về những gì đang diễn ra. Khi agent viết code, chúng ta vẫn muốn biết chúng đang làm gì, đúng không? Chúng ta vẫn muốn hiểu codebase. Chúng ta vẫn không muốn mất dấu, không muốn đánh mất cái nhìn tổng thể ở mức high level về những gì thực sự đang diễn ra trong phần mềm của mình (theo Owain, video đăng ngày 26/10/2026).

Bài viết của Anthropic cũng chia đúng hai việc này: tìm và sửa vấn đề trước khi ship, và xây dựng bối cảnh chung, sự hiểu biết về codebase trong cả team; phần lớn bài tập trung vào việc thứ nhất và quay lại việc thứ hai ở gần cuối (đọc ngày 26/10/2026).

Theo Owain, bài viết có vài ý rất hay, và ý đầu tiên anh thấy đặc biệt sâu sắc: chúng ta hay nghĩ tới câu hỏi "đã có người đọc đoạn code này chưa?", nhưng câu hỏi đó thật ra không hữu ích lắm. Bài viết gọi nó là một thước đo không chính xác cho câu hỏi thật sự: thay đổi này có thể hỏng ở đâu, và bước kiểm tra nào, tự động hay con người, là bước phù hợp để bắt được lỗi đó (đọc ngày 26/10/2026).

5. Rủi ro, blast radius và sự chú ý có hạn của con người

Khi nghĩ về code review, theo Owain, điều rất quan trọng là hiểu rằng code review không chỉ có một cấp độ. Có nhiều mức rủi ro khác nhau.

Nếu bạn sửa tài liệu, nguy cơ có gì hỏng rõ ràng là rất, rất thấp. Nếu bạn lỡ sai và merge vào thì cũng không sao, đúng không, chẳng tạo ra khác biệt gì. Nên blast radius (phạm vi ảnh hưởng khi có sự cố) của thay đổi đó là rất, rất nhỏ.

Nhưng nếu bạn thay đổi database hay hạ tầng thanh toán, một bug lọt lên production có thể gây ra một sự cố ngừng dịch vụ rất lớn. Khách hàng có thể không truy cập được dịch vụ hay hệ thống của bạn. Rõ ràng blast radius của thay đổi đó lớn hơn rất nhiều.

Vì vậy, Owain nói, bạn luôn muốn nghĩ về code review theo nhiều mức rủi ro khác nhau, chứ không coi mọi thay đổi code là như nhau. Thời gian và sự chú ý của con người lúc nào cũng sẽ là điểm nghẽn trong phát triển phần mềm. Nên chúng ta chỉ muốn đặt human review ở những chỗ thật sự cần. Theo anh, ý này xuất hiện xuyên suốt bài viết; bài viết có hẳn một phần tên "The scarce resource: human time and attention" (đọc ngày 26/10/2026).

Sự chú ý của con người rõ ràng là có hạn. Nếu AI agent đang tạo ra hàng trăm thay đổi code (theo Owain, video đăng ngày 26/10/2026), chúng ta không thể kỳ vọng một cách hợp lý rằng một người sẽ review từng thay đổi một, vì con người đơn giản là không có đủ thời gian hay sự chú ý để làm việc đó.

6. Đo hiệu quả của quy trình review

Một điều rất hay về code review, theo Owain, là bạn có thể đo quy trình code review của mình hiệu quả tới đâu một cách rất, rất dễ (video đăng ngày 26/10/2026).

• Theo Owain (video đăng ngày 26/10/2026), bạn có thể xem mất bao lâu từ lúc một thay đổi được mở cho tới lúc nó được merge.
• Theo anh (video đăng ngày 26/10/2026), bạn cũng có thể đo những thứ như thay đổi có hay bị hỏng không: revert rate hay defect rate của các thay đổi code là bao nhiêu?

Anh nói đây là một cách rất dễ để đo chất lượng của quy trình code review. Nếu bạn làm trong một team, anh thấy lúc này (video đăng ngày 26/10/2026) là thời điểm rất đáng để bắt đầu đo những thứ này, để bạn thấy quy trình của mình cải thiện ra sao khi bắt đầu đưa AI vào.

Bài viết của Anthropic đo theo cùng tinh thần: số lượt người duyệt trên mỗi PR (median và percentile 95), số comment của người, thời gian một PR phải chờ một người, và lấy tỉ lệ revert cùng tỉ lệ sự cố làm rào chắn (đọc ngày 26/10/2026).

7. Các lớp review mà Anthropic dùng

Owain nói anh sẽ đi qua các bước Anthropic đang dùng để review code, và đi sâu vào từng bước. Trên các slide của anh, các bước được đánh số từ 01/06 tới 06/06; khi nói, anh tách bước cuối thành bước sáu (phát hành dần) và bước bảy (phát hiện nhanh, rollback nhanh). Ở mức high level, theo cách Owain đọc bài viết (đọc ngày 26/10/2026):

• Local review. Trước cả khi mở một thay đổi để review, họ đảm bảo nó đã được review ở máy local. Họ chạy một loạt kiểm tra tự động: test, build check, linting, type checking. Rồi họ dùng một AI agent để review code với một context window mới (theo bài viết, đọc ngày 26/10/2026).
• Khi đã mở thay đổi, họ lại chạy một loạt kiểm tra tự động tĩnh để tìm các lỗi hiển nhiên (theo bài viết, đọc ngày 26/10/2026).
• Rồi tới Claude code review: họ dùng một hoặc nhiều AI agent để review code (theo bài viết, đọc ngày 26/10/2026).
• Họ chạy một security review (theo bài viết, đọc ngày 26/10/2026).
• Và họ có risk-based approval, duyệt theo rủi ro (theo bài viết, đọc ngày 26/10/2026).

Owain nói anh rất thích ý tưởng risk-based approval và sẽ bàn kỹ hơn ở phần sau của video (video đăng ngày 26/10/2026). Ý tưởng là chúng ta phân loại thay đổi thành rủi ro thấp, rủi ro trung bình hoặc rủi ro cao. Thay đổi rủi ro thấp thì có thể auto merge. Thay đổi rủi ro trung bình thì có một người review. Thay đổi rủi ro cao thì có hai người review. Anh cho đây là một chiến lược rất khôn ngoan.

Ngoài ra, theo cách anh đọc bài viết (đọc ngày 26/10/2026), họ còn có cách đưa thay đổi ra cho các team nội bộ trước để lấy feedback, và phát hành thay đổi dần dần. Rồi nếu đã deploy lên production, họ có cách rollback khi có lỗi. Lý do, theo Owain: trên thực tế code review không hoàn hảo. Nếu nó hoàn hảo, chúng ta đã chẳng có bug trên production. Nên bạn vẫn muốn mặc định rằng code review có lỗ hổng; nó không phải một quy trình hoàn hảo.

8. Bước 1: review ở máy local bằng một agent mới

Bước một là local review. Owain đoán nhiều người có lẽ đã làm việc này rồi: sau khi agent viết code xong, bạn nhờ một subagent hoặc một agent mới review codebase. Việc này có thể dùng Claude, hoặc một agent khác như Codex. Nếu bạn dùng Claude Code, bạn có thể nhờ Codex agent review code, hoặc ngược lại (theo Owain, video đăng ngày 26/10/2026).

Theo Owain, đây rõ ràng là một best practice: nếu làm việc với AI, bạn luôn nên review code, dù AI có năng lực và thông minh y như một con người (theo anh, video đăng ngày 26/10/2026). Lần đầu tiên viết một đoạn code, dù bạn là AI agent hay con người, nhiều khả năng sẽ có một bug hoặc một chỗ có thể cải thiện, đúng không? Không AI agent nào viết code hoàn hảo ngay lần đầu, và đó là lý do code review quan trọng đến vậy.

Owain dẫn lời Boris Cherny, người tạo ra Claude Code: quá trình lặp ở local như vậy sẽ làm kết quả cuối cùng tốt hơn hai đến ba lần. Bài viết ghi rằng Boris ước tính việc cho Claude một cách để tự verify công việc của nó làm kết quả cuối cùng tốt hơn hai đến ba lần (đọc ngày 26/10/2026). Owain thấy điều đó hợp lý, vì mỗi lần anh nhìn vào một thay đổi code do AI tạo ra, lúc nào cũng có một vấn đề nào đó; nếu bạn nhờ một subagent review code, nhiều khả năng nó sẽ tìm ra một vấn đề (theo anh, video đăng ngày 26/10/2026). Nên anh cho bước này thật sự, thật sự quan trọng.

9. File REVIEW.md

Một ý rất thú vị mà bài viết nhắc tới, và Owain nói chính anh cũng đang dùng (video đăng ngày 26/10/2026), là file REVIEW.md. Ý tưởng như sau: khi làm code review, bạn không thật sự review một thay đổi chung chung. Thường thì bạn tập trung vào những vùng cụ thể.

• Nếu bạn build một ứng dụng thanh toán, có lẽ bạn muốn để ý thật kỹ tới bảo mật, đảm bảo authorization và những thứ tương tự là đúng.
• Nếu bạn làm một ứng dụng web, có thể bạn muốn dành nhiều thời gian review UI.
• Có thể bạn muốn dành nhiều thời gian xem xét hiệu năng database.

Mỗi ứng dụng phần mềm khác nhau mà bạn làm, bạn sẽ muốn tập trung vào những thứ hơi khác nhau. Đó là ý tưởng đằng sau file REVIEW.md. Bạn tạo file này, bảo agent đọc nó, và theo Owain (video đăng ngày 26/10/2026) agent sẽ tập trung vào những thứ cụ thể bạn muốn chúng tập trung.

Owain cho xem một ví dụ file REVIEW.md; trên màn hình là trang docs "Customize Code Review" của Claude Code. Trong file, chúng ta nói cho agent biết điều gì quan trọng với mình khi nó review code: trình bày finding thế nào; đừng xét linting hay formatting; đừng nhìn vào những thư mục này; đừng để địa chỉ email hay thông tin người dùng trong log, hãy đặc biệt để ý chuyện đó. Ví dụ trên trang docs, đúng như trên màn hình của Owain, có nội dung (đọc ngày 26/10/2026):

# Review instructions

## What Important means here

Reserve Important for findings that would break behavior, leak data, or block a rollback: incorrect logic, unscoped database queries, PII in logs or error messages, and migrations that aren't backward compatible. Style, naming, and refactoring suggestions are Nit at most.

## Cap the nits

Report at most five Nits per review.

## Do not report

- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules

## Always check

- New API routes have an integration test
- Log lines don't include email addresses, user IDs, or request bodies
- Database queries are scoped to the caller's tenant

Theo Owain, đây là một cách rất hay để khiến agent tập trung vào những thứ cụ thể khi review code. Như anh nói (video đăng ngày 26/10/2026), tất cả những gì bạn cần là có file này trong codebase, rồi bảo agent tham chiếu hoặc đọc nó.

Anh còn cho xem một ví dụ từ project của chính mình: một software factory anh đang làm, repo tên Machinist. File review.md ở đây tập trung vào cách làm code review: nó bảo agent phân loại thay đổi thành rủi ro thấp, trung bình hoặc cao, và đưa ra hướng dẫn về ý nghĩa của từng mức. Rồi nó đưa hướng dẫn chung về những gì cần để ý trong riêng codebase này (như trên màn hình video đăng ngày 26/10/2026).

10. Bước 2: AI review trên mọi pull request, và demo hai lệnh review

Bước tiếp theo là chạy AI review trên mọi pull request. Ý tưởng là khi đã đẩy thay đổi code lên một nơi như GitHub, bạn chạy một code review tự động, để một AI agent review code của bạn. Theo Owain (video đăng ngày 26/10/2026), có rất nhiều cách làm việc này: dùng một công cụ như CodeRabbit hay Greptile, hoặc dùng chính Claude Code hay Codex. Anh nói anh dùng Codex để chạy một bản review cơ bản trên thay đổi code của mình.

Rồi Owain cho xem hai lệnh trong Claude Code mà anh cho là đáng nhớ (video đăng ngày 26/10/2026). Lệnh thứ nhất là /code-review, rõ ràng là để làm code review. Lệnh thứ hai cũng nên biết là /security-review. Theo anh, khi gõ lệnh này bạn có thể cho nó tập trung vào các file cụ thể, ví dụ review file này, hoặc review các thay đổi chưa commit; bạn có thể đưa thêm context ngay khi gõ slash command để nó tập trung vào một vùng hay một chủ đề cụ thể.

Trên màn hình, Claude Code (bản v2.1.309, model Opus 5.5, theo video đăng ngày 26/10/2026) chạy hai phiên cạnh nhau. Bên trái là /code-review, chạy ngầm dưới tên @code-review. Bên phải, anh gõ:

/security-review Review the uncommitted changes in the working tree, including the untracked file internal/controlplane/run_search.go.

Agent code review trả kết quả trước và đã phát hiện cả loạt lỗi (demo trong video đăng ngày 26/10/2026). Owain giải thích anh đã cố tình cài một lỗ hổng SQL vào code để xem nó có bắt được không. Kết quả có những vấn đề nghiêm trọng: SQL injection, không có auth trên một endpoint; rồi tới phần correctness, những thứ cần sửa như lỗi logic, một giá trị không bao giờ được kiểm tra; và cả phần quality.

Sau đó, theo Owain (video đăng ngày 26/10/2026), bạn chỉ việc bảo agent đi qua và sửa hết các lỗi đó. Có lẽ bạn sẽ muốn chạy việc này vài lần: để agent sửa, rồi chạy lại. Bạn cũng có thể cho code review tập trung vào một chủ đề cụ thể, ví dụ review phần tài liệu; trên màn hình, ở phiên bên trái anh gõ /code-review review the documentation. Tuỳ việc đang làm mà bạn hướng review vào những thứ khác nhau.

Rồi feedback từ agent security review trả về (demo trong video đăng ngày 26/10/2026). Owain nhận xét feedback khá tốt: theo lời anh, finding SQL injection có mức confidence 9 trên 10, kèm phần mô tả. Theo anh, đây là một bản review kỹ hơn nhiều so với code review thông thường. Bản review thường cũng đã bắt được lỗi này, nhưng bản security review đi vào chi tiết hơn hẳn: trên màn hình có kịch bản khai thác (exploit scenario) với việc server lắng nghe trên loopback ở một port đoán được, các đề xuất sửa câu lệnh SQL, và thêm một lỗ hổng khác là path traversal.

Kết luận của Owain từ demo (video đăng ngày 26/10/2026): security review cho nhiều chi tiết hơn và đi sâu hơn, còn code review thông thường cũng bắt được nhiều lỗi trong số đó nhưng không đi sâu bằng. Vì thế anh khuyên chạy cả hai cùng lúc.

11. Tư duy factory: cùng một chuỗi bước cho mọi task

Owain đưa ra một gợi ý để luôn nhớ làm những việc này, vì trên thực tế chúng ta mệt, chúng ta quên. Điều anh khuyên là trở nên có hệ thống hơn trong quy trình phát triển. Ý anh là chuyển sang một factory mindset (tư duy nhà máy): nhận một task, rồi lần nào cũng cho nó chạy qua cùng một chuỗi bước, theo một cách thật sự lặp lại được.

Anh cho xem một factory plugin anh đang build. Trong đó có các agent khác nhau cho từng bước của quy trình (theo màn hình video đăng ngày 26/10/2026):

• một implementer agent nhận yêu cầu thay đổi và viết code;
• một review agent;
• một security review agent;
• một UX review agent, review trình duyệt, xem web app trông thế nào bằng browser testing và các cách tương tự (theo Owain, video đăng ngày 26/10/2026);
• một triage agent;
• và một classifier agent đổi mức rủi ro trên ticket: nó thêm một label vào GitHub issue tuỳ theo loại thay đổi (theo Owain, video đăng ngày 26/10/2026).

Theo Owain (video đăng ngày 26/10/2026), bạn có thể ghép tất cả những thứ đó thành một chuỗi, để gần như chỉ cần đưa một lệnh, truyền vào một task, rồi agent chạy qua tất cả các bước này mỗi lần. Đó là chuyển sang factory mindset: bạn không còn prompt agent một cách tuỳ hứng (ad hoc) nữa, mà trở nên chặt chẽ và có hệ thống hơn nhiều trong quy trình phát triển. Anh nghĩ đây là chìa khoá để thật sự có được chất lượng khi làm việc với AI agent.

Anh nhấn mạnh: bạn không cần làm việc này phức tạp. Anh không nghĩ bạn cần nhiều skill đến thế. Anh không có một setup phức tạp, và anh không nghĩ lúc này (video đăng ngày 26/10/2026) bạn còn cần cài cả đống skill phức tạp nữa. Theo anh, khi agent thông minh hơn, bạn có thể giữ setup thật tối giản. Nhưng thứ bạn cần có là tính lặp lại được và tính dự đoán được trong workflow, trong quy trình của mình.

12. Một lệnh review và chạy cả ticket qua Software Factory

Owain thử ý tưởng chặt chẽ hơn trong quy trình phát triển này: đảm bảo lần nào thay đổi cũng chạy security review, lần nào cũng chạy code review, lần nào cũng kiểm tra linting và tooling cần thiết. Cách làm là build một hệ thống kiểu factory nào đó.

Plugin anh đang build tên là Software Factory. Theo anh (video đăng ngày 26/10/2026), về cơ bản nó chỉ là một nhóm Claude Code subagent được nối với nhau thành chuỗi. Trong đó có một lệnh review, và bạn có thể truyền thêm thông tin tuỳ ý. Bạn truyền vào một task, và agent làm đúng cùng một việc mỗi lần.

Lệnh review này gộp nhiều thứ khác nhau: một code review thông thường, cộng thêm một security review. Thay vì phải gõ từng lệnh riêng lẻ, thay vì phải nhớ prompt theo một cách nhất định, bạn có một lệnh duy nhất nhận thay đổi của bạn và nhớ làm đủ các bước đúng mỗi lần. Theo Owain, đây chỉ là làm cho quy trình thật sự lặp lại được. Owain nói về kết quả review rằng đây là ý tưởng lấy từ bài viết của Anthropic: thay đổi được phân loại là rủi ro trung bình, nên cần một người duyệt (demo trong video đăng ngày 26/10/2026).

Bạn còn có thể làm ở mức cao hơn, và Owain nói đó là cách anh hay làm (video đăng ngày 26/10/2026): truyền vào một task rồi để factory chạy toàn bộ thay đổi qua cả chuỗi bước: lập kế hoạch, build, test, review, v.v. Thay vì chỉ có một lệnh để review code, bạn lấy nguyên một task và lần nào cũng cho nó chạy qua tất cả các bước.

Anh lấy một ticket ra làm thử (demo trong video đăng ngày 26/10/2026). Trên màn hình, trong Claude desktop app, anh gõ:

/software-factory:factory 345

Theo lời Owain (video đăng ngày 26/10/2026), task sẽ được chuyển qua rất nhiều subagent khác nhau trong lúc chạy. Ticket được triage, rồi code được build, tức được viết ra. Rồi code được review bằng tất cả các subagent và tất cả các cách đã nói ở trên. Một lần nữa, tất cả những gì anh làm chỉ là truyền task vào.

Vì đã mã hoá workflow vào Software Factory, vào hệ thống, anh không phải nghĩ nhiều về các bước. Anh chỉ đảm bảo mình làm chúng mỗi lần, và theo anh đó mới là điều thật sự quan trọng với loại việc này. Bởi như anh đã nói, bạn sẽ quên làm code review, hoặc quên chạy lệnh security review. Nhưng khi làm theo cách này, theo Owain (video đăng ngày 26/10/2026), agent luôn đi đúng các bước, luôn làm đúng việc, luôn chạy classifier. Đó là cách anh đang chuyển sang khi làm agentic coding.

13. Triage một yêu cầu thô thành spec, rồi review theo acceptance checks

Một việc Owain đang làm cho riêng mình, và anh rất thích ý tưởng này, là bước triage. Đây cũng là một ý của software factory. Khi build một thay đổi, anh viết ra toàn bộ spec: anh lấy một mô tả vấn đề rất thô, một input rất mơ hồ, rồi dùng một agent để triage yêu cầu gốc và tách nó thành một bản spec (video đăng ngày 26/10/2026).

Trên màn hình là một bản phân tích rất chi tiết: đã thêm label, và về cơ bản đã có spec (demo trong video đăng ngày 26/10/2026). Issue #345 trên GitHub có tiêu đề "fix(tui): Ctrl-C idle quits instantly, Esc cancels without confirmation, Ctrl/Shift-Enter unreachable on most terminals", với các mục Problem, Fix, Spec, gắn label bug và factory. Theo Owain, đây là cách làm software factory: lấy một task, để agent viết một bản đặc tả khá chi tiết mà mình có thể review nếu muốn, rồi để agent build code, rồi chạy tất cả các kiểm tra tự động, rồi code review.

Thường còn có những thứ như các acceptance checks này nữa. Khi chạy code review, theo Owain, việc tham chiếu tới các acceptance check là rất quan trọng. Trong plan ban đầu, chúng ta có một loạt trường hợp mà mình cũng muốn kiểm tra. Nên khi code review, đây là một thứ nữa cần để ý: code có làm đúng việc nó phải làm không? Code có thực sự đáp ứng mọi yêu cầu, mọi acceptance check mà bạn nghĩ ra khi mới quyết định build nó không?

Anh nói đây là một điều rất hữu ích để nghĩ tới: có những acceptance check này. Khi làm quy trình code review, hãy đảm bảo bạn tham chiếu tới các acceptance criteria đó, và bạn sẽ đảm bảo được code thực sự làm đúng việc nó phải làm.

14. Bước 3 và 4: security review, linting, type checking và build

Bước thứ ba là security review. Theo Owain (video đăng ngày 26/10/2026), cái này có sẵn trong Claude Code: có lệnh /security-review mà bạn dùng được. Ý tưởng là bắt mọi lỗ hổng bảo mật trong codebase. Anh nói có lẽ bạn muốn chạy nó định kỳ, chứ không muốn chạy nó mỗi lần thay đổi code. Anh cũng gợi ý tự động hoá việc này, vì trên thực tế phần lớn chúng ta sẽ quên chạy lệnh đó.

Anh mở một bài viết hay về chủ đề này, bài "Automated Security Reviews in Claude Code" trên trang hỗ trợ của Claude. Những thứ bạn tìm là: rủi ro SQL injection, cross-site scripting, lỗi authentication và authorization, xử lý dữ liệu không an toàn, thiếu validation, và dependency có lỗ hổng. Trang hỗ trợ đó ghi rằng có hai cách dùng: lệnh /security-review để kiểm tra theo yêu cầu ngay trong terminal, hoặc GitHub Actions để tự động review pull request (đọc ngày 26/10/2026).

Bước bốn là dùng các kiểm tra tự động mang tính tất định (deterministic): linting, type checking. Nếu bạn chưa quen, đây là các công cụ bạn chạy để tìm những lỗi hiển nhiên trong code. Chúng đã có từ rất lâu, và theo Owain (video đăng ngày 26/10/2026) phần lớn developer đã dùng chúng rồi.

Một cách hay để làm việc này, theo anh, là nhờ agent cấu hình chúng cho ngôn ngữ cụ thể của bạn. Tuỳ ngôn ngữ bạn dùng mà sẽ có tooling khác nhau. Điều anh sẽ làm là khi bắt đầu một project, nhờ agent thiết lập những thứ này cho mình, cả ở local lẫn trên GitHub; theo anh (video đăng ngày 26/10/2026), agent sẽ cấu hình hết cho bạn. Gồm type checking, đảm bảo code build đúng, và các formatter riêng cho từng ngôn ngữ mà về cơ bản bạn chạy mỗi lần thay đổi code.

15. Bước 5: con người duyệt theo mức rủi ro

Bước năm là human approval scaled by risk, con người duyệt theo mức rủi ro. Owain nói đây là phần anh thích nhất trong cả bài viết, và anh nghĩ đây là một cách nghĩ rất khôn ngoan về code review. Theo bài viết (đọc ngày 26/10/2026), họ dùng một classifier để quyết định một thay đổi code là rủi ro cao, thấp hay trung bình. Theo Owain, điều này rất quan trọng, vì bạn luôn muốn nghĩ tới blast radius của một thay đổi.

Bạn không muốn nhiều người cùng review một thay đổi tài liệu chẳng hạn, vì đó sẽ là một sự lãng phí rất lớn thời gian của mọi người. Nếu là một thay đổi nhỏ, tầm thường, anh nghĩ để agent tự auto merge là hợp lý (video đăng ngày 26/10/2026). Tới một lúc nào đó bạn cũng muốn tin agent.

• Thay đổi rủi ro trung bình, như một feature lớn: theo Owain (video đăng ngày 26/10/2026), bạn có thể cho một người review.
• Thay đổi rủi ro cao hơn, như thay đổi database hay hạ tầng, có blast radius lớn hơn nhiều: theo Owain (video đăng ngày 26/10/2026), bạn có thể cho hai người review.

Owain thấy đây là một cách nghĩ về code review rất thực tế và khôn ngoan. Bài viết còn ghi rõ (đọc ngày 26/10/2026): ở mức Low (tài liệu, copy, feature chỉ dùng nội bộ, thay đổi bổ sung nằm sau flag) không cần người duyệt khi review tự động và kiểm tra bảo mật đã xanh; Medium cần một người; High cần hai người; và chính thay đổi quyết định mức, chứ không phải tác giả.

Họ cũng đảm bảo người tạo ra thay đổi phải chịu trách nhiệm về nó. Theo Owain, dù AI agent viết code, chúng ta rõ ràng vẫn có trách nhiệm đảm bảo thay đổi code có chất lượng cao. Bài viết gọi đúng điều này là "whoever prompted the change is on the hook for it": trên một PR do agent viết, người điều khiển agent được tính là một trong những người review bắt buộc (đọc ngày 26/10/2026).

16. Bước 6 và 7: phát hành dần, phát hiện nhanh, rollback nhanh

Bước sáu là gradual release, phát hành dần dần. Theo cách Owain đọc bài viết (đọc ngày 26/10/2026), về cơ bản họ đưa thay đổi ra cho các team nội bộ trước. Việc này cho họ một cách lấy feedback về các vấn đề trước khi thay đổi tới tay công chúng.

Bước bảy là fast detection, fast rollback: phát hiện nhanh, rollback nhanh. Ý tưởng là code review không hoàn hảo. Agent của bạn giỏi tới đâu cũng vậy, setup của bạn tốt tới đâu cũng vậy, bạn sẽ không bao giờ bắt được mọi lỗi có thể xảy ra trong một lần code review, đúng không? Có những loại lỗi bạn chỉ tìm ra được khi đã deploy thay đổi lên production, như memory leak hay vấn đề hiệu năng; theo Owain (video đăng ngày 26/10/2026), rất khó phát hiện chúng chỉ bằng cách nhìn vào code.

Nên bạn luôn muốn mặc định rằng quy trình code review của mình không hoàn hảo. Và điều họ làm, theo bài viết (đọc ngày 26/10/2026), là nếu tung ra một thay đổi có vấn đề, họ có thể rollback nó thật, thật nhanh. Họ cũng làm on-call review định kỳ, làm incident review. Owain gọi đây là thực hành tốt trong team: mỗi tuần mọi người ngồi lại, xem các thay đổi code của tuần trước, tìm những vùng có vấn đề, rồi cải thiện quy trình để bắt được những vùng đó về sau.

Team Anthropic còn đi xa hơn, về cơ bản là dùng những lỗi trong quá khứ: những trường hợp đã đi qua quy trình code review mà không bắt được lỗi. Theo Owain và bài viết (đọc ngày 26/10/2026), họ dùng chúng làm eval, làm feedback cho các reviewer về sau. Nếu họ có một thay đổi database đã lọt qua code review nhưng thực tế gây lỗi trên production, họ sẽ dùng nó làm một bài test, hay một kiểu context, để lần sau agent đặc biệt để ý tới chuyện đó.

17. Giữ con người trong vòng lặp, và demo HTML explainer

Theo Owain, rõ ràng điều rất quan trọng là con người vẫn ở trong vòng lặp. Con người có những context mà AI agent không có. Riêng anh, lúc này (video đăng ngày 26/10/2026) anh khá thoải mái với việc auto-merge một số loại thay đổi nhất định. Và anh nghĩ khi AI agent tốt hơn, chuyện này bắt đầu hợp lý hơn. Tới một lúc nào đó chúng ta phải tin agent một chút.

Nhưng vẫn có những lúc bạn thật sự cần một người trong vòng lặp. Rõ ràng là với bất cứ thứ gì rủi ro: theo Owain (video đăng ngày 26/10/2026), con người thường có nhiều context hơn hẳn, họ nhìn ra những thứ mà AI agent không thấy. Nhưng ngược lại, AI agent cũng sẽ nhìn ra những thứ con người không thấy. Nên bạn luôn muốn kết hợp cả hai.

Điều nữa mà anh nghĩ (video đăng ngày 26/10/2026) rất quan trọng với code review: bạn vẫn cần hiểu ở mức high level chuyện gì đang diễn ra với code của mình. Dù agent viết code, bạn vẫn muốn hiểu chuyện gì đang xảy ra, thay đổi đó làm gì, tác động của nó là gì, và nó ảnh hưởng thế nào tới kiến trúc tổng thể của hệ thống.

Một việc bạn có thể làm, theo Owain (video đăng ngày 26/10/2026), mà sẽ giúp rất nhiều với code review và các thay đổi code, là nhờ agent viết cho bạn một explainer. Bạn có thể để agent viết một trang HTML có sơ đồ, giải thích cho bạn thay đổi đó là gì; nó giúp bạn thật sự hiểu thay đổi code là gì và rủi ro tiềm ẩn là gì. Anh gọi đây là một kỹ thuật rất hay nếu bạn muốn hiểu, hoặc dễ nắm hơn, những gì agent đang làm. Bài viết của Anthropic cũng kể: khi ai đó muốn hiểu một phần codebase, họ nhờ Claude viết một explainer cho đúng phần đó (đọc ngày 26/10/2026).

Trong demo, dù thay đổi code của ticket kia vẫn đang chạy, Owain thử xem Claude có làm việc này song song được không (demo trong video đăng ngày 26/10/2026). Trên màn hình, anh gõ:

Generate me a html explainer showing what this change is and include a diagram to help me understand it

Theo anh (video đăng ngày 26/10/2026), bạn chỉ cần nhờ Claude tạo những tài liệu HTML explainer như vậy. Đây là một kỹ thuật rất hữu ích để hiểu, đặc biệt nếu bạn đang làm một thay đổi code lớn hơn, và đặc biệt nếu bạn đang chuyển qua lại giữa nhiều việc hoặc quay lại sau một thời gian: để agent tạo một dạng sơ đồ trực quan giúp bạn nhớ thay đổi đó là gì, và hiểu nó sâu hơn một chút.

Đây là explainer nó đã tạo (demo trong video đăng ngày 26/10/2026). Theo Owain, rõ ràng bạn có thể tuỳ chỉnh nó cho dễ hiểu hơn. Anh nói anh thường thấy khá khó hiểu một số output của các agent này; theo anh, lúc này (video đăng ngày 26/10/2026) chúng không giỏi giải thích lắm. Nhưng ở đây có sơ đồ, bạn thấy được quy trình đang diễn ra, thấy được cách tái hiện nó, và nó cho bạn một cách để hiểu thay đổi sâu hơn.

18. Tóm tắt, và chất lượng đến từ việc lặp lại

Theo Owain, đó là một kỹ thuật rất hữu ích để đi qua thay đổi code, thấm được chuyện gì đang diễn ra và hiểu nó tốt hơn. Rồi anh tóm tắt lại những gì bài viết gợi ý (đọc ngày 26/10/2026):

• Trước khi mở một thay đổi code: chạy một loạt formatting và linting tự động. Theo Owain, bạn có thể dùng một Claude Code hook cho việc này, hoặc đơn giản là một pre-hook của git để tự review trước khi push (video đăng ngày 26/10/2026).
• Chạy /code-review và /security-review ở local, hoặc dùng một subagent mới. Anh nói anh luôn dùng một subagent mới, và nghĩ đó là cách làm tốt hơn nhiều; nói chung đó là cách anh đang làm (video đăng ngày 26/10/2026).
• Thêm một file REVIEW.md để đưa vào đó những thứ cụ thể bạn muốn code review tập trung. Mỗi lần thấy một vấn đề lặp đi lặp lại, hãy đưa nó vào REVIEW.md để agent tập trung vào đó về sau (theo bài viết, đọc ngày 26/10/2026).
• Khi đã push thay đổi: đảm bảo có một AI reviewer. Owain nói anh đang dùng Codex, đôi khi dùng CodeRabbit và các công cụ khác; có rất nhiều lựa chọn, và Greptile cũng là một lựa chọn rất tốt (theo anh, video đăng ngày 26/10/2026).
• Tinh chỉnh file REVIEW.md, tự động chạy security review, và để công sức review tương xứng với rủi ro (theo bài viết, đọc ngày 26/10/2026).

Owain nhắc lại, đây là một trong những bài học chính cần nhớ về code review: để công sức review tương xứng với rủi ro. Bạn không muốn tốn chừng ấy thời gian cho những thay đổi thường ngày. Bạn muốn dùng phán đoán của con người ở chỗ nó thật sự quan trọng: những thay đổi rủi ro cao hơn, quan trọng hơn, đáng kể hơn. Bạn không muốn phí thời gian và sự chú ý của con người vào những thay đổi code thật sự tầm thường.

Cuối cùng, sau khi đã merge, hãy bắt đầu học từ những thay đổi đó: học từ những gì code review để lọt, học từ những gì không hiệu quả trong quy trình code review, rồi liên tục tinh chỉnh và cải thiện nó.

Bài học cuối của Owain từ bài viết (video đăng ngày 26/10/2026): hãy dùng nhiều cấp độ code review. Bạn có thể kiểm tra chất lượng ở rất nhiều cấp độ khác nhau, và chất lượng đến từ việc lặp lại (quality comes from iteration). Dù bạn là developer giỏi nhất thế giới, bạn vẫn sẽ mắc lỗi. Nên bạn luôn cần kiểm tra công việc của mình, luôn cần tinh chỉnh và lặp lại. Chất lượng luôn đến từ việc lặp lại.

Với AI agent cũng vậy, theo Owain (video đăng ngày 26/10/2026): AI agent có thông minh tới đâu cũng không quan trọng, bạn vẫn luôn cần review code, vì nhiều khả năng vẫn có chỗ cải thiện được. Không ai làm đúng ngay lần đầu. Cách tiếp cận lặp lại này, review, tinh chỉnh và cải thiện các thay đổi code, là cách để có chất lượng ở quy mô lớn.

Tóm lại: verification, kiểm tra tự động, AI review, human review khi cần, và đảm bảo có một quy trình tốt để liên tục cải thiện, theo dõi và đo quy trình code review. Owain khuyên đo và cải thiện quy trình code review của mình theo thời gian. Anh cảm ơn mọi người đã xem.