Team Claude Code review code do AI viết qua bảy layer

1. John đọc bài viết về code review của team Claude Code

John mở đầu bằng một câu hỏi: bạn đã bao giờ tự hỏi Anthropic làm code review cho chính code của mình như thế nào chưa? Anh tình cờ đọc được một bài viết của team Claude Code kể lại cách team thực sự làm code review, và anh nghĩ sẽ rất hay nếu đọc bài này, phản hồi từng phần và đưa ra nhận định tổng quan của mình, để xem cách làm của anh có khác biệt lớn nào không. Vì vậy định dạng video lần này hơi khác, nhưng anh hy vọng mọi người vẫn thích (video đăng ngày 01/11/2026).

Tiêu đề bài viết là "How the Claude Code team does code review", với câu hỏi phụ: làm sao review code ở đúng khối lượng mà agent tạo ra? Bài viết của một nhóm tác giả, trong đó có Addy Osmani, người John theo dõi trên X; anh biết tới bài này chủ yếu qua một bài đăng của Addy. John nói những người còn lại hiển nhiên cũng làm trên Claude Code; trang bài viết ghi hai đồng tác giả kia là Morgan Westlee Lunt và Qing Wang (bài đăng ngày 15/10/2026, đọc ngày 01/11/2026).

Ngay từ đầu, John nói anh hoàn toàn đồng ý với hướng đi của bài. Theo anh, có những đoạn code đơn giản là dễ land và không thật sự cần thêm người review, nhưng chắc chắn vẫn có những thứ cần thêm những vòng review tốn thời gian (nhận định của John, video đăng ngày 01/11/2026).

2. Những con số mở đầu: PR gấp đôi, tỉ lệ revert giảm

John đọc đoạn mở bài. Team Claude Code từng nói rằng Claude viết khoảng 90% code của chính Claude Code. Vậy làm sao review code ở đúng khối lượng team tạo ra? Còn ai đọc code nữa không? Và nếu có gì hỏng, ai sẽ bắt được? Bài viết kể lại quy trình code review của team Claude Code và cách nó thay đổi theo thời gian (theo bài viết, đăng ngày 15/10/2026).

Con số đầu tiên: từ tháng 6 tới tháng 9, số pull request được merge vào codebase Claude Code tăng hơn gấp đôi, trong khi tỉ lệ PR phải revert giảm hơn 40% (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

John nói kiểu số liệu tổng quan này, khối lượng code tăng gấp đôi, tăng vọt theo cấp số nhân, là một pattern anh thấy ở tất cả bạn bè của mình và ở khắp nơi: gần như mọi kỹ sư anh nói chuyện đều kể rằng khối lượng code đang vượt khỏi tầm kiểm soát. Một điểm quan trọng khác là tỉ lệ revert: những đoạn code do AI viết và được review rồi land tự động có đang bị revert ở mức đáng báo động không? Theo John, tỉ lệ đó cũng đang giảm khi các model ngày càng tốt lên (nhận định của John, video đăng ngày 01/11/2026).

Bài viết tiếp: team không bỏ review, nhưng đã chuyển phần lớn việc đọc code sang máy, tối ưu cho thời gian và sự chú ý của con người, và đầu tư mạnh để việc sửa sai trở nên nhanh và dễ (theo bài viết đăng ngày 15/10/2026).

Phần "Rethinking the purpose of code review" mở bằng nhận xét: khi agent viết code, số thay đổi tăng rất nhanh. Trong monorepo của Anthropic, số thay đổi được land mỗi ngày tăng từ khoảng 2.500 vào tháng 5 lên hơn 30.000 vào tháng 9 năm nay (theo bài viết đăng ngày 15/10/2026). John nói những con số đó thật sự điên rồ khi nghĩ tới, và đây là cảm nhận rất phổ biến ở những công ty công nghệ hàng đầu mà anh có bạn làm việc (video đăng ngày 01/11/2026).

Anh thêm một lưu ý mà anh thấy rất thú vị: dù khối lượng code tăng, số quyết định sản phẩm và tính năng sản phẩm được ship lại không tăng nhanh như khối lượng code. Điều đó, với John, cho thấy mọi người đang viết nhiều test hơn rất nhiều và làm nhiều việc engineering tốt hơn mà trước đây người ta hay bỏ qua, vì những việc đó thật ra rất dễ land và không cần thống nhất với ai (nhận định của John, video đăng ngày 01/11/2026). Trên đồ hoạ đi kèm có nhãn "MY READ · ILLUSTRATIVE, NO DATA", với đường "CODE VOLUME" đi lên tách xa đường "PRODUCT FEATURES SHIPPED", khoảng cách giữa hai đường ghi là "THE GAP".

3. Hai việc của code review và review chạy liên tục

Bài viết ghi tiếp: Claude Code nằm trong một repository riêng, tách khỏi monorepo, nhưng cũng đang chịu nhiều áp lực. Khi ship nhanh như vậy, review thủ công từng dòng một là cực kỳ khó, nếu không nói là không thể (theo bài viết đăng ngày 15/10/2026).

Theo bài viết, code review làm hai việc: tìm và sửa lỗi trước khi ship, và xây dựng context chung, sự hiểu biết về codebase trong cả team (đăng ngày 15/10/2026). John nói anh chắc chắn đồng ý, đặc biệt là với ý thứ hai. Theo anh, việc thứ hai giờ đã hoàn toàn agentic, AI làm trọn: bất kỳ ai cũng có thể lặn vào bất kỳ codebase nào ngay lập tức, và thành thật mà nói, chỉ review một đống diff sẽ không còn cho bạn hiểu biết tốt nhất nữa. Đó là ý kiến của anh: review diff không còn là cách tốt nhất để hiểu code (nhận định của John, video đăng ngày 01/11/2026).

Bài viết chủ yếu nói về việc tìm và sửa lỗi, và sẽ quay lại việc thứ hai ở gần cuối. Team cho rằng câu hỏi "đã có người đọc code chưa?" là một thước đo gián tiếp không chính xác cho câu hỏi thật: "thay đổi này có thể làm hỏng gì, và check nào, tự động hay con người, là check đúng để bắt được nó?" (theo bài viết đăng ngày 15/10/2026).

Đặt câu hỏi đó cũng làm thay đổi thời điểm review. Trước đây, review là một cái cổng ở cuối đường: viết code, mở PR, chờ đồng nghiệp. Giờ review chạy liên tục, giống spell check khi bạn đang gõ. Phần lớn thay đổi đã được Claude review và sửa ít nhất một lần trước khi có người được nhờ xem. Việc này bắt được phần lớn lỗi thường gặp và để dành sự chú ý của team cho những câu hỏi ở tầm cao hơn và việc soi kỹ hơn (theo bài viết đăng ngày 15/10/2026).

John cho rằng ý Claude Code tự review trước cả khi bạn push code là một ý khá hay, và nhiều người thật ra đã tạo hook, lifecycle hook: trước khi PR được submit, hook đó kiểm tra xem Claude đã chạy review hay chưa (nhận định của John, video đăng ngày 01/11/2026).

Nhưng theo anh, rốt cuộc tất cả đều là đánh đổi, tuỳ bạn muốn land code nhanh tới đâu và muốn an toàn tới đâu. Ví dụ, nếu bạn có một hook quá gắt, chặn không cho bạn submit PR, thì theo anh đó không phải hook tốt, vì nó sẽ cản bạn chạy những goal dài, chẳng hạn vậy. John nói anh hay nhắc tới ý gỡ bỏ chướng ngại bằng cách cho AI thêm quyền tự chủ và thêm tool, để con người ngày càng ít đứng trong vòng lặp hơn và đứng ở tầng cao hơn của chu trình phát triển (nhận định của John, video đăng ngày 01/11/2026).

Anh hoàn toàn đồng ý rằng Claude luôn làm review. Mỗi khi anh submit một PR để review, anh đã chạy adversarial review với nhiều agent khác nhau, vì rốt cuộc chúng hay bất đồng với nhau (theo John, video đăng ngày 01/11/2026).

4. Tài nguyên khan hiếm: thời gian và sự chú ý của con người

Phần tiếp theo của bài viết có tiêu đề "The scarce resource: human time and attention", và John nói ngay anh đồng ý. Bài viết ghi: team muốn giữ thời gian và sự chú ý của con người cho những vấn đề chỉ con người giải được, và để các automated check bắt phần còn lại. Với tốc độ thay đổi hiện tại, vẫn còn một khối lượng việc khổng lồ cho con người, và team gặp những thách thức mới gần như mỗi ngày (theo bài viết đăng ngày 15/10/2026).

John nói anh hoàn toàn đồng ý điều này. Anh biết nhiều người đang rất lo, và có người nói đùa rằng "nếu coding đã được giải quyết thì con người còn làm gì". Theo trải nghiệm riêng của anh, anh bận hơn bao giờ hết từ khi có AI. Một phần vì có quá nhiều thứ anh có thể tự làm một mình, và có quá nhiều code được tạo ra mà anh vẫn muốn review (theo John, video đăng ngày 01/11/2026).

Một trong những "arbitrage" lớn anh đang nghĩ tới lúc này là làm sao uỷ thác, làm sao mua lại sự chú ý cho chính mình, thậm chí thuê người làm một phần việc steering thay anh, dù là dựng video hay làm một side project. Anh muốn xây một cách để đẩy bớt những quyết định ở tầng thấp ra khỏi đầu mình (theo John, video đăng ngày 01/11/2026).

Bài viết giải thích: thời gian con người nằm ở cả hai phía của chi phí review, là thời gian người ta bỏ ra để review, và thời gian người ta bỏ ra để sửa những gì code tệ làm hỏng. Cắt phía thứ nhất chẳng giúp gì nếu thời gian đó chỉ hiện ra ở phía thứ hai. Vì vậy mục tiêu là phần lớn pull request trong các repo Claude Code (CLI, desktop, web app và mobile app) được merge với tối đa một người trong vòng lặp, và người đó có thể chính là tác giả, mà không làm tăng revert hay incident (theo bài viết đăng ngày 15/10/2026).

Để đo thời gian con người, team theo dõi số human approval trên mỗi PR (bài viết ghi median và P95), số comment của con người, và thời gian một PR phải chờ một người. Tỉ lệ revert và incident là guardrail: nếu chúng tăng, team chưa tiết kiệm được thời gian con người, mà chỉ chuyển nó đi chỗ khác (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

John nói anh thật sự thích việc bài viết đưa vào những metric tổng quan như vậy; theo anh, đây chắc chắn là kiểu metric bạn nên liên tục theo dõi. Anh muốn thêm rằng còn những metric tổng quan khác mà có lẽ bài sẽ nói tới sau: tỉ lệ revert, các SEV, và những vấn đề hiệu năng gây tốn thêm thời gian. Đó về bản chất là chuyển thời gian từ chỗ không bắt được lỗi sang về sau (nhận định của John, video đăng ngày 01/11/2026). Trên phiên bản tiếp theo của đồ hoạ, một thẻ "SEVs" được thêm vào cạnh khung Guardrail, cùng một ô trống có dấu cộng.

5. Vòng đời của một thay đổi

Phần "The life of a change": một thay đổi điển hình, từ laptop của một kỹ sư hoặc một Claude session trong Slack, đi qua nhiều layer code review (theo bài viết đăng ngày 15/10/2026). John chen vào: cái Claude session trong Slack này cực kỳ hay. Trên màn hình lúc đó là một kênh Slack "#product-team" với một tin báo bug, và trong thread bên cạnh có người tag Claude để nhờ điều tra; Claude trả lời bằng bản tóm tắt các thay đổi và nút "View Claude Code session" cùng "Create PR" (demo trong video đăng ngày 01/11/2026).

Rồi anh mở hình PNG trong bài, sơ đồ vòng đời của một thay đổi. Anh đọc từng bước (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026):

• Trước pull request, công việc được verify: Claude chạy test, build và linter; một agent thứ hai review diff trong một context mới (theo bài viết, video đăng ngày 01/11/2026).
• Trên mọi pull request có CI bắt buộc: lint, type, test trên nhiều nền tảng, build và đóng gói; đỏ là chặn merge (theo bài viết, video đăng ngày 01/11/2026).
• Claude code review: các agent săn bug song song, các verifier bỏ phiếu cho từng finding, những finding còn lại được xếp theo mức nghiêm trọng (theo bài viết, video đăng ngày 01/11/2026).
• Security review: một lượt riêng; finding còn mở từ bất kỳ review nào trong hai review đều chặn merge (theo bài viết, video đăng ngày 01/11/2026).
• Risk-based approval: một classifier đặt tier, không cần người, một người, hoặc hai người; có những path luôn cần một người (theo bài viết, video đăng ngày 01/11/2026).

Về agent thứ hai review diff trong context mới, John nói đây là phần cực kỳ quan trọng, chính là phần adversarial agent. Nếu bạn không hiểu context window hoạt động thế nào, và context window có thể khiến agent của bạn về cơ bản "gian lận bài tập về nhà" ra sao, thì đó là lý do bạn cần một agent thứ hai chuyên hơn cho việc review (nhận định của John, video đăng ngày 01/11/2026).

Về bước Claude code review, anh đoán nhiều khả năng đây là nhiều agent chuyên về các vai khác nhau, như security, performance, UI, hình ảnh, v.v. (suy đoán của John, video đăng ngày 01/11/2026). Còn với security review, anh nói hoá ra team thật sự có một bước check security riêng, và điều đó hợp lý: security là một trong những phần khó nhất và quan trọng nhất của tất cả những thứ này (nhận định của John, video đăng ngày 01/11/2026).

6. Classifier, cây codebase và những gì xảy ra sau merge

Ở bước risk-based approval (một classifier đặt tier, không người, một hay hai người, có path luôn cần người), John nói cách này rất giống cách OpenAI làm: về cơ bản có một classifier quyết định (so sánh của John, video đăng ngày 01/11/2026). Nếu muốn biết classifier là gì, anh gợi ý tìm hiểu Jev. Theo John, Jev là một model về bản chất là model classifier, hay Decisions API của OpenAI, về cơ bản là cùng một thứ: nó không viết ra chữ nào mà chỉ đưa ra quyết định, và quyết định đó không chỉ là có hay không mà luôn dựa trên phần trăm, và bạn có thể đặt một schema theo cách lập trình cho thứ bạn muốn (theo John, video đăng ngày 01/11/2026).

Theo cách John hiểu, tuỳ code đó chạm vào path nào, ví dụ một thứ trong hạ tầng, nó sẽ tự động bị đánh trượt. Anh nói đây cùng một ý với khái niệm cái cây của anh: thay đổi càng nằm gần thân cây thì có lẽ càng rủi ro, và càng ít kết nối, giống một node lá, thì càng dễ và có lẽ ổn để auto merge (nhận định của John, video đăng ngày 01/11/2026). Trên màn hình là một bản phác về một codebase như một cái cây: "I think of the codebase like a tree", với App.jsx là "root coordinator", gameReducer.js là "trunk state", "API and shared game rules", và "Presentational components · leaves".

Tiếp theo trong sơ đồ: merge queue, nơi các check chạy lại trên main mới nhất với thay đổi được áp vào. Sau merge, thay đổi nằm sau một flag và được dùng nội bộ trước: nhân viên Anthropic chạy nó trước khi nó tới tay mọi người (theo bài viết đăng ngày 15/10/2026). John nói đây là việc rất phổ biến, một quy trình dogfooding.

Gradual release: kênh latest nhận trước, kênh stable đi sau (theo bài viết đăng ngày 15/10/2026). John so sánh với canary deployment, rất rất giống. Bước cuối: watch, fix forward hoặc roll back. Tác giả và người on-call theo dõi; flag được tắt nhanh, build hỏng được revert (theo bài viết đăng ngày 15/10/2026).

Nhìn cả quy trình, John nói bạn sẽ hiểu vì sao CI pipeline dạo này đang chật vật. Theo anh, nhiều hạ tầng như GitHub và các tool CI vốn không được thiết kế để mở rộng vượt quá khối lượng code trung bình mà con người viết được; ai mà ngờ được mức tăng 10 lần chỉ trong vài tháng, và đó là lý do nhiều người đang phàn nàn về GitHub và những thứ tương tự (nhận định của John, video đăng ngày 01/11/2026). Trên màn hình lúc này là một trang "GITHUB STATUS · INCIDENT HISTORY" của tháng 10/2026 với nhiều mục như "Incident with Dependabot", "Incident with Actions, Pages, and Webhooks", "Disruption with GitHub services".

Sau đó là sơ đồ "Layer by layer", mà John gọi là một sơ đồ nhỏ rất hay, trực quan hoá các layer: verification, required CI, AI review, security review, human in the loop, merge queue và flag. Mỗi layer bắt được một số vấn đề và bỏ lọt những vấn đề khác; rất ít vấn đề lọt qua được tất cả, và rollback xử lý phần còn lại (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

7. Layer 1: công việc được verify trước khi ai khác nhìn

Layer số một: công việc được verify trước khi bất kỳ ai khác nhìn vào. Phần lớn việc review giờ diễn ra trước khi PR tồn tại. Team đưa cho Claude một thứ nó có thể chạy được, như test, một bản build, hay một screenshot để so với thiết kế, và yêu cầu nó cho xem output thay vì chỉ nói là đã xong. Sau đó một sub-agent review diff với context mới. Cả hai thói quen này đều đến từ hướng dẫn best practices của team (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

John muốn thêm một ghi chú. Nhiều người hỏi anh: làm sao biết agent làm đúng, làm sao biết agent không chỉ đang hallucinate? Điều anh luôn làm là yêu cầu bằng chứng của công việc và mức độ tự tin về công việc đó, rồi yêu cầu nó trực quan hoá, chẳng hạn trong một bảng, để anh dễ nhìn (theo John, video đăng ngày 01/11/2026).

Với anh, cách này rất hữu ích: nếu AI quay lại với "đây là điều tôi nghĩ" và mức tự tin chỉ khoảng 80%, thì bạn sẽ bảo "không, đào sâu thêm chút nữa và xem mình có thật sự đúng không". Theo John, đây chắc chắn là điều bạn nên đưa vào workflow của mình (lời khuyên của John, video đăng ngày 01/11/2026).

Bài viết tiếp: trước khi mở PR, nhiều người trong team còn chạy vài internal skill: một skill săn bug, một skill đơn giản hoá diff, và một skill kiểm tra hành vi end-to-end. Thay đổi UI còn được đối chiếu với design guideline của team (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

8. Boris Cherny về verification, và những domain khó verify

Bài viết trích Boris Cherny, người tạo ra Claude Code: ông từng gọi việc cho Claude một cách để verify công việc của nó là có lẽ điều quan trọng nhất để có kết quả tốt (theo bài viết đăng ngày 15/10/2026). John nói anh hoàn toàn đồng ý: theo anh, agentic validation là bước quan trọng nhất, và là thứ thật sự giúp các goal chạy được ngay từ đầu (nhận định của John, video đăng ngày 01/11/2026).

Theo bài viết, Boris ước tính việc này làm kết quả cuối tốt hơn hai tới ba lần, và ông viết: "Verification looks different for each domain. It might be as simple as running a bash command, or running a test suite, or testing the app in a browser or phone simulator." (trích trong bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

Tới đây John dừng lại để nói rằng câu này thật sự thú vị, vì anh hoàn toàn đồng ý: có những thứ đơn giản là khó verify xem nó có đúng hay không. Ví dụ, video game cũng là thứ code được, và nhiều game rất thành công thường có một game khác đã làm điều tương tự, vì có thứ để tham chiếu và verify. Nhưng nếu bạn đang tạo một cơ chế game hoàn toàn mới, thì làm sao bạn hỏi được "nó có vui không"? Đó là một kiểu validation rất khó (nhận định của John, video đăng ngày 01/11/2026).

Vì vậy, theo anh, những domain khó hơn và sẽ được "giải quyết" (anh nói trong ngoặc kép) lâu hơn, muộn hơn về sau, chính là những domain có bài toán validation khó hơn, hay tiêu chí validation khó hơn (nhận định của John, video đăng ngày 01/11/2026).

9. CLAUDE.md và REVIEW.md

Bài viết tiếp: khi automated reviewer cứ flag đi flag lại cùng một thứ, team sửa nó tận gốc: trong skill, bằng một lint rule, hoặc bằng cách cập nhật các file hướng dẫn (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

CLAUDE.md cho Claude biết project là gì: stack, các quy ước, mục tiêu và những thứ không phải mục tiêu. Mọi lần review đều nạp nó, nên trong một codebase lớn team giữ nó ngắn và trỏ sang các tài liệu khác từ đó. Reviewer cũng flag những đoạn code phá quy ước trong file đó, và những thay đổi khiến một dòng trong file bị lỗi thời (theo bài viết đăng ngày 15/10/2026).

REVIEW.md do code owner viết, cho reviewer biết điều gì quan trọng trong phần code của họ. Team kiểm tra riêng xem reviewer có thật sự làm theo nó không. Những file tốt thì ngắn. Chúng nói thất bại trông như thế nào trong repo đó: với docs là "it lies", với config là "it misroutes"; chúng giới hạn số nit, liệt kê những path cần bỏ qua, và yêu cầu dẫn file và dòng làm bằng chứng thay vì đoán từ một cái tên. Chúng cũng yêu cầu một bản tóm tắt mở đầu bằng một con số đếm và nói thẳng khi không có gì để sửa (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

John nói với REVIEW.md, Codex cũng có một pattern tương tự, nơi bạn chỉ định cho agent của Codex cách review như vậy (so sánh của John, video đăng ngày 01/11/2026). Theo anh, có một REVIEW.md là hợp lý, và nó nên khác nhau tuỳ domain của codebase và tuỳ cách team bạn thích review code.

Với project cá nhân, thành thật mà nói anh không nghĩ bạn cần cái này. Nhưng nếu project lớn lên và bạn cần làm việc với người khác, anh nghĩ chắc chắn nên có nó (nhận định của John, video đăng ngày 01/11/2026).

10. Layer 2: AI review trên mọi pull request

Layer số hai: AI review trên mọi pull request. Mọi pull request đều được Claude review trước khi có người nhìn. Nó đọc diff đối chiếu với toàn bộ repo và ý định mà PR nêu ra, rồi hỏi: thay đổi này có giải quyết đúng vấn đề, có hợp với hệ thống, hay có làm hỏng thứ khác không? Với một bug fix, nó tìm nguyên nhân gốc (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

Bản public, Code Review for Claude Code, giờ đã generally available trên các gói Team và Enterprise, và lệnh /code-review chạy một bản nhẹ hơn ở local (theo bài viết đăng ngày 15/10/2026; trang tài liệu Code Review ghi "For Team and Enterprise plans", đọc ngày 01/11/2026). John nói hơi khó chịu là tính năng này không có cho các gói không phải team, nhưng anh đoán cũng hợp lý: nếu bạn code một mình và không làm PR thì cần gì một PR code review (nhận định của John, video đăng ngày 01/11/2026).

Khi ra mắt bản research preview, tỉ lệ PR nội bộ nhận được comment review có thực chất tăng từ 16% lên 54%. Phần lớn PR trên 1.000 dòng có finding, còn phần lớn PR nhỏ quay về sạch. Admin đặt mỗi repo ở mức Quick, Standard hoặc Deep; Deep đáng dùng ở những nơi một bug bị bỏ sót tốn kém hơn thời gian review thêm (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

John nói một PR 1.000 dòng nghe đã khá tệ rồi. Anh hiểu rằng nhiều code AI viết đang ngày càng lớn, nhưng một pro tip của anh là bạn nên có vài review skill chia nhỏ diff ra. Anh vẫn nghĩ PR chủ yếu là artifact để con người xem lại về sau, nên chắc chắn đáng để chia nhỏ (lời khuyên của John, video đăng ngày 01/11/2026). Anh có thể đổi ý nếu code review được giải quyết 100%, nhưng cho tới lúc đó, anh nghĩ PR dễ đọc vẫn rất quan trọng, ít nhất để bạn có thể đào lại và xem lại lịch sử mọi thứ đã diễn ra thế nào.

Bài viết tiếp: finding được các agent khác verify trước khi con người review. Nhiều agent tìm bug cùng lúc, rồi một nhóm riêng bỏ phiếu cho từng finding, và finding chỉ được đăng nếu đủ số agent đồng ý rằng nó có thật (bài viết ghi "enough of them agree", còn John đọc thành "one of them agree"). Những finding chỉ về style, diagnostics hay dọn dẹp bị loại (theo bài viết đăng ngày 15/10/2026, video đăng ngày 01/11/2026).

John nói đây chắc chắn là điều tốt: nit cần phải bị loại (nhận định của John, video đăng ngày 01/11/2026). Bài viết ghi team đã A/B test các bộ lọc đó trên chính PR của mình trước khi giữ lại. Những gì còn lại hiện ra dưới dạng inline comment xếp theo mức nghiêm trọng, mỗi comment được gắn nhãn Important, Nit hoặc Pre-existing, để một bug không do PR này tạo ra không trông như lỗi của tác giả (theo bài viết đăng ngày 15/10/2026).

John thấy phần cuối này thật sự thú vị và cũng hợp lý. Anh vẫn nghĩ PR là artifact của con người; nếu mục tiêu chỉ là land code thì những thứ như vậy sẽ không quan trọng (nhận định của John, video đăng ngày 01/11/2026).

Mọi finding đều phải được trả lời: hoặc bạn sửa, hoặc resolve thread kèm lý do. Thường thì một agent nhận việc sửa qua đêm, nên tác giả quay lại với một PR đã qua thêm một vòng (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

11. Layer 3 và 4: security review và automated checks có quyền chặn

Layer số ba: security review có thể chặn. Security cũng có automated review riêng. Bài viết ghi một PR không merge được ("can't merge") khi bất kỳ finding nào từ bug review hay security review còn mở; John đọc câu này thành "can merge". Bạn hoặc sửa, hoặc đóng thread với một lý do ngắn, và đó là cách xử lý một false positive. Nếu một commit sau đó sửa được vấn đề, finding tự được clear (theo bài viết đăng ngày 15/10/2026, video đăng ngày 01/11/2026).

Bài viết ghi bạn có thể dựng điều tương tự bằng GitHub Action security review open source hoặc lệnh /security-review; phần cài đặt nằm trong trang "Automated security reviews in Claude Code" (theo bài viết đăng ngày 15/10/2026, video đăng ngày 01/11/2026). Trên màn hình là trang hỗ trợ đó của Claude, với dòng giới thiệu về lệnh /security-review và GitHub Actions.

John nói thật hay khi team đưa nó ra cho ai cần. Và vì đó là một skill, theo anh bạn có lẽ có thể sửa nó, đổi theo cách bạn muốn, hoặc hỏi xem nó là gì rồi clone và làm phiên bản của riêng mình. Nhưng anh hoàn toàn đồng ý rằng security review nên là một bước riêng; anh nghĩ nó quan trọng tới mức đó (nhận định của John, video đăng ngày 01/11/2026).

Layer số bốn: automated check có quyền chặn. Những thứ quen thuộc: lint, type check, test trên mọi nền tảng, và build. Team đã viết riêng về việc mở rộng CI cho khối lượng này. Một pull request điển hình của CLI có thể chạy hàng chục check trước khi có người nhìn vào. PR template hỏi thay đổi được test thế nào và làm sao để undo nó. Claude có thể điền phần đó, nhưng người yêu cầu thay đổi là người ký xác nhận (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026). Đồ hoạ đi kèm cho thấy một PR template với hai câu hỏi "How was it tested?" và "How do we undo it?", và ô "WHO ASKED" có chữ ký, nhãn "Signed off".

John nói dù team đã tự động hoá nhiều như vậy, điều anh rút ra tới giờ là vẫn còn một loạt việc con người phải làm. Agent đang giúp, nhưng có một loạt bước quan trọng mà con người thật sự phải đọc output, dành thời gian đọc output, rồi đóng dấu duyệt hoặc steer nó (nhận định của John, video đăng ngày 01/11/2026).

Đó cũng là trải nghiệm của anh ở chỗ làm: anh dành ngày càng nhiều thời gian đọc code. Anh nghĩ dạo này anh đọc nhiều hơn bất cứ lúc nào trong đời: đọc câu trả lời của agent nhiều hơn cả viết prompt, đọc code review, đọc tin nhắn Slack và những thứ tương tự, đọc không ngừng. Anh nói thêm: học tiếng Anh cho thật giỏi, anh đoán đó là điểm mấu chốt (theo John, video đăng ngày 01/11/2026).

12. Layer 5: human approval theo mức rủi ro

Layer số năm: human approval, chia theo rủi ro. Một bản sửa docs và một thay đổi ở auto-updater mang rủi ro khác nhau nên được review khác nhau (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026). John đọc bảng ba mức:

• Thấp (Low): docs, copy, tính năng chỉ dùng nội bộ, thay đổi bổ sung nằm sau flag; không cần human approval (bài viết ghi thêm: khi automated review và security check đều xanh). John nói đây giống khái niệm node lá của anh (theo bài viết, video đăng ngày 01/11/2026).
• Trung bình (Medium): thay đổi sản phẩm thông thường, và thay đổi ở các vùng nhạy cảm như caching, auto-updater hay system prompt; cần một người (theo bài viết, video đăng ngày 01/11/2026).
• Cao (High): code rủi ro cao nhất, cộng với một nhóm nhỏ path luôn cần hai người (theo bài viết, video đăng ngày 01/11/2026).

Ở mức trung bình, John thắc mắc: "một người" ở đây là chính bạn hay một ai khác? Anh nói chỗ này không rõ lắm (video đăng ngày 01/11/2026). Với mức cao cần hai người, anh nói đây là một khái niệm thật sự thú vị, nhưng anh không chắc nó có thật sự cần thiết. Ý tổng quan là bạn tin mọi người và mỗi người đều nên có thẩm quyền. Nhưng với khối lượng code lớn như vậy, anh nghĩ có hai người là hợp lý, để người ta không chỉ đóng dấu cho qua (nhận định của John, video đăng ngày 01/11/2026).

Tuy vậy, theo anh, một giải pháp tốt hơn là có các chuyên gia theo codebase: chính codebase biết path file nào có những người được coi là chuyên gia trong domain đó. Anh nghĩ đó có lẽ là cách dễ mở rộng hơn so với để hai người cùng đóng dấu một thứ (nhận định của John, video đăng ngày 01/11/2026).

Bài viết tiếp: thay đổi quyết định tier, không phải tác giả. Một classifier đọc thay đổi và chọn tier rủi ro. Một classifier thứ hai hỏi xem riêng thay đổi này có cần thêm một người không, kể cả khi tier của nó nói là không. Có những path luôn cần một người: bất cứ thứ gì owner đã liệt kê là nhạy cảm, và mọi file CI workflow (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

John nói trước khi Jev được công bố, anh sẽ nghĩ tới việc dùng chính Claude Code để đưa ra những quyết định này. Nhưng anh nghĩ dùng classifier là một lựa chọn rất đúng, vì nó rẻ và rất nhanh (nhận định của John, video đăng ngày 01/11/2026). Đồ hoạ lúc đó so sánh hai cách: một khối "Claude Code" đang suy nghĩ với đồng hồ và nhãn "$$$", và "A CLASSIFIER" trả về "Medium" với đồng hồ và một ký hiệu xu.

Chỉ tác giả có tên trong danh sách tin cậy của repo mới được đi đường nhẹ hơn, phần lớn là team sở hữu repo đó; mọi người khác cần thêm một người thứ hai duyệt (theo bài viết đăng ngày 15/10/2026). John nói giờ thì anh hiểu vì sao có chuyện duyệt thêm người thứ hai này.

Approval của một agent cũng không bao giờ được tính như approval của một người. Automated reviewer có thể cho qua một thay đổi rủi ro thấp, nhưng không thể lấp một suất cần con người. Ai prompt ra thay đổi thì người đó chịu trách nhiệm. 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 reviewer bắt buộc, y như khi họ tự gõ code (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

Một approval chỉ áp cho một commit cụ thể. Nếu có commit mới mà hệ thống không bảo đảm được, như một lần push của agent hay một lần merge mà ai đó resolve bằng tay, approval phải được đưa lại (theo bài viết đăng ngày 15/10/2026, video đăng ngày 01/11/2026). Đồ hoạ lúc này cho thấy một PR "agent-written" ở file billing/refund.ts trên làn "HIGH RISK" cần "2 people", với nhãn "you, directing" và "1 of 2".

13. Điểm nghẽn sự chú ý, và Layer 6: merge queue, flag, release từng bước

John tóm lại: rất nhiều approval, rất nhiều review. Và thành thật mà nói, theo anh đây chính là "arbitrage" lớn, dù bạn làm trong lĩnh vực nào. Anh thật sự nghĩ việc giải điểm nghẽn sự chú ý này, và hiểu AI dễ hỏng ở đâu, là chìa khoá (nhận định của John, video đăng ngày 01/11/2026).

Nếu bạn trả lời được những câu hỏi đó cho domain cụ thể của mình, dù là điều hành một doanh nghiệp content hay một doanh nghiệp khác, nếu bạn tìm ra một hệ thống dùng AI cho những việc dễ và chỉ cần con người duyệt ở đúng những chỗ then chốt, thì theo John đó là lúc bạn có được năng suất thật (nhận định của John, video đăng ngày 01/11/2026). Đồ hoạ đi kèm vẽ "AI OUTPUT" như một dòng chấm sáng chảy vào một điểm "HUMAN ATTENTION", rồi một chuỗi Idea, Script, Record, Edit cho "Content business" và Lead, Quote, Build, Ship, Support cho "Any business".

Layer số sáu: merge queue, flag và release từng bước. Merge queue chạy lại mọi check trên main với thay đổi được áp vào, nên hai PR pass riêng rẽ không thể kết hợp thành một main bị hỏng. Hành vi mới thường được ship sau một flag cho nhân viên Anthropic trước, và việc team dùng nhiều thường làm lộ regression trước khi người dùng gặp. Bản release công khai vào kênh latest trước, kênh stable đi sau (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

John nói một điều hấp dẫn ở riêng sản phẩm này, Claude Code ở Anthropic, là anh cá rằng mọi người ở Anthropic đều dùng Claude Code mỗi ngày, và dùng rất mạnh; ai cũng là power user. Nên việc dogfooding nội bộ này có lẽ là một trong những kiểu dogfooding mạnh nhất mà bạn có thể có (nhận định của John, video đăng ngày 01/11/2026). Anh chắc Codex cũng tương tự.

Anh lấy ví dụ: ở các công ty khác, chẳng hạn bạn làm ở Linear, bạn có lẽ dùng Linear để quản lý task, nhưng có lẽ bạn dành nhiều thời gian cho Claude Code hay Codex hơn. Nên theo anh, thật thú vị khi tool nội bộ của Anthropic cũng chính là tool bán ra ngoài, và anh nghĩ điều đó rất thông minh (nhận định của John, video đăng ngày 01/11/2026). Đồ hoạ lúc đó có nhãn "MY TAKE · EVERY PERSON, EVERY DAY": một cửa sổ terminal tên "Chat Storage", trong đó agent đang "Thinking…", chia yêu cầu thêm chat history và nút "New Chat" thành năm bước, rồi bắt đầu đọc file components/LeftSidebar.tsx.

14. Layer 7: phát hiện nhanh, rollback nhanh

Layer số bảy: phát hiện nhanh, rollback nhanh. Một số lỗi vẫn sẽ lọt qua, nên layer cuối là để bắt chúng thật nhanh. Flag tắt được mà không cần deploy. Claude Code có lịch on-call xoay vòng hằng tuần, và các buổi incident review hỏi layer nào lẽ ra phải bắt được vấn đề (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

Việc phát hiện một lần merge tệ vẫn phụ thuộc vào tác giả và người on-call, cũng như các dashboard revert và incident. Team chưa có những circuit breaker tự siết approval khi các con số đó biến động; kỹ sư ở đây muốn có chúng trước khi thêm nhiều code chuyển sang merge không cần người (theo bài viết đăng ngày 15/10/2026, video đăng ngày 01/11/2026). Trên đồ hoạ đi kèm có ô "CIRCUIT B" với nhãn "NOT YET".

Một đồng nghiệp trong team nói rằng đi chậm lại đúng là làm giảm tỉ lệ lỗi, nhưng chủ yếu là vì bạn làm ít đi mọi thứ. Team thà nhanh hơn trong việc nhận ra và sửa vấn đề (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

John nói đây là một điểm thật sự thú vị: tỉ lệ lỗi phụ thuộc rất nhiều vào mẫu số, và mẫu số là lượng việc bạn làm. Trò chơi bạn nên chơi là làm nhiều việc hơn trong khi giữ tỉ lệ lỗi như cũ hoặc thậm chí thấp hơn. Theo anh, đó là thách thức thật sự lúc này với AI coding, và mọi thứ bạn làm với AI nói chung đều nên gắn với điều đó (nhận định của John, video đăng ngày 01/11/2026).

Anh nói thêm về khái niệm "token maxing", thứ mà theo anh bạn nên nghĩ tới. Nếu coi token là đầu vào, thì sự chú ý của bạn được biến thành token qua những prompt bạn đưa ra: đó là token vào. Và nếu đầu ra cao hơn hẳn với cùng một lượng chú ý, đó là nhờ các harness bạn xây bên trong và tất cả những check khác nhau như thế này (nhận định của John, video đăng ngày 01/11/2026).

Ở đây đang nói về review, nhưng theo John, bạn có thể thấy cả luồng việc review này là một harness cho agent, và nó thật ra chỉ làm nổi bật những điểm bạn cần bước vào để sửa và steer cho đúng. Nên nếu bạn thật sự muốn tiến xa trong project, công ty hay bất cứ việc gì, anh nghĩ tìm ra những hệ thống cốt lõi như thế này và xây các harness cho agent chính là đòn bẩy thật (nhận định của John, video đăng ngày 01/11/2026).

15. Làm reviewer tốt hơn: incident thành eval, đo noise, review phải hội tụ

Phần "How we make the reviewer better": quy trình code review của team liên tục được cải thiện trong một vòng lặp. Mọi incident giờ đều thành eval. Team gom các PR trong quá khứ từng gây incident, cùng với các bản fix-forward và revert của chúng, rồi nhờ những kỹ sư hiểu đoạn code đó xác nhận từng bug và vị trí của nó. Reviewer chạy trên bộ đó mỗi ngày (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

John gọi đây là "thiên tài thuần tuý": là một công ty làm machine learning, dùng chính nhân viên của mình làm eval là rất thông minh. "Our incidents are the evals." Anh thấy khá điên rồ khi có một bộ eval chạy mỗi ngày gắt như vậy, và theo anh kiểu workflow này có thể áp dụng cho nhiều thứ khác, không chỉ review (nhận định của John, video đăng ngày 01/11/2026).

Bài viết tiếp: team đo noise bằng cách xem người ta làm gì với các comment. Bắt được nhiều bug hơn là dễ nếu bạn không ngại flag cả đống thứ không phải bug, nên cần một check cho chuyện đó. Team phân loại mọi comment reviewer để lại theo cách người trên PR phản hồi: họ sửa, họ nói nó sai, họ nói hành vi đó là cố ý, hoặc họ quyết định nó không quan trọng. Team cũng chạy reviewer trên những PR đã biết là sạch, và đếm xem nó báo bao nhiêu lần một thứ có thể khiến ai đó tạo ra một thay đổi có hại (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

Ưu tiên được ghi thành văn bản của team là bắt bug thật trước, cắt bớt vòng review sau. Noise tốn kém hơn khi tác giả là agent: một người có thể gạt một nit đi trong vài giây, còn agent thì sửa nó, nghĩa là thêm một commit và thêm một vòng review (theo bài viết đăng ngày 15/10/2026). John nói đây là lý do những thứ như nit không còn tồn tại, vì nó quá đắt. Theo anh, cả quy trình này khá tốn kém cho mỗi PR, bạn có thể thấy có bao nhiêu lượt review đang diễn ra. Nếu bạn phàn nàn kiểu "file này phải viết ở trên kia", "tôi thích viết theo cách của tôi", thì theo John nit đúng là đã chết (nhận định của John, video đăng ngày 01/11/2026).

Review phải hội tụ. Một agent tác giả và một agent reviewer có thể làm nhau bận mãi không dứt. Một PR của CLI đã đi qua hơn 50 vòng review và sửa qua đêm trước khi tác giả của nó dừng lại. Khi team chạy git blame trên những gì reviewer cứ flag mãi, khoảng 59% là code đã có từ lượt review đầu tiên của reviewer. Reviewer hiếm khi tìm ra bug mới; nó chỉ tìm thêm vài bug cũ ở mỗi vòng (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026). John nói đây là một điểm thật sự thú vị.

Bài viết thừa nhận team tự làm nó tệ hơn: team đã quen chạy nhiều vòng theo mặc định, vì mỗi lượt lại bắt thêm được một thứ mới. Việc đó có thể đáng làm với một thay đổi rủi ro, nhưng không phải với mọi PR. Giờ team theo dõi "rounds to pass" song song với recall (theo bài viết đăng ngày 15/10/2026). John nói đây là một ý rất hay: "rounds to pass" là một metric thật sự thú vị mà anh chưa từng nghĩ tới, nhưng hoàn toàn hợp lý (nhận định của John, video đăng ngày 01/11/2026).

Các thay đổi team áp cho việc re-review (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026):

• Giới hạn số vòng: sau ba vòng, reviewer yêu cầu tác giả dừng lại, lùi một bước và cân nhắc lại cách tiếp cận (theo bài viết, video đăng ngày 01/11/2026).
• Sau vài lượt đầu, chỉ re-review phần diff; John nói cái này rất hay, chỉ xem lại phần thay đổi (theo bài viết, video đăng ngày 01/11/2026).
• Flag cả lớp bug, để tác giả sửa mọi chỗ, không chỉ một dòng; John nói cái này cũng hợp lý (theo bài viết, video đăng ngày 01/11/2026).
• Không lặp lại các finding đã đăng (theo bài viết, video đăng ngày 01/11/2026).

Các review agent cũng chạy hằng đêm trên code đang có, giúp team bắt bug cũ trước khi chúng hiện ra ở chỗ khác (theo bài viết đăng ngày 15/10/2026). John nói phần này là thứ anh nghĩ mình đã làm theo trực giác trước đây, nhưng chưa thật sự thấm. Anh mừng vì đọc được nó, và đây là thứ anh chắc chắn sẽ lấy về cho workflow của mình (theo John, video đăng ngày 01/11/2026).

16. Con người còn ở đâu trong vòng lặp

Phần "Where humans stay in the loop": kéo một senior engineer ra khỏi lúc đang tập trung sâu chỉ để bắt một lỗi thường gặp tốn kém hơn nhiều so với một automated review (theo bài viết đăng ngày 15/10/2026). Đồ hoạ đi kèm có tiêu đề "The interruption tax", với nhãn "Focus broken", "Missed null check" và bộ đếm "47:13" dưới chữ "SENIOR ENGINEER".

Theo bài viết, người trong team vẫn chịu trách nhiệm quyết định có nên build nó hay không: hướng đi, gu và phạm vi. Một team từng tuyên bố đã giải quyết xong điểm nghẽn review vẫn giữ human review cho những thay đổi đến từ bên ngoài team, để có người hỏi "chúng ta có nên làm việc này không?" (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

John nói chuyện quyết định build cái gì là một câu hỏi thật sự, thật sự quan trọng. Trong một thế giới AI nơi coding rẻ và build thứ mới cũng rẻ, anh nghĩ việc quyết định build gì còn quan trọng hơn. Vì nếu bạn có thể build 10 thứ khác nhau cùng lúc, prototype 10 thứ và chúng đều có vẻ ổn, thì vẫn còn rất nhiều việc phía sau, từ một prototype tới lúc thật sự ship, mà chưa thể làm hoàn toàn bằng agent (nhận định của John, video đăng ngày 01/11/2026).

Theo anh, đây là chỗ gu và agentic validation cực kỳ quan trọng: làm sao bạn biết trải nghiệm A hay trải nghiệm B đáng build, trước khi bạn có thể chạy một A/B test? Việc đó rất khó, nhưng không có nghĩa câu trả lời là chạy 10 A/B test, như vậy khá lãng phí (nhận định của John, video đăng ngày 01/11/2026).

Anh lấy Apple làm ví dụ: anh có cảm giác Apple không làm nhiều A/B test, đặc biệt với phần cứng. Họ cứ thế ra quyết định và làm ra một sản phẩm thật tốt; Apple rất giỏi ra quyết định theo cảm nhận dựa trên thử nghiệm nội bộ và những gì họ muốn làm. Và anh nghĩ đó là "cơ bắp" bạn cần rèn nhiều hơn nữa lúc này, vì AI giúp bạn làm ra đủ thứ linh tinh quá dễ (nhận định của John, video đăng ngày 01/11/2026). Trên màn hình lúc đó là vài cảnh một chiếc điện thoại.

Những việc con người vẫn giữ, theo bài viết (đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026):

• Review code rủi ro như billing, auto-updater, các CI workflow (theo bài viết, video đăng ngày 01/11/2026).
• Review kiến trúc đặt ra một pattern mà người khác sẽ sao chép (theo bài viết, video đăng ngày 01/11/2026).
• Đọc bằng chứng: output của test, lệnh đã chạy và kết quả nó trả về, một screenshot, các finding của reviewer. Nếu bạn không nói được các check sẽ bỏ sót gì, hãy yêu cầu một lượt review thật thay vì một approval nhanh (theo bài viết, video đăng ngày 01/11/2026).
• Chịu trách nhiệm về kết quả: một người chịu trách nhiệm cho mọi thay đổi được ship, bất kể ai gõ ra nó (theo bài viết, video đăng ngày 01/11/2026).

John nói anh hoàn toàn đồng ý với ý đọc bằng chứng. Còn ý chịu trách nhiệm về kết quả, theo anh, là điều lớn nhất. Một trong những điều anh rất ghét là câu "AI làm đấy, nên không phải lỗi của tôi". Bạn có thể nói AI đã giúp bạn làm tất cả những thứ này, và thành thật mà nói giờ đó là điều được mong đợi, nhưng nếu bạn là người ship nó, người đưa nó lên production, thì rốt cuộc đó là lỗi của bạn (nhận định của John, video đăng ngày 01/11/2026).

Theo anh, đó là lý do có bước review ban đầu ngay trước khi lên PR, rồi tất cả các check chạy và phần auto merge diễn ra. Nên hãy chịu trách nhiệm cho kết quả của mình (lời khuyên của John, video đăng ngày 01/11/2026).

17. Chia sẻ context, "You land it, you own it" và khi đổi hướng

Phần "Sharing context across the team": việc thứ hai của code review xưa nay là lan toả hiểu biết về codebase. Đọc diff của một đồng đội là cách bạn biết cái gì đã đổi và các mảnh ghép khớp với nhau thế nào (theo bài viết đăng ngày 15/10/2026). John nói ý kiến riêng của anh là giờ bạn nên tự làm những lần đào sâu để học các phần code khác, và đừng đóng góp code mà bạn không hiểu (lời khuyên của John, video đăng ngày 01/11/2026).

Bài viết ghi team không có quy trình chính thức cho việc này. Không ai trong team giữ trọn một mental model của Claude Code trong đầu (John chen vào: với hầu hết project, chuyện đó là bất khả thi), và team không nghĩ ai cần phải như vậy. Khi ai đó muốn hiểu một phần codebase, người đó nhờ Claude viết một explainer cho đúng lát cắt đó. Việc này mất vài phút và phản ánh code đúng như nó đang là hôm nay (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

Một số người trong team còn đi xa hơn: nhờ Claude dựng một artifact nhỏ trực quan hoá phần code đó và dạy nó theo đúng cách người đó thích học (theo bài viết đăng ngày 15/10/2026). John nói đây là một pro tip anh dùng suốt: anh nhờ nó trực quan hoá code và nó biến thành artifact. Theo anh, bạn thậm chí không cần artifact; bạn chỉ cần bảo "đưa nó cho tôi và trực quan hoá bằng ASCII" hay gì đó tương tự, sẽ nhanh hơn một chút (theo John, video đăng ngày 01/11/2026). Đồ hoạ lúc đó vẽ một artifact nhỏ với bốn khối sessions, resume, history, compact nối với nhau.

Theo bài viết, nếu mục tiêu là dùng sự chú ý của con người cho tốt, cách này tốt hơn việc đọc những diff vặt từng dòng một: một thay đổi copy một dòng gần như chẳng dạy bạn điều gì, còn một explainer cho module bạn sắp sửa dạy bạn nhiều hơn nhiều. Văn hoá mặc định làm việc trong các kênh Slack mở cũng giúp, vì bạn thấy người khác đang build gì ngay trong lúc họ build (theo bài viết đăng ngày 15/10/2026).

John nói anh chắc chắn sẽ lấy ý này. Công ty anh cũng làm kiểu này phần nào, và anh cũng làm một phần, nhưng anh nghĩ đây là một phiên bản cực đoan hơn, nơi bạn chủ động build một cách công khai: ít kênh nhỏ hơn, nhiều kênh lớn hơn, rồi Claude có thể truy cập toàn bộ context của domain đó. Anh nghĩ điều đó thật sự thông minh (nhận định của John, video đăng ngày 01/11/2026).

Phần "You land it, you own it": nếu bạn land một thay đổi nhỏ hoặc vừa mà vẫn có gì đó hỏng, thì theo quy ước của team, thường bạn là người sửa. Có vài thứ giữ cho việc này không trở nên tệ (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026):

• Thay đổi nhỏ, nên dễ review, debug và revert (theo bài viết, video đăng ngày 01/11/2026).
• Mọi thứ đều đảo ngược được: flag, revert và release theo giai đoạn gỡ phần lớn lỗi trong vài phút (theo bài viết, video đăng ngày 01/11/2026).
• Blast radius đặt ra mức yêu cầu: code đắt giá có thêm người và thêm check (theo bài viết, video đăng ngày 01/11/2026).
• Regression hiện ra nhanh qua telemetry và việc dùng nội bộ (theo bài viết, video đăng ngày 01/11/2026).
• Đây không phải đổ lỗi: người sở hữu bản sửa là người có nhiều context nhất, và incident review nhìn vào hệ thống (theo bài viết, video đăng ngày 01/11/2026).

Quyền sở hữu cũng được chia sẻ. Phần lớn công việc của team diễn ra trong các kênh mở, nơi ai cũng thấy người khác đang build gì, có thể nhận một thread, hoặc trỏ một Claude vào chỗ còn hở, và feedback cũng đến từ những người không sở hữu code đó. Sự cởi mở đó là một phần lớn lý do chất lượng vẫn cao mà không cần một cái cổng trên từng dòng (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

Phần "When we change direction": agent làm cho việc bắt đầu một thứ gì đó trở nên rẻ, nên có những việc không nên được land. Thường thì ai đó trong kênh hỏi vì sao, chỉ vào một quyết định trước đó, hoặc gợi ý một hướng đơn giản hơn, và tác giả đóng hoặc làm lại PR (theo bài viết đăng ngày 15/10/2026). John nói điều này thật sự thú vị; anh gần như cảm thấy team đang code công khai, ngay trong Slack, như một dòng thông tin lên xuống mà bạn cứ ra vào, và anh thấy khá cuốn hút (nhận định của John, video đăng ngày 01/11/2026).

Vì code được viết nhanh, đóng PR không còn có cảm giác là mất mát. Mẹo là nêu một hướng khác trong thread sớm, chứ không phải dưới dạng một comment chặn trên một PR đã xong (theo bài viết đăng ngày 15/10/2026). John nói anh đồng ý. Với anh, có rất nhiều ý tưởng muốn build, và trong Slack bạn thật sự có thể kích hoạt agent bắt đầu làm việc: nếu có một ý tưởng, anh để Slack mở thread, mở session cho anh, rồi anh quay lại sau. Anh có một loạt harness làm tất cả các tự động hoá này, tự build và thêm gating, v.v. (theo John, video đăng ngày 01/11/2026).

Anh nghĩ mình vứt đi rất nhiều code, rồi kết luận "ý tưởng hay đấy, nhưng tôi không nghĩ nó thật sự hiệu quả". Nên nếu bạn đang nghĩ "đây là code quý giá của tôi, tôi không thể vứt nó đi", thì theo John đó là kiểu tư duy bạn cần vứt bỏ (lời khuyên của John, video đăng ngày 01/11/2026).

18. Cách áp dụng quy trình này, và hướng đi tiếp theo

Phần "How you can adopt this process": theo bài viết, phần lớn các mảnh ghép để làm điều này với team của bạn đã có sẵn (bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026). John đọc từng nhóm bước.

Trước pull request (theo bài viết đăng ngày 15/10/2026, video đăng ngày 01/11/2026): cho agent những check nó chạy được, liệt kê trong một CLAUDE.md ngắn, cộng thêm hook chạy formatter và linter. Chạy /code-review và /security-review ở local, hoặc một lượt review bằng sub-agent với context mới. Thêm một REVIEW.md và chuyển những comment review lặp lại vào đó. John nói bài không nói rõ nên đặt REVIEW.md ở đâu; anh đoán là ở chỗ CLAUDE.md của bạn, nhưng có lẽ nằm trong thư mục kiểu .claude/rules (suy đoán của John, video đăng ngày 01/11/2026).

Trên mọi pull request (theo bài viết đăng ngày 15/10/2026, video đăng ngày 01/11/2026): yêu cầu CI, và thêm "Testing", "Risk" và "How to revert" vào PR template. Thêm một AI reviewer (Code Review for Claude Code, hoặc Claude Code GitHub Action) trên một repo, tinh chỉnh REVIEW.md trong vài tuần, rồi mở rộng. Thêm automated security review, và yêu cầu mọi thread review được resolve trước khi merge. Cân công sức review theo rủi ro: một lượt nhanh cho thay đổi thường lệ, một lượt sâu ở nơi bug bị bỏ sót sẽ đắt (Quick, Standard hoặc Deep trong Code Review). Giới hạn số vòng review; sau vài vòng đầu, chỉ re-review phần diff mới.

Approval (theo bài viết đăng ngày 15/10/2026, video đăng ngày 01/11/2026): viết ra các tier rủi ro, đặt theo thay đổi chứ không theo tác giả; bắt đầu chặt rồi nới dần khi có bằng chứng. Giữ đường approval nhẹ hơn cho những tác giả bạn tin. Dùng CODEOWNERS và branch protection để auth, billing, CI và release workflow, và các installer luôn cần một người. Đừng bao giờ để approval của bot thay cho một người bắt buộc; huỷ approval khi có commit mới.

Về chuyện huỷ approval khi có commit mới, John nói nó thú vị. Tiền đề là bạn đã duyệt một thứ, nhưng rồi tác giả ban đầu thêm vào, nên approval đó bị vô hiệu. Theo anh, điều này tuỳ bạn muốn mạo hiểm tới đâu, nhưng anh cho rằng bạn vẫn nên tin tác giả ban đầu rằng họ không thay đổi gì quá lớn. Đó là quan điểm riêng của anh, và thật ra còn tuỳ mức rủi ro và bạn muốn đi nhanh tới đâu (nhận định của John, video đăng ngày 01/11/2026).

Merge và sau đó (theo bài viết đăng ngày 15/10/2026, video đăng ngày 01/11/2026): dùng merge queue, feature flag, dùng nội bộ trước, release theo giai đoạn và rollback một bước. Biến incident và revert thành một bộ eval, và chấm lại reviewer mỗi khi prompt, tool hoặc model của nó thay đổi. Đo thời gian con người, với tỉ lệ revert và incident làm guardrail.

Phần "Where this is going" của bài: thông báo ra mắt Code Review nói việc approve một pull request vẫn là quyết định của con người; sản phẩm đăng finding, không đăng approval. Các repo của chính team đi xa hơn, để owner quyết định những thay đổi rủi ro thấp nào được merge chỉ dựa trên automated check, và ranh giới đó vẫn đang dịch chuyển (theo bài viết đăng ngày 15/10/2026, John đọc trong video đăng ngày 01/11/2026).

Khi một lượt review bỏ sót điều gì, team hỏi model đã không có gì trước mặt, rồi đưa bản sửa vào CLAUDE.md, một skill, hoặc một check mới (theo bài viết đăng ngày 15/10/2026). John thêm: hoặc một agentic tool mới. Mục tiêu không đổi: ít thời gian con người hơn cho mỗi thay đổi, và không nhiều revert hơn trước (theo bài viết đăng ngày 15/10/2026, video đăng ngày 01/11/2026).

Đọc xong, John nói bài viết thật sự đáng đọc, và thành thật mà nói anh thấy rất yên tâm về flow review của chính mình. Theo anh, nhiều khái niệm cốt lõi trong bài giống khái niệm cái cây của anh; team chỉ đổi thuật ngữ thành rủi ro thấp, rủi ro trung bình, rủi ro cao, và có lẽ đó là một phép so sánh dễ hiểu hơn. Anh cũng không biết vì sao mình lại dùng phép so sánh cái cây cho riêng mình (nhận định của John, video đăng ngày 01/11/2026).

Những điều anh rút ra: vẫn còn rất nhiều việc mà kỹ sư cần làm, và nếu muốn mở rộng, bạn cần xây một hệ thống như thế này, nơi bạn dùng classifier để đặt các mức nhịp review và tự động hoá khác nhau, sao cho bạn đẩy việc ra quyết định và steering ngày càng xa khỏi con người. Bạn phải mở rộng sự chú ý của con người nhiều nhất có thể (nhận định của John, video đăng ngày 01/11/2026).

Anh hy vọng mọi người thích video này, và chào tạm biệt tới lần sau.