Triển khai coding agent — playbook chọn đúng từ đầu

Triển khai coding agent — playbook chọn đúng từ đầu

4 surface, 2 model tier, approval flow — playbook giúp team dev chọn đúng cách triển khai coding agent mà không đốt budget.

Bạn vừa được duyệt budget cho coding agent. Slack đã nổ 3 thread: một bên muốn model mới nhất, một bên lo bill gấp đôi, một bên hỏi "thế chạy trên surface nào?" Câu hỏi đúng không phải "có nên dùng coding agent không" — mà là dùng cái nào, chạy ở đâu, cho task gì.

Playbook này giúp team dev 3–15 người ra được 3 quyết định đó trong một tuần, thay vì mất một quý thử sai.

Playbook này dành cho ai?

Mình viết cho developer và tech lead đang cân nhắc đưa coding agent vào workflow thật — không phải demo cuối sprint. Cụ thể, mình lấy OpenAI Codex làm case study vì nó đang là nền tảng có nhiều surface (bề mặt triển khai) nhất để so sánh, nhưng framework chọn lựa bên dưới áp dụng được cho GitHub Copilot, Cursor, hay bất kỳ agent nào bạn đang đánh giá.

Codex không phải một model đơn lẻ — nó là lớp sản phẩm bọc quanh các model flagship của OpenAI, kèm theo file access, shell execution, sandbox (môi trường cô lập), và approval flow (quy trình phê duyệt). Hiểu điều này trước, bạn sẽ tránh được sai lầm phổ biến nhất: đánh đồng "chọn model" với "chọn agent."

Checklist: 4 câu phải trả lời trước khi cài

Trước khi mở terminal, ngồi lại với lead và trả lời:

  1. Budget tháng cụ thể bao nhiêu? Model flagship mới nhất (GPT-5.5) có chi phí per-token gấp khoảng 2 lần thế hệ trước. Giả sử team bạn 5 người, mỗi người dùng 2–3 giờ/ngày — con số cuối tháng có thể lệch xa ước tính nếu không chia model theo task.
  2. Task nào đang ngốn thời gian nhiều nhất? Viết test? Review PR? Refactor legacy? Mỗi nhóm task phù hợp surface khác nhau.
  3. Ai sẽ dùng? Chỉ dev, hay QA/PM cũng cần tương tác với output?
  4. Repo có dữ liệu nhạy cảm không? Sandbox và approval flow không phải "nice-to-have" — chúng là lớp bảo vệ bắt buộc khi agent có quyền thực thi code.

Nếu chưa trả lời được cả 4, dừng ở đây. Triển khai mà thiếu bất kỳ câu nào là đang mời rủi ro vào nhà.

Từng bước: 3 quyết định cốt lõi

Quyết định 1 — Chọn surface

Coding agent hiện đại chạy trên nhiều bề mặt. Với Codex, có 4 lựa chọn:

| Surface | Dùng khi | Tránh khi |
|---------|----------|-----------|
| CLI | Script automation, CI/CD, task có cấu trúc rõ | Team chưa quen terminal |
| IDE extension (VS Code, Cursor, Windsurf) | Code hàng ngày, inline suggestion, fix nhanh | Task dài cần chạy nền |
| Desktop app | Brainstorm, prototype, hỏi-đáp nhanh | Production code cần review chặt |
| Codex Cloud | Task lớn chạy background, review toàn repo trên GitHub | Quick fix, task cần phản hồi tức thì |

Ví dụ thực tế: Một team backend ở TP.HCM mình biết bắt đầu bằng Codex Cloud cho cả nhóm — kết quả là 3 PR được merge tự động mà không ai đọc kỹ, một trong số đó phá vỡ API contract với mobile team. Tuần sau họ quay về IDE extension kèm approval flow bắt buộc, và chỉ bật Cloud cho task refactor lớn có người review.

Khuyến nghị cho team Việt Nam: Bắt đầu bằng IDE extension cho dev, CLI cho lead và DevOps. Cloud chỉ mở khi team đã quen workflow và có approval matrix rõ ràng.

Quyết định 2 — Chọn model theo task, không theo tên

Đây là chỗ nhiều team đốt tiền không cần thiết. GPT-5.5 cải thiện rõ rệt ở khả năng giữ long-context (ngữ cảnh dài) và giảm hallucination (bịa thông tin) so với GPT-5.4 — nhưng chi phí gấp đôi.

Dịch sang quyết định thực tế:

Quyết định này giống chọn luật sư: tranh chấp hợp đồng nhỏ không cần senior partner, nhưng vụ kiện lớn mà giao cho thực tập sinh thì rủi ro không đáng.

Quyết định 3 — Thiết lập approval flow theo blast radius

Blast radius (phạm vi ảnh hưởng khi có lỗi) quyết định mức phê duyệt. Giả sử team 5 người, chia 3 mức:

  1. Auto-approve: Format code, thêm comment, update dependency version — sai thì sửa nhanh, không ảnh hưởng ai.
  2. Single review: Viết test mới, refactor function đơn lẻ — cần một người xác nhận logic đúng.
  3. Double review: Thay đổi schema, sửa business logic, code liên quan authentication — phải có 2 người ký trước khi merge.

Codex Cloud hỗ trợ cấu hình approval level. Nếu bạn dùng nền tảng khác, branch protection rules và CODEOWNERS file vẫn cho kết quả tương đương.

Ba cái bẫy phổ biến nhất

Bẫy 1 — "Model đắt nhất cho chắc." Một team fintech ở Hà Nội mình từng trao đổi: tháng đầu dùng toàn flagship cho mọi task, bill cuối tháng gấp 3 dự tính. Tháng sau chia model theo task type, chi phí giảm quá nửa mà chất lượng output ở nhóm task ngắn gần như không đổi.

Bẫy 2 — "Agent chạy tốt, mình khỏi review." Agent không có context về business rule mà chỉ team bạn hiểu. Coi agent như nhân chứng chuyên gia trước tòa — ý kiến rất có giá trị, nhưng phán quyết cuối cùng vẫn phải do hội đồng xét xử quyết định.

Bẫy 3 — "Rollout cả team ngày đầu." Bắt đầu với 1–2 người, chạy task bounded trong 2 tuần, đo lường thời gian tiết kiệm và số lỗi phát sinh. Rollout toàn team từ ngày một là cách nhanh nhất để không ai dùng đúng cách.

Hành động cụ thể

  1. Chiều nay: Cài IDE extension, thử 3 task bounded (viết test, fix lint error, generate docstring). Ghi lại thời gian trước và sau.
  2. Tuần này: Viết approval matrix 3 mức cho team, map từng loại task vào đúng mức.
  3. 2 tuần tới: Track chi phí theo task type. So sánh flagship vs model thế hệ trước ở từng nhóm — bạn sẽ thấy chỗ nào đáng trả gấp đôi, chỗ nào không.

Nếu team đã dùng GitHub Copilot hay Cursor, framework 3 quyết định trên vẫn áp dụng nguyên — chỉ thay tên surface, giữ nguyên logic phân loại.

Bản chất thật sự: coding agent không thiếu, thiếu là quy trình chọn đúng cái nào cho đúng việc.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo