# AI viết code nhanh, sao dự án vẫn chậm?

[Phong Ho](https://homus.dev/speakers/phong-ho) · [Phong Ho](https://homus.dev/orgs/phong-ho)

> Sáu trạm của quy trình làm phần mềm gốc AI với Claude Code: mỗi trạm một tờ giấy, luật nằm trong tệp, agent tự kiểm, con người giữ cổng.

Topics: Workflow, Coding Agents, Skills

Canonical: https://homus.dev/talks/ai-viet-code-nhanh-sao-du-an-van-cham-quy-trinh-lam-phan-mem-kieu-moi-voi-claude-code

## 1. Tiệm hoa và trang theo dõi đơn nằm im hai tuần

Video mở bằng một câu chuyện về một tiệm hoa, dùng xuyên suốt cả bài. Trong câu chuyện của video, ở tiệm hoa của anh Tùng, điện thoại reo suốt ngày và câu hỏi lúc nào cũng giống nhau: "Hoa của tôi đi tới đâu rồi?". Anh Tùng muốn có một trang để khách tự xem đơn hoa của mình đang ở đâu. Chị Lan lo phần kỹ thuật cho tiệm, và chị giao việc này cho Mây, trợ lý lập trình AI của chị. Mây làm xong phần code chỉ trong một buổi sáng.

![Hình hoạt hình: anh Tùng mặc tạp dề cam đứng trong tiệm hoa, sau lưng là quầy với ba chiếc điện thoại đang sáng](https://homus.dev/photos/6haausRo7R0-0003.jpg)

Cảnh mở đầu: nhân vật anh Tùng, chủ tiệm hoa trong câu chuyện của video, đứng giữa quầy có ba chiếc điện thoại đang đổ chuông, phía sau là kệ hoa, cửa sổ và bảng ghim giấy.

Nhưng hai tuần sau (trên màn hình hiện tờ lịch và dòng chữ "Hai tuần sau"), khách vẫn gọi điện hỏi y như cũ. Tính năng nằm im ở đó: chờ anh Tùng đọc lại, chờ người duyệt, chờ người kiểm, chờ ngày được đưa lên chạy thật. Phần khó nhất đã xong nhanh như chớp, vậy mà sao mọi thứ vẫn chậm?

## 2. Cẩm nang của Anthropic và sáu trạm làm phần mềm

Để trả lời đúng câu hỏi đó, Phong dựa vào một cẩm nang của đội ứng dụng AI của Anthropic, gom lại những cách đội này đang làm hằng ngày cùng khách hàng (theo Phong, video đăng ngày 27/10/2026). Trên màn hình là bìa tài liệu "The AI-native SDLC playbook" với sáu biểu tượng, dòng chú thích bên dưới ghi "Cẩm nang · Đội ứng dụng AI của Anthropic". Trong video, Phong đi cùng tiệm hoa qua cả sáu trạm, từ một ý tưởng tới lúc tính năng chạy thật, để người xem thấy nên đặt agent ở đâu và giữ con người ở đâu.

![Bìa tài liệu The AI-native SDLC playbook với sáu biểu tượng tròn](https://homus.dev/photos/6haausRo7R0-0043.jpg)

Bìa cẩm nang "The AI-native SDLC playbook" mà video dựa vào, với sáu biểu tượng ứng với sáu trạm; dòng chữ dưới ghi đây là cẩm nang của đội ứng dụng AI của Anthropic (theo video đăng ngày 27/10/2026).

Quy trình làm phần mềm, người trong nghề gọi là vòng đời phát triển phần mềm (SDLC), thường có sáu trạm: lên kế hoạch, thiết kế, xây dựng, kiểm thử, đưa lên chạy thật và bảo trì (theo video đăng ngày 27/10/2026). Trên màn hình, sáu trạm xếp thành một đường thẳng, mỗi trạm có tên tiếng Việt và tiếng Anh: Plan, Design, Build, Test, Deploy, Maintain.

Theo cách truyền thống mà Phong mô tả (video đăng ngày 27/10/2026), mỗi trạm do một người khác nhau giữ. Người lo sản phẩm viết yêu cầu, người thiết kế vẽ giải pháp, kỹ sư xây, người kiểm thử tìm lỗi, đội phát hành đưa lên và đội vận hành canh hệ thống. Việc được chuyển từ trạm này sang trạm kia bằng giấy tờ, phiếu việc và chữ ký; ba chữ này hiện dưới đường thẳng trong lúc những tờ giấy nhỏ bay qua giữa các hình người.

Theo Phong (video đăng ngày 27/10/2026), quy trình nặng như vậy là có lý do: để trạm nào cũng có người chịu trách nhiệm và kiểm soát được. Và nó được thiết kế cho một thời mà viết code là việc tốn thời gian và tốn tiền nhất. Viết tài liệu yêu cầu, họp ước lượng, duyệt bảo mật, tất cả để mọi người thống nhất trước khi lao vào hàng tuần, hàng tháng viết code. Theo anh, thời đó đã qua (trên màn hình, trạm xây dựng được đánh dấu bằng một tia chớp và dòng chữ "Thời đó đã qua").

## 3. Khâu xây chỉ còn vài giờ thì chỗ tắc dời đi đâu

Phong mời người xem nghĩ cùng: nếu khâu xây chỉ còn vài giờ, chỗ tắc sẽ dời đi đâu? Câu trả lời của anh (video đăng ngày 27/10/2026): nó không biến mất, nó dời sang hai bên. Lên kế hoạch ở phía trước; duyệt, kiểm thử và đưa lên ở phía sau. Những khâu đó vẫn chạy bằng tốc độ con người.

![Đường sáu trạm với chồng giấy dày ở trạm lên kế hoạch, kiểm thử và đưa lên, dòng chữ Tốc độ người](https://homus.dev/photos/6haausRo7R0-0203.jpg)

Trạm xây dựng sáng lên, còn chồng giấy dồn lại ở trạm lên kế hoạch, kiểm thử và đưa lên, kèm dòng chữ "Tốc độ người": chỗ tắc dời sang hai bên khâu xây, theo cách Phong giải thích trong video đăng ngày 27/10/2026.

Ở tiệm hoa, chuyện này rất dễ hình dung. Giả sử tiệm có một người thợ cắm hoa siêu tốc, cắm xong một bó chỉ trong nháy mắt. Nhưng tiệm vẫn chỉ có một người duyệt mẫu và một người đi giao. Hoa sẽ không tới tay khách nhanh hơn; hoa chỉ chất đầy quầy.

Đây là một hiểu lầm rất dễ mắc, trên màn hình ghi "Hiểu lầm: AI viết nhanh = dự án nhanh". Theo Phong (video đăng ngày 27/10/2026), AI viết code nhanh thì cả dự án sẽ nhanh là không đúng, nếu mọi thứ xung quanh vẫn giữ nguyên như cũ.

## 4. Cách kiểm soát cũ không còn khớp với thực tế

Phong nói còn một chuyện khó hơn: cách kiểm soát cũ bắt đầu không khớp với thực tế. Đọc từng dòng code bằng tay là hợp lý khi chính con người viết ra nó. Nhưng khi agent dần viết phần lớn thay đổi, người đọc không theo kịp nữa (theo Phong, video đăng ngày 27/10/2026).

Anh lấy ví dụ đội bảo mật (video đăng ngày 27/10/2026). Quy mô của đội được tính theo sức viết của con người. Khi agent nhân sản lượng code lên, chỉ còn hai khả năng: hoặc hàng chờ duyệt dài ra, hoặc code đi ra mà chưa được kiểm đủ. Một tổ chức phải tuân thủ quy định chặt chẽ thì không chấp nhận được cả hai. Vì vậy, theo Phong, việc kiểm tra phải chạy kịp tốc độ của agent. Nghĩa là quy trình quanh việc viết code cũng phải được làm lại, ở đúng mức mà chính việc viết code đã thay đổi.

Ví dụ đội bảo mật trong video đăng ngày 27/10/2026: khi agent nhân sản lượng code lên mà quy mô đội vẫn tính theo sức viết của con người, theo Phong chỉ còn hai khả năng, và một tổ chức tuân thủ chặt chẽ không chấp nhận được cả hai.

Làm lại không có nghĩa là bỏ kiểm soát. Phong nhấn mạnh (video đăng ngày 27/10/2026): mục tiêu kiểm soát vẫn giữ nguyên, chỉ có cách thực thi được làm mới.

## 5. Từ đường thẳng thành vòng tròn, nối bằng những tờ giấy

Trên màn hình, đường thẳng sáu trạm uốn lại thành một vòng tròn, ở giữa ghi "AI-native SDLC", và ở trạm nào cũng có một nhân vật đứng cạnh. Phong nói người ta gọi cách làm này là quy trình làm phần mềm gốc AI (AI-native), hay quy trình có agent; tên gọi khác nhau nhưng là cùng một thứ (theo Phong, video đăng ngày 27/10/2026).

![Sáu trạm xếp thành vòng tròn, giữa ghi AI-NATIVE SDLC, mỗi trạm có một nhân vật đứng cạnh](https://homus.dev/photos/6haausRo7R0-0323.jpg)

Sáu trạm (lên kế hoạch, thiết kế, xây dựng, kiểm thử, đưa lên, bảo trì) uốn thành một vòng tròn mang tên "AI-native SDLC", mỗi trạm có AI làm việc, như video đăng ngày 27/10/2026 minh hoạ.

Và có một sợi chỉ chạy xuyên suốt cả vòng tròn ấy. Mỗi trạm kết thúc bằng việc để lại một tờ giấy; trạm sau bắt đầu bằng việc đọc tờ giấy đó. Phong hỏi: thử đoán xem, ngày xưa giấy tờ dùng để làm chậm lại cho chắc (trên màn hình là một tờ "Thủ tục" và dòng "Để làm chậm cho chắc"), còn ở đây tờ giấy để làm gì? Câu trả lời của anh (video đăng ngày 27/10/2026): nó là thứ mà cả người lẫn agent cùng đọc được và cùng làm theo được.

Ở mấy trạm đầu, tờ giấy chủ yếu là tệp chữ, đuôi `.md`. Từ trạm xây trở đi, tờ giấy là chính code và những bài kiểm đi kèm. Mọi tờ giấy được lưu vào một kho có ghi lịch sử, thường là Git, giống một cuốn sổ cái ghi lại từng lần thay đổi: ai đổi, đổi gì, lúc nào. Trên màn hình, cuốn sổ có ba cột "Ai", "Đổi gì", "Lúc nào", với các dòng ví dụ của nhân vật trong truyện. Nhờ vậy, theo Phong (video đăng ngày 27/10/2026), chuỗi tờ giấy cũng là dấu vết để kiểm tra lại: ai đã yêu cầu điều gì, agent đã làm ra gì, và ai đã duyệt.

Theo Phong (video đăng ngày 27/10/2026), con người vẫn chịu trách nhiệm cho mọi quyết định cần đến phán đoán (dòng chữ trên màn hình: "Phán đoán = con người"). Chỉ là sự chú ý của họ dời theo những tờ giấy cần được duyệt. Từ đây, video đi theo tờ giấy qua từng trạm một.

## 6. Trạm 1, lên kế hoạch: tờ ý định intent.md

Ở cách làm cũ, ý tưởng của anh Tùng phải đi qua nhiều lớp: ghi vào danh sách việc chờ, viết thành câu chuyện người dùng, chấm điểm độ khó, rồi họp để tinh chỉnh. Bốn bước này hiện thành bốn nhãn dưới bốn hình người trên màn hình, cạnh bong bóng "Thêm trang đơn?". Mỗi lần chuyển tay là một lần đổi người giữ, nên cái tới được kỹ sư đã cách ý ban đầu nhiều bước (theo video đăng ngày 27/10/2026).

Cách mới mà Phong kể đơn giản hơn nhiều: anh Tùng tự nói chuyện với Claude bằng lời của chính mình. Anh kể khách đang gặp khó ở đâu, ai bị ảnh hưởng, như thế nào là tốt hơn, và việc gì không nằm trong phạm vi. Theo video (đăng ngày 27/10/2026), Claude hỏi lại đúng những câu một người phân tích sẽ hỏi: làm tới đâu, ai dùng, có ràng buộc gì, và thế nào là thành công.

![Khung chat Claude giữa anh Tùng và chị Lan, với các câu hỏi đáp về trang theo dõi đơn hoa](https://homus.dev/photos/6haausRo7R0-0503.jpg)

Cuộc trò chuyện minh hoạ trong video đăng ngày 27/10/2026: anh Tùng nói "Khách gọi hỏi đơn suốt", Claude hỏi "Ai gặp chuyện này?" và "Như thế nào là tốt hơn?", anh trả lời "Khách và người bán", "Khách tự xem được". Bên phải là ba câu Claude cần làm rõ: làm tới đâu, ai dùng, ràng buộc; dưới cùng ghi "Bằng lời của chính mình".

Khi ý đã rõ, Claude viết lại thành một tờ tên là `intent.md`, tờ ý định. Trên đó có vấn đề, kết quả mong muốn, ai và hệ thống nào bị ảnh hưởng, các ràng buộc và những câu hỏi còn bỏ ngỏ. Anh Tùng sửa lại những chỗ Claude hiểu sai rồi mới lưu vào sổ cái. Theo video (đăng ngày 27/10/2026), anh không cần biết dùng Git: Claude có thể lưu hộ anh qua một kết nối tới repo (dòng chữ trên màn hình: "Không cần biết Git").

Ý tưởng không còn phải chờ ai đó rảnh để viết ra; nó được ghi một lần bằng chính lời người nghĩ ra nó. Còn tờ ý định có được đi tiếp hay không, theo Phong (video đăng ngày 27/10/2026), vẫn là người phụ trách sản phẩm quyết.

## 7. Trạm 2, thiết kế: spec.md và luật viết sẵn thành skill

Ở cách làm cũ, yêu cầu và thiết kế là hai giai đoạn của hai nhóm người. Người phân tích viết yêu cầu ra, rồi người thiết kế lại phải đọc và hiểu lại. Theo Phong (video đăng ngày 27/10/2026), tách ra để rõ trách nhiệm, nhưng vừa chậm vừa rơi rớt ý.

Cách mới, theo Phong (video đăng ngày 27/10/2026), gộp cả hai vào một buổi làm việc với agent. Lúc này Claude đọc tờ ý định đã được chấp nhận và viết ra tờ thiết kế `spec.md`; trên màn hình, tờ `intent.md` nhỏ nằm cạnh tờ `spec.md` lớn đang được chị Lan chỉ vào. Điểm hay nằm ở chỗ: luật của tổ chức đã được viết sẵn thành kỹ năng, hay skill. Luật thương hiệu, luật bảo mật, luật tuân thủ, chuẩn trải nghiệm người dùng, và Claude dùng các luật đó ngay trong lúc viết. Nên chỗ trái luật được thấy ngay lúc đang viết, chứ không phải bị phát hiện ở một buổi duyệt vài tuần sau.

Claude còn phải chỉ rõ những chỗ đang lo, nhất là chỗ hai luật mâu thuẫn nhau mà không thể cùng thỏa (theo Phong, video đăng ngày 27/10/2026).

Trạm 2 theo video đăng ngày 27/10/2026: Claude đọc tờ ý định đã được chấp nhận, dùng các luật đã viết thành skill ngay lúc viết `spec.md`, cắm cờ chỗ hai luật mâu thuẫn; người phụ trách sản phẩm đọc và duyệt.

Theo video (đăng ngày 27/10/2026), người phụ trách sản phẩm đọc và duyệt tờ thiết kế, nhưng không phải tự viết nó. Những chỗ bị cắm cờ được giải quyết với người giữ luật đó trước khi kỹ sư nhìn thấy. Và tờ thiết kế có được chuyển sang trạm xây hay không luôn do một con người quyết định (trên màn hình, anh Tùng đóng dấu "Đi tiếp" lên tờ `spec.md`, dòng chữ dưới ghi "Con người quyết").

## 8. Trạm 3, xây dựng: plan mode và tờ plan.md

Trạm 3 là xây dựng, và luật đầu tiên ở đây, theo Phong (video đăng ngày 27/10/2026), là chưa có kế hoạch được duyệt thì chưa làm gì cả. Ở cách làm cũ, kỹ sư đọc thiết kế rồi bắt tay viết code luôn. Sửa những tệp nào, kiểm bằng gì, tất cả nằm trong đầu kỹ sư (nhãn "Nằm trong đầu" trên màn hình, cạnh bong bóng suy nghĩ có ổ khoá). Thứ đầu tiên người duyệt được thấy là code đã viết xong (nhãn "Thấy khi đã xong"), và lúc đó muốn làm lại thì đã chậm.

Cách mới: chị Lan mở phiên làm việc ở chế độ lập kế hoạch, plan mode. Theo video (đăng ngày 27/10/2026), ở chế độ này Mây được đọc code nhưng không được thay đổi thứ gì. Chị đưa cho Mây tờ ý định và tờ thiết kế, rồi yêu cầu một kế hoạch: tệp nào sẽ thay đổi, làm theo thứ tự nào, và bài kiểm nào chứng minh là đã xong.

![Nhãn PLAN MODE trên một tờ kế hoạch với ba mục Tệp nào, Thứ tự nào, Bằng chứng xong; chị Lan cầm kính lúp soi tờ giấy](https://homus.dev/photos/6haausRo7R0-0723.jpg)

Plan mode trong câu chuyện của video (đăng ngày 27/10/2026): tờ kế hoạch có ba mục "Tệp nào", "Thứ tự nào", "Bằng chứng xong"; một nhân vật cầm laptop bên trái, chị Lan cầm kính lúp soi kế hoạch bên phải.

Rồi chị đặt câu hỏi khó cho kế hoạch: thay đổi này có thể làm hỏng cái gì, bước nào rủi ro nhất, có phương án nào em đã cân nhắc mà không chọn? Hai bên làm qua lại cho tới khi một kỹ sư chưa từng xem cuộc trò chuyện vẫn làm được chỉ nhờ đọc tờ kế hoạch. Tờ đó được lưu lại với tên `plan.md` (theo video đăng ngày 27/10/2026).

Tại sao lại kỹ như vậy? Phong giải thích (video đăng ngày 27/10/2026): vì lúc này đổi hướng chỉ là sửa một văn bản, giống như sửa bản vẽ thì rẻ hơn rất nhiều so với đập tường của một ngôi nhà đã xây. Và với một kế hoạch chắc, phần làm thường xong chỉ trong một lượt. Nếu đang làm mà phải lệch khỏi kế hoạch thì tờ kế hoạch được cập nhật cùng lúc.

Tới đây đã có ba tờ giấy, và Phong (video đăng ngày 27/10/2026) đố người xem nhớ lại tờ nào do ai duyệt (màn hình hiện ba lá bài úp với dòng "Tờ nào, ai duyệt?"). Câu trả lời trong video:

Ai duyệt tờ nào, theo video đăng ngày 27/10/2026: tờ ý định và tờ thiết kế do người phụ trách sản phẩm duyệt; tờ kế hoạch do kỹ sư duyệt, còn việc rủi ro cao thì chuyển lên người đứng đầu nhóm kỹ thuật.

## 9. Luật nằm trong tệp: CLAUDE.md và skill

Nhưng Mây làm việc với rất nhiều quy ước của tiệm (trên màn hình, chị Lan đứng giữa một đám giấy nhớ màu vàng bay quanh), vậy ai nhắc cho Mây nhớ? Câu trả lời của Phong (video đăng ngày 27/10/2026): luật không nằm trong đầu người nữa, luật nằm trong tệp.

Cái tệp đầu tiên là sổ tay `CLAUDE.md`. Theo Phong, nó chứa những gì một người mới vào đội cần biết ngày đầu tiên: lệnh hay dùng, quy ước, cấu trúc dự án và những lỗi đội hay gặp. Kiến thức từng nằm trong đầu người và trên các trang ghi chú nội bộ, giờ thành một tệp mà agent đọc ở đầu mỗi phiên (theo video đăng ngày 27/10/2026).

Phong nêu một quy tắc rất dễ nhớ (video đăng ngày 27/10/2026): Claude sai một điều hai lần thì lời sửa được ghi vào sổ. Và giữ sổ dưới một trang, vì Claude đọc hết nó mỗi lần, dòng nào cũ chỉ chiếm chỗ vô ích. Cẩm nang của Anthropic ghi đúng quy tắc này: "When Claude makes a mistake twice, the correction goes into CLAUDE.md", và giữ tệp dưới một trang vì Claude đọc hết nó lúc bắt đầu phiên (đọc ngày 28/10/2026).

Tệp thứ hai là kỹ năng, hay skill, dành cho loại kiến thức cả tổ chức phải áp dụng giống nhau mọi lần. Chẳng hạn một chuẩn bảo mật, một quy ước thiết kế API, hay một luật thương hiệu đang được áp lúc có lúc không. Trên màn hình là một giá sách với sáu cuốn "SKILL", một cuốn màu cam được kéo lên với nhãn "Chuẩn bảo mật". Theo Phong (video đăng ngày 27/10/2026), khi luật đổi chỉ cần đổi skill, cả đội tự nhận bản mới từ phiên làm việc sau.

## 10. Skill là lời khuyên, hook là cái chốt

Phong đặt một câu hỏi: một skill ghi "không bao giờ làm X", có chắc X sẽ không bao giờ xảy ra không? (Trên màn hình là một giá skill nhỏ với dòng "Không bao giờ làm X" và nhãn "Lời khuyên".) Câu trả lời của anh (video đăng ngày 27/10/2026): không chắc. Skill là một lời khuyên; nó làm Claude dễ làm đúng hơn, nhưng không có gì ép một phiên phải tuân theo. Luật nào phải đúng mà không có ngoại lệ thì cần một cái chốt phía sau: hook. Skill làm cho vi phạm hiếm đi; hook làm cho vi phạm gần như không thể xảy ra.

Ở trạm xây, theo Phong (video đăng ngày 27/10/2026), hook có thể chặn việc sửa vào những vùng cấm, tự chạy công cụ định dạng mỗi khi có tệp được sửa, và giữ mật khẩu cùng khóa bí mật không lọt vào phần thay đổi.

![Nhãn HOOK ở trạm 3 xây dựng với hai biểu tượng: ổ khoá Chặn vùng cấm và dấu tích Tự chạy định dạng](https://homus.dev/photos/6haausRo7R0-0943.jpg)

Hook ở trạm 3 trong video đăng ngày 27/10/2026, lúc màn hình mới hiện hai việc: "Chặn vùng cấm" (ổ khoá) và "Tự chạy định dạng" (dấu tích). Việc thứ ba Phong nói ngay sau đó là giữ mật khẩu và khóa bí mật không lọt vào phần thay đổi.

Những cái chốt này phải chạy thật nhanh, vì nó chạy sau từng thao tác. Kiểm nặng như chạy toàn bộ bài kiểm thì để tới lúc gửi thay đổi (theo Phong, video đăng ngày 27/10/2026).

Trong câu chuyện của video đăng ngày 27/10/2026, tới đây Mây đã viết code nhanh hơn và đúng luật hơn. Nhưng Phong nhắc lại vấn đề ở đầu video: chỗ tắc nằm ở phía sau, ở khâu duyệt và kiểm. Agent viết nhiều như vậy, ai đọc cho hết? Chẳng lẽ lại quay về đọc từng dòng?

## 11. Nhiều phiên song song, worktree và subagent

Trước khi tới khâu duyệt, Phong cho xem chị Lan đang làm việc thế nào. Chị không còn làm một việc một lúc: chị mở hai, ba phiên Claude cùng lúc, mỗi phiên một việc riêng (trên màn hình, ba chị Lan ngồi ở ba bàn làm việc). Theo video (đăng ngày 27/10/2026), mỗi phiên làm trong một worktree, tức một bản sao riêng của dự án trên một nhánh riêng, nên các phiên không dẫm lên tệp của nhau.

Việc lặp đi lặp lại thì giao cho trợ lý phụ, subagent, có không gian làm việc riêng và chỉ được dùng những công cụ được cho phép. Ví dụ một trợ lý chuyên chạy thử ứng dụng, kiểm hành vi, rồi chỉ báo cáo, không được tự sửa gì (theo Phong, video đăng ngày 27/10/2026).

Công việc của kỹ sư dời dần sang điều phối, rồi xa hơn nữa, sang xây và giám sát cả vòng lặp. Nhưng nên mở bao nhiêu phiên? Theo Phong (video đăng ngày 27/10/2026), trần thực tế không nằm ở máy; nó nằm ở số luồng việc mà một người duyệt được cho tử tế. Chỉ thêm phiên khi việc duyệt vẫn còn theo kịp. Và thế là lại quay về khâu duyệt: làm sao để duyệt kịp?

![Một nhân vật với bốn vạch nối lên trên, ba vạch xanh và một vạch đỏ, giấy tờ rơi xuống; dòng chữ Trần = sức duyệt của một người](https://homus.dev/photos/6haausRo7R0-1143.jpg)

Dòng chữ "Trần = sức duyệt của một người" trong video đăng ngày 27/10/2026: ba luồng việc màu xanh còn duyệt kịp, luồng thứ tư màu đỏ làm giấy tờ rơi ra kèm một dấu hỏi.

## 12. Trạm 4, kiểm thử: cho Claude một cách tự kiểm bài

Trạm 4 là kiểm thử. Bí quyết đầu tiên, theo Phong (video đăng ngày 27/10/2026): luôn cho Claude một cách để tự kiểm bài của mình. Đó có thể là chạy bộ bài kiểm, chạy lệnh build, hay chụp màn hình rồi so với bản mẫu; ba lựa chọn này hiện thành ba biểu tượng trên màn hình dưới tiêu đề "Cho Claude cách tự kiểm". Như vậy, phiên làm việc tự kiểm và tự sửa lỗi của chính nó trước khi kỹ sư nhìn thấy (các nhãn "Làm", "Kiểm", "Sửa" xoay quanh nhân vật, dưới cùng ghi "Trước khi kỹ sư nhìn thấy").

Ở cách làm cũ, tín hiệu báo code đúng hay sai đến rất muộn. Hệ thống kiểm tự động báo sau vài phút, người kiểm thử báo sau vài ngày, còn lỗi lộ ra khi chạy thật thì sau vài tuần; trên màn hình là ba chiếc đồng hồ với ba mốc "Vài phút", "Vài ngày", "Vài tuần". Với agent viết code, theo Phong (video đăng ngày 27/10/2026), tín hiệu muộn nghĩa là một người phải tự kiểm toàn bộ những gì agent làm ra, và người đó trở thành nút thắt.

So sánh trong video đăng ngày 27/10/2026: ở cách làm cũ tín hiệu đến sau vài phút, vài ngày, vài tuần; cách mới cho phiên làm việc tự làm, tự kiểm và tự sửa trước khi kỹ sư nhìn thấy.

Muốn agent tự kiểm mà không phải hỏi bạn, đích phải đo được. Không phải "làm cho tốt vào", mà là "làm mọi bài kiểm trong tệp này đều qua", hay "ảnh chụp khớp với bản mẫu". Với giao diện, vòng này rất rõ: làm, chụp màn hình, so, rồi chỉnh. Theo Phong (video đăng ngày 27/10/2026), hai ba vòng là bình thường, và mỗi vòng kết quả phải khá lên.

## 13. Sửa lỗi theo thứ tự ngược, và kiểm cả bộ cấu hình

Phong đưa ra một câu hỏi khó hơn. Trang có một lỗi: đơn hoa đã giao xong nhưng trang vẫn báo đang giao (trên màn hình, khung "Đơn hoa của bạn" có bốn mốc Đã nhận, Đang cắm, Đang giao, Đã tới, và mốc sáng là "Đang giao"). Bạn bảo Mây sửa. Nếu Mây được phép sửa luôn cả bài kiểm, chuyện gì có thể xảy ra? Theo Phong (video đăng ngày 27/10/2026), nó có thể làm cho bài kiểm dễ đi thay vì sửa lỗi thật: bài kiểm qua trong khi lỗi vẫn còn.

Vì vậy, với lỗi, hãy làm theo thứ tự ngược lại (dòng "Làm ngược lại" trên màn hình). Trước tiên, bảo Claude viết một bài kiểm tái hiện đúng lỗi đó, chạy nó và xác nhận nó thất bại đúng vì lý do bạn nghĩ. Lưu bài kiểm đó lại. Rồi mới bảo Claude làm cho nó qua, mà không được đụng vào bài kiểm. Theo Phong (video đăng ngày 27/10/2026), một cái hook chặn việc sửa tệp kiểm trong lúc sửa lỗi sẽ giữ đúng điều này.

![Bốn bước sửa lỗi ở trạm 4 kiểm thử, bên phải là khung bài kiểm lỗi có ổ khoá và một cần gạt ghi HOOK](https://homus.dev/photos/6haausRo7R0-1323.jpg)

Bốn bước trên màn hình (video đăng ngày 27/10/2026): "1 · Viết bài kiểm tái hiện lỗi", "2 · Xác nhận nó thất bại", "3 · Lưu lại, khóa", "4 · Làm cho nó qua"; bên phải là khung "bài kiểm lỗi" bị khoá và một cần gạt hook.

Theo Phong (video đăng ngày 27/10/2026), một bài kiểm có từ trước khi sửa, mà agent không thể viết lại, chính là bằng chứng lỗi đã hết. Phong nói câu này đáng dán lên tường chỗ sửa code: đừng sửa bài kiểm. Và hãy đưa việc kiểm thành một phần của chữ "xong": chạy kiểm trước khi báo xong, rồi đưa kết quả ra cho người xem.

Còn một thứ ít ai nghĩ tới: bộ cấu hình điều khiển agent cũng cần được kiểm (màn hình ghi "Cấu hình cũng cần được kiểm"). Mỗi lần bạn sửa sổ tay, skill hay hook, hoặc đổi sang model mới, agent có còn làm tốt như cũ không? Cách làm Phong nêu (video đăng ngày 27/10/2026): gom vài chục việc thật gần đây, kèm kết quả đã được chấp nhận, làm thành một bộ bài thi cho agent. Mỗi lần cấu hình thay đổi, bộ bài thi chạy lại; điểm tụt thì phải xem xét trước khi cho thay đổi đi vào. Và mỗi sự cố ngoài thực tế được viết thành một bài thi mới, nằm lại đó để lỗi cũ không quay lại.

Bộ bài thi cho agent theo video đăng ngày 27/10/2026: vài chục việc thật gần đây kèm kết quả đã chấp nhận; mỗi lần cấu hình đổi thì chạy lại, điểm tụt thì xem lại trước khi cho thay đổi đi vào, và mỗi sự cố thật thành một bài thi mới.

## 14. Trạm 5: máy đọc từng dòng, người phán xét ý định và rủi ro

Trạm 5 là đưa lên chạy thật, và đây là câu trả lời cho câu hỏi lúc nãy: ai đọc hết? Theo Phong (video đăng ngày 27/10/2026): máy đọc từng dòng, người phán xét ý định và rủi ro. Mọi thay đổi gửi lên, gọi là pull request, đều được Claude duyệt qua cùng một bộ lượt giống hệt nhau: lượt tìm lỗi logic, lượt tìm lỗ hổng bảo mật, và lượt kiểm xem thay đổi có khớp với tờ thiết kế và tờ kế hoạch không. Các phát hiện được xếp theo mức nghiêm trọng.

![Một kỹ sư đứng trên bục, bên dưới là thẻ Pull request Trang theo dõi đơn hoa với ba nhãn Quan trọng, Nên sửa, Lỗi vặt](https://homus.dev/photos/6haausRo7R0-1443.jpg)

Thẻ pull request "Trang theo dõi đơn hoa" với các phát hiện xếp theo mức "Quan trọng", "Nên sửa", "Lỗi vặt"; người duyệt đứng ở tầng trên với câu hỏi "Đúng ý kế hoạch?" (video đăng ngày 27/10/2026).

Nhờ vậy, theo video đăng ngày 27/10/2026, sự chú ý của con người được dời lên một tầng: thay đổi này có làm đúng điều kế hoạch muốn không, và rủi ro có chấp nhận được không.

Claude còn nhận góp ý, theo video (đăng ngày 27/10/2026): người duyệt gắn tên Claude vào một bình luận, Claude sửa và đẩy phần sửa lên, mọi thứ ghi lại ngay trên luồng thảo luận. Lỗi nào bị nhắc tới lần thứ hai lúc duyệt thì lời sửa được ghi vào sổ tay, để từ lần sau chính bước duyệt bắt được nó.

Nhưng có một điều Phong nói không bao giờ đổi (video đăng ngày 27/10/2026): agent viết code không có đường nào để tự duyệt code của mình. Các phát hiện của máy không tự cho qua hay tự chặn; người giữ phần code đó vẫn phải bấm duyệt (trên màn hình, cạnh chị Lan là một con dấu duyệt).

## 15. Cổng cuối giữ bằng hook, mức tự chủ theo môi trường

Còn cổng cuối cùng, cổng đưa lên chạy thật, được giữ bằng chính cái chốt đã gặp: hook. Theo Phong (video đăng ngày 27/10/2026), ở trạm xây hook chỉ cho qua hoặc chặn; ở đây nó còn biết hỏi: dừng thao tác lại, chờ đúng một người cụ thể đồng ý. Ví dụ, lệnh đưa lên môi trường chạy thật sẽ bị chặn cho tới khi người phụ trách phát hành cho phép. Và khi chặn, cái chốt phải nói rõ vì sao bị chặn, và muốn được duyệt thì đi đường nào.

![Ba nút Cho qua, Hỏi, Chặn, nút Hỏi được tô sáng; bên phải là thanh chắn Chạy thật có nhãn HOOK và ổ khoá](https://homus.dev/photos/6haausRo7R0-1523.jpg)

Ba cách hook phản ứng trong video đăng ngày 27/10/2026: "Cho qua", "Hỏi", "Chặn", với "Hỏi" được tô sáng, cạnh thanh chắn trước cổng "Chạy thật" có nhãn HOOK và ổ khoá.

Những cái chốt bắt buộc nằm trong phần cài đặt do đội quản trị giữ, từng kỹ sư không tự tắt được (trên màn hình: "Cài đặt bắt buộc" và "Kỹ sư không tự tắt được"), theo Phong trong video đăng ngày 27/10/2026. Anh gom nguyên tắc lại thành một câu: agent làm mọi thứ cho tới cổng cuối và không bước qua cổng đó.

Mức tự chủ cũng đổi theo môi trường (theo Phong, video đăng ngày 27/10/2026). Ở môi trường thử, agent tự đưa lên thoải mái. Ở môi trường thật, agent chuẩn bị mọi thứ, còn người phụ trách phát hành là người cho phép. Khu tập dượt nằm ở giữa. Và đường quay về phiên bản trước, khi có sự cố, phải là con đường được tập dượt nhiều nhất. Vì sao? Phong nói câu trả lời nằm ở trạm cuối cùng.

Mức tự chủ của agent theo môi trường, như video đăng ngày 27/10/2026 trình bày: thử, tập dượt, thật, và đường quay về phiên bản trước là con đường được tập dượt nhiều nhất.

## 16. Trạm 6, bảo trì: vòng lặp tự khép lại

Trạm 6 là bảo trì. Theo Phong (video đăng ngày 27/10/2026), năm trạm trước luôn có một người bấm nút khởi động; trạm này thì khác. Ở cách làm cũ, bảo trì là chuyện bị động: mọi phiếu báo lỗi, mọi sự cố đều chờ một người tới xử lý. Cảnh báo lúc 3 giờ sáng có thể bị bỏ lỡ (trên màn hình, anh Tùng ngủ gật trong tiệm tối, chiếc điện thoại trên quầy báo đỏ). Phiếu lỗi có thể nằm trong hàng chờ cho tới khi có người nhặt lên. Còn bài học sau sự cố có khi không bao giờ tới được code, vì một đám cháy khác đã bắt đầu.

Cách mới, theo Phong (video đăng ngày 27/10/2026): một kích hoạt gọi Claude dậy mà không cần ai đứng ở giữa. Kích hoạt có thể là một chỉ số vượt ngưỡng, một phiếu việc, một tin nhắn trong kênh chat của đội, hay một lịch hẹn giờ.

Phong đố: thứ đang canh chỉ số suốt ngày đêm ấy có phải là AI không? Không. Theo anh (video đăng ngày 27/10/2026), việc phát hiện luôn do một chương trình cố định làm, đo xem chỉ số có lệch khỏi dải bình thường không; không có model AI nào ở đó (màn hình ghi "Chương trình cố định" và "Không có AI ở đây"). Claude chỉ được gọi khi chỉ số đã vượt dải. Và lệch càng xa, Claude càng được làm nhiều hơn: lệch nhẹ thì chương trình chỉ ghi lại; lệch vừa thì Claude được gọi để chẩn đoán, và chỉ được đọc; lệch mạnh thì Claude mới được hành động, nhưng chỉ bằng hai đường: mở một thay đổi đi vào cổng duyệt, hoặc chạy một quy trình đã được duyệt từ trước.

![Biểu đồ chỉ số với ba dải 1σ, 2σ, 3σ và một đỉnh vọt lên; bên phải là các mức Ghi lại, Chẩn đoán chỉ đọc, Hành động qua cổng](https://homus.dev/photos/6haausRo7R0-1723.jpg)

Ba dải lệch trong video đăng ngày 27/10/2026: 1σ "Ghi lại", 2σ "Chẩn đoán · chỉ đọc", 3σ "Hành động qua cổng", với hai đường hành động "Mở thay đổi → cổng duyệt" và "Quy trình đã duyệt trước"; dòng dưới ghi "Lệch càng xa · Claude càng được làm nhiều". Cẩm nang của Anthropic mô tả cùng ba mức 1σ, 2σ, 3σ (đọc ngày 28/10/2026).

Chẳng hạn tỷ lệ lỗi tăng vọt ngay sau một lần đưa lên: theo Phong (video đăng ngày 27/10/2026), Claude sẽ chạy đường quay về phiên bản trước, chính con đường đã được tập dượt kỹ ở trạm 5. Sau đó Claude viết lại điều nó tìm được thành một tờ ý định mới, đúng theo mẫu của trạm 1, và vòng tròn bắt đầu lại.

Người trực xem hàng chờ và quyết: sửa ngay, xếp lịch hay bỏ qua (ba lựa chọn này hiện cạnh vòng tròn sáu trạm). Mỗi lần bỏ qua giúp chỉnh lại dải cho bớt báo động thừa. Sửa xong, sự cố đó được thêm vào bộ bài thi, để agent không vấp lại đúng lỗi ấy. Và người không còn phải là người khởi động mọi việc; theo Phong (video đăng ngày 27/10/2026), họ phân loại và duyệt.

## 17. Sáu tờ giấy, sáu trạm, và bắt đầu từ đâu

Phong quay về câu hỏi ở đầu video: code xong nhanh như chớp, sao mọi thứ vẫn chậm? Câu trả lời của anh (video đăng ngày 27/10/2026): vì chỗ tắc đã dời sang những khâu vẫn chạy bằng tốc độ con người. Và cách gỡ là làm lại cả vòng quanh việc viết code: mỗi trạm để lại một tờ giấy, luật nằm trong tệp, agent tự kiểm bài, và con người đứng ở cổng.

Anh mời nhớ lại lần cuối sáu tờ giấy (video đăng ngày 27/10/2026) của sáu trạm: tờ ý định, tờ thiết kế, tờ kế hoạch, code kèm bài kiểm, pull request kèm nhận xét, và hồ sơ sự cố.

Sáu tờ giấy của sáu trạm mà Phong nhắc lại ở cuối video đăng ngày 27/10/2026: tờ ý định, tờ thiết kế, tờ kế hoạch, code kèm bài kiểm, pull request kèm nhận xét, và hồ sơ sự cố.

Theo Phong (video đăng ngày 27/10/2026), không cần làm lại tất cả trong một ngày. Các bước có thể chuyển dần, trạm nào cần trước thì làm trước. Có những bước không cần gì làm trước: một sổ tay `CLAUDE.md`, một cách để agent tự kiểm, tờ ý định đầu tiên, hay một cái cổng bằng hook.

Theo Phong (video đăng ngày 27/10/2026), lúc đầu bạn tự ra lệnh cho từng bước. Đích đến là một vòng lặp mà mỗi tờ giấy được duyệt sẽ tự mở cánh cổng kế tiếp. Cẩm nang khép lại bằng một câu mà Phong nghĩ người làm việc với agent nào cũng nên nhớ: vòng lặp cứ chạy, phán đoán của con người đứng phía trên nó. Nguyên văn trong cẩm nang là "The loop keeps running. Human judgement stays above it." (đọc ngày 28/10/2026).

## Nguồn và liên kết

- Tên gốc: AI viết code nhanh, sao dự án vẫn chậm? Quy trình làm phần mềm kiểu mới với Claude Code
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=6haausRo7R0](https://www.youtube.com/watch?v=6haausRo7R0)

- Kênh YouTube Phong Ho (Phong Ho): [youtube.com/channel/UCxtbiArFoZi3t20Q0FMMb3g](https://www.youtube.com/channel/UCxtbiArFoZi3t20Q0FMMb3g)

- Cẩm nang mà video dựa vào, "The AI-native SDLC playbook" (Claude by Anthropic, bài ghi ngày 21/08/2026; đọc ngày 28/10/2026): [claude.com/resources/articles/the-ai-native-sdlc-playbook](https://claude.com/resources/articles/the-ai-native-sdlc-playbook)

Nguồn: https://homus.dev/talks/ai-viet-code-nhanh-sao-du-an-van-cham-quy-trinh-lam-phan-mem-kieu-moi-voi-claude-code · cập nhật 2026-10-28