Agent code đang tranh ghế build pipeline

Đừng chọn coding agent theo demo đẹp. Với team build thật, câu hỏi đúng là agent nào chịu được orchestration, guardrail và audit trail.

Bụi Wire

2026-07-16

“Agent này tự mở PR được rồi, vậy mình có cần junior dev nữa không?” — nếu bạn từng nghe câu này trong một buổi planning hơi thiếu cà phê, xin chào, bạn không cô đơn.

Nhưng mình nghĩ câu hỏi đó đang lệch hướng. Coding agent không chỉ đang cạnh tranh nhau ở chuyện viết code nhanh hơn. Tín hiệu đáng để ý hơn là: ai sẽ kiểm soát workflow từ prompt đến pull request — model lab, IDE, cloud platform, hay chính team bạn?

Cuộc so kè giữa Mistral Vibe for Code, Claude Code, Cursor và Codex nhìn bề ngoài giống một bảng điểm tool. Nhưng đọc kỹ hơn, nó là dấu hiệu thị trường: coding agent đang rời khỏi vai “autocomplete thông minh” để tranh ghế trong build pipeline. Và khi agent đã ngồi vào pipeline, production không tha thứ cho kiểu “nó thông minh mà”.

Sơ đồ minh họa cho bài Agent code đang tranh ghế build pipeline

Sơ đồ tóm tắt ý chính của bài viết.

Cuộc tranh luận không còn là “agent nào code giỏi hơn”

Một scaffold-to-PR task nghe khá đời: trong service Python/FastAPI có sẵn, thêm endpoint /subscriptions, tạo route, Pydantic models, service layer, test unit/integration, chạy test, sửa lỗi, rồi mở pull request có mô tả rõ.

Đây không phải bài toán “viết một hàm đảo chuỗi”. Nó đụng vào ba vùng đau thật của engineering:

Scaffold: hiểu cấu trúc repo và đặt file đúng chỗ.
Test loop: tạo test, chạy test, đọc lỗi, sửa tiếp.
Ship: mở PR, viết mô tả, để người khác review được.

Nói thẳng ra thì, nếu một coding agent chỉ mạnh ở bước đầu, nó giống đồng nghiệp viết draft rất nhanh nhưng cứ đến daily standup là không biết hôm qua mình đã làm gì, fail ở đâu, cần ai review. Trong production, phần “nhớ đường đi nước bước” nhiều khi quan trọng hơn đoạn code đầu tiên.

Vì vậy, mình sẽ không đọc các agent này theo bảng xếp hạng đơn giản. Mình đọc theo quyền kiểm soát workflow.

Biến số 1: agent nằm ở đâu trong hệ thống làm việc?

Cùng là “coding agent”, nhưng vị trí triển khai khác nhau kéo theo tradeoff khác nhau.

| Hướng tiếp cận | Điểm mạnh | Điểm phải coi chừng |
|---|---|---|
| IDE-first như Cursor | Sát tay developer, context repo tốt, vòng lặp nhanh | Dễ thành năng suất cá nhân, khó chuẩn hóa team-wide |
| CLI/agent-first như Claude Code, Codex, Mistral Vibe CLI | Tự động hóa được trong terminal, dễ gắn với script/CI hơn | Cần guardrail rõ để không chạm nhầm file, tool, secret |
| Platform-first như Vercel AI Gateway/Sandbox | Có lớp deploy, audit, sandbox, token routing | Dễ phụ thuộc platform, cần hiểu chính sách dữ liệu và chi phí |

Ở đây có một tín hiệu thị trường khá rõ: platform không muốn chỉ là nơi host app sau khi code xong. Vercel nói họ thấy lượng deployment rất lớn, trong đó có phần đáng kể được kích hoạt bởi coding agents, và AI gateway xử lý lượng token khổng lồ mỗi ngày. Điều này cho thấy incentive đã đổi: ai đứng giữa agent và production sẽ nắm log, routing, policy, billing và governance.

Với team Việt Nam, nhất là team 5-20 dev, câu hỏi thực dụng không phải “tool nào đang hot”. Câu hỏi là:

Agent này chạy trong laptop từng người, trong CI, hay trong một sandbox có kiểm soát?

Nếu câu trả lời là “chưa rõ”, bạn chưa chọn tool; bạn mới chọn một cảm giác.

Biến số 2: orchestration có được thiết kế hay chỉ cầu may?

Orchestration là cách điều phối nhiều bước, nhiều tool hoặc nhiều agent để hoàn thành một việc. Trong coding task, orchestration không chỉ là “model gọi terminal”. Nó là thứ quyết định agent có biết:

đọc cấu trúc repo trước khi sửa,
giới hạn phạm vi file được phép chạm,
chạy test nào trước,
dừng lại khi fail kiểu nguy hiểm,
viết PR description dựa trên diff thật.

Nguồn AWS về multi-agent social intelligence tuy không nói trực tiếp về coding agent, nhưng có một bài học đáng kéo sang: khi tín hiệu đến từ nhiều nguồn và nhiều API khác nhau, một agent tổng quát dễ bị quá tải. Họ chia việc cho specialist agents rồi dùng agent phân tích để hợp nhất kết quả. Trong codebase cũng vậy: test runner, dependency checker, diff reviewer, security scanner — mỗi vai có luật riêng.

Ví dụ cụ thể: giả sử team bạn muốn agent tự xử lý ticket “thêm subscription endpoint”. Một orchestration tử tế có thể chia như sau:

Planner agent:
  - đọc issue
  - liệt kê file dự kiến sửa
  - tạo kế hoạch ngắn

Coder agent:
  - chỉ được sửa trong allowlist file/path
  - không được ghi vào migration nếu chưa có approval

Test agent:
  - chạy unit test liên quan trước
  - nếu fail, trả log đã rút gọn cho Coder

Review agent:
  - kiểm tra diff
  - so PR với acceptance criteria
  - chặn nếu thiếu test hoặc động vào secret/config nhạy cảm

Đây là chỗ nhiều team hiểu sai: agent mạnh hơn không tự động làm orchestration tốt hơn. Nếu brief lệch, đồng nghiệp giỏi vẫn có thể giao sai việc cho cả nhóm. Agent cũng vậy.

Vậy chọn A hay B: tool liền mạch hay stack tự kiểm soát?

Mình sẽ đặt quyết định thành hai hướng chính.

Hướng A: chọn agent “end-to-end” để tăng tốc ngay

Phù hợp khi:

repo chưa quá nhạy cảm,
team cần tăng tốc scaffold, refactor nhỏ, test generation,
review vẫn do người làm,
chưa muốn đầu tư nhiều vào hạ tầng agent riêng.

Ưu điểm là nhanh có kết quả. Cursor, Claude Code, Codex hay Mistral Vibe đều đang chạy đua để biến prompt thành PR ít ma sát hơn. Với team product nhỏ, đây có thể là cách hợp lý để giảm việc lặp lại.

Nhưng bẫy nằm ở chỗ: nếu agent đã có quyền chạy lệnh, sửa nhiều file, mở PR, bạn cần audit trail — vết ghi lại tool nào được gọi, dữ liệu nào được đọc, file nào được sửa. Không có audit trail thì khi PR làm hỏng staging, bạn chỉ còn cuộc họp truy vết bằng cảm tính. Mà cảm tính trong postmortem thì thường giống OKR viết vội: đọc xong ai cũng gật, nhưng không ai biết owner là ai.

Hướng B: tự dựng lớp orchestration và guardrail quanh agent

Phù hợp khi:

repo có logic nghiệp vụ nhạy cảm,
cần kiểm soát quyền truy cập file, secret, database,
agent sẽ chạy trong CI hoặc môi trường bán tự động,
team muốn đổi model/tool mà không viết lại workflow.

Ở hướng này, bạn không “cưới” một agent duy nhất. Bạn thiết kế hợp đồng làm việc: input là issue/acceptance criteria, output là branch/PR/diff/test result. Agent nào ngồi vào giữa cũng phải theo luật.

Guardrail là lan can vận hành: quy tắc giới hạn agent được làm gì, ở đâu, khi nào phải hỏi lại. Với builder, guardrail nên cụ thể ở mức:

allowlist thư mục được sửa,
denylist file nhạy cảm như .env, auth config, billing rules,
timeout cho lệnh terminal,
yêu cầu test pass trước khi mở PR,
bắt buộc human approval nếu đổi schema/database/migration,
log đầy đủ tool calling.

Tool calling là khả năng để model gọi công cụ hay API thay vì chỉ trả lời bằng chữ. Khi tool calling bước vào repo thật, mỗi tool nên có scope rõ. run_tests khác deploy_preview, và khác rất xa write_file.

Một khung chọn nhanh cho tech lead

Nếu là mình, mình sẽ không hỏi “agent nào điểm cao nhất?”. Mình sẽ dùng khung 3 ghế trong workflow:

1. Ghế viết code

Agent có hiểu repo không? Có tạo được test không? Có sửa theo log fail không?

Đây là phần bảng so sánh scaffold-to-PR giúp ích. Nhưng nó chỉ là ghế đầu tiên.

2. Ghế điều phối

Agent có kế hoạch nhiều bước không? Có biết dừng đúng lúc không? Có tách việc giữa scaffold, test, review không?

Nếu không, bạn cần orchestration bên ngoài: script, CI job, agent framework, hoặc platform sandbox.

3. Ghế chịu trách nhiệm

Khi có lỗi, ai giải thích được chuyện đã xảy ra? Có log tool calls không? Có diff dễ review không? Có policy chặn hành động nguy hiểm không?

Đây là ghế nhiều demo bỏ trống.

Hình dung thế này: bạn không tuyển một đồng nghiệp chỉ vì họ nói chuyện lanh. Bạn cần biết họ nhận brief thế nào, báo tiến độ ra sao, có đụng nhầm dữ liệu khách hàng không, và khi làm sai có để lại dấu vết đủ rõ để sửa. Coding agent cũng nên bị đánh giá như vậy.

Team Việt Nam nên để ý incentive nào?

Market signal ở đây là các bên đang kéo coding agent về lãnh địa của mình:

Model lab muốn bạn gắn workflow vào model/agent của họ.
IDE muốn giữ developer trong editor.
Cloud platform muốn trở thành nơi agent deploy, chạy, log và kiểm soát.
Open-source CLI muốn mở đường cho tự chủ và tùy biến.

Không bên nào “sai”. Nhưng incentive của họ không trùng hoàn toàn với incentive của team bạn.

Team bạn cần:

chi phí dự đoán được,
quyền đổi model khi giá/chất lượng đổi,
log đủ để audit,
guardrail đủ để ngủ được,
workflow không vỡ khi vendor đổi default model tuần sau.

Sau bài này, nếu bạn đổi một cách nghĩ, hãy đổi điểm này: coding agent không phải một app năng suất cá nhân nữa; nó đang trở thành một thành phần production trong engineering system. Mà đã là production component thì phải có contract, policy, monitoring và rollback.

Agent code có thể là đồng nghiệp tăng tốc rất đáng giá. Nhưng trước khi cấp thẻ ra vào production, nhớ hỏi nó thuộc team nào, báo cáo cho ai, và có biết viết handover không.

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