Team Claude Code review code thế nào, so với T3 Code

1. Review code thế nào khi agent ship nhanh tới vậy

Theo Browne mở đầu (video đăng ngày 06/11/2026): gần đây anh và kênh đã dành rất nhiều thời gian nói về cách build hiệu quả nhất có thể với agent, nhưng anh nghĩ anh và kênh chưa nói đủ về phần giao tiếp xoay quanh việc đó. Làm việc cùng nhau như một team thế nào? Review code thế nào? Chọn cái gì được merge và cái gì không? Quản lý tất cả những thứ đó ra sao, nhất là ở tốc độ ship mà các công cụ như Opus 5.5 cho phép (theo video đăng ngày 06/11/2026)?

Anh nói các team ở Anthropic, như team Claude Code, đang trải qua chuyện này ở một quy mô khó hình dung. Theo lời anh, họ thậm chí không còn dùng được Git và GitHub nữa vì hai thứ đó làm họ chậm lại quá nhiều (theo Theo, video đăng ngày 06/11/2026). Vậy một team có thể review hết các yêu cầu thay đổi từ người khác bằng cách nào? Quản lý một lượng pull request như vậy ra sao?

Anh và team T3 Code cũng đang tự trải qua chuyện này: T3 Code đã có những ngày nhận tới 800 PR được mở trong một ngày. Theo anh, tìm cách xử lý hết chừng đó với một team nhỏ ba người là gần như không thể (theo video đăng ngày 06/11/2026).

Theo nói đây đơn giản là một thế giới khác, và cách review rồi land code đang, và nên, được làm theo một cách khác về căn bản. Đó là chủ đề của video: xử lý mức tải này thế nào, gánh nặng của những yêu cầu thay đổi liên tục trên mọi repo, khi Opus đã khiến việc có một pull request dễ như gửi một prompt. Quyết định thế nào, quản lý thế nào, đối phó thế nào với tất cả (theo video đăng ngày 06/11/2026)?

Anh nói anh có cảm giác đây sẽ là một video vui. Anh chưa đọc bài viết này, vì muốn đọc nó cùng người xem, và hy vọng mọi người học được vài điều, vì chuyện này không dễ. Theo anh, tìm ra lời giải ở đây là một mảnh rất quan trọng để làm đúng thời kỳ mới của ngành engineering. Anh cũng nói sẽ chia sẻ vài hiểu biết riêng về cách team T3 Code tăng tốc nhiều tới vậy, và rất háo hức giới thiệu thêm về quy trình của team, vì dạo này mọi thứ đang rất vui và một thành viên trong team đang làm việc hăng hơn bao giờ hết (theo video đăng ngày 06/11/2026).

2. Bài viết của Anthropic: tối thiểu thời gian review của con người

Theo nói anh sẽ bắt đầu từ cách team Claude Code làm code review, rồi xem nó giống và khác thế nào với cách team T3 Code đang làm, và team của anh học được gì từ đó. Anh nói anh thật sự háo hức vì có thể cải thiện được quy trình của mình (video đăng ngày 06/11/2026).

Bài viết mở bằng câu hỏi hiển nhiên: review code thế nào ở khối lượng code mà agent tạo ra? Theo đọc đoạn mở đầu (bài viết đăng ngày 15/10/2026): trên team Claude Code, từng có lúc họ có độ phủ cao và review sâu, rồi họ chuyển sang tối ưu cho lượng thời gian review của con người ít nhất mà không làm tăng revert hay incident. Theo nói nghe có vẻ đúng, dù câu này được định dạng tệ khủng khiếp, rồi đọc tiếp (video đăng ngày 06/11/2026).

3. 90% code do Claude viết, số PR gấp đôi, revert giảm hơn 40%

Theo đọc: Anthropic từng nói Claude viết khoảng 90% code của chính Claude Code (bài viết đăng ngày 15/10/2026). Anh nói tới giờ con số đó phải cao hơn thế. Anh không nghĩ anh hay bất kỳ ai trong team đã tự tay sửa một dòng code nào trong T3 Code, ngoài phần văn xuôi trong các file markdown, trong ít nhất ba tháng, có lẽ còn lâu hơn. Theo anh, riêng Claude có lẽ đã chiếm hơn 90% code của team, phần còn lại là Codex (theo video đăng ngày 06/11/2026).

Anh nói anh thấy khó hiểu ở chỗ này: anh tưởng tới giờ con số phải cao hơn. Trước đây những con số đã điên rồ rồi, kiểu "chúng tôi gần như không chạm tay vào code nữa, 85% code là Claude". Một năm sau, nó là 90. Theo anh, nghe vậy là thấp (video đăng ngày 06/11/2026).

Bài viết đặt tiếp mấy câu hỏi: họ review code thế nào ở khối lượng họ đang tạo ra? Còn ai đọc code nữa không? Nếu có gì hỏng, ai bắt được? Bài viết nói nó trình bày luồng code review của team Claude Code và nó đã thay đổi ra sao theo thời gian. Từ tháng 6 tới tháng 9, số PR được merge vào codebase của Claude Code tăng hơn gấp đôi, trong khi tỉ lệ phải revert giảm hơn 40% (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo nói cảm giác của anh là phần này đến từ cải tiến model nhiều ngang với cải tiến quy trình. Với team anh, cải tiến quy trình đã mang lại những cú thắng lớn hơn mức này, nhưng cải tiến model còn mang lại nhiều hơn nữa. Anh nói, theo cảm nhận riêng, revert rate của team đã giảm nhiều hơn 40% kể từ khi Opus 5.5 ra mắt. Team còn có thêm một đợt giảm lớn nữa khi anh cấm mọi model Gemini land code (theo video đăng ngày 06/11/2026).

Theo đọc tiếp: Addy và nhóm tác giả nói họ không bỏ review. Họ 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 gỡ lại sai lầm trở nên nhanh và dễ (bài viết đăng ngày 15/10/2026). Theo hỏi: đây sẽ là safety net, không phải guardrail, đúng không? Anh nói làm ơn hãy là safety net, không phải guardrail, nó sẽ làm anh vui lắm, và anh có linh cảm tốt về bài này (video đăng ngày 06/11/2026).

4. Viết lại mục đích của code review: hai việc

Phần đầu của bài viết bắt đầu bằng việc nghĩ lại mục đích của code review. Theo đọc: khi agent viết code, số thay đổi tăng nhanh. Ở 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. Claude Code nằm trong repo riêng, tách khỏi monorepo, nhưng cũng đang chịu nhiều áp lực. Khi ship nhanh tới vậy, review code thủ công từng dòng là cực kỳ khó, nếu không nói là không thể (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo dừng lại ở chi tiết Claude Code nằm trong repo riêng. Theo anh, điều đó có nghĩa là Anthropic đang cân nhắc open source nó (theo Theo, video đăng ngày 06/11/2026).

Bài viết nói code review có hai việc chính: tìm và sửa vấn đề trước khi ship, và xây dựng context chung, hiểu biết chung về codebase trong cả team (bài viết đăng ngày 15/10/2026). Theo nói việc thứ hai, theo ý anh, còn quan trọng hơn, và là khía cạnh bị đánh giá thấp nhất của code review. Anh vẫn đang tìm cách giữ được nó khi tốc độ ship của team tăng lên (video đăng ngày 06/11/2026).

Anh kể những câu hỏi anh đang gặp: làm sao để team hiểu những thay đổi điên rồ anh đang làm với wire protocol? Làm sao để những thay đổi của một thành viên trong team cho phần tích hợp computer use được các contributor khác hiểu? Làm sao để mọi người nắm được Orchestrator V2 trước khi merge nó? Anh kể có những contributor ngẫu nhiên đã đẩy branch của Orchestrator V2 rất mạnh từ trước khi team land nó, và họ hiểu cuộc đại tu tầng orchestration rõ hơn cả anh bây giờ, ngay từ trước khi nó được merge. Theo anh, đó là thứ sẽ khó cân bằng theo thời gian, và anh háo hức xem nó đi tới đâu (video đăng ngày 06/11/2026).

Bài viết chủ yếu tập trung vào việc thứ nhất, tìm và sửa vấn đề, và hẹn quay lại việc thứ hai ở gần cuối. Theo nói anh chờ được (video đăng ngày 06/11/2026).

5. "Có người đọc code chưa?" là một thước đo kém

Theo đọc quan điểm của nhóm tác giả: câu hỏi "đã có người đọc code chưa?" là một thước đo rất thiếu chính xác cho câu hỏi "thay đổi này có thể sai ở đâu, và lớp kiểm tra nào, tự động hay con người, là lớp đúng để bắt nó?" (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo nói đây là một chi tiết quan trọng. Anh thấy cuộc bàn luận về code review đã xuống cấp tệ hại, vì nó xoay quanh ý tưởng rằng agent mắc lỗi dồn dập và thường xuyên hơn con người nhiều, nên nếu không có người kiểm tra để chắc AI không mắc một lỗi ngớ ngẩn hiển nhiên nào thì sẽ chỉ ship ra slop (theo Theo, video đăng ngày 06/11/2026).

Anh nói thật lòng: gần như mọi regression team anh từng ship ở T3 Chat hay T3 Code, dù anh có review code đó hay không, anh cũng sẽ không bắt được nó khi review. Và anh hứa là không ai trong số người xem bắt được. Theo anh, loại bug lọt qua bây giờ không phải loại mà cứ nhìn chằm chằm vào code đủ lâu là suy ra được chỗ sai. Cần rất nhiều cách khác để phân tích và verify code (theo video đăng ngày 06/11/2026).

Anh nêu thêm một hot take: phần lớn agent giờ đã review code giỏi hơn phần lớn con người, và nếu trong codebase của bạn chúng không giỏi hơn, đó là vì codebase của bạn tệ, không phải vì agent tệ (theo Theo, video đăng ngày 06/11/2026).

Theo đọc tiếp: đặt câu hỏi kia 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, rồi chờ đồng nghiệp. Bây giờ review chạy liên tục, giống spell check khi đ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 (bài viết đăng ngày 15/10/2026). Theo nói không nên là "phần lớn", phải là "tất cả". Anh nhấn mạnh: nếu bạn mở PR mà agent của bạn còn chưa review, bạn đang lãng phí thời gian của team, và chuyện đó làm anh bực (video đăng ngày 06/11/2026).

Anh nhắc một bài trả lời trên X của Boris Cherny dưới bài đăng về bài viết này, khi có người hỏi 10% còn lại do ai viết: "Also Claude, but we're fixing up the attribution to be super confident before claiming it". Theo nói chúc may mắn, chuyện đó buồn cười thật (video đăng ngày 06/11/2026).

Một người xem trong chat đưa ra ví dụ vui về chuyện code tệ vẫn lọt qua review: một bug trong LLVM đã làm hỏng safe Rust suốt 10 năm. Theo nói đó là một trong những đoạn code được review kỹ nhất, bởi một số kỹ sư thông minh nhất thế giới, vậy mà vẫn để lọt một bug nghiêm trọng, đơn giản vì người giỏi nhất cũng không bắt được mọi thứ. Con người và agent đều bỏ sót. Khác biệt chính giữa AI thông minh nhất và con người thông minh nhất, theo anh, là AI sẽ không kiệt sức nếu bạn bảo nó kiểm đi kiểm lại, kiểm đi kiểm lại mãi. Còn những người đủ giỏi để tìm ra những thứ này thì cũng đủ bận để không buồn làm (theo Theo, video đăng ngày 06/11/2026).

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

Theo nói tới đây là phần anh thích nhất của cuộc bàn luận này. Bài viết gọi tên tài nguyên thật sự khan hiếm duy nhất lúc này, ngoài GPU: thời gian và sự chú ý của con người (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo đọc: nhóm tác giả 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 kiểm tra tự động bắt phần còn lại. Ở tốc độ thay đổi hiện tại, vẫn còn cực nhiều việc cho con người, và team của họ gặp những thử thách mới gần như mỗi ngày (bài viết đăng ngày 15/10/2026). Theo nói anh đồng ý hoàn toàn (video đăng ngày 06/11/2026).

Anh muốn thêm một ý: năng lượng của con người khác với thời gian và sự chú ý, vì có những việc đòi nhiều năng lượng hơn và ít thời gian hơn những việc khác. Cần tìm cách giảm chi phí năng lượng, để con người không phải làm những việc thấy đau khổ, chậm chạp, khổ sở, mà dành thời gian cho những việc cuốn hút và quan trọng. Theo anh, đây là một phân biệt có giá trị (theo Theo, video đăng ngày 06/11/2026).

Bài viết nói thời gian của con người nằm ở cả hai phía chi phí của một lần review: 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 (bài viết đăng ngày 15/10/2026). Theo nói còn một khía cạnh thời gian khác: khoảng thời gian giữa các bước. Một người mở PR, thời gian trôi trong lúc chờ. Một người khác vào review, lại chờ. Người viết ban đầu thấy review, đọc, đi sửa, push lại PR. Lại chờ trước lần review tiếp theo (theo Theo, video đăng ngày 06/11/2026).

Theo anh, đó là rất nhiều thời gian, và phần lớn bị tiêu vào việc chờ và vào giao tiếp hơn là vào làm việc thật. Đây là một trong những nút thắt lớn nhất khiến mọi thứ không ship được. Nên dù làm cho việc review ít tốn thời gian hơn, nếu thời gian vẫn bị phí vào sửa code thì cũng không đáng kể lắm (theo Theo, video đăng ngày 06/11/2026).

Theo đọc mục tiêu của team Claude Code: phần lớn pull request trong các repo Claude Code, gồm CLI, ứng dụng desktop và web, và ứng dụng mobile, phải merge được với nhiều nhất 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. Để đo thời gian của con người, họ theo dõi số human approval mỗi PR, số comment của con người, và thời gian một PR phải chờ một người. Revert rate và incident rate là guardrail: nếu chúng tăng, họ chưa tiết kiệm được thời gian của con người, mà chỉ chuyển nó sang chỗ khác (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

7. Vòng đời một thay đổi, và cách Theo verify ở T3 Code

Bài viết đi qua vòng đời của một thay đổi. Một thay đổi điển hình, từ laptop của một kỹ sư hoặc từ một phiên Claude trong Slack, đi qua nhiều lớp code review. Sau khi thay đổi được tạo, công việc được verify: có thể là Claude chạy test, build và lint, có thể có một agent thứ hai vào review diff trong một context mới (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo muốn thêm: khi có thể, công việc nên được verify nhiều hơn một lượt test nhanh kiểu check build, check lint. Nếu thay đổi đủ phức tạp, gần như luôn đáng công dựng nó lên và test thật, nhất là với việc UI, dù là dựng trong một trình duyệt giả lập hay dựng bằng computer use trong một môi trường nơi agent mở được app và thật sự kiểm tra mọi thứ (theo Theo, video đăng ngày 06/11/2026).

Anh kể một điều anh rất thích ở T3 OS: anh làm cho mỗi thread dễ dàng dựng được một cửa sổ riêng, tương tự cách macOS có nhiều workspace. Mỗi thread có được một cái như vậy, và nhờ đó một thread rất dễ dựng một Electron dev server cho T3 Code, quay video thay đổi đang chạy, rồi gửi cho anh hoặc đính vào PR (theo Theo, video đăng ngày 06/11/2026).

Anh cũng thêm vào chế độ dev những lựa chọn model giả, có sẵn các event dựng trước để đẩy qua pipeline, nhờ vậy agent chạy được một bài test end-to-end đầy đủ mà không phải đốt token, ngoài số token nó tốn cho phần quan sát hình ảnh lúc kiểm tra. Theo anh, những thứ như vậy đã giúp rất nhiều cho việc ship tự tin và cho tần suất anh dám land những thay đổi đáng sợ, vì agent của anh giờ test và kiểm chứng code được theo cách một người dùng làm. Khi agent báo code đã sẵn sàng để xem, nó đã verify theo phần lớn những cách anh sẽ tự verify (theo Theo, video đăng ngày 06/11/2026).

Anh nói đó là quy trình của anh, không phải của team Claude, rồi quay lại bài viết. Trên mọi pull request, thay đổi đi qua CI bắt buộc gồm lint, type, test trên nhiều nền tảng, build và đóng gói; đỏ là chặn merge. Theo nói như dự đoán. Rồi tới bước Claude code review: nó dựng nhiều agent song song đi tìm bug, verify thay đổi, dùng verifier để bỏ phiếu cho từng finding; những finding sống sót được xếp hạng theo mức độ nghiêm trọng (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026). Theo diễn đạt bước này là chính Claude Code vào chạy thử như một người dùng sẽ chơi với nó (theo video đăng ngày 06/11/2026).

8. Các lớp kiểm tra, không phải một cổng

Theo đọc tiếp các bước: security review là một lượt riêng để tìm những thứ có thể không an toàn. Rồi tới risk-based approval: một classifier xét thay đổi này rủi ro tới đâu và cần bao nhiêu can thiệp của con người, không người nào, một người hay hai người (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo nói chỗ này thú vị. Anh đã nghĩ tới việc làm điều tương tự ở T3 Code: trong template, hoặc trong skill dùng để mở PR, anh đang cân nhắc cho nó thêm một đoạn ở cuối mỗi PR, chấm trên thang từ một tới mười xem thay đổi có tác động lớn tới đâu, bao nhiêu người dùng bị ảnh hưởng, và rủi ro tới đâu, để các PR dễ đọc hơn khi được mở (theo Theo, video đăng ngày 06/11/2026).

Tiếp theo là merge queue. Theo nói T3 Code chưa có, và có lẽ nên có. Team đã làm hỏng main đủ nhiều lần, không phải hỏng theo kiểu build vỡ, mà theo kiểu một hai thứ CI ngẫu nhiên bị fail. Anh nói có lẽ tới lúc team cần merge queue, nhưng chưa có, và anh muốn tránh nó lâu nhất có thể (theo video đăng ngày 06/11/2026).

Sau khi merge, theo bài viết, thay đổi nằm sau một flag, ban đầu chỉ dùng nội bộ, rồi release dần dần; team theo dõi bản release để chắc mọi thứ ổn, fix forward nếu hỏng, hoặc roll back nếu hỏng quá nặng không sửa nhanh được (bài viết đăng ngày 15/10/2026). Theo nói tất cả nghe hợp lý (video đăng ngày 06/11/2026).

Theo nói anh thích cách đóng khung theo lớp: muốn thay đổi tốt đi qua được, và muốn mọi lớp chặn những gì đang đi sai đường. Có thể một thay đổi tệ lọt qua lớp verification nhưng fail ở lớp CI. Có thể nó qua CI rồi fail ở AI review. Có thể qua luôn lớp đó rồi fail ở AI security review. Các lớp này tăng khả năng code tệ bị lọc ra trước khi xuống tới đáy (theo Theo, video đăng ngày 06/11/2026).

Nhưng anh lưu ý một vấn đề khác: mỗi lớp không chỉ cắt bớt cái tệ, đôi khi nó còn thêm vào những thứ không cần. Anh nói không đếm nổi bao nhiêu lần anh thấy một PR lẽ ra chỉ khoảng 50 dòng code bị phình lên 800 tới 2,000 dòng, vì agent ở giữa xử lý mọi feedback từ mọi lớp trên đường đi, và kết quả đơn giản là tệ (theo Theo, video đăng ngày 06/11/2026).

Theo anh, thứ quan trọng nhất nằm ở dưới cùng: nếu có gì tệ lọt tới cuối, phải roll back được thật nhanh. Bài viết ghi rằng thất bại nên ảnh hưởng tới càng ít người càng tốt và càng rẻ để gỡ lại càng tốt (bài viết đăng ngày 15/10/2026). Theo nói điều này xưa nay vẫn đúng, nhưng giờ còn nặng hơn bao giờ hết: hệ thống của mọi người đều cần được dựng sao cho rollback khả thi (theo video đăng ngày 06/11/2026).

9. Verify trước khi ai xem, và sửa ở tầng gần nguồn nhất

Bước một trong bài viết: công việc được verify trước khi bất kỳ ai khác nhìn vào. Phần lớn review giờ diễn ra trước khi PR tồn tại. Nhóm tác giả đưa cho Claude thứ nó chạy được, như một bài test, một bản build, hoặc một screenshot để so với design, và bảo nó cho xem output thay vì nói là xong. Rồi một subagent review diff với context mới. Cả hai thói quen đến từ hướng dẫn best practices của họ. Trước khi mở PR, nhiều người trong team còn chạy vài skill nội bộ: một skill săn bug, một skill đơn giản hoá diff, một skill kiểm tra hành vi end-to-end. Thay đổi UI còn được kiểm tra theo design guideline của họ (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026). Theo nói đúng, đây là đúng điều anh vừa nói lúc trước (video đăng ngày 06/11/2026).

Bài viết nhắc Boris Cherny, người tạo ra Claude Code, đã gọi việc cho Claude 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 (bài viết đăng ngày 15/10/2026). Theo nói anh hoàn toàn đồng ý. Theo anh, nhiều người đang vật lộn để có kết quả tốt khi làm với agent là vì họ chưa cho agent cách nào để kiểm tra thứ nó làm có chạy hay không. Và công bằng mà nói, nhiều đồng nghiệp của họ, nhất là khi tuyển một kỹ sư mới, có lẽ cũng gặp đúng những vấn đề đó, vì nếu bạn viết code khó kiểm tra thì bạn đã tạo ra một codebase tệ để làm việc (theo Theo, video đăng ngày 06/11/2026).

Theo bài viết, Boris ước tính điều này làm kết quả cuối tốt hơn hai tới ba lần, và viết rằng verification trông khác nhau ở mỗi lĩnh vực: có thể đơn giản như chạy một lệnh bash, chạy một bộ test, hay test app trong trình duyệt hoặc trình giả lập điện thoại (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo nói nó cũng có thể phức tạp hơn nhiều: anh đã phải dựng những thứ VM điên rồ để test T3 OS. Test không phải lúc nào cũng dễ, dựng hệ thống để verify cũng không phải lúc nào cũng dễ, nhưng phải tìm ra cách. Theo anh, lúc nào cũng có một cách nào đó (video đăng ngày 06/11/2026).

Bài viết nói tiếp: nếu thấy các reviewer tự động cứ liên tục flag cùng một thứ, đó là lúc sửa ở nguồn, trong một skill, bằng một lint rule, hoặc bằng cách cập nhật các file hướng dẫn. Ví dụ một thay đổi trong CLAUDE.md, file nói cho Claude biết project là gì và theo những convention nào; hoặc REVIEW.md, do code owner viết, nói cho reviewer biết điều gì quan trọng trong phần code của họ. Nhóm tác giả 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, nói thất bại trông như thế nào trong repo đó: với docs là "nó nói sai", với config là "nó route sai". Có thể giới hạn số nit, liệt kê đường dẫn cần bỏ qua, và vân vân (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo nói đây không phải điểm xuất phát đúng. Anh trích hướng dẫn của Lauren Tan vì anh thấy nó tốt hơn một chút: khi phải sửa agent, hãy tìm chỗ gần đỉnh nhất để sửa thứ đã khiến agent làm sai (theo Theo, video đăng ngày 06/11/2026).

Theo giải thích tam giác đó (video đăng ngày 06/11/2026): tầng trên cùng là codebase. Nếu agent mắc lỗi trong code, xem có sửa được code để nó ít khả năng mắc lỗi hơn không. Đừng làm việc này bằng cách rải comment khắp nơi, mà bằng cách làm kiến trúc tốt hơn và dễ làm việc hơn.

Tầng tiếp theo, theo Theo, là static analysis: linter, checker, rule, type check, mọi thứ có thể cho agent, hay thậm chí con người, phản hồi rằng thứ đó chưa được làm đúng. Nó cho agent phản hồi cần thiết để làm đúng, nếu agent không tự hiểu "đúng" là gì từ chính code (video đăng ngày 06/11/2026).

Nếu cả hai tầng này đều không bắt được vấn đề, và bạn đã thử mà không làm được để những vấn đề cụ thể đó không thể lọt qua hai tầng kia, thì mới đưa văn xuôi vào. Đó là lúc bắt đầu đụng tới CLAUDE.md, REVIEW.md, AGENTS.md, bắt đầu dựng skill. Theo nói hãy làm việc đó sau khi mọi cách kia đã thất bại, và lúc nào cũng cố hết sức để chính codebase, lint, check và những thứ tương tự dẫn con người và agent tới thành công (theo Theo, video đăng ngày 06/11/2026).

Anh đưa ra một cách hình dung mà anh gọi là ngớ ngẩn nhất: tưởng tượng một người cực kỳ thông minh vừa vào team nhưng chưa biết thứ gì nằm ở đâu, người đã làm trong hàng nghìn codebase trước đây nhưng chưa từng làm trong codebase của bạn. Hãy làm cho người đó dễ nhất có thể để cứ thế lao vào làm mà ít có khả năng mắc lỗi ngớ ngẩn nhất. Và tưởng tượng thêm người này không ngại việc nhàm chán, sẽ làm việc nhàm chán cả ngày, mỗi ngày mà không cần lý do. Theo anh, nếu bạn vốn đã dựng codebase để đồng đội thành công, chuyển đổi này sẽ rất dễ với bạn (theo Theo, video đăng ngày 06/11/2026).

10. AI review trên mọi PR, và chuyện prompt suggestion

Phần tiếp theo của bài viết, mà Theo nói là của Addy, là AI review trên mọi PR. Theo đọc: mỗi pull request được Claude review trước khi có người xem. Nó đọc diff trên toàn bộ repo cùng ý định đã ghi của PR, và hỏi: thay đổi này có giải quyết được vấn đề không, có khớp với hệ thống không, hay nó làm hỏng thứ gì khác? Với một bug fix, nó tìm root cause. Bản công khai, Code Review for Claude Code, giờ đã phát hành chung trên các gói Team và Enterprise, và /code-review chạy một phiên bản nhẹ hơn trên máy (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo bài viết, 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, và phần lớn PR nhỏ trở về sạch. Admin đặt mỗi repo ở mức Quick, Standard hoặc Deep. Deep đáng giá khi một bug bị bỏ sót tốn hơn thời gian review thêm (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo nói anh sẽ không giới thiệu sản phẩm review của Claude, vì anh nghĩ nó quá, quá, quá đắt với phần lớn trường hợp thực tế, nhất là khi ship nhanh như bài viết khuyến nghị. Theo anh, có nhiều công cụ review khác rẻ hơn hoặc dùng được trên máy với chi phí được bù qua subscription (theo Theo, video đăng ngày 06/11/2026).

Một thứ anh rất thích là council skill của anh, nơi code của anh được ba model khác nhau từ ba họ model khác nhau review. Việc đó được bù qua subscription, anh dùng chính các subscription của mình cho nó, và theo anh nó cho kết quả tốt bằng, nếu không nói là tốt hơn, các quy trình code review kia. Nó lại chạy trên một máy tính thật, nên dựng được code lên để kiểm tra. Vì vậy anh không nghĩ người xem nên dùng sản phẩm của họ cho việc này: nó không tệ, nhưng đắt so với những gì nó là, và có thể chỉ cần prompt tốt hơn cùng các agent khác. Anh nói khía cạnh nhiều model là thứ họ sẽ không bao giờ nói tới, nhưng anh thấy nó thật sự tốt (theo Theo, video đăng ngày 06/11/2026).

Theo nói có một mảnh quan trọng khác mà anh ngạc nhiên là mọi người vẫn chưa nắm, dù anh biết nhiều người xem chưa nắm: không nên để agent và review bot để lại một đống comment trên PR rồi con người đi qua từng cái bằng tay, chọn cái nào xử lý, cái nào bỏ. Theo anh, đó là việc của agent (video đăng ngày 06/11/2026).

Anh nhắn tới những công ty đang làm sản phẩm AI code review, vì anh biết họ xem các video kiểu này: hãy bỏ cái prompt suggestion khỏi code review đi. Theo anh, đó là chuyện của năm 2024, còn bây giờ là năm 2026. Anh không copy paste gì từ code review về cho agent cả. Agent của anh trông PR. Agent của anh quyết định feedback có tốt hay không. Anh nói mọi code reviewer đều làm vậy, kể cả BugBot, thứ mà anh nghĩ từ Cursor ra thì phải hiểu điều này, nhưng không: mặc định tất cả đều để lại cái prompt suggestion "one-click AI fix" để copy paste sang. Anh nói không, dẹp nó đi (theo Theo, video đăng ngày 06/11/2026).

Anh nói cũng không phải autofix, bỏ hết đi. Anh muốn agent của anh quyết định feedback có tốt không, và không người nào phải nhìn vào cho tới khi việc đó xong. Anh không nên phải thấy những comment mà agent của anh để lại trên PR. Nên hãy chắc rằng các finding đã được agent khác verify trước khi bắt con người review (theo Theo, video đăng ngày 06/11/2026).

Theo đọc tiếp đúng phần đó của bài viết: nhiều agent có thể cùng lúc tìm bug, rồi một nhóm riêng bỏ phiếu cho từng finding và chỉ đăng nó khi đủ số đồng ý rằng finding đó là thật. Finding chỉ về style, diagnostics hay dọn dẹp bị loại. Nhóm tác giả đã A/B test các bộ lọc này trên PR của chính họ trước khi giữ lại. Phần còn lại hiện thành inline comment xếp theo mức độ nghiêm trọng, mỗi cái gắn nhãn Important, Nit hoặc Pre-existing, để một bug mà PR không gây ra không trông như lỗi của tác giả (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Mọi finding qua được bộ lọc đều phải được trả lời: sửa nó, hoặc resolve thread kèm lý do. Thường 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 (bài viết đăng ngày 15/10/2026). Theo hỏi phải chăng Anthropic đang chậm hơn team anh: anh có những PR đi qua tám vòng như vậy trở lên trong một hai tiếng, rồi mới làm phiền anh khi đã sẵn sàng (theo video đăng ngày 06/11/2026).

11. Security review chặn merge, và human approval theo mức risk

Phần tiếp theo là security review có quyền chặn. Theo đọc: security cũng có automated review riêng. Một PR không merge được khi còn bất kỳ finding nào từ bug review hay security review đang mở. Sửa nó, hoặc đóng thread kèm một lý do ngắn, đó là cách dọn false positive. Nếu một commit sau sửa được vấn đề, finding tự biến mất. Có thể dựng điều tương tự với security review mã nguồn mở, GitHub Action, hoặc lệnh /security-review, và cách cài đặt có trong hướng dẫn của họ (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026). Theo nói hay, tuyệt (video đăng ngày 06/11/2026).

Rồi tới automated check có quyền chặn: CI thông thường, type check, lint, test, những thứ mà Theo nói hy vọng người xem giờ đã biết (video đăng ngày 06/11/2026).

Theo đọc phần human approval: rủi ro thấp nghĩa là không cần người, cứ merge khi xanh; mức trung bình, thay đổi thông thường, cần một người xem; mức cao là nghiêm trọng, cần ít nhất hai người xem (bài viết đăng ngày 15/10/2026). Theo nói anh không thích cách đóng khung 0, 1, 2 này. Anh muốn anh và các agent của mình quyết định trên một thang linh hoạt hơn. Anh sẽ thử nghiệm với những ý này, rồi xem sau (theo Theo, video đăng ngày 06/11/2026).

Theo anh, ý chính của việc chia mức là nó không chọn tác giả, nó chọn mức rủi ro. Nhiều bot anh thấy cố chọn người để tag vào, kiểu người này phải review cái này, người kia phải review cái kia. Lý tưởng là team đủ tin nhau để biết ai review được code, và nếu một người vào review rồi thấy nên để người khác xem thì họ làm vậy được; nhưng bot không nên là bên tag từng người cụ thể. Bot nên mô tả mức độ rủi ro, còn con người lo phần còn lại (theo Theo, video đăng ngày 06/11/2026).

Theo kể những người bạn ở Cursor nói với anh rằng risk tiering là một cuộc chiến thua. Họ vẫn làm, nhưng đến giờ chưa có trải nghiệm tốt với nó (theo Theo, video đăng ngày 06/11/2026).

Bài viết còn nói có một số đường dẫn lúc nào cũng cần một người: mọi thứ owner đã liệt kê là nhạy cảm, và mọi file CI workflow (bài viết đăng ngày 15/10/2026). Theo nói hợp lý. Anh có vài chỗ như vậy ở T3 Code, ví dụ mọi thứ đụng tới scroll area là của anh: không merge cho tới khi anh xem (theo video đăng ngày 06/11/2026).

12. Trusted author, approval theo commit, rollback nhanh

Phần tiếp theo: chỉ tác giả đáng tin mới được đi đường nhẹ. Theo đọc: chỉ tác giả có tên trong danh sách trusted của repo, chủ yếu là team sở hữu nó, mới được đi các đường approval nhẹ; mọi người khác cần một người thứ hai duyệt. Approval của agent không bao giờ được tính là của một người. Automated review có thể duyệt một thay đổi rủi ro thấp, nhưng không lấp được một suất cần con người (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo nói đây là một trong những điều làm anh bực rất nhiều trên GitHub: anh muốn bot của anh được đánh dấu khác với anh. Anh đã làm điều đó theo nghĩa thêm skill để bot đặt một dòng chú thích lớn, nói rằng đây là Opus 5.5 chạy qua Claude Code và T3 Code, để lại comment thay mặt Theo. Nhưng anh muốn thấy lúc bot của Theo approve tách biệt với lúc Theo approve, với hai approval check khác nhau (theo Theo, video đăng ngày 06/11/2026).

Bài viết cũng nói người prompt ra thay đổi là người chịu trách nhiệm (bài viết đăng ngày 15/10/2026). Theo diễn đạt: bạn không thể đổ lỗi cho agent nếu chính bạn prompt nó; đó là phần sở hữu của bạn, là vấn đề của bạn (video đăng ngày 06/11/2026).

Theo đọc tiếp: approval chỉ áp cho những commit cụ thể. Nếu có commit mới land mà hệ thống không bảo đảm được, như một lần agent push hay một merge ai đó resolve bằng tay, approval phải làm lại. Họ có merge queue cùng flag và release dần: kênh latest nhận thay đổi trước, kênh stable nhận sau. Phát hiện nhanh, rollback nhanh. Một số sai lầm vẫn sẽ lọt, nên lớp cuối là bắt chúng thật nhanh (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo bài viết, team có lịch on-call xoay vòng hằng tuần, và incident review hỏi lớp nào lẽ ra phải bắt được vấn đề. Việc nhận ra một merge tệ vẫn phụ thuộc vào tác giả và người on-call, cùng các dashboard revert và incident. Họ chưa có circuit breaker tự siết approval khi các con số đó biến động, và các kỹ sư ở đó muốn có nó trước khi chuyển thêm code sang merge không cần người (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026). Theo nói hợp lý (video đăng ngày 06/11/2026).

Theo nhận xét vậy là họ chưa làm nhiều merge không cần người. Team T3 Code đang bắt đầu làm một chút việc này với những bug fix đủ dễ, và theo anh đó là cách một thành viên trong team bắt đầu land khoảng 400 PR mỗi ngày (theo Theo, video đăng ngày 06/11/2026).

Bài viết kể một đồng nghiệp nói rằng chậm lại thì giảm được error rate, nhưng chủ yếu chỉ vì bạn làm ít đi mọi thứ. Các team quyết định họ muốn nhanh hơn trong việc nhận ra và sửa vấn đề thay vì chậm lại để phòng chúng (bài viết đăng ngày 15/10/2026). Theo nói anh đồng ý: nếu giải pháp của bạn cho việc không ship breaking change là cứ đi chậm hơn, thì bạn chưa thật sự giải quyết vấn đề. Anh gọi đoạn này là một câu "banger" (theo video đăng ngày 06/11/2026).

13. Làm reviewer tốt hơn: incident thành eval, đo noise

Theo nói tới phần quan trọng hơn: làm thế nào để thật sự nâng chất lượng của review và của reviewer. Theo đọc: quy trình code review của họ liên tục được cải thiện theo một vòng lặp. Mọi incident giờ đều thành một eval. Team gom những PR trong quá khứ đã gây incident, cùng 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à nơi nó nằm. Reviewer chạy trên bộ đó mỗi ngày (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo nói đó không phải cách anh sẽ làm, nhưng anh thích hướng họ đang đi: có incident, một chuyên gia kiểm tra và xác nhận, họ thêm nó vào bộ, rồi chạy eval hằng ngày để xem những thứ đó có xảy ra lại không. Anh nói hay (video đăng ngày 06/11/2026).

Theo đọc tiếp: nhóm tác giả đ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 thì dễ, nếu không ngại flag cả đống thứ không phải bug, nên cần một phép kiểm cho chuyện đó (bài viết đăng ngày 15/10/2026). Theo nói anh hoàn toàn đồng ý: noise trong PR là địa ngục (video đăng ngày 06/11/2026).

Theo bài viết, họ phân loại mọi comment reviewer để lại theo cách người trên PR phản hồi: sửa nó, nói nó sai, nói hành vi đó là cố ý, hay quyết định nó không quan trọng. Họ còn chạy reviewer trên những PR họ biết là sạch, và đếm xem nó báo bao nhiêu lần một thứ có thể khiến ai đó thực hiện một thay đổi có hại (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Ưu tiên đã viết ra của họ là bắt bug thật trước, cắt bớt số vòng review sau. Theo nói hợp lý. Bài viết nói noise tốn hơn khi tác giả là một agent: một người có thể gạt một nit đi trong vài giây, còn agent sẽ sửa nó, nghĩa là thêm một commit, thêm một vòng review (bài viết đăng ngày 15/10/2026). Theo thêm: thêm code không cần thiết và đủ loại slop khác. Nên các review phải hội tụ (theo Theo, video đăng ngày 06/11/2026).

14. Review phải hội tụ

Bài viết nói một tác giả là agent và một reviewer là agent có thể làm nhau bận mãi không dứt (bài viết đăng ngày 15/10/2026). Theo kể một chuyện của chính anh: anh có một thay đổi tưởng là đơn giản. Anh đang làm trải nghiệm kiểu Grok Bot trong T3 Code, nơi có một thread chính điều khiển mọi thread khác. Anh có một prototype chạy được nhưng chưa đúng cách anh muốn, nên anh ném nó vào council review và nói đây là thứ anh muốn, cứ lặp tới khi cả council cho qua. Rồi anh quên mất, vì nó bị gập lại trong tab làm việc của anh (theo Theo, video đăng ngày 06/11/2026).

Mới hôm qua anh để ý thấy nó đã chạy suốt bốn ngày. PR nó đang làm đã lên tới khoảng 80,000 dòng code, và anh phải nhảy vào bảo nó rằng nó đang chạy vòng vòng. Anh nhận ra mình cần thêm short circuit cho một số skill, vì nó không còn tiến triển gì nữa. Theo anh, review phải hội tụ, mọi thứ phải kết thúc vào lúc nào đó (theo Theo, video đăng ngày 06/11/2026).

Theo đọc tiếp: một PR của CLI đã đi qua hơn 50 vòng review và sửa trong một đêm trước khi tác giả dừng nó lại (bài viết đăng ngày 15/10/2026). Anh nói anh còn chưa đọc tới câu đó khi kể chuyện của mình, thật buồn cười (video đăng ngày 06/11/2026).

Bài viết kể: khi chạy git blame trên những gì reviewer cứ flag mãi, khoảng 59% là code đã nằm đó từ lượt đầu của reviewer (Theo đọc thành khoảng 60%). Reviewer hiếm khi tìm ra bug mới, mà chỉ tìm thêm vài bug cũ mỗi vòng. Nhóm tác giả tự làm cho tình hình tệ hơn: họ đã quen chạy nhiều vòng theo mặc định, vì mỗi lượt đều bắt được gì đó mới. Điều này có thể đáng giá với một thay đổi rủi ro, nhưng không phải với mọi PR. Team giờ theo dõi số vòng để qua bên cạnh recall, và thay đổi cách re-review (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo kể anh cũng đã sửa chuyện này theo một cách ngớ ngẩn. Thay vì theo dõi mọi nit và chạy tới khi agent nói "thế này ổn rồi", anh chuyển sang một hệ chấm điểm, nơi agent review cho điểm từ một tới mười, và anh chọn một ngưỡng điểm đủ cao. Vì một PR có thể có 18 comment mà vẫn được 9 trên 10, khi mọi comment chỉ là những nit vặt; còn một PR khác chỉ có một comment nhưng được 6 trên 10. Ở trạng thái đó, PR có một comment cần sửa trước PR có 20 comment. Theo anh, tìm cách đặt ngưỡng không theo số comment còn lại, mà theo mức tin cậy xây được trong hệ thống, là con đường hiệu quả (theo Theo, video đăng ngày 06/11/2026).

Theo đọc các thay đổi của họ, bắt đầu bằng round cap, và nói anh chưa làm việc này với council và cần làm. Danh sách gồm: một round cap, sau ba vòng reviewer sẽ yêu cầu tác giả lùi lại và xem lại cách tiếp cận; re-review chỉ trên diff sau vài lượt đầu; flag cả lớp bug để tác giả sửa mọi chỗ, không chỉ một dòng; và không lặp lại finding đã đăng. Theo nói đây là những thay đổi tốt (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Agent review còn chạy hằng đêm trên code hiện có, giúp bắt bug cũ trước khi chúng lộ ra ở chỗ khác (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo đọc kết quả: sau các thay đổi để review hội tụ, số PR qua được sau một vòng review và sửa tăng 13%; số PR cần năm vòng trở lên giảm từ 9% xuống 1.5 (biểu đồ ghi 8.9% và 1.5%); số lần review trung bình để qua giảm từ 2.08 xuống 1.32 (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026). Anh nói đây là những thay đổi tốt (video đăng ngày 06/11/2026).

Trước khi sang phần tiếp, Theo kể thêm một góp ý hay từ một người bạn ở Graphite, mà anh gọi là "aka Cursor, aka SpaceX AI, aka Grok Bot". Người này cho rằng chấm điểm không phải lời giải: agent nên đủ đáng tin để ra một quyết định boolean với đúng context, giống như những kỹ sư con người được trả lương để làm việc đó: "mình có bỏ qua comment này được không?" (theo Theo, video đăng ngày 06/11/2026).

Theo nói đây là một lời giải tốt, mục tiêu là giữ mọi thứ đơn giản, và anh phần lớn đồng ý. Anh nói anh cần thử nghiệm thêm các lựa chọn khác: thường thì nếu không hài lòng với một cách, anh mày mò tới khi có cách tốt hơn rồi dùng nó cho tới khi nó làm anh bực, và anh cần thử nhiều cách khác nhau hơn. Anh cảm ơn những người bạn ở các lab đã vào góp ý trong lúc anh quay, vì điều đó giúp rất nhiều để làm đúng tất cả chuyện này (theo video đăng ngày 06/11/2026).

15. Con người còn ở đâu trong vòng lặp, và chia sẻ context

Câu hỏi mà Theo nói ai cũng tò mò: với tất cả những thứ này, con người ở lại đâu trong vòng lặp? Theo đọc: con người quyết định thứ đó có đáng build hay không: hướng đi, gu và phạm vi. Một team đã tuyên bố giải quyết xong nút thắt review vẫn giữ review của con người cho những thay đổi từ ngoài team, để có ai đó hỏi "mình có nên làm việc này không?" (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo bài viết, con người còn review code rủi ro như billing, auto-updater và CI workflow; review kiến trúc, vì nó đặt ra pattern mà người khác sẽ chép theo; đọc bằng chứng: output của test, những lệnh đã chạy và chúng thật sự trả về gì, screenshot, finding của review. Nếu không nói được các check sẽ bỏ sót gì, hãy xin một lần review thật thay vì một approval nhanh. Và tất nhiên là sở hữu kết quả: ai mở PR thì người đó sở hữu nó, bất kể code đến từ đâu (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Rồi tới chia sẻ context giữa các team. Theo nói đây chính là thứ anh yêu ở code review, không chỉ bắt bug: anh yêu code review vì nó bảo đảm mọi người biết chuyện gì đang diễn ra trong codebase. Tới giờ, khi anh nhờ một đồng đội review code, thường là vì lý do đó: anh muốn họ hiểu nó. Nếu họ không hiểu, anh phải tự sửa mọi thứ; nếu họ hiểu, anh không phải một mình chịu trách nhiệm về sau (theo Theo, video đăng ngày 06/11/2026).

Theo đọc: việc thứ hai của code review xưa nay là lan truyền hiểu biết về codebase. Đọc diff của đồng đội là cách bạn biết cái gì đã đổi và các mảnh khớp với nhau ra sao. Nếu máy làm phần lớn việc đọc, thì ai học được code? Nhóm tác giả không có quy trình chính thức cho việc này. Không ai trong team giữ một mental model hoàn chỉnh về Claude Code trong đầu (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo nói anh biết một số người xem sẽ nghĩ thế là điên, rằng phải có ai đó biết toàn bộ nó chạy thế nào. Anh nói nếu bạn nghĩ vậy thì hy vọng cuộc sống thất nghiệp đang đối xử tốt với bạn, vì không codebase cỡ lớn nào có một người biết hết mọi thứ. Anh kể anh đã tranh luận về chuyện này và đã đổi ý qua lại: có rất nhiều codebase quan trọng được một hai người duy trì hiểu rõ, những codebase rất nhỏ, nhưng đó không còn là việc toàn thời gian nữa (theo Theo, video đăng ngày 06/11/2026).

Theo anh, nếu codebase đủ nhỏ để một người hiểu hết, thì codebase đó không có đủ throughput, không phải theo nghĩa traffic. Có thể có một codebase nhỏ xử lý hàng tỉ request mỗi ngày, nhưng nó không thay đổi đủ nhiều để cần dựng một quy trình "tôn giáo" quanh nó cho các thay đổi hằng ngày. Nếu bạn chỉ có một thay đổi mỗi tuần, dành năm trong sáu ngày làm việc để chắc thay đổi đó tốt là ổn, rất hợp lý. Chỉ là đó hoàn toàn không phải loại việc đang bàn ở đây. Anh nói phần lớn công việc toàn thời gian đang diễn ra trong những codebase mà không người nào, và không agent nào, hiểu hết được (theo Theo, video đăng ngày 06/11/2026).

Bài viết nói không ai cần hiểu hết cả. Khi ai đó muốn hiểu một phần codebase, họ có thể nhờ Claude viết một bản giải thích cho đúng lát cắt đó. Việc này mất vài phút và phản ánh code ở trạng thái hiện tại (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo nói anh nghĩ mọi người đánh giá quá thấp sức mạnh của việc này. Khi review những thay đổi lớn, anh thường dán PR vào T3 Code với Claude và nhờ nó tóm lược các thay đổi: cái gì đang đổi, vì sao đổi, và rủi ro nằm ở đâu (theo Theo, video đăng ngày 06/11/2026).

Theo đọc: một số người trong team còn đi xa hơn, để Claude build một artifact trực quan hoá phần code đó, dạy họ nó hoạt động thế nào theo cách người đó thích học (bài viết đăng ngày 15/10/2026). Theo nói điều này tuyệt vời và anh rất khuyến khích. Bài viết nói nếu mục tiêu là dùng sự chú ý của con người cho tốt, việc này đánh bại việc đọc từng dòng một diff vặt; một thay đổi copy một dòng chẳng dạy được gì, còn bản giải thích cho module bạn sắp đổi dạy được rất nhiều (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Bài viết còn nói 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 lúc họ build (bài viết đăng ngày 15/10/2026). Theo nói anh rất thích điều đó. Một trong những điều anh thật sự mong tìm ra ở T3 Code là cách làm việc cùng nhau như một team và thấy ai đang làm gì, khi nào. Có nhiều lý do khiến việc đó khó, nhưng anh muốn tìm ra (theo video đăng ngày 06/11/2026).

16. Land thì own, và đổi hướng sớm

Tiếp theo là "you land it, you own it". Theo đọc: nếu bạn land một thay đổi nhỏ hoặc vừa mà có gì vẫn hỏng, chuẩn mực của team là bạn sẽ là người sửa nó. Vài điều giữ cho việc này không trở nên tệ: thay đổi nhỏ, nên dễ review, debug và revert; mọi thứ đều gỡ lại được; blast radius đặt ngưỡng, code đắt giá thì có nhiều người hơn và nhiều check hơn; regression lộ ra nhanh qua telemetry và dùng nội bộ; và đây không phải đổ lỗi (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo diễn đạt lại ý đó (video đăng ngày 06/11/2026): sở hữu không có nghĩa bạn có lỗi, mà nghĩa là bạn hiểu rõ nhất, nên bạn sẵn sàng vào sửa thứ mà bạn có nhiều context nhất. Bài viết nói quyền sở hữu cũng được chia sẻ: phần lớn team làm việc trong các kênh mở, nơi ai cũng thấy người khác đang build gì, có thể nhận tiếp một thread, hoặc chỉ một Claude vào một chỗ hở; và feedback đến cả từ những người không sở hữu đoạn code đó. Sự cởi mở đó là một phần lớn của cách chất lượng được giữ cao mà không cần chặn cổng từng dòng (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo nói tới một mảnh lớn khác mà anh rất thích vì họ đưa vào bài: đổi hướng. Bài viết nói agent làm cho việc bắt đầu một thứ trở nên rẻ, nên có những việc không nên land (bài viết đăng ngày 15/10/2026). Theo đoán ngay cả với PR của chính anh trong T3 Code, khoảng một nửa được merge, nửa còn lại bị đóng vì đủ loại lý do (theo Theo, video đăng ngày 06/11/2026).

Theo đọc tiếp: thường có ai đó trong kênh hỏi vì sao, chỉ vào một quyết định trước đó, hoặc gợi ý một đường đơn giản hơn, và tác giả đóng hoặc làm lại PR. Vì code viết nhanh, đóng PR không thấy như một mất mát. Mẹo là nêu một hướng khác trong thread thật sớm, không phải dưới dạng một comment chặn hay một PR đã hoàn chỉnh (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

17. Áp dụng quy trình: trước, trong và sau PR

Phần tiếp theo của bài viết là làm sao áp dụng những quy trình Anthropic chia sẻ. Theo nói anh ghét chuyện không biết ai viết đoạn này: anh biết Addy viết nhiều phần, nhưng cách định dạng một số câu thì kinh khủng, và đây là một trong những câu tệ nhất anh từng đọc. Câu đó viết rằng phần lớn các mảnh để làm việc này với team của bạn đã có sẵn hôm nay, mà không có một chỗ ngắt hay phân đoạn nào. Theo anh, nó cần một hai dấu phẩy, hoặc tách thành nhiều câu (theo Theo, video đăng ngày 06/11/2026).

Anh xin lỗi vì khó tính về văn xuôi, anh thích viết. Anh nói thật điên rồ khi các large language model đã giỏi gần như mọi thứ trừ việc tạo ra văn bản, và anh ghét văn LLM vô cùng, anh đang ngửi thấy những thứ anh không thích ở đây. Trên màn hình, anh mở một bài đăng của chính mình trên X, ngày 02/11/2026, với đúng ý đó: "Crazy how Large Language Models have gotten good at pretty much everything other than generating text" (video đăng ngày 06/11/2026).

Dù vậy, theo anh vẫn học được từ cách áp dụng quy trình. Anh thích việc bài viết bắt đầu từ trước PR, vì có trước, trong và sau PR, và đó là các phần nên dùng để nghĩ về chuyện này (theo Theo, video đăng ngày 06/11/2026).

Theo đọc phần trước PR (video đăng ngày 06/11/2026): cho agent những check nó chạy được và cách verify công việc của nó; chạy các skill code review và security review trên máy. Anh nói anh có việc này trong skill chính để land thay đổi, và agent tự quyết định kéo cái gì vào và không kéo cái gì. Thêm một REVIEW.md, và các comment review lặp lại có thể đưa vào đó. Theo nhắc: nên sửa code trước.

Trên mọi PR (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026): bắt buộc CI, thêm "Testing", "Risk" và "How to revert" vào template PR. Theo nói anh thích phần này: template PR, hay skill hoặc bất cứ thứ gì bạn dùng để mở PR, nên có cách test, rủi ro là gì, và cách gỡ thay đổi này. Thêm một AI reviewer, có thể là cái họ gợi ý, trên một repo; chỉnh REVIEW.md trong vài tuần rồi mở rộng phạm vi check về sau. Theo nói hoàn toàn ổn (video đăng ngày 06/11/2026).

Bài viết khuyên thêm automated security review và bắt buộc mọi thread review được resolve trước khi merge (bài viết đăng ngày 15/10/2026). Theo nói anh thích việc họ cứ thả câu này vào như thể ai cũng làm được, trong khi Claude của "chúng ta" còn chặn không cho hỏi về chuyện bảo mật. Theo anh, có giải pháp cho vấn đề đó, nhưng tiếc là sẽ không thường đến từ phía Anthropic (theo Theo, video đăng ngày 06/11/2026).

Bài viết khuyên khớp công sức review với rủi ro: một lượt nhanh cho thay đổi thường lệ, một lượt sâu khi bỏ sót bug là đắt, tức Quick, Standard hay Deep trong Code Review; và giới hạn số vòng review (bài viết đăng ngày 15/10/2026). Theo nói để nó không chạy mãi, vì anh đã đốt rất nhiều token với những vòng review vô tận ngoài ý muốn (theo video đăng ngày 06/11/2026).

Về approval (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026): viết ra các mức rủi ro, đặt mức theo thay đổi, không theo tác giả. Giữ đường approval nhẹ hơn cho tác giả bạn tin. Dùng code owner và branch protection, để auth, billing, CI, các luồng release và những thứ quan trọng khác có người cụ thể duyệt. Không bao giờ để approval của bot thay cho con người. Theo nói đúng vậy (video đăng ngày 06/11/2026).

Về merge và sau đó (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026): dùng merge queue, feature flag, dùng nội bộ trước, release theo giai đoạn; rollback một bước cũng rất quan trọng. Biến incident và revert thành bộ eval, và chấm lại reviewer khi prompt, tool hay model thay đổi để có điểm mới, biết model có thật sự tiến bộ không.

Theo nói (video đăng ngày 06/11/2026) bất cứ thứ gì không đo được thì giờ không sửa được, vì AI giỏi sửa mọi thứ tới vậy khi bạn đưa cho nó công cụ để leo dần lên. Nếu bạn làm được một eval từ những loại thay đổi đã lọt vào code mà lẽ ra không được lọt, và biến nó thành một bài test chạy được, sửa những thứ đó sẽ trở nên rất dễ.

Bài viết cũng gợi ý đo thời gian của con người là hữu ích, cùng với đo revert rate và incident rate (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

18. Hướng đi tiếp theo, và AGENTS.md của T3 Code

Theo đọc phần "Where this is going": khi ra mắt sản phẩm code review cho Claude Code, Anthropic nói approve một PR 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 họ giờ đang đi xa hơn, cho 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 đó cứ dịch dần. Khi một review bỏ sót điều gì, họ hỏi model đã không có gì trước mặt, và đưa bản sửa vào một CLAUDE.md, một skill, hoặc một check mới (bài viết đăng ngày 15/10/2026, Theo đọc trong video đăng ngày 06/11/2026).

Theo nói không, chỗ này không đúng, anh không thích hướng dẫn này. Theo anh, nên cố sửa code trước. Nếu không sửa được code theo cách ngăn được vấn đề, thì thêm một check. Nếu không sửa được ở đó, thì mới có thể thêm một skill hay một CLAUDE.md (theo Theo, video đăng ngày 06/11/2026).

Anh kể team T3 Code gần đây đã đại tu toàn bộ hướng dẫn trong repo, rồi mở file AGENTS.md trên GitHub để xem nó thay đổi thường xuyên tới đâu. Có một thay đổi cách đó tám tiếng. Theo anh, file thay đổi nhiều hơn trước, nhưng vẫn không nhiều: một tháng thay đổi vẫn vừa một trang, ít hơn nhiều so với những chỗ khác trong codebase. Ví dụ component chat view thay đổi khoảng 30 tới 50 lần một ngày, còn AGENTS.md của team đổi chừng một lần một ngày, và trước đó còn ít hơn, chừng năm ngày một lần. Nên team không liên tục chỉnh tất cả những thứ này (theo Theo, video đăng ngày 06/11/2026).

Mở commit mới nhất, anh thấy một thành viên trong team đã chuyển công cụ typecheck. Trên màn hình là PR #31028, "build: typecheck with tsrs and Effect's rules through @effect/tsgo", với mô tả rằng việc typecheck trước đó chạy trên @tsc-rs/typescript, bản bị đóng băng ở build ngày 22/10, nên các rule mới của Effect không tới được (video đăng ngày 06/11/2026). Theo nói lẽ ra người đó cứ bảo anh tiếp tục, anh sẽ dựng lại agent của mình. Hoá ra team đã bỏ công cụ cũ vì người đó muốn các tính năng mới của Effect (theo Theo, video đăng ngày 06/11/2026).

Theo anh, ở đó hướng dẫn thật sự đã thay đổi, nhưng team không chỉnh nó vì thấy một thứ nhỏ làm phiền. Team không đổi nó vì thấy agent làm sai, mà vì chính repo đã thay đổi và một phần hướng dẫn không còn đúng nữa. Đó là thứ dẫn tới thay đổi, không phải những vấn đề trong codebase mà team cố đưa thêm câu chữ để agent né (theo Theo, video đăng ngày 06/11/2026).

Anh đưa ra một so sánh (video đăng ngày 06/11/2026): tưởng tượng bạn bị mù và đang đi qua một mê cung trong một căn phòng tối, cứ đâm vào tường và vấp ngã. Có thể đưa cho bạn chỉ dẫn tốt hơn trước khi bước vào mê cung, hoặc có thể lấp các cái hố và làm cho chỉ dẫn bên trong mê cung tốt hơn, để không còn quan trọng bạn nhìn rõ tới đâu khi bước vào. Theo nói anh không muốn cứ đưa thêm chỉ dẫn cho model trước khi nó bước qua cửa; anh muốn căn phòng nó đi qua dễ đi nhất có thể. Và anh không nghĩ ngày càng nhiều file REVIEW.md là lời giải.

Bài viết kết bằng lời mời: họ muốn nghe nhiều hơn về việc các team đang tự động hoá những check nào, check nào vẫn cần người, và họ đang sai ở đâu (bài viết đăng ngày 15/10/2026). Theo nói vì vậy anh càng háo hức đưa video này ra, vì anh biết họ sẽ lắng nghe và có thể thật sự thử vài điều, nhất là khi trong đó có Addy và Emma, hai người bạn cũ. Anh nói Emma thì giỏi không thể tin nổi và anh rất vui khi cô giờ ở Anthropic; anh không quen Michael và Amie bằng, nhưng đã nghe những điều tốt về họ. Phần cảm ơn cuối bài viết ghi tên Emma Webb, Michael Segner và Amie Rotherham (video đăng ngày 06/11/2026).

Theo nói đây là một bài viết tuyệt, và thật tốt khi Anthropic minh bạch hơn nhiều về quy trình của họ: một năm trước, những bài blog như thế này không tồn tại, họ không chia sẻ nhiều tới vậy về cách làm việc nội bộ, và có được loại thông tin này là một thay đổi rất dễ chịu (theo Theo, video đăng ngày 06/11/2026). Anh nói anh hy vọng người xem thích bài này như anh, vì anh thích được nhìn vào hậu trường cách mọi người làm việc với các công cụ này, và có thể người xem cũng học được vài điều về cách tự mình dùng chúng.