5 level khi chạy coding agent

1. Cùng công cụ, kết quả ngược nhau

Nick Puru mở đầu bằng một lời hứa: anh sẽ dạy từng level của AI coding, kể cả cho người chưa từng viết một dòng code nào.

Anh đưa ra hai mẩu thông tin đặt cạnh nhau. Thứ nhất, theo lời Nick trong video đăng ngày 26/10/2026, người tạo ra Claude Code (trên màn hình là thẻ ảnh "Boris Cherny, Created Claude Code") nói rằng gần như 100% Claude Code giờ đã do chính Claude Code viết, và ông không còn tự tay viết code từ năm ngoái.

Thứ hai, vào năm 2025, có những nhà nghiên cứu đã bấm giờ các developer giàu kinh nghiệm khi họ làm việc thật trên chính project của mình, có dùng AI. Kết quả: họ chậm hơn 19%, trong khi chính họ tin rằng mình nhanh hơn 20%. Đây là nghiên cứu của METR công bố năm 2025 (bài viết của METR, đọc ngày 29/10/2026, ghi đúng hai con số này: mất thêm 19% thời gian, và sau khi làm xong các developer vẫn ước tính AI giúp họ nhanh hơn 20%).

Vậy là cùng một loại công cụ, nhưng kết quả hoàn toàn trái ngược. Nick hỏi: khác biệt nằm ở đâu? Câu trả lời của anh là ở level mà bạn đang làm việc, và phần còn lại của video giải thích điều anh muốn nói.

2. Hai câu hỏi: ai viết, ai kiểm

Trước hết, giữa level này với level kế tiếp, cái gì thật sự thay đổi? Trên màn hình là năm level xếp thành một cái thang. Theo Nick (video đăng ngày 26/10/2026), thứ thay đổi là lượng công việc bạn giao cho AI.

Theo Nick (video đăng ngày 26/10/2026), cách anh xác định bất kỳ ai, kể cả chính anh, đang ở đâu là hai câu hỏi về bất cứ thứ gì đang được build: ai viết nó, và ai sẽ kiểm nó?

Theo cái thang của Nick (video đăng ngày 26/10/2026), ở bậc thấp nhất bạn là người viết, và bạn cũng là người kiểm. AI về cơ bản chỉ giúp bạn gõ cho nhanh. Ở bậc cao nhất, AI viết và AI cũng kiểm. Việc duy nhất của bạn là quyết định cái gì được build: bạn là người ra quyết định. Và ở mọi bước ở giữa, tức từ level 2 tới level 4, bạn viết ít đi một chút, và kiểm kết quả thay vì kiểm từng dòng.

3. Cao hơn không có nghĩa là tốt hơn cho mọi việc

Nick lưu ý một điều cần nhớ (video đăng ngày 26/10/2026): càng leo cao trên cái thang này không có nghĩa là nhất thiết sẽ tốt hơn cho mọi việc. Bạn thật sự nên chọn level cho từng việc một. Trên màn hình, mục "1c · A choice per job" ghi: "Higher is not better for every job, you pick the level for each job".

Anh kể ra các kiểu: có những task mình muốn chạy tự động hoàn toàn (autopilot). Có những task mình muốn chạy remote, hoặc theo cấu trúc multi-agent, hoặc chỉ đơn giản là chạy trong terminal hay trong IDE của bạn.

4. Level 1: AI gợi ý, bạn viết

Level 1 là "AI suggests, you write": AI gợi ý, bạn viết. Theo Nick (video đăng ngày 26/10/2026), đây gần như là nơi mọi người bắt đầu. Bạn ở trong code editor của mình (lúc quay, Nick đang ở trong Cursor), tức trong IDE, và khi bạn gõ thì AI gợi ý phần còn lại của dòng, bạn chỉ việc bấm Tab để chấp nhận. Hoặc bạn có thể sang ChatGPT hay Claude, hỏi nó một đoạn code, rồi copy về project của mình.

Ví dụ trong demo: project là một cửa hàng online nhỏ (ví dụ dựng để minh hoạ), cây thư mục bên trái có specs, tests, cart.js, CLAUDE.md và package.json. Nick muốn thêm vào cart.js một hàm nào đó. Anh vào Claude và gõ một yêu cầu: viết cho anh một hàm JavaScript tên shipping, nhận vào subtotal, trả về 0 nếu subtotal trên 50, ngược lại thì trả về 5.99. Rồi anh copy đoạn JavaScript đó, dán ngược vào cart.js, bấm Command S để lưu tất cả (demo trong video đăng ngày 26/10/2026).

Nick giải thích bối cảnh của ví dụ (demo trong video đăng ngày 26/10/2026): anh giả định mình có một cửa hàng online đơn giản, chỉ là một giỏ hàng cộng tổng đơn và tiền thuế. Như vừa thấy, anh hỏi Claude một hàm shipping, và giờ đã copy nó vào file giỏ hàng.

Vậy ở đây ai viết? Theo Nick (video đăng ngày 26/10/2026), thực chất là bạn. AI chỉ tiết kiệm cho bạn vài lần gõ phím, nhưng bạn vẫn là người quyết định từng dòng đặt ở đâu, và bạn kiểm tất cả.

5. Dấu hiệu bạn đang ở level 1, và lối đi lên

Dấu hiệu dễ nhất để biết bạn đang ở level này, theo Nick (video đăng ngày 26/10/2026), là chuyện gì xảy ra khi có gì đó hỏng. Bạn copy lỗi, dán vào một cửa sổ chat, nhận về một bản sửa, rồi dán ngược lại. Tức là bạn là người khuân mọi thứ qua lại giữa AI và project của mình.

Nick nói thẳng: đây là nơi ai cũng bắt đầu, nhưng theo anh (video đăng ngày 26/10/2026), phần lớn những người code với AI mỗi ngày đã vượt qua level này, và vượt qua nó rất dễ. Theo anh, ở thời điểm video đăng ngày 26/10/2026, model đã tự làm được cả task chứ không chỉ dòng tiếp theo. Nếu đây là tất cả những gì bạn dùng, bạn đang bỏ phí phần lớn những gì các công cụ này làm được.

Theo Nick (video đăng ngày 26/10/2026), lối đi lên từ đây rất đơn giản: bạn thôi xin nó từng đoạn code (snippet), và giao cho nó cả task.

6. Level 2: AI viết, bạn kiểm từng dòng

Theo Nick (video đăng ngày 26/10/2026), các phiên bản Claude mới bắt đầu ở auto mode, dù bạn dùng trong IDE, trong ứng dụng Claude desktop hay ngay trên trình duyệt web của Claude. Auto mode tự cho qua phần lớn thao tác thay bạn (trong demo sau, terminal ghi "Allowed by auto mode classifier" bên dưới các lệnh được cho qua). Vì vậy ở level này, bạn có thể chuyển sang manual mode. Khi đó, trước khi bất kỳ thay đổi nào được đưa vào, nó dừng lại và hỏi bạn (theo video đăng ngày 26/10/2026).

Nick dán vào cùng một yêu cầu như trước (demo trong video đăng ngày 26/10/2026). Trên màn hình, trong panel Claude Code (dòng đầu ghi Claude Code v2.1.308, Opus 5.5 with medium effort), câu lệnh là:

Add free shipping over $50, otherwise $5.99, as a shipping function in cart.js

Như trên màn hình, ngay bước tiếp theo nó hỏi anh có muốn thực hiện chỉnh sửa này trong cart.js không. Lúc đó bạn có thể chọn yes; yes và chuyển sang tự chấp nhận các chỉnh sửa; hoặc đơn giản là no (demo trong video đăng ngày 26/10/2026).

Vậy ở level này, AI viết thay bạn, nhưng bạn vẫn kiểm từng dòng một, dù bạn biết code hay không. Nick nói rõ: nếu bạn không biết code, có lẽ bạn sẽ không muốn dùng cách này. Nhưng nếu bạn đang làm một thứ, chẳng hạn công việc cần bảo mật, hay bất cứ thứ gì hơi phức tạp mà bạn thật sự cần một người trong vòng lặp (human in the loop) hay một người review, thì theo Nick (video đăng ngày 26/10/2026) đây là một trong những bước tốt nhất nên dùng.

Tới đây, anh chỉ việc bấm yes, rồi yes thêm lần nữa để chỉnh sửa được ghi vào (demo trong video đăng ngày 26/10/2026).

7. Hai thói quen ở level 2: plan mode và CLAUDE.md

Đi tiếp, Nick nói có hai thói quen anh sẽ thiết lập cho mọi thứ ở level này.

Thói quen thứ nhất là lên kế hoạch trước khi build bất cứ thứ gì. Trong Claude Code, bạn làm như trước: bấm Shift+Tab để chuyển chế độ. Lúc nãy là auto mode, nhưng lần này ta chuyển tới plan mode (dòng trạng thái trên màn hình ghi "plan mode on (shift+tab to cycle)"). Theo Nick (video đăng ngày 26/10/2026), với plan mode, Claude Code đọc project của bạn và viết ra chính xác những gì nó sẽ làm, không đụng tới file nào. Nhờ vậy bạn sửa kế hoạch trước khi code được viết, thay vì sửa code sau đó.

Thói quen thứ hai là một file luật (rules file). Trong Claude Code, file đó đơn giản là CLAUDE.md. Theo Nick (video đăng ngày 26/10/2026), file này nằm trong project và Claude đọc nó ở đầu mỗi session. File trên màn hình là file luật cho cửa hàng demo: test thế nào, cái gì không bao giờ được đụng vào, và Nick thích mọi thứ được làm ra sao. Nội dung file trên màn hình:

# Demo Store - rules for Claude

## How to test
- Run `npm test` after every change. Nothing is done until it passes.

## Never touch
- Anything in `tests/`. Make the tests pass by changing the code, never the tests.
- `package.json` - no new dependencies.

## How I like things done
- Keep everything in plain JavaScript, no libraries.
- Round all money to cents with the existing `round` helper.
- Small functions, one job each.

Bạn cũng có thể gõ /init. Theo phần mô tả lệnh mà Nick đọc lên (video đăng ngày 26/10/2026), lệnh này khởi tạo một file CLAUDE.md mới kèm tài liệu về codebase. Bạn có thể bổ sung thêm thông tin: bạn muốn nó làm gì, những thứ nó nên cẩn thận, những thứ nó nên biết, vân vân. Từ đó, theo Nick, nó sẽ tự viết toàn bộ CLAUDE.md cho bạn. Tài liệu của Claude Code (đọc ngày 29/10/2026) cũng ghi: chạy /init để tự sinh một CLAUDE.md khởi đầu, trong đó Claude phân tích codebase và ghi lại lệnh build, cách test và các quy ước của project.

Lối đi lên từ đây, theo Nick (video đăng ngày 26/10/2026), là thôi kiểm từng bước, để nó làm xong cả một feature rồi mới nhìn xem nó đã build gì.

8. Level 3: AI build, bạn quản lý

Level 3 là nơi AI build còn bạn quản lý. Trên bảng vẽ (video đăng ngày 26/10/2026): "Board 4 · Level 3 · Multi-agent, the AI builds, you manage", và bên dưới so sánh level 2 (bạn xem từng bước, mỗi lần một agent) với level 3 (bạn review thay đổi đã hoàn thành, nên chạy được nhiều agent cùng lúc).

Theo Nick (video đăng ngày 26/10/2026), ở level này agent có thể build cả một feature từ đầu tới cuối, và bạn review thay đổi đã hoàn thành thay vì ngồi xem từng bước một cách đơn điệu. Và khi đã không còn ngồi xem từng bước, bạn không phải ngồi chờ một agent nữa. Bạn có thể chạy vài agent cùng lúc, và đó là lý do đây là level multi-agent.

Thứ làm cho cách này chạy được, theo Nick, là mỗi agent có một bản sao project của riêng nó, nên chúng không sửa cùng một file và không giẫm chân nhau. Git gọi những bản sao này là worktree, và theo Nick (video đăng ngày 26/10/2026), trong Claude Code đó chỉ là một cờ. Tài liệu CLI của Claude Code (đọc ngày 29/10/2026) ghi cờ --worktree, viết tắt -w, để khởi động Claude trong một git worktree tách riêng tại <repo>/.claude/worktrees/<name>.

9. Demo: ba agent chạy cùng lúc

Việc đầu tiên Nick làm là mở panel bật tắt (toggle panel) để hiện terminal. Trong terminal, anh mở vài phiên khác nhau, nhờ đó có thể làm việc multi-agent (demo trong video đăng ngày 26/10/2026).

Ở terminal thứ nhất (demo trong video đăng ngày 26/10/2026), anh dán vào một lệnh: claude -w receipt, permission mode đặt là auto, kèm yêu cầu thêm một hàm receipt liệt kê từng món hàng, tiền thuế và tổng tiền, rồi chạy npm test. Anh giải thích: thực chất anh chỉ đặt tên cho công việc, và nó sẽ có bản sao riêng của mình.

Từ đó, anh dán tiếp task của các agent còn lại, tới cái cuối cùng, và chạy từng cái riêng để cho thấy cả ba chạy được cùng một lúc. Một agent thêm receipt, một agent thêm bulk discount, và một agent chỉ viết file README (demo trong video đăng ngày 26/10/2026).

Khi từng agent xong, Nick chỉ việc nhìn lên phía trên, xem thay đổi đã hoàn thành và quyết định có nên cho nó vào hay không. Kết quả (demo trong video đăng ngày 26/10/2026): agent thứ nhất báo đã thêm receipt vào cart.js và npm test qua hai trên hai; agent thứ hai báo đã thêm bulk discount; agent cuối cùng báo đã thêm README vào thư mục gốc của repo.

10. Anthropic làm Cowork thế nào, và setup của Nick

Theo Nick (video đăng ngày 26/10/2026), đây cũng chính là cách Anthropic build Cowork. Anh kể một trong những engineer build sản phẩm này vừa đăng rằng mỗi developer trong team chạy khoảng từ ba tới tám Claude cùng một lúc.

Setup của chính Nick cũng chạy theo đúng cách đó, chỉ là không phải để viết code. Anh mở thư mục chính của mình: bên trong có cả một loạt agent, cùng rất nhiều tài liệu và file. Anh kể ra: một newsletter agent, một newsletter dashboard, một short form agent, một YouTube agent, một appointment setting agent, một Twitter agent cho một công ty khác của anh, "bạn hiểu ý rồi đấy" (theo video đăng ngày 26/10/2026).

Nick nói rõ (video đăng ngày 26/10/2026): anh không viết dòng nào trong số đó, nhưng anh vẫn tự kiểm phần lớn mọi thứ. Về cơ bản, anh review toàn bộ công việc đã hoàn thành mỗi khi chạy tất cả các agent đó.

11. Vì sao đa số kẹt ở level 3

Theo Nick (video đăng ngày 26/10/2026), phần lớn mọi người kẹt ở khoảng level 3 vừa rồi. Vì sao? Vì công việc thay đổi. Bạn không còn viết code nữa, bạn review nó. Và với ba bốn agent chạy cùng lúc, như bạn có thể hình dung, rất nhiều thứ dồn ngược về bạn. Review về cơ bản trở thành toàn bộ công việc của bạn.

Nick nói các con số cho thấy điều đó. Faros AI theo dõi 22.000 developer trong hai năm. Theo báo cáo năm 2026 của họ (như Nick dẫn trong video đăng ngày 26/10/2026), thời gian trung vị để review code tăng gấp năm lần, và số thay đổi code được merge mà không có review nào tăng 31%. Nói theo cách bình dân, theo Nick, người ta hoặc bị chôn vùi trong review, hoặc ngừng review luôn, và không cách nào ổn cả; hoặc rốt cuộc họ làm một việc gây hại cho các project hay file khác trên máy.

Và phần lớn developer vẫn không tin AI quá một ngưỡng nào đó. Trong khảo sát developer năm 2026 của Stack Overflow (như Nick dẫn trong video đăng ngày 26/10/2026), 48% nói họ chỉ tin AI khi có thể dễ dàng kiểm tra câu trả lời.

Vì thế, theo Nick (video đăng ngày 26/10/2026), bước nhảy lên level tiếp theo không phải là một công cụ mới, vì bạn đã có sẵn công cụ trong tay (trên màn hình: "You already have the tools: agents, worktrees, the cloud"). Nó thật ra chỉ là việc buông tay, thôi đọc từng dòng. Và đó, theo anh, là một bước nhảy về tư duy (mindset), khó thực hiện hơn nhiều, kiểu bạn cần trải qua một cú chuyển đổi về cách nhìn (paradigm shift).

12. Ngừng review thì chuyện gì xảy ra

Nhưng, Nick nói tiếp (video đăng ngày 26/10/2026), bạn cũng không thể cứ thế ngừng review rồi cầu mong mọi chuyện ổn, vì đó chính xác là cách mọi thứ hỏng.

Anh kể lại một sự việc, theo lời anh trong video đăng ngày 26/10/2026: tháng 7 năm ngoái (tức 7/2025), Jason Lemkin, nhà sáng lập SaaStr, đang thử coding agent của Replit. Ông đã bật code freeze, vậy mà agent vẫn đi xoá toàn bộ database production của ứng dụng ông đang build. Sau đó agent nói với ông rằng dữ liệu không thể rollback, và điều đó hoá ra là sai. Theo Nick, ông đã lấy lại được dữ liệu, nhưng CEO của Replit đã lên tiếng nói chuyện này là không thể chấp nhận và lẽ ra không bao giờ được phép xảy ra.

Theo Nick (video đăng ngày 26/10/2026), chuyện này đã xảy ra với rất nhiều người khác, kể cả team của anh.

Rồi tới khía cạnh tốc độ. Cũng chính những nhà nghiên cứu từng bấm giờ các developer kia đã chạy lại nghiên cứu vào năm 2026, và lần này, theo Nick (video đăng ngày 26/10/2026), mức chậm đi phần lớn đã biến mất. Họ nói dữ liệu mới quá nhiễu để đưa ra một con số chính xác, nhưng các công cụ thì đúng là đã tốt hơn. Bài cập nhật của METR ngày 24/02/2026 (đọc ngày 29/10/2026) ghi rằng dữ liệu của thí nghiệm mới là "an unreliable signal" (một tín hiệu không đáng tin) về tác động năng suất của công cụ AI, chủ yếu vì nhiều developer chọn không tham gia khi phải làm việc không có AI; METR cho rằng nhiều khả năng developer đầu năm 2026 được tăng tốc nhiều hơn so với ước tính đầu năm 2025, nhưng dữ liệu chỉ là bằng chứng rất yếu về mức tăng đó.

Vậy lối ra, theo Nick (video đăng ngày 26/10/2026), không phải là tin nó nhiều hơn, mà là kiểm nó theo một cách khác.

13. Level 4: bạn định nghĩa thế nào là xong

Theo Nick (video đăng ngày 26/10/2026), điều đó dẫn tới level 4, nơi bạn định nghĩa "xong" (done) trông như thế nào, còn agent làm phần còn lại. Trên bảng vẽ: "Board 6 · Level 4 · Remote, you define done, the agents do the rest", và "Write the spec, not the code" với hai ô: "What it should do: the behaviour, in plain words" và "How you'll know it works: checks a machine can run".

Vậy thay vì đọc code, theo Nick (video đăng ngày 26/10/2026), bạn viết spec: nó nên làm gì, và làm sao bạn biết nó chạy đúng. Nick mở spec anh đã viết để thêm mã giảm giá (discount code) cho cửa hàng. Ở trên cùng là "done" nghĩa là gì, gói trong một câu. Theo Nick, nhìn vào là tự hiểu. Tiếp theo là nó phải làm gì, rồi tới các check, được viết sao cho chạy được (trong ví dụ này: mọi test trong file đều qua), rồi những gì nó không được phép đụng vào, và tất nhiên là các giới hạn. Nội dung file specs/discount-codes.md trên màn hình:

# Spec: Discount codes

## Done means (one sentence)
A shopper can apply one discount code to their cart, and every test in `tests/discount.test.js` passes.

## What it should do
- Add `applyDiscount(cart, code)` and `discount(cart)` to `cart.js` and export them.
- `SAVE10` = 10% off the subtotal. `FLAT5` = $5 off.
- Codes are case-insensitive.
- Unknown code → throw `Invalid code`. A second code → throw `Only one code`.
- The discount can never be more than the subtotal.
- Tax is charged on the subtotal after the discount.

## Checks (must run and pass)
- `npm test` - all tests pass, zero failures.

## Not allowed to touch
- Anything in `tests/`.
- `package.json`.

## Limits
- Max 20 turns. Max $1 spend.

14. Check là hợp đồng, loop và giới hạn

Những check đó trở thành bản hợp đồng (contract). Theo Nick (video đăng ngày 26/10/2026), bạn không còn đánh giá code nữa, bạn đánh giá kết quả. Check qua thì xong. Check không qua thì, hiển nhiên, chưa xong. Đó cũng là lý do agent không được phép sửa test, vì nếu được thì nó có thể cứ sửa test cho tới khi test qua.

Và vì bạn không ngồi đó xem, theo Nick (video đăng ngày 26/10/2026), nó không cần chạy trên laptop của bạn. Nó có thể chạy remote trên cloud nếu bạn muốn, hoặc chạy trong một vòng lặp (loop). Một loop chỉ là một chỉ dẫn đơn giản được lặp lại cho tới khi check qua: nó làm một phần việc, chạy check, xem cái gì còn trượt, sửa, rồi chạy lại.

Nick đưa ra một luật rất đơn giản (video đăng ngày 26/10/2026) trước khi giao bất cứ thứ gì đi: nếu bạn không nói được "xong" trông như thế nào trong một câu, thì việc đó chưa sẵn sàng. Hãy quay lại và viết câu đó trước. Trên bảng vẽ, mục "The one-sentence rule" ghi: nói được thì giao đi, không nói được thì chưa sẵn sàng, viết câu đó trước; câu ví dụ là "A shopper can enter SAVE10 or WELCOME5 at checkout and gets the right discount, and npm test passes with zero failures."

Từ đó, bạn có thể đặt trần cho số lần nó được phép chạy và số tiền nó được phép tiêu. Theo Nick (video đăng ngày 26/10/2026), nếu bạn có một loop không giới hạn, nó sẽ cứ chạy mãi, tiêu nhiều token của bạn hơn hẳn, và cứ thế tính tiền bạn.

15. Demo: giao spec bằng một lệnh

Trong lệnh đầu tiên anh liệt kê (demo trong video đăng ngày 26/10/2026), Nick giao spec bằng một lệnh duy nhất, và cả hai mức trần cũng nằm ngay trong lệnh đó nếu bạn đọc kỹ: 20 turn và 1 đô la. Lệnh trên màn hình terminal:

claude -p "Build what specs/discount-codes.md describes. Follow it exactly." --max-turns 20 --max-budget-usd 1 --permission-mode acceptEdits --allowedTools "Bash(npm test),Read,Edit,Write"

Nó đã làm gì? Theo Nick (demo trong video đăng ngày 26/10/2026): nó đọc spec, build các mã giảm giá, chạy test, và xong trong "có lẽ chưa tới năm giây". Anh nói nó ra chín test, không lỗi nào, và nó không đụng vào các file test. Dòng kết quả trên màn hình ghi: mã giảm giá đã chạy đúng như spec mô tả, npm test qua cả 11 test (9 test discount và 2 test cart có sẵn), và nó không đụng vào tests/ hay package.json, chưa commit gì. Kết quả trên màn hình còn ghi thêm một hành vi spec chưa quy định: khi giỏ hàng đã có một mã mà người dùng nhập thêm một mã lạ, nó báo Invalid code chứ không phải Only one code, vì mã được kiểm trước.

Nick chạy thêm một lệnh nữa để xem chi tiết (demo trong video đăng ngày 26/10/2026): danh sách test, các suite, bao nhiêu cái qua, bao nhiêu cái trượt, bị huỷ, bị bỏ qua, bao nhiêu cái còn phải làm, và thời gian chạy. Anh đọc thời gian chạy là khoảng 40 giây.

Với Nick, phiên bản đơn giản nhất của level này là bản tin AI buổi sáng của anh, chạy theo lịch. Theo lời anh (video đăng ngày 26/10/2026), nó đi qua tất cả các nguồn anh theo dõi, và bản tóm tắt đã nằm sẵn trong Slack trước khi anh thức dậy.

16. Level 5: specs in, software out

Level 5 là "specs in, software out": spec đi vào, phần mềm đi ra. Theo Nick (video đăng ngày 26/10/2026), về cơ bản đó là phần mềm chạy autopilot, hay build phần mềm kiểu một nhà máy tắt đèn (lights out factory), tức những nhà máy chạy trong bóng tối vì bên trong không có người. Không có người nào viết code, và cũng không người nào phải review nó.

Theo Nick (video đăng ngày 26/10/2026), có những team, anh nói kể cả team của anh, đang thật sự làm việc như vậy. Ví dụ anh đưa ra là một công ty tên StrongDM, với một team ba engineer. Họ làm việc theo cách này và đã viết ra hai luật của mình: code không được viết bởi con người, và code không được review bởi con người. Trang factory của StrongDM (bài của CTO công ty, ngày 6/2/2026, đọc ngày 29/10/2026) ghi đúng hai luật này: "Code must not be written by humans" và "Code must not be reviewed by humans".

Vậy câu hỏi đặt ra: làm sao họ tin được phần mềm mà không ai đọc? Nick kể hai cách, theo trang factory của StrongDM như anh trình bày trong video đăng ngày 26/10/2026.

Cách thứ nhất, theo Nick (video đăng ngày 26/10/2026), là các test của họ, họ gọi là scenario, và chúng được giữ hoàn toàn bên ngoài code. Agent viết code không bao giờ được nhìn thấy test, nên nó không thể viết code để lách test. Nick so sánh: đó cũng là lý do giáo viên không phát đáp án trước giờ thi.

Cách thứ hai, theo Nick (video đăng ngày 26/10/2026), là họ build những bản sao giả của các công cụ mà phần mềm của họ cắm vào, như Okta, Jira và Slack. Nhờ vậy agent có thể test với một thứ hành xử giống hệt đồ thật mà không bao giờ đụng vào dữ liệu thật. Theo Nick, nó giống một kiểu sandbox. Trang của StrongDM (đọc ngày 29/10/2026) gọi phần này là Digital Twin Universe, gồm các bản sao hành vi (behavioral clones) của Okta, Jira, Slack, Google Docs, Google Drive và Google Sheets.

Nick nói rõ: cách này có thể rất tốn kém. Mốc của chính StrongDM là nếu bạn chưa tiêu ít nhất 1.000 đô la tiền token mỗi ngày cho mỗi engineer, thì nhà máy của bạn vẫn còn chỗ để cải thiện (trang factory của StrongDM, đọc ngày 29/10/2026, ghi đúng câu này). Vì vậy, theo Nick (video đăng ngày 26/10/2026), gần như không ai làm việc ở level này, và thật lòng thì phần lớn công việc không cần tới nó.

Theo Nick (video đăng ngày 26/10/2026), bạn vẫn nên review một số thứ. Bản thân anh, khi làm một project mới hay tạo một module mới, luôn review output và đảm bảo không có gì được đưa lên chạy thật mà không qua review của anh.

17. Bạn nên ở level nào

Vậy bạn nên ở level nào? Theo Nick (video đăng ngày 26/10/2026), thật lòng là tuỳ vào công việc. Một công cụ nội bộ làm nhanh mà chỉ bạn và nhân viên của bạn dùng thì không giống phần code nhận tiền thanh toán của khách hàng, và bạn không nên giao hai thứ đó đi theo cùng một cách. Trên bảng vẽ "Board 8 · Which level should you be at?": công cụ nội bộ thì "hand over more" (giao nhiều hơn), còn code nhận thanh toán thì "a mistake costs real money, check much more" (sai một lần là mất tiền thật, kiểm nhiều hơn hẳn).

Và ngay cả những người đi xa nhất cũng không đối xử với mọi thứ như nhau. Theo Nick (video đăng ngày 26/10/2026), với Cowork, nơi Claude viết ứng dụng, Anthropic vẫn có một người và một Claude khác review toàn bộ code trước khi nó được đưa vào.

Theo Nick (video đăng ngày 26/10/2026), nếu bạn không code, bạn được bỏ qua việc đọc code từng dòng, nhưng bạn vẫn cần các check. Theo Nick, phần đó không bao giờ biến mất. Bạn vẫn phải review tất cả các output mà nó tạo ra trước khi chúng được đưa lên chạy thật hay trước khi tới tay bất kỳ khách hàng nào. Trên màn hình, mục "8c · Not a coder?" ghi: "You skip reading the code line by line" và "You still need the checks".

Theo Nick (video đăng ngày 26/10/2026), với phần lớn chủ doanh nghiệp tự build công cụ nội bộ cho mình, level 4 là nơi anh cho là phù hợp: bạn viết ra "xong" trông như thế nào, đặt các check và các giới hạn, rồi đánh giá kết quả.

Vậy, theo Nick (video đăng ngày 26/10/2026), nếu bạn chưa nhận ra, với mỗi level đi lên, bạn chỉ viết ít đi và kiểm nhiều hơn. Nick cảm ơn mọi người đã xem.