7 Agent: Từ Vibe Coding đến Software Factory
Nguồn: BlockTempo / tác giả @sairahul1 · 2026-05-31
Tôi tưởng mình đang dùng AI để viết code. Thực ra, tôi chỉ đang gõ phím nhanh hơn mà thôi.
我以為我在用 AI 寫程式。實際上，我只是打字打得比較快而已。
Vấn đề không ai nói đến
Vòng lặp trông có vẻ năng suất nhưng thực sự thì không: Yêu cầu Claude làm một tính năng → Nó sinh code → Có thứ gì đó bị lỗi → Bạn paste thông báo lỗi lại → Nó sửa → Một thứ khác lại hỏng → Lại hỏi tiếp.
那個看起來很有產能、其實沒有的循環：要 Claude 幫你做一個功能 → 它生出程式碼 → 某個地方壞了 → 把錯誤訊息貼回去 → 它修補 → 又壞了另一個地方 → 再問一次。
Ngày 1: Như phép thuật. Ngày 30: Bạn dành nhiều thời gian giám sát AI hơn là tự viết code trước đây.
第 1 天：這像魔法。第 30 天：你花在監督 AI 的時間，比過去自己寫程式還多。
Không phải AI đang thất bại — quy trình làm việc của bạn đang thất bại.
不是 AI 在失敗 — 是你的工作流在失敗。
Bước ngoặt: Từ Vibe Coding đến Software Factory
Một đội ngũ kỹ sư thực sự không làm việc trong một cuộc hội thoại duy nhất. Người thì làm rõ vấn đề người dùng, người nghĩ về kiến trúc, người viết API, người viết UI, người nghĩ về edge case, người review. Khi bạn nén tất cả vào một cuộc hội thoại AI, lỗi sẽ âm thầm tích lũy.
真正的工程團隊，不會在一個大型對話裡工作。有人釐清使用者問題、有人思考架構、有人寫 API、有人寫 UI、有人思考邊界情況、有人做審查。當你把所有這些塌縮成一個 AI 對話，錯誤就會悄悄地累加。
Giải pháp: Chia công việc cho các agent chuyên biệt. Mỗi agent có: một nhiệm vụ tập trung, context window riêng sạch sẽ, chỉ những công cụ thực sự cần, quy tắc nghiêm ngặt về "phạm vi không được chạm vào".
修正之道：把工作拆給專門化的代理人。每一個代理人會得到：一個聚焦的工作、自己乾淨的上下文視窗、只擁有它真正需要的工具、對它「不可碰觸的範圍」有嚴格規則。
7 Agent
1. Codebase Researcher (Nghiên cứu viên)
Chỉ đọc — Luôn chạy đầu tiên
Quét codebase và giải thích hiện trạng trước khi bất kỳ dòng code nào được viết. Đánh dấu file liên quan, ghi nhận pattern hiện có, tìm tính năng tương tự đã xây, chỉ ra rủi ro (timezone, multi-tenant, retry logic).
掃過程式碼並解釋現況——在一行程式被寫下來之前。標出相關檔案、記錄既有模式、找出類似功能、標示風險。
- Công cụ: Read, Grep, Glob
- Không được: sửa file, chạy lệnh thay đổi trạng thái, tự suy đoán
2. Story Writer (Người viết câu chuyện)
Chỉ đọc — Human review point 1
Biến ý tưởng tính năng thô thành user story thực sự: "Là [vai trò], tôi muốn [hành vi] để [kết quả]". Kèm theo: tiêu chí chấp nhận, edge case, phạm vi ngoài, câu hỏi chưa giải đáp.
把粗略的功能構想變成真正的使用者故事。產出驗收標準、邊界情況、不在範圍內、未解問題。
- Công cụ: Read
- Không được: phát minh business rule, viết code, tiếp tục khi có điều chưa rõ
3. Spec Writer (Người viết đặc tả)
Chỉ đọc — Human review point 2
Biến story đã duyệt thành brief kỹ thuật: data model, background job, API endpoint, frontend component, test cần viết, rủi ro. Đây là bản thiết kế mà mọi builder agent sẽ tuân theo.
把核准的故事變成技術簡報：資料模型變動、API 變動、前端變動、需要的測試、風險。這是每個建造代理人會遵循的藍圖。
- Công cụ: Read, Grep, Glob
- Không được: sửa file, phát minh infrastructure mới, bỏ qua tenant isolation
4. Backend Builder (Người xây dựng backend)
Đọc + Ghi — Chỉ trong thư mục backend
Xây dựng API routes, services, database migrations, background jobs, unit test. Chỉ đụng đến backend — không bao giờ chạm vào React component hay client-side hook.
建造 API 路由、Services、資料庫遷移、背景任務、單元測試。只碰後端——永遠不可能不小心弄壞前端。
- Công cụ: Read, Edit, Write, Bash (chỉ backend)
- Phải: chạy typecheck + lint + test trước khi dừng
5. Frontend Builder (Người xây dựng frontend)
Đọc + Ghi — Chỉ trong thư mục frontend
Đọc tóm tắt của Backend Builder trước. Xây dựng React component, page, hooks, loading/error state, UI test. Nếu API shape sai với UI, báo cáo sự không khớp — không tự vá.
先讀後端建造者的摘要。建造 React 元件、頁面、hooks、狀態、UI 測試。如果 API 的形狀對 UI 而言是錯的，回報出來——不是自己打補丁。
- Công cụ: Read, Edit, Write, Bash (chỉ frontend)
6. Test Verifier (Người xác minh kiểm thử)
Chỉ viết test — Viết acceptance test
Viết acceptance test phủ từng tiêu chí chấp nhận trong user story. Test từ bên ngoài — như cách người dùng thực sự trải nghiệm. Báo cáo: cái nào pass, cái nào fail. Không sửa code — trả lỗi về đúng builder.
寫驗收測試覆蓋每個驗收標準。從外部測試——就像真實使用者體驗的方式。回報哪些通過、哪些失敗。不修補程式碼——丟回正確的建造者。
- Công cụ: Read, Edit, Write (chỉ file test), Bash
7. Implementation Validator (Người xác nhận triển khai)
Chỉ đọc — Người nói sự thật
Đối chiếu implementation với story và spec đã duyệt, báo cáo khoảng cách. Kiểm tra: tiêu chí chưa implement, failure path thiếu test, lỗi bảo mật (thiếu permission check, tenant isolation, key trong log), file ngoài phạm vi bị sửa, pattern không nhất quán. Output phân loại: Critical / Important / Minor. Mỗi phát hiện đều kèm đường dẫn file và số dòng.
拿實作對照核准的故事與簡報，回報落差。檢查安全議題、範圍外檔案、不一致模式。輸出按嚴重度：Critical / Important / Minor。每個發現附檔案路徑與行號。
- Công cụ: Read, Grep, Glob
- Không sửa gì cả. Chỉ nói sự thật.
Chuỗi hoạt động
Research → Story ⏸ Duyệt → Spec ⏸ Duyệt → Backend → Frontend → Test → Validate → ⏸ PR
3 điểm kiểm duyệt của con người. Mọi thứ khác tự chạy. Bạn chỉ ở lại những khâu mà phán đoán của bạn thực sự quan trọng: Đây có phải đúng vấn đề không? Đây có phải thiết kế đúng không? Cái này có an toàn để deploy không?
三個人類審核點。其他都自己跑。你留在那些「你的判斷真正重要」的環節裡：這是對的問題嗎？這是對的設計嗎？這個可以安全上線嗎？
Nền tảng: CLAUDE.md
Mỗi lần mở Claude Code, nó bắt đầu với "không bộ nhớ". CLAUDE.md khắc phục điều này — file Markdown ở thư mục gốc, tự động tải vào mỗi cuộc hội thoại. Chứa: tech stack, lệnh, quy tắc kiến trúc, những điều không được làm, con trỏ đến tài liệu sâu hơn. Giữ trong 100-300 dòng.
每次打開 Claude Code 都是從零記憶開始。CLAUDE.md 修正這件事 — repo 根目錄的 Markdown 檔，自動載入。放技術棧、指令、架構規則、不要做的事、深入文件的指標。保持在 100-300 行。
Thiết lập cuối tuần (2-3 giờ)
- Cài Claude Code
- Tạo cấu trúc thư mục:
.claude/agents/, .claude/skills/, .claude/hooks/
- Viết CLAUDE.md (100-300 dòng)
- Dùng lệnh
/agents tạo 7 agent
- Tạo feature-factory orchestrator skill
- Tạo build-with-tests skill
- Thêm pre-commit hook (chặn .env, .key, secrets.json)
- Chạy một tính năng thật qua toàn bộ chuỗi
Tóm tắt 7 Agent
| Agent | Vai trò | Quyền |
|---|
| Researcher | Quét codebase trước khi code | Chỉ đọc |
| Story Writer | Viết user story + acceptance criteria | Chỉ đọc |
| Spec Writer | Viết technical brief | Chỉ đọc |
| Backend Builder | API, services, jobs, unit test | Backend folder |
| Frontend Builder | Components, pages, hooks, UI test | Frontend folder |
| Test Verifier | Viết acceptance test | Chỉ file test |
| Validator | Đối chiếu, báo cáo gap | Chỉ đọc |
Ứng dụng thực tế: Chúng ta có thể học được gì?
Bài học #1: Thêm bước "đặc tả" trước khi chia task
Hiện tại khi nhận yêu cầu, chúng ta trực tiếp chia thành các task nhỏ và gán cho sub-agent. Vấn đề: không có tài liệu đặc tả chung, mỗi sub-agent tự diễn giải yêu cầu theo cách riêng → inconsistency.
目前收到需求後直接拆 task 派給 sub-agent。問題：沒有共通的規格書，每個 sub-agent 各自解讀需求 → 不一致。
Cách áp dụng: Trước khi delegate_task, dành 1 lượt để viết brief kỹ thuật ngắn (data model, API contract, file dự kiến thay đổi). Brief này được inject vào context của mọi sub-agent. Không cần separate agent — tự làm trong 1-2 phút.
做法：在 delegate_task 之前，花 1 回合寫一份簡短技術摘要（資料模型、API contract、預期改動的檔案）。這份摘要注入每個 sub-agent 的 context。不需要獨立 agent — 自己做，1-2 分鐘。
Bài học #2: Phân loại lỗi review theo Critical / Important / Minor
Hiện tại reviewer chỉ trả về PASS/REQUEST_CHANGES. Điều này khiến implementer không phân biệt được "phải sửa ngay" và "nên cân nhắc".
目前 reviewer 只回 PASS/REQUEST_CHANGES。implementer 無法區分「必須改」和「建議改」。
Cách áp dụng: Cập nhật prompt reviewer trong subagent-driven-development skill — yêu cầu output theo 3 mức: Critical (chặn merge), Important (nên sửa trước merge), Minor (có thể defer). Mỗi mục kèm file path + line number.
做法：更新 subagent-driven-development skill 中 reviewer prompt — 要求輸出三個等級：Critical（阻擋合併）、Important（應在合併前修正）、Minor（可延後）。每項附檔案路徑和行號。
Bài học #3: Pre-commit hook chặn secret
Bài viết nhấn mạnh chặn .env, .key, .pem, secrets.json trong commit. Đây là thứ dễ làm nhất, tác động lớn nhất, và chúng ta chưa có.
文章強調阻擋 .env、.key、.pem、secrets.json 進 commit。這是最容易做、影響最大、我們卻還沒做的事。
Cách áp dụng: Thêm file .git/hooks/pre-commit hoặc cấu hình trong .pre-commit-config.yaml để quét pattern như sk-, Bearer, -----BEGIN trước mỗi commit. 5 phút thiết lập, ngăn được thảm họa.
做法：在 repo 加入 pre-commit hook，掃描 sk-、Bearer、-----BEGIN 等 pattern。5 分鐘設定，防止災難。
Bài học #4: Viết acceptance test từ user story — không chỉ unit test
Hiện tại chúng ta chỉ yêu cầu sub-agent viết unit test. Nhưng unit test kiểm tra hàm — không kiểm tra "tính năng có thực sự làm điều người dùng cần không".
目前只要求 sub-agent 寫 unit test。但 unit test 測函式 — 不測「功能是否真的滿足使用者需求」。
Cách áp dụng: Khi user nêu yêu cầu (ví dụ: "thêm nút cảnh báo hóa đơn quá hạn"), trích xuất 2-3 tiêu chí chấp nhận trước khi code. Sub-agent implement xong thì một agent khác viết test kiểm tra đúng các tiêu chí đó. Không cần 7 agent — thêm 1 bước là đủ.
做法：使用者提需求時先萃取 2-3 條驗收標準。sub-agent 實作完後，另一個 agent 針對這些標準寫 acceptance test。不需要 7 個 agent — 加一個步驟就夠。
Điều không nên sao chép
Không nên: Chuỗi tuần tự cứng nhắc. Research → Story → Spec → Backend → Frontend → Test → Validate là quá chậm cho hầu hết task thực tế. Mỗi lần Frontend phát hiện API sai, phải quay lại Backend → chạy lại toàn bộ phần sau.
不該照抄：死硬的串聯鏈。Research → Story → Spec → Backend → Frontend → Test → Validate 對大部分任務太慢。前端發現 API 有問題就要從後端重跑整條鏈。
Làm thay: Giữ nguyên mô hình song song của chúng ta (nhiều sub-agent chạy đồng thời), nhưng thêm brief kỹ thuật chung làm input. Backend và Frontend cùng đọc chung một spec — không cần chạy tuần tự.
替代方案：保持我們現有的並行模式（多個 sub-agent 同時跑），但加入共通的技術摘要作為 input。Backend 和 Frontend 一起讀同一份 spec — 不需要串聯。
Tóm tắt: 3 việc làm ngay
| Hạng mục | Thời gian | Tác động |
|---|
| Thêm brief kỹ thuật trước khi delegate_task | 1-2 phút/task | Giảm inconsistency giữa các sub-agent |
| Reviewer output phân cấp Critical/Important/Minor | Cập nhật prompt | Implementer biết ưu tiên sửa gì |
| Pre-commit hook chặn secret | 5 phút | Ngăn lộ key lên GitHub |