05. Thực Thi Với AI Agent — Vibe Coding Series

Lần đầu dùng multi-agent, tôi ngồi nhìn 3 agent chạy song song và cảm giác như đang điều phối một đội dev nhỏ. Agent A đang implement hashPassword, agent B đang viết LoginForm, agent C đang setup database schema — tất cả cùng lúc. Mười lăm phút sau, tôi có 3 branch với code hoàn chỉnh, sẵn sàng để merge.

Nhưng lần đầu đó cũng là lần tôi học được rằng multi-agent không phải cứ “thả ra là chạy”. Không có workflow rõ ràng, 3 agent đó sẽ tạo ra 3 cách implement khác nhau, 3 naming convention khác nhau, và một đống conflict khi merge.

---

Bối cảnh

Ở bài 04, tôi đã breakdown feature “user authentication” của TaskFlow thành 8 task có acceptance criteria rõ ràng, kèm test spec cho từng task. Bài này bước vào Phase 4: thực thi — làm thế nào để feed task đó cho AI agent và nhận lại code đúng với kỳ vọng.

---

Single Agent Workflow

Feed context đúng cách

Sai lầm phổ biến nhất khi làm việc với AI agent là bắt đầu session mới và gõ thẳng: “Viết function hashPassword.” AI không biết bạn đang build gì, tech stack là gì, convention là gì.

Mỗi session mới, tôi feed context theo thứ tự này:

1. AI_CONTEXT.md — tổng quan project, tech stack, convention
2. Spec liên quan — OpenAPI spec hoặc task spec của feature đang làm
3. Task description — mô tả cụ thể task này, acceptance criteria, test spec

Prompt mẫu tôi dùng để mở session:

Đây là context cho session này:

[paste nội dung AI_CONTEXT.md]

Task cần implement:
- Tên: hashPassword utility
- Mô tả: Function hash password dùng bcrypt
- Acceptance criteria:
  * hashPassword(plaintext) → bcrypt hash với salt rounds = 12
  * verifyPassword(plaintext, hash) → boolean
  * Unit test cover happy path và wrong password
- Test spec: [paste test spec từ bài 04]

Implement function để tất cả test pass. Không thêm gì ngoài yêu cầu trên.

Câu cuối — “Không thêm gì ngoài yêu cầu trên” — quan trọng hơn bạn nghĩ. Không có câu đó, AI thường tự thêm logging, error handling phức tạp, hoặc abstraction layer không cần thiết.

Checkpoint pattern

Sau mỗi task hoàn thành, tôi commit ngay — dù task đó chỉ là một function 20 dòng.

git add -p                          # review từng hunk trước khi stage
git commit -m "feat(auth): add hashPassword and verifyPassword utilities"

Lý do: commit nhỏ = rollback dễ. Nếu task tiếp theo AI làm hỏng gì đó, tôi có thể git diff HEAD~1 để thấy chính xác thay đổi nào gây ra vấn đề. Với commit lớn, debug trở thành ác mộng.

Checkpoint cũng là tín hiệu để bạn review. Trước khi commit, bạn đọc diff — không phải đọc toàn bộ code, chỉ đọc những gì thay đổi. Đây là thời điểm tốt nhất để catch vấn đề sớm.

Context rot: nhận biết và xử lý

Context rot xảy ra khi AI “quên” dần context ban đầu sau nhiều lượt trao đổi. Dấu hiệu nhận biết:

• AI bắt đầu dùng naming convention khác với những gì đã thống nhất
• AI đề xuất giải pháp mâu thuẫn với architecture đã chốt
• AI hỏi lại những thông tin đã được cung cấp trước đó
• Code output bắt đầu diverge khỏi style của codebase

Khi thấy dấu hiệu này, đừng cố “nhắc nhở” AI trong cùng session. Cách xử lý hiệu quả nhất:

1. Reset session — mở conversation mới
2. Re-feed context — paste lại AI_CONTEXT.md và task description
3. Thêm context về những gì đã làm — “Đã implement Task 1–3, đây là code hiện tại: [paste relevant code]”

Context rot thường xảy ra sau 15–20 lượt trao đổi trong một session. Với task phức tạp, tôi chủ động reset sau mỗi 2–3 task thay vì đợi đến khi thấy dấu hiệu.

---

Multi-Agent Workflow

Git worktrees: chạy song song

Git worktrees cho phép bạn có nhiều working directory từ cùng một repository — mỗi worktree trên một branch riêng. Đây là nền tảng của multi-agent workflow.

# Tạo worktree cho từng agent
git worktree add ../taskflow-agent-auth feature/auth-utilities
git worktree add ../taskflow-agent-ui feature/login-form
git worktree add ../taskflow-agent-db feature/user-schema

# Mỗi thư mục là một working copy độc lập
# Agent A làm việc trong ../taskflow-agent-auth
# Agent B làm việc trong ../taskflow-agent-ui
# Agent C làm việc trong ../taskflow-agent-db

# Sau khi xong, dọn dẹp
git worktree remove ../taskflow-agent-auth

Mỗi agent chạy trong IDE riêng (hoặc tab riêng trong Cursor), trỏ vào thư mục worktree tương ứng. Các agent không biết nhau tồn tại — chúng chỉ làm task của mình trên branch của mình.

Orchestrator pattern

Với multi-agent, tôi dùng một agent đặc biệt làm “orchestrator” — agent này không viết code, chỉ điều phối.

Orchestrator nhận toàn bộ task list và dependency graph từ bài 04, rồi quyết định:

• Task nào có thể chạy song song (không có dependency)
• Task nào phải đợi task khác hoàn thành
• Khi nào cần human review trước khi tiếp tục

Trong thực tế với TaskFlow, tôi dùng orchestrator để quản lý 8 task auth:

Orchestrator cũng là nơi tôi track tiến độ — sau mỗi batch, tôi review output trước khi cho orchestrator phân công batch tiếp theo.

Merge strategy

Sau khi các agent hoàn thành, merge theo thứ tự dependency:

# Merge theo thứ tự: base trước, dependent sau
git checkout main
git merge feature/user-schema        # Task 3 — base
git merge feature/auth-utilities     # Task 1, 2 — không depend vào nhau
git merge feature/auth-endpoints     # Task 5, 6, 7, 8 — depend vào trên

Trước mỗi merge, tôi chạy git diff main...feature/branch-name để xem toàn bộ thay đổi. Với multi-agent, conflict thường xảy ra ở shared files như types/index.ts hoặc utils/index.ts — những file mà nhiều agent cùng import. Giải pháp: định nghĩa shared types trước khi chạy agent, đưa vào AI_CONTEXT.md.

---

HITL (Human-in-the-Loop) Checkpoints

Khi nào cần human review bắt buộc

Không phải mọi task đều cần human review sâu. Nhưng có những điểm bắt buộc phải dừng lại:

• Security-critical code: authentication logic, authorization check, input validation, cryptography
• Database migration: schema change không thể rollback dễ dàng
• External API integration: code gọi đến third-party service, xử lý webhook
• Business logic phức tạp: pricing calculation, permission matrix, state machine
• Bất kỳ thứ gì AI “sáng tạo” ngoài spec: nếu AI thêm feature không được yêu cầu, đó là red flag

Với TaskFlow, tôi review bắt buộc trước khi merge bất kỳ task nào liên quan đến auth — dù test đã pass.

Cách review AI code hiệu quả

Đừng đọc từng dòng code AI viết — bạn sẽ mất cả ngày và vẫn bỏ sót vấn đề quan trọng. Thay vào đó:

Focus vào interface, không phải implementation. Hàm nhận input gì, trả về gì, throw exception khi nào? Đây là phần bạn cần hiểu và đồng ý.

Đọc test trước, đọc code sau. Test spec là acceptance criteria — nếu test pass và test spec đúng, code likely đúng. Đọc code để hiểu cách nó làm, không phải để verify nó có làm đúng không.

Hỏi AI giải thích những đoạn không rõ. “Tại sao dùng Promise.all ở đây thay vì sequential?” — câu trả lời của AI sẽ cho bạn biết nó có hiểu trade-off không, hay chỉ đang pattern-match.

Check edge case trong spec. Với auth, tôi check: điều gì xảy ra khi token expired? Khi database down? Khi user gửi request đồng thời? Nếu spec không cover, đó là lỗ hổng cần bổ sung.

---

Ví dụ thực chiến: TaskFlow Auth + UI

3 task auth với single agent

Task 1, 2, 3 của auth (hash, JWT, user model) không có dependency — nhưng tôi chọn dùng single agent cho cả 3 vì chúng share nhiều type definition.

Session flow:

1. Feed AI_CONTEXT.md + task spec cho cả 3 task
2. Yêu cầu AI implement Task 1 trước, chạy test, commit
3. Trong cùng session, yêu cầu AI implement Task 2, chạy test, commit
4. Task 3 tương tự — AI vẫn có context từ Task 1 và 2, nên type definition nhất quán
5. Sau Task 3, reset session trước khi làm Task 4

Kết quả: 3 task trong ~45 phút, code nhất quán, test pass 100%.

2 task UI với multi-agent

Sau khi auth backend xong, tôi cần LoginForm và RegisterForm — hai component độc lập, không có dependency.

# Setup 2 worktrees
git worktree add ../taskflow-login feature/login-form
git worktree add ../taskflow-register feature/register-form

# Mở 2 tab Cursor, mỗi tab trỏ vào 1 worktree
# Feed context cho cả 2 agent: AI_CONTEXT.md + design system token + task spec

Agent 1 implement LoginForm, agent 2 implement RegisterForm — song song. Cả hai đều được feed design system token từ bài 03, nên style nhất quán dù chạy độc lập.

Sau 20 phút, tôi có 2 branch. Review từng branch, merge login-form trước, register-form sau. Không có conflict vì hai component nằm ở file riêng biệt.

---

Những điều cần tránh

Approve code AI mà không hiểu. “Test pass là được” là tư duy nguy hiểm — đặc biệt với security code. Test chỉ verify behavior đã được spec, không verify behavior chưa được nghĩ đến. Nếu bạn không hiểu code, bạn không thể biết spec có đủ không.

Để agent chạy quá lâu không có checkpoint. Một agent chạy 2 tiếng không có checkpoint = 2 tiếng code có thể đi sai hướng. Checkpoint sau mỗi task không chỉ là git commit — đó là cơ hội để bạn verify direction trước khi AI đi quá xa.

---

Tóm tắt

• Feed context theo thứ tự: AI_CONTEXT.md → spec → task description, mỗi session mới
• Commit sau mỗi task: checkpoint nhỏ = rollback dễ, review hiệu quả
• Context rot xảy ra sau ~15–20 lượt — reset session và re-feed thay vì cố nhắc nhở
• Git worktrees cho phép nhiều agent chạy song song trên branch riêng
• HITL bắt buộc với security code, database migration, và bất kỳ thứ gì AI thêm ngoài spec

---

Tiếp theo

Code đã được implement và commit. Bước tiếp theo là đảm bảo code đó đủ chất lượng để merge vào main — automated QA, AI-assisted code review, và PR workflow khi phần lớn code do AI viết.

→ Bài 06: QA, Code Review & PR Workflow

← Bài 04: Task Planning & Test Strategy