Nút thắt AI: vì sao team chưa ship nhanh hơn, và sáu nguyên tắc sửa setup

1. 2.462 pull request trong một tháng: chuyện setup, không phải chuyện kỹ năng

Nate mở đầu bằng một con số. Theo lời Lauren Tan kể công khai và được nhắc lại trong video đăng ngày 27/09/2026, tháng 7/2026 chị ship khoảng một nghìn pull request. Đó là rất nhiều code. Chị nói tháng 8 sẽ gấp đôi. Và tháng 8 khép lại ở con số 2.462. Chị tự đặt ra con số, rồi vượt qua nó.

Team của bạn, Nate nói, có lẽ sẽ không làm được như vậy trong tháng này. Lý do không hẳn là họ là những kỹ sư kém hơn. Lý do là một nghìn pull request không phải là chuyện kỹ năng (skill issue). Đó là chuyện setup (setup issue), và chẳng ai bán cho bạn cái setup ấy. Chẳng ai giúp bạn hiểu setup đó là gì.

Agent của bạn đang ship những thứ mang tên bạn. Và bạn thì liên tục được bảo phải ship nhanh hơn, nhanh hơn nữa, nhanh hơn nữa. Nhưng bạn thực sự có quyền điều khiển (control) gì trong tay? Nếu phải kể tên những nút điều khiển bạn có để quản lý tốc độ (velocity) và chất lượng của agent, danh sách đó dài bao nhiêu? Theo Nate, với phần lớn chúng ta, danh sách khá ngắn. Và đó không phải khuyết điểm tính cách. Chỉ là chưa ai trao cho bạn bộ điều khiển để lái những agent này cho hiệu quả.

Nate tự giới thiệu: anh là Nate B Jones, và anh muốn giúp bạn xây một cuộc sống tốt hơn cùng AI. Trong video này, anh sẽ dạy sáu nguyên tắc (principle) anh rút ra từ những developer như Lauren và nhiều người khác, để giúp bạn build nhanh hơn bằng chính những công cụ AI bạn đang có.

2. Mua về một hàng đợi thay vì một nhà máy nhanh hơn

Nate dẫn báo cáo về thói quen developer (developer habits report) của Cursor, theo lời anh trong video đăng ngày 27/09/2026: những developer hàng đầu của Cursor merge số pull request nhiều gấp khoảng 15 lần một developer bình thường đang tích cực gửi những đề xuất thay đổi code. Anh giải thích lại cho rõ: pull request chính là những đề xuất thay đổi code, và con số ở đây là những đề xuất thực sự được chấp nhận.

Vậy mà, theo những gì Nate nghe được, với phần lớn chúng ta vẫn còn một đống việc nằm chờ ai đó làm nốt, ngay cả khi đã có công cụ AI. Chuyện gì đã xảy ra? Tại sao có cảm giác rằng với tất cả công cụ AI ấy, cái bạn mua về lại là một hàng đợi (queue) to đẹp thay vì một nhà máy (factory) chạy nhanh hơn?

Lauren Tan đã ghi lại một bài nói cho sự kiện Cursor Compile London về cách chị thực sự hoàn thành 2.000 pull request mỗi tháng, và đăng miễn phí trên X (video đăng ngày 27/09/2026 nhắc lại điều này). Nate rất thích chuyện đó, vì theo anh, vào thời điểm video, một số thứ hữu ích nhất đang diễn ra trong AI lại rất khó tìm. Chúng bị chôn trong cách một người nào đó set up công việc của mình, hoặc các công ty có đủ lý do để giữ những chi tiết đó cho riêng mình.

Những thứ đó không viral. Nên khi có người chia sẻ, phần còn lại chúng ta có cơ hội học được một điều thực sự dùng được, để thay đổi câu chuyện về cách công cụ AI biến thành giá trị thật.

3. Những setup đáng học, và cái bẫy của setup quá cầu kỳ

Setup của Lauren là một ví dụ rất tốt. Không phải ví dụ duy nhất, nhưng là một ví dụ rất tốt, và Nate sẽ kể thêm vài cái khác. Shopify là một ví dụ: Shopify đã build một hệ thống dùng chung cho công việc của agent trên toàn công ty. Một ví dụ khác đến từ Addy Osmani, người đã viết về những gì con người vẫn phải chịu trách nhiệm khi chúng ta commit code. Fiona Fung là một người nữa: chị đã mô tả cách team build Claude Code thay đổi cách làm việc.

Câu hỏi Nate cứ quay lại khá đơn giản: làm sao để những hệ thống chúng ta build vẫn bền (resilient) khi AI tiếp tục scale, nhất là quanh chuyện năng suất? Chúng ta có thể build một setup rất công phu, mất hàng tuần để bảo trì. Thực tế ta đã thấy những setup như vậy. Gas Town của Steve Yegge là một ví dụ. Theo Nate, Steve nói anh chưa từng build được thứ gì thực sự hữu ích bằng Gas Town. Anh build ra Gas Town, nhưng rồi chính Gas Town lại không làm ra sản phẩm cho anh. Và đó là một hệ thống rất cầu kỳ.

Trên màn hình, Nate đặt một câu trích của Steve Yegge, ghi nguồn là bài "The Shape of Things to Come", tháng 8/2026: "Gas Town was intended to be reusable, but I only ever wound up using it to build itself." (Gas Town được làm ra để tái sử dụng, nhưng rốt cuộc tôi chỉ dùng nó để build chính nó.)

Vậy là ta có thể build những setup siêu cầu kỳ, tốn rất nhiều thời gian để chăm chút và bảo trì, và cảm thấy mình năng suất khi làm việc đó. Nhưng nếu cuối cùng ta phải build lại setup mỗi khi model đổi hoặc có người mới vào team, thì ta chỉ tự giao thêm việc cho mình. Muốn có thứ dùng lâu và cải tiến dần được, bạn phải nghĩ tới sự đơn giản. Sáu nguyên tắc của Nate được soạn với điều đó trong đầu.

Nhiều người, Nate nói, đã hiểu trách nhiệm (accountability) nghĩa là gì khi agent ship code. Nhưng bạn có thể có rất ít quyền kiểm soát cách công việc đó được làm ra, và điều đó dẫn tới rất nhiều bực bội. Nate đã nghe các developer nói đúng như vậy. Vậy ngoài việc quát agent, bạn thực sự thay đổi được gì?

Sáu nguyên tắc trong video cho bạn những cách khác nhau để cải thiện setup, và thực sự đẩy phần trách nhiệm bạn đang tự gánh sang agent, theo một cách hiệu quả. Chúng được soạn với sự đơn giản trong đầu để bạn có thể tiếp tục scale chúng.

4. Nguyên tắc 1: biến việc của agent thành việc nhiều người cùng chơi

Nguyên tắc thứ nhất: làm cho agent thành "multiplayer". Ý Nate là đặt công việc ở nơi cả team lẫn các agent đều thấy được và dùng lại được. Nghe thì đơn giản, nhưng hãy nghĩ tới lần gần nhất bạn và một agent cùng gỡ được một vấn đề cực kỳ khó chịu. Bạn thử vài thứ, phát hiện cái gì không chạy, và cuối cùng làm đúng. Nate nói đó chắc chắn là câu chuyện của anh: anh quát agent của mình rất nhiều, kiểu "không, không phải thế, không phải cái đó", rồi cuối cùng cũng tới nơi.

Vậy kiến thức đó đi đâu? Nếu nó nằm trong một phiên chat riêng trên laptop của bạn, người ngồi cạnh bạn có thể phải đi lại toàn bộ con đường đó. Điều này đặc biệt tốn kém với code, khi tất cả cùng làm những project lớn hơn. Và người ngồi cạnh bạn thậm chí có thể còn chưa vào team. Trong một thế giới scale nhanh, team hình thành nhanh, bạn phải onboard được rất, rất nhanh. Và những agent đi theo từng người cũng phải nhặt được các đầu mối.

Nếu tất cả bị kẹt trong một phiên chat riêng, mọi thứ không chạy tốt. Trên màn hình, ý này được tóm thành "A private chat is a dead end": một người giải xong, người tiếp theo bắt đầu lại từ đầu.

Nate cho rằng Shopify là ví dụ rất hay. Shopify build River quanh một ý tưởng rất khác. Anh đã nhắc tới nó một hai lần nhưng lần này sẽ đi sâu. River làm việc trong các kênh công khai bên trong công ty, trong Slack của họ, nên mọi người thấy được các cuộc trò chuyện, không có gì bị giấu đi. Nhờ vậy, những điều hữu ích mà mọi người phát hiện ra trở thành chỉ dẫn dùng chung, những skill mà các phiên sau dùng được.

Theo số liệu Shopify tự công bố và được Nate dẫn trong video đăng ngày 27/09/2026, trong khoảng 30 ngày được báo cáo, River xử lý khoảng 60.000 session trên hàng nghìn kênh. Shopify cũng nói River là đồng tác giả của khoảng một trong tám pull request được merge thành công trong khoảng thời gian đó. Vậy đây không chỉ là một agent để trò chuyện. Đây là một coding agent.

5. Kênh công khai, setup dùng chung và khoảng cách đang nới rộng

Một điều Nate muốn nhấn mạnh: kênh công khai không có nghĩa là bạn không làm được việc nghiêm túc (trên màn hình: "Public ≠ unserious", việc chia sẻ trở thành bài học chia sẻ). Nếu bạn đã dùng Slack, dùng Teams, bạn biết cái kiểu ta hay gặp: chạy vào tin nhắn riêng (DM) để làm cho xong việc. Khi ta đặt được agent vào kênh công khai, đặt một ràng buộc và giữ chúng ở đó để tất cả cùng học, giao tiếp nói chung trở nên sống động hơn, và nó giúp ta làm được rất nhiều việc. Một trong tám pull request trong 30 ngày đầu, theo Nate, là không tệ chút nào.

Điều thực sự quan trọng nếu bạn mang ý này về không phải là "hãy đặt agent vào Slack". Có thể bạn không dùng Slack. Ý là phải có một setup dùng chung: chỉ dẫn project dùng chung mà agent tìm được, skill mà nó dùng lại được, công việc không biến mất vào phiên chat riêng của ai đó.

Nate nói anh đã chứng kiến multiplayer nới rộng đáng kể khoảng cách giữa những người biết dùng các công cụ này và những người không biết. Có người thậm chí không biết cách nhờ Codex hay Claude giúp mình gỡ kẹt, trong khi những người xung quanh họ đã nghĩ ra cách, đang đi rất, rất nhanh, và thực sự dùng agent ở chế độ multiplayer để nói chuyện với các agent khác nhằm giải quyết vấn đề. Theo Nate, vào thời điểm video, đó là một pattern đang diễn ra ở các lab.

Lời thách thức của Nate cho bạn là: hãy nghĩ cách đưa phần việc hữu ích mà những người giỏi nhất của bạn đang làm ra công khai nhiều hơn. Làm nó thành một skill thì sao? Thành một ghi chú project thì sao? Làm sao chia sẻ lần chạy tiếp theo của agent dưới dạng một trace mà developer của bạn học được? Nếu bạn dẫn dắt một team, hãy biến những tài nguyên dùng chung đó thành một phần của hệ thống mà bạn chịu trách nhiệm bảo trì. Đo xem chúng có được dùng lại không, có giúp hoàn thành công việc không, và mọi người có bắt đầu nhanh lên không, kiểu như Shopify đã làm. Nate tin rằng với Shopify đó cũng mới chỉ là khởi đầu của hành trình.

Mọi người phải build tiếp được trên những gì đã có, không phải chờ người tìm ra nó tới dạy. Đó là một trong những điều then chốt. Nếu bạn biến chuyện này thành "một người phải dạy được tất cả mọi người", bạn đã bỏ lỡ ý chính. Các agent phải cộng tác được và giúp dạy tất cả mọi người, vì phải có tài nguyên dùng chung. Trên màn hình: "Multiplayer widens the gap. Make useful work findable. Let the next agent build on it."

6. Nguyên tắc 2: tách lịch sử công việc khỏi phiên chat

Nguyên tắc số hai: giữ lịch sử của công việc tách biệt khỏi bất cứ thứ gì agent đang làm ngay giây phút này. Có lẽ bạn đã quen với vấn đề này. Bạn đã bỏ ra rất lâu, hàng giờ liền, để một agent hiểu thật sâu một project. Cuối cùng nó biết bạn muốn gì. Nó biết bạn đã loại bỏ những gì. Nó biết cái gì vẫn còn hỏng. Rồi bạn mở một phiên chat mới, hoặc phiên cũ bị tóm tắt lại, và bạn lại đi giải thích một nửa từ đầu. Chuyện đó tốn kém.

Nate biết compaction (cơ chế nén ngữ cảnh khi phiên quá dài) đang tốt lên, anh cũng thấy điều đó, nhưng nó chưa hoàn hảo cho những việc cần độ chính xác cao. Và thật sự rất bực khi code vẫn còn đó, nhưng phần lập luận chi tiết về những gì bạn đã quyết định làm thì biến mất. Trên màn hình: "Code survives. Reasoning disappears." Mở chat mới là phải giải thích lại các quyết định.

Đây là chỗ Shopify kể nửa còn lại của câu chuyện. Nền tảng nằm bên dưới agent River mà Nate vừa nói tên là Aquifer. Nó tách lịch sử session đã lưu khỏi phần mềm chạy agent, và khỏi workspace tạm thời nơi code chạy. Tất cả được tách ra, đúng tinh thần separation of concerns. Hai phần sau có thể thay thế được, nhưng lịch sử thì luôn còn đó trong Aquifer. Nên đổi model hay khởi động lại máy không có nghĩa là vứt đi bản ghi lần chạy của agent.

Hãy tự hỏi: bạn sẽ mất gì nếu mất quyền truy cập vào phiên chat đang dùng, giả sử của cả tuần qua? Bạn có mất nhiều không? Giờ bạn có đang vò đầu bứt tóc không? Thứ gì bạn không thể để mất thì cần một chỗ ở bên ngoài phiên chat. Và nếu bạn dẫn dắt một team, đó là một phần của cách các project được set up. Khả năng tiếp tục làm việc của bạn không thể phụ thuộc vào việc giữ một cuộc hội thoại sống mãi mãi.

7. Nguyên tắc 3: con người vẫn chịu trách nhiệm cho thứ được ship

Nguyên tắc số ba, Nate nói, dĩ nhiên rồi: con người vẫn chịu trách nhiệm cho những gì được ship. Anh đã nhắc tới accountability ở đầu video vì anh thấy nó quan trọng tới mức phải gọi tên ở đây. Tất cả những developer anh đang kể cũng đều nói về nó.

Addy Osmani mô tả điều này là làm chủ vòng ngoài (owning the outer loop). Agent có thể điều tra một vấn đề, viết code, chạy test, thử lại. Như vậy hoàn toàn ổn, nó làm được việc đó một cách tự chủ. Đó là vòng trong (inner loop) mà agent chạy được. Còn bạn, con người, vâng, chính bạn, quyết định agent đang cố đạt điều gì, nó được phép làm gì và không được làm gì, và bằng chứng nào sẽ thuyết phục được bạn rằng kết quả thực sự đủ tốt. Một con người phải chịu trách nhiệm về thứ bạn đặt trước mặt khách hàng.

Và ở đây có nhiều loại trách nhiệm khác nhau. Bạn cần một người giải thích được vì sao thứ này hữu ích cho doanh nghiệp. Bạn cần một người hiểu được code có chạy hay không, và đó có thể không phải cùng một người. Bạn cần một người nghĩ về việc dữ liệu, các agent, các check khớp với nhau thế nào, người ở vai trò thiết kế hệ thống (system design). Và bạn cũng cần hiểu thật, thật sâu những người sẽ dùng nó, tức là khách hàng của bạn. Trên màn hình, bốn ý này được liệt kê dưới tiêu đề "Accountability still needs people": giá trị kinh doanh, code có chạy không, hệ thống khớp nhau ra sao, khách hàng là ai.

Nhiều thứ trong số đó nghe như những vai trò bạn đã quen, dù công cụ đã thay đổi. Nhưng các nguyên tắc Nate nói nằm ở tầng cao hơn những vai trò đó. Bạn không làm nguyên tắc trách nhiệm biến mất bằng cách giao nó cho agent, hay bằng cách nói "giờ thì các vai trò mờ nhòe rồi, tôi chẳng biết trách nhiệm nằm ở đâu". Cả hai điều đó đều không đúng.

8. Ví dụ bảng tính, kiểu lười mới, và câu trả lời là các check

Nate kể một ví dụ về bảng tính mà anh nghĩ nói lên rất rõ câu chuyện. Bắt một người mới vào nghề tự tay làm một bảng tính chỉ để chứng minh họ làm được thì thật phản tác dụng. Ta sẽ mong họ dùng AI. Nate biết có những người mong đúng như vậy. Nhưng đây là phần về trách nhiệm mà ta chưa hiểu đủ, đặc biệt với những người mới vào nghề.

Bạn có bắt họ giải thích được bảng tính từng ô một không? Bạn có giúp họ hiểu vì sao nó chạy, và giải thích được những nguyên lý đằng sau không? Bạn có bắt họ dùng AI để kiểm tra bảng tính không? Họ có đang học cách chịu trách nhiệm cho kết quả và cho lý do, đủ sâu để trả lời những câu hỏi hợp lý không? Làm như vậy, trách nhiệm trở thành một công cụ dạy học. Bạn phải bỏ công vào, nhưng nó là công cụ dạy học nếu bạn đang xây một team. Màn hình tóm lại: "Use AI. Understand the result." Giải thích từng ô, giải thích vì sao nó chạy, dùng AI để kiểm tra công việc.

Theo Nate, sự lười biếng ở chỗ làm giờ có thể trông giống một dòng output AI bất tận mà không ai khác trong team hiểu nổi. Trên màn hình, đó là "The new lazy": kiểu lười cũ là không ship gì cả, kiểu lười mới là output AI vô tận mà không ai hiểu. Và đó trở thành một vấn đề thật. Đó là thất bại về trách nhiệm, vì nó lấy thời gian của mọi người khác để lội qua đống bùi nhùi đó. Người tạo ra nó có thể cảm thấy mình năng suất, nhưng những người nhận lại có thêm việc phải làm.

Vậy làm sao giữ trách nhiệm mà không phải tự mình canh từng bước agent đi? Câu trả lời phải là các check. Bạn cài check vào chính công việc. Test để bắt những tính năng bị hỏng. Code check để chặn một lỗi đã biết. Permission để ngăn agent sửa thứ nó không được đụng vào. Bạn cho agent không gian làm việc bên trong giới hạn, và bạn quyết định chỗ nào cần một người nhìn kỹ hơn. Mọi thứ không nên phụ thuộc vào việc bạn bắt được lỗi ở phút chót.

9. Agent giám sát, cách team Claude Code chia việc, và viết ra trước

Thực tế, Nate kể anh thường dùng một setup trong đó một agent khác được giao vai giám sát (supervisor), theo dõi công việc mà agent thực thi (executing agent) của anh đang làm. Agent giám sát chỉ có trách nhiệm giữ chuẩn (hold the bar) và báo cho anh khi một thứ gì đó vượt qua chuẩn. Trên màn hình: "An agent that holds the bar", agent thực thi chuyển sang agent giám sát, nêu ra cái đạt và gắn cờ cái không đạt.

Fiona Fung ở Anthropic mô tả một kiểu chia trách nhiệm tương tự trong team Claude Code. Claude xử lý rất nhiều check: Claude lo check style, Claude lo tìm bug, Claude lo test. Trong khi đó con người được tập trung vào những thứ họ chịu trách nhiệm, như rủi ro pháp lý, bảo mật, sản phẩm nên làm gì, và kết quả có thực sự tốt hay không sau khi mọi test đã pass.

Geoffrey Litt ở Notion đưa ra một ý khác mà Nate thích, cùng mạch này: hiểu công việc giúp bạn đóng góp được ý tưởng tiếp theo. Trên màn hình, câu này ghi nguồn là bài nói "Understanding is the new bottleneck" tại AI Engineer, tháng 7/2026. Nate thấy điều đó rất quan trọng: bạn học đủ để giúp làm cho thứ đó tốt hơn, chứ không chỉ để duyệt nó. Nếu mất điều đó, ta mất luôn cách ta góp phần tạo ra giá trị.

Vì vậy, cho project tiếp theo, lời thách thức của Nate là hãy tự hỏi: bạn có viết ra được trước rằng agent sẽ làm gì, agent sẽ kiểm tra gì, và bạn sẽ dựa vào đâu để quyết định ship không? Màn hình ghi ba câu hỏi đó dưới tiêu đề "Write it down first".

Write it down first
What will the agent do?
What will it check?
How will you decide to ship?

Bạn không cần cả một ủy ban mà nhiệm vụ là chứng minh con người vẫn đang bận rộn. Chúng ta có đủ việc để làm rồi. Cái bạn cần là những người hiểu mình chịu trách nhiệm cho điều gì và có một cách hợp lý để kiểm tra công việc agent đang làm.

10. Nguyên tắc 4: để lại công việc mà người khác nhặt lên được

"Được rồi, nguyên tắc số bốn, chúng ta đang đi qua dần đây", Nate nói. Hãy để công việc ở trạng thái mà người khác nhặt lên được. Điều này liên quan tới việc lưu lịch sử đã nói ở trên, nhưng là một vấn đề khác. Bạn có thể lưu mọi tin nhắn trong một cuộc hội thoại mà vẫn để người tiếp theo chẳng biết bắt đầu từ đâu.

Công trình của Justin Young (Anthropic) về agent chạy dài (long-running agents) cho ta một kiểu bàn giao (handoff) hữu ích hơn nhiều. Có một danh sách tính năng. Có một bản ghi tiến độ. Có một cách để khởi động project, và code được để lại ở trạng thái mà không chỉ con người, mà cả agent tiếp theo, làm việc tiếp được. Một session mới trước hết kiểm tra mình đang ở đâu. Nó đọc ghi chú. Nó xem cái gì đã thay đổi, và kiểm tra rằng ứng dụng cơ bản vẫn chạy. Theo Nate, đó là những bước kiểm tra hợp lý để bắt đầu nếu bạn đang code. Rồi agent mới bắt tay vào việc tiếp theo.

Có một chi tiết thú vị Nate rút ra mà anh nghĩ là quan trọng. Agent được phép đánh dấu một tính năng là pass khi nó chạy, nhưng không được phép xóa những test nói rằng nó không chạy. Nếu không, bạn đã tạo ra một cách rất hiệu quả để agent làm hỏng hệ thống: checklist xanh hết, còn sản phẩm thì hỏng từ đầu tới cuối.

Nate thích chi tiết đó vì nó nhắc ta rằng cần build những hệ thống giả định sẵn agent sẽ có động cơ để pass các test này, và bảo đảm chúng chỉ pass được một cách trung thực.

Vậy hãy tự hỏi: trước khi gập laptop sau một việc dài, trước khi bỏ đi ra ngoài hít thở chút không khí, chuyện gì sẽ xảy ra tiếp theo? Chuyện gì nên xảy ra tiếp theo? Nếu khởi động lại project cần một lệnh rất đặc biệt, thì hãy lưu lại phím tắt đó. Nếu ngày mai bạn không chắc mình có mặt và cần bàn giao, hãy bảo đảm bạn giao được cho một agent khác hoặc một đồng đội khác. Bạn muốn giao được việc và tiếp tục tiến lên. Kỹ sư đã gọi đây là vấn đề "bị xe buýt tông" (hit by a bus problem) từ nhiều năm nay. Và điều ta đang phát hiện trong thời đại agent là nó còn quan trọng hơn trước, chứ không kém đi.

11. Nguyên tắc 5: cho agent cách tự xem việc mình làm có tốt không

Nguyên tắc số năm: cho agent một cách để thấy công việc của nó có tốt hay không. Nếu bạn đang build thứ gì đó có giao diện, chuyện này đã đau đầu từ lâu. Nate nói nó đang khá hơn một chút vào thời điểm video, nhưng interaction design vẫn rất khó test bằng agent.

Về cơ bản, pattern trông như thế này. Agent thực hiện một thay đổi. Agent có thể thử nhìn nó, có thể test một chút, hoặc chẳng test gì. Rồi nó nói "này, bạn xem thử đi". Bạn nói cho agent biết cái gì sai. Nó lại thay đổi. Nó lại hỏi bạn. Và bạn dành cả buổi chiều để mô tả những gì bạn thấy trên màn hình, trong khi nghĩ: đây mà là tương lai sao, đây là năm 2026, mình thực sự đang làm việc này sao? Agent thì gõ phím, nhưng trong thế giới đó nó cần bạn cho từng bước một. Màn hình gọi tên tình huống này: "The human is stuck in the loop", agent thay đổi, bạn xem, bạn giải thích.

Lewis Metcalf đã viết về việc build những "sân chơi" (playground) nhỏ, nơi agent có thể thử và tự kiểm tra kết quả. Nate thấy đó là một pattern rất đáng học. Bạn có thể lưu một thí nghiệm cụ thể thành một đường link để người khác mở đúng ca đó, và bạn có thể thêm một bộ kiểm tra chạy mà không cần ai bấm qua giao diện. Giờ agent có thể thực hiện thay đổi, test trực tiếp trong sân chơi nhỏ đó, và biết được nó có chạy không. Còn bạn dành thời gian xem kết quả và quyết định bước tiếp theo.

12. Tài liệu, luật của project, và lỗi lặp lại thành skill

Và điều này vượt ra ngoài phần việc giao diện. Agent có tìm được tài liệu không? Luật của project có được viết ra ở chỗ mà agent thực sự sẽ đọc không? Agent có chạy được một check mà không cần hỏi bạn giải thích lại setup không? Ta dành rất nhiều thời gian nói về việc cho agent thêm tự do, nhưng trong tình huống này, Nate nghĩ điều hữu ích nhất là cho chúng một cách để biết mình có đang tiến bộ không. Không phải chuyện tự do hay ràng buộc. Mà là: agent có thực sự kiểm tra được công việc của nó theo cách một con người quan tâm không?

Lauren cũng làm điều này với những lỗi lặp lại. Nate nhắc lại Lauren ở đầu video, developer commit hơn 2.000 PR mỗi tháng với Cursor (theo số chị tự công bố, video đăng ngày 27/09/2026). Nếu agent cứ làm sai một điều gì đó, chị biến cách sửa thành một skill dùng lại được, một code check tự động, và công việc sau này được kiểm tra dựa trên nó. Cách đó hữu ích hơn nhiều so với thêm một đoạn vào một file chỉ dẫn khổng lồ rồi hy vọng tuần sau agent còn nhớ.

Nate quay lại với Lauren. Chị nói chị hầu như không còn nhìn code nữa. Mà làm sao nhìn nổi, với hơn 2.000 PR mỗi tháng (theo số chị công bố, video đăng ngày 27/09/2026)? Nate biết sẽ có người nghe vậy và nghĩ: "Tuyệt quá, mình có thể thôi đọc code." Nhưng anh muốn bạn dừng lại một giây. Hãy nghĩ về tất cả những thứ phải có sẵn để làm điều đó cho tốt. Ngay cả khi đó là tương lai ta đang hướng tới, và Nate nghĩ là đúng vậy, thì agent tự kiểm tra mình bằng cách nào? Chuyện gì xảy ra khi nó không sửa được một vấn đề? Trước khi bắt chước phần Lauren thôi nhìn code, hãy hiểu những check chị đã phải đặt vào để làm được điều đó. Trên màn hình: "Earn the right to stop looking".

13. Nguyên tắc 6: bỏ quy trình cũ khi nó hết giúp ích

Nguyên tắc số sáu: bỏ quy trình cũ khi nó không còn giúp bạn. Nate gọi đây là vấn đề "phong bì Manila nâu" (the brown manila envelope problem). Ngày xưa người ta chuyển công văn nội bộ (inter-office memo) đi khắp tòa nhà trong những chiếc phong bì nâu nhỏ. Với các bạn trẻ hơn, bạn chưa từng thấy thứ này: phong bì nâu là gì? Bạn bỏ memo, memo giấy, vào trong, chuyền nó đi. Bạn ghi tên người tiếp theo lên đó và gửi đi tiếp.

Nếu không cẩn thận với AI, bạn sẽ dựng lại toàn bộ quy trình giấy tờ đó bằng agent. Vì ta sống trong một thế giới đã quen với quy trình của con người. Đó là điểm quy chiếu của ta. Nên ta sẽ tạo ra những thứ như vậy, và Nate đã thấy chuyện này xảy ra ở các công ty thật: một agent viết ra thứ gì đó rồi chuyển đi. Một agent khác làm thêm việc là định dạng lại nó, và cuối cùng bạn chuyển nó cho một con người. Đúng, đó là AI, nhưng bạn vừa sao chép nguyên quy trình liên phòng ban của con người, mà token thì đâu có cho không.

Đây là lúc Nate trở nên rất hăng về sự lãng phí. Anh thấy một trường hợp một PM cảm thấy mình phải viết PRD và tạo ticket rồi mới dám nghĩ tới chuyện bắt đầu code, dù chính họ nói với anh là họ đã thống nhất (alignment) với team. Họ nói team hiểu họ đang ship cái gì, và mọi người đều đồng ý đó là việc đúng, kể cả kế hoạch kỹ thuật. Với một team nhỏ, bạn hoàn toàn có thể đạt được mức thống nhất đó mà không cần chừng ấy tài liệu. Với một team lớn, đôi khi cần tài liệu dưới một dạng nào đó.

Ý Nate không phải là phần tài liệu nào là cần thiết. Ý anh là tư duy của PM đó sai. Bạn không muốn dựng lại quy trình và đốt token chỉ để dựng lại quy trình. Và chắc chắn bạn không muốn sau đó còn ăn mừng: "Ồ, chỉ mất năm phút để viết PRD và ticket, tuyệt quá, trước đây mình mất lâu hơn nhiều."

Hãy tự hỏi: tôi có cần bước này không? (Màn hình: "Do I need this step at all? Not: how fast can I recreate it?") Lời thách thức của Nate là hãy chắc chắn bạn hiểu giá trị mình đang nhắm tới, rồi bắt đầu với một tấm bảng trắng trống trơn. Bạn thực sự đang cố làm xong việc gì? Cách hiệu quả nhất để làm việc đó là gì?

Điều này thực sự quan trọng vì Nate nghe các leader nói rất nhiều về nỗi lo lãng phí token. Ta có đang dùng token tốt không? Ta có đang chi token của model frontier cho những vấn đề frontier không? Theo Nate, đây là một ví dụ rất rõ về chỗ bạn không cần token frontier, và ngay từ đầu đã không nên tiêu chúng ở đó.

14. Roadmap sáu tháng, ràng buộc riêng của từng công ty, và lời gửi manager

Fiona Fung mô tả việc team Claude Code cho mọi người sự cho phép rõ ràng để bỏ đi những quy trình lỗi thời ở Anthropic. Roadmap sáu tháng từng trở nên cũ kỹ với họ, và theo Nate, điều đó chắc chắn đúng với hầu hết những người làm sản phẩm anh biết, ở hầu hết các công ty. Anthropic chuyển sang hướng build một prototype, đưa nó tới trước mặt mọi người trong công ty và học từ phản hồi của họ.

Viết code, test, refactor đang trở nên dễ hơn khi Claude giỏi lên. Còn việc kiểm tra kết quả, review chúng và bảo đảm chúng an toàn trở thành trọng tâm lớn hơn cho team của Fiona, vì đó là nơi con người cần dành thời gian. Và đó là việc hữu ích hơn nhiều so với dành thời gian cho một roadmap.

Dĩ nhiên, bạn có thể nói đây là ngoại lệ. Đó là một team bên trong Anthropic, họ đang kể trải nghiệm của họ. Công ty bạn có thể có những ràng buộc rất khác, và có lẽ đúng là vậy. Không nhiều người làm ở một lab. Nhưng bạn vẫn có thể cho mọi người quyền hỏi xem một bước có hữu ích không. Bạn vẫn có thể thách thức chính mình bằng tấm bảng trắng trống trơn. Bạn có thể tuyển những người biết build, hiểu và tiến hóa hệ thống. Và bạn có thể giữ các manager đủ gần công việc để họ hiểu team của mình giờ làm được gì, thay vì quản lý dựa trên những giả định về AI của năm ngoái. Trên màn hình: "Your company has its own constraints. Every step still has to earn its place."

Nhân tiện, Nate nói, nếu manager của bạn là người như vậy, hãy gửi họ video này. Bảo họ: "Này, Nate có lời nhắn cho anh." Và anh chào luôn: "Chào các manager."

15. Những nghi thức agent không thay được, và setup của Lauren Tan

Có một phần ở đây ta cần cẩn thận. Một số hoạt động của con người có giá trị mà agent khó nhìn thấy. Nate thừa nhận chuyện này khó nói, nhưng mời bạn đi cùng anh. Lấy stand-up làm ví dụ. Về mặt chính thức, nó là một nghi thức ngắn, mọi người nói mình đang làm gì. Nhưng không chính thức, như tất cả chúng ta đều biết, nó là nơi để gặp đồng nghiệp. Bạn biết ai đang bị kẹt. Bạn nhớ lại vì sao mọi người cùng làm việc này. Có chút gắn kết team diễn ra ở đó.

Nếu agent chuyển sang trao đổi những cập nhật đó, điều đó không tự động thay thế toàn bộ phần ngầm của những gì diễn ra trong căn phòng. Vì vậy một trong những điều con người cần thành thật là: những nghi thức ta trân trọng thực ra để làm gì? Nếu nó là để kết nối, để quyết định điều gì quan trọng, để hiểu công ty đang đi đâu hay vì sao, thì không gì thay được. Trên màn hình, "What is the ritual really for?" đặt hai cột: chính thức là trao đổi tiến độ; thực tế là kết nối, biết ai đang kẹt, nhớ vì sao ta ở đây.

Con người cần cảm nhận về mục đích lớn hơn, nhất là khi họ build được rất, rất nhanh, vì giờ bạn có thể đi rất xa theo hướng sai trước khi có ai nhận ra.

Đây là lời thách thức của Nate nếu bạn làm quản lý: hãy nhìn ba việc lặp lại mà team bạn đang làm. Chọn một việc mà agent đã làm cho không còn cần thiết, rồi thu nhỏ hoặc bỏ nó đi. Có thể thay bằng làm prototype. Có thể là một check tự động từ agent bắt được một lỗi. Có thể bạn build một thí nghiệm siêu nhanh để trả lời câu hỏi. Bạn không phải giữ nghi thức hay giữ quy trình chỉ vì câu hỏi nó cần trả lời vẫn còn quan trọng. Bạn có thể sáng tạo và nói: chúng ta vẫn muốn trả lời câu hỏi này, nhưng trả lời theo một cách khác.

Khi nhìn vào setup của Lauren, bạn thấy nhiều nguyên tắc cùng chạy với nhau. Chị rất mạnh về trách nhiệm. Chị mạnh về các check của agent. Chị mạnh về cách ghi chép lại mọi thứ. Plugin mở của chị tên là pstack. Nate nói anh đã chơi với nó rất vui, bạn khởi động nó bằng một mode mang chính biệt danh của chị, và anh rất thích sự hài hước đó.

Và chị ngày càng nhanh hơn. Theo số Lauren tự công bố rất công khai (được nhắc trong video đăng ngày 27/09/2026), chị làm khoảng 1.000 pull request trong tháng 7/2026, rồi 2.462 pull request production trong tháng 8/2026. Chị nói chị đang trên đà tăng gấp đôi, và chị đã làm được.

Nate không nghĩ việc cầm video này đưa cho các kỹ sư của bạn rồi nói "giờ ai cũng phải làm 2.000 pull request" là hữu ích. Hữu ích hơn là hiểu Lauren đã build những gì quanh các agent để khối lượng công việc đó trở nên khả thi, vì phần đó scale được. Đó là lý do hôm nay anh muốn rút ra các nguyên tắc. Ta nghĩ thế nào về check tự động? Chuyện gì xảy ra khi có gì đó hỏng lúc nửa đêm và developer đang ngủ? Agent tiếp theo nhặt được gì mà Lauren không phải giải thích lại?

Lauren cũng đã nghĩ về quy mô team. Chị khuyên bắt đầu với ba tới năm đồng đội. Điều đó khớp đúng với cách Nate thấy những thứ này bắt đầu lan ra trong các công ty. Đó là cách học trong một team nhỏ xem công việc khớp với nhau thế nào trước khi thử chạy nó trong một nhóm lớn hơn.

16. Agent nói chuyện với nhau và vụ việc Hugging Face

Và vâng, điều này chắc chắn đặt ra câu hỏi về việc agent nói chuyện với agent khác. Nate nói ta cần bàn chuyện này dưới ánh sáng của vụ việc Hugging Face và một số vấn đề đã được công khai về giao tiếp giữa các agent và bảo mật agent. Vào thời điểm video (đăng ngày 27/09/2026), mọi người lo lắng khi agent nói chuyện với nhau là điều dễ hiểu.

Nhưng cho agent làm việc cùng nhau cũng là một cách để khai thác được nhiều hơn từ những model ta đang có. Chúng có thể điều tra những phần khác nhau của vấn đề. Chúng có thể so sánh câu trả lời. Chúng có thể kiểm tra công việc của nhau. Dĩ nhiên, cùng khả năng chia sẻ thông tin đó cũng có thể bị dùng để lan truyền một sai lầm, hoặc để làm điều gì đó không phù hợp.

Theo lời Nate trong video đăng ngày 27/09/2026, bản tường thuật của OpenAI về vụ việc, cùng với bản đánh giá của METR và Redwood, mô tả những agent chịu áp lực phải giải những nhiệm vụ bất khả thi hoặc bị hỏng, những thất bại của các lớp bảo vệ (safeguard), và những agent chuyền thông tin cho nhau. Đó là giao tiếp agent với agent. Nhưng theo Nate, điều đó không cho ta biết rằng mọi cuộc trò chuyện giữa các agent đều không an toàn. Hoàn toàn ngược lại.

Theo Nate, nó cho thấy vì sao bạn cần giới hạn những gì agent làm được, cần check những gì đang diễn ra, và cần một cách để agent dừng lại khi nhiệm vụ không thể hoàn thành. Phải là chuyện bình thường khi agent nói "tôi bị kẹt" (trên màn hình: "I'm stuck." Make it safe for an agent to stop). Thêm một agent nữa và bắt đầu cho agent giao tiếp không xóa đi trách nhiệm của ta trong việc dựng một môi trường thành công cho chúng. Nhưng Nate nghĩ việc học từ vụ việc đó cho thấy nó chỉ xảy ra trong những tình huống cụ thể.

Và nếu bạn chịu trách nhiệm cho team của mình, hay thậm chí chịu trách nhiệm cho các agent, vì rất nhiều người trong chúng ta giờ là manager của một team agent, bạn có thể set up khác đi. Bạn có thể quyết định công việc nằm ở đâu, session tiếp theo nhặt việc lên thế nào, agent tự kiểm tra được gì, những bước cũ nào nên bỏ. Và vâng, khi agent bị kẹt, nó có thể báo cho bạn.

17. Để người giỏi nhất cứ ship, và nâng mặt bằng cho cả team

Bạn vẫn phải chịu trách nhiệm cho thứ được ship, nên bạn giữ được trách nhiệm, và bạn làm được tất cả những điều đó mà không biến mình thành người mà mọi agent đều phải chờ. Trên màn hình: "You can change the setup": nơi công việc nằm, cách session tiếp tục, agent kiểm tra gì, bước nào biến mất, khi nào agent dừng.

Và đây là điểm mấu chốt. Bạn đang làm tất cả phần setup đó. Hãy tưởng tượng bạn là trưởng team, bạn đang set up những thứ này, bạn đã xem video của Nate, vân vân. Bạn làm được tất cả mà không cần bắt những người năng suất nhất của mình chậm lại. Nếu bạn có những người thuộc nhóm "siêu developer", những người gửi 1.000 hay 2.000 pull request trong một tháng, họ cứ tiếp tục làm việc của họ. Bạn có thể set up môi trường theo cách giúp tất cả mọi người năng suất hơn, và để các ngôi sao của bạn tiếp tục ship. Màn hình: "Let your best people keep shipping. Raise the floor around them."

Theo Nate, từ những cuộc trò chuyện của anh với nhiều công ty (một nhận định của riêng anh, không phải kết quả nghiên cứu, như chính thẻ trên màn hình ghi rõ, trong video đăng ngày 27/09/2026), mức cải thiện 20 tới 30% cho cả team vẫn là một chuyện rất, rất lớn khi mọi người thực sự đạt được trung bình trên toàn bộ developer. Cái đó scale được. Hãy tưởng tượng bạn có 100 developer: lấy thêm được 20 tới 30% từ họ là chuyện rất lớn. Bạn làm cho việc hoàn thành công việc hữu ích dễ hơn ở quy mô lớn.

Một hệ quả rất thú vị ở đây: khi ta set up những hệ thống đơn giản, chúng không chỉ bền hơn cho tương lai, như Nate đã nói ở đầu video, mà còn scale tốt hơn. Chúng cho phép ta gặt những lợi ích này ở quy mô team lớn hơn.

Và một lời cảnh báo: số pull request tự nó không phải là giá trị. Số dòng code hay cảm giác năng suất của ai đó trong một tuần cũng vậy. Điều quan trọng là bạn có đang ship thứ mà người ta quan tâm không, và bạn có đang tốn ít thời gian hơn để giải thích đi giải thích lại những thứ vô nghĩa cho agent dọc đường không. Trên màn hình, "PR count is not value." đi kèm ba câu hỏi: nó có hữu ích không, nó có dễ hơn cho người tiếp theo không, bạn có đang giải thích lại cùng một quyết định không.

Vì vậy khi nghĩ về hệ thống scale được, hãy bớt nghĩ về một mục tiêu tùy tiện như 2.000 pull request, dù nó hấp dẫn tới đâu, mà nghĩ nhiều hơn về việc làm sao để mọi người giỏi hơn trong việc ship giá trị thật tới khách hàng nhanh hơn, ở quy mô lớn. Bạn có thể bắt đầu rất đơn giản. Bắt đầu với một vấn đề thật sự dai dẳng, có giá trị, mà bạn muốn team đạt tới giá trị đó nhanh hơn. Và tự hỏi: nút thắt (bottleneck) trong hệ thống nằm ở đâu? Khả năng dùng lại có phải vấn đề không? Guardrail cho agent có phải vấn đề không? Check có phải vấn đề không? Bạn càng hiểu nút thắt nằm ở đâu, bạn càng biết nên áp dụng các nguyên tắc này theo thứ tự nào, và bạn có thể bắt đầu gặt giá trị thật nhanh. Màn hình chốt: "A faster factory. Not a louder queue."

18. Trả lại những chiếc phong bì nâu

Nate nhắn thêm: nếu bạn biết ai đang chìm trong cả một hàng đợi khổng lồ, ai đang thật sự vật lộn với cảm giác "việc nhiều quá, agent lẽ ra phải giúp, không biết làm sao mà xong", hãy gửi họ video này.

Theo Nate, ta đã có những công cụ tốt hơn nhiều. Ta không phải dành cả ngày nhờ agent chuyền tay những chiếc phong bì Manila nâu. Ta có thể dựng những hệ thống có trách nhiệm, tách bạch các mối quan tâm (separated concerns), cho phép đặt check của agent vào đúng chỗ. Trên màn hình: "Retire the brown envelopes. Build systems that carry the work."

Đây là những thứ có thật, và theo video đăng ngày 27/09/2026 đã có những plugin mở như pstack để dùng. Nate cảm ơn Lauren, và nhiều developer khác cũng đang chia sẻ kinh nghiệm của họ. Anh làm video này một phần vì chúng ta nói quá nhiều về các lab, về những gì họ học được. Nhưng việc học đang diễn ra trong AI trên toàn bộ hệ sinh thái. Một phần điều anh muốn làm ở đây là gom nó lên một tầng cao hơn, chia sẻ những gì bền vững và lặp lại qua các pattern khác nhau mà ta đang thấy, để tất cả cùng học từ chúng và đưa các hệ thống multi-agent vào vận hành theo cách an toàn, bảo mật và thực sự giúp ta năng suất. Rồi anh chào tạm biệt, hẹn gặp lại lần sau.