Agent coding: đừng giao bài khi chưa chấm được

Agent coding: đừng giao bài khi chưa chấm được

Muốn đưa coding agent lên production? Đừng hỏi agent nào thông minh nhất trước. Hãy hỏi orchestration, quyền hạn và bảng điểm vận hành đã rõ chưa.

Bạn có dám giao cùng một GitHub issue cho bốn coding agent rồi tắt laptop đi uống cà phê không?

Mình hỏi vậy vì dạo này nhiều team đang có một thói quen khá buồn cười: laptop mở hé như học sinh giấu truyện trong ngăn bàn, chỉ để agent đang chạy không bị chết giữa chừng. Claude Code, Codex, Kiro, Cursor CLI, Gemini CLI hay harness tự ráp đều gặp chung một chuyện: chúng cần shell, filesystem, repo, dependencies và quyền truy cập. Laptop có đủ, nên laptop bị bắt làm máy chủ bất đắc dĩ.

Nhưng câu hỏi production không phải là “agent nào viết code hay nhất?”. Câu hỏi đúng hơn là: team bạn đã có giáo án, quyền vào lớp, và bảng điểm để chấm agent chưa?

Nói thẳng ra thì, coding agent chỉ đáng tin khi orchestration và guardrail rõ ràng. Model mới nhất chỉ là một học sinh giỏi. Hệ thống production cần cả cách giao bài, giới hạn được phép làm, log từng bước, và tiêu chí chấm bài sau khi nộp.

Sơ đồ minh họa cho bài Agent coding: đừng giao bài khi chưa chấm được

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

Quyết định đầu tiên: chạy trên laptop hay đưa vào runtime riêng?

Nguồn từ AWS về Amazon Bedrock AgentCore đặt ra một điểm rất thực tế: coding agent không nhất thiết phải sống trên laptop. Nếu bóc lớp hào nhoáng đi, một agent cần môi trường Linux cô lập, workspace bền, shell thật, lệnh chạy có thể dự đoán, và quyền truy cập đúng mức.

Với team builder, đây là quyết định kiến trúc, không phải lựa chọn tool cho vui.

| Lựa chọn | Khi hợp | Điểm mạnh | Rủi ro |
|---|---|---|---|
| Chạy trên laptop dev | Thử nghiệm cá nhân, task ngắn | Nhanh, ít setup | Khó audit, phụ thuộc máy cá nhân, dễ lộ credential |
| Self-host sandbox | Team có infra mạnh, cần tùy biến | Kiểm soát cao | Tốn vận hành, phải tự lo identity và observability |
| Managed runtime như AgentCore | Team muốn chuẩn hóa agent workflow | Có isolation, identity, gateway, log tập trung | Phụ thuộc cloud, cần tính kỹ cost và permission model |

Điểm mình muốn bạn đổi cách nghĩ: đừng chọn agent theo demo; hãy chọn môi trường chạy theo khả năng kiểm soát lỗi. Nếu agent sửa nhầm file, gọi nhầm API, hoặc treo giữa pipeline, bạn cần biết nó đã làm gì, với quyền nào, trong phiên nào.

Framework 4 ô: trước khi cho agent cầm repo

Thay vì hỏi “nên dùng Claude Code hay Codex?”, mình sẽ bắt đầu bằng bốn ô kiểm tra này.

1. Runtime — agent ngồi ở đâu?

Runtime là môi trường chạy agent: nơi có shell, repo, dependency và workspace. Với production, runtime nên cô lập theo phiên hoặc theo task. Nếu một agent làm bể môi trường, phiên khác không bị kéo theo.

Ví dụ cụ thể: giả sử team bạn có 5 developer, mỗi người đều thỉnh thoảng giao agent sửa bug. Nếu tất cả chạy trên laptop cá nhân, việc reproduce lỗi sẽ giống chấm bài mà mỗi bạn dùng một đề khác nhau. Runtime chuẩn hóa giúp team nói cùng một ngôn ngữ: cùng OS, cùng dependency, cùng cách chạy test.

2. Identity — agent đang đại diện cho ai?

Identity là lớp định danh và phân quyền: agent hành động dưới danh tính người hoặc service đã được cho phép. Đây là phần nhiều demo bỏ qua, nhưng production thì không.

Nếu agent mở pull request, comment Jira, đọc Slack, hay gọi service nội bộ, bạn cần biết hành động đó thuộc về ai. Không phải để đổ lỗi, mà để giới hạn phạm vi. Một intern được giao bài tập về nhà không nên có chìa khóa vào phòng điểm của cả trường.

3. Gateway — agent được gọi công cụ nào?

Gateway là lớp trung gian gom tool/API lại, thường có thể đi qua MCP, tức Model Context Protocol — giao thức giúp model truy cập công cụ theo cách thống nhất. Ý tưởng hay ở AgentCore là token thật nằm ngoài agent, còn agent chỉ gọi qua cổng đã kiểm soát.

Điều này quan trọng hơn bạn tưởng. Khi nhiều agent cùng dùng GitHub, Jira, Slack, Figma hoặc service nội bộ, bạn không muốn mỗi agent giữ một bộ credential riêng. Bạn muốn một cửa ra vào có log, policy và khả năng thu hồi quyền.

4. Observability — chấm bài bằng gì?

Observability là khả năng quan sát hệ thống: log, trace, metric, event để biết chuyện gì đã xảy ra. Với agent, observability không chỉ là “có log không”, mà là có trả lời được các câu này không:

Không có bảng điểm này, bạn chỉ đang tin vào cảm giác.

Một buổi để thử: bài kiểm tra nhỏ cho team builder

Nếu muốn kiểm chứng mà không biến thành dự án quý, bạn có thể làm một bài test gọn trong một buổi chiều.

Bước 1: Chọn một issue thật nhưng không nguy hiểm.

Đừng chọn task toy. Hãy lấy một bug nhỏ có test rõ, hoặc một refactor có phạm vi hẹp. Task phải đủ thật để lộ vấn đề orchestration, nhưng không đủ lớn để làm cháy sprint.

Bước 2: Viết spec đầu vào như đề kiểm tra.

Spec nên có:

- Mục tiêu thay đổi
- File hoặc module liên quan
- Lệnh test bắt buộc chạy
- Điều không được làm
- Format kết quả mong muốn

Phần “điều không được làm” rất đáng tiền. Ví dụ: không đổi public API, không sửa schema, không thêm dependency mới nếu chưa giải thích.

Bước 3: Chạy cùng task qua 2-3 agent hoặc 2 runtime.

Không cần biến thành benchmark hoành tráng. Bạn chỉ cần so sánh theo tiêu chí vận hành:

Nguồn AWS mô tả cách giao cùng một GitHub issue cho nhiều coding agent trong môi trường riêng và chấm theo latency, dollar cost, test pass. Mình thích hướng đó vì nó kéo cuộc tranh luận khỏi “model nào thông minh hơn” sang “workflow nào kiểm soát được hơn”.

Bước 4: Đặt ngưỡng đổi quyết định.

Đây là đoạn nhiều team bỏ sót. Trước khi thử, hãy viết sẵn điều kiện:

Hình dung thế này: bạn không chỉ xem học sinh nào làm bài nhanh, bạn còn xem bài có ghi lời giải đủ để thầy cô chấm lại không. Agent làm đúng một lần nhưng không giải thích được đường đi vẫn là rủi ro production.

Case đáng học: review code không chỉ nhìn diff

Nguồn về Baz có một chi tiết hay: họ không dừng ở review code theo diff, mà kéo product requirement, design intent và hành vi thực tế vào cùng workflow. Agent không chỉ hỏi “code có compile không?”, mà hỏi “feature có đúng spec không?”.

Đây là bước trưởng thành của agent automation. Với team Việt Nam, mình thấy bài học áp dụng được ngay: nếu code review của bạn vẫn phụ thuộc vào một anh lead nhớ hết context sản phẩm trong đầu, agent có thể giúp gom context trước khi con người ra quyết định.

Nhưng đừng hiểu nhầm. Agent review không thay reviewer. Nó chuẩn bị mặt bàn: lấy Jira, đối chiếu Figma, chạy test, ghi nhận mismatch. Người review vẫn quyết định có merge không.

Orchestration — điều phối nhiều bước và nhiều tool — chính là phần khiến agent review hữu ích. Không có orchestration, bạn chỉ có một chatbot đọc diff. Có orchestration, bạn có workflow biết lấy yêu cầu, kiểm tra UI, so với spec, rồi đưa ra bằng chứng.

Bẫy: nhiều agent không tự nhiên thành hệ thống tốt

Nguồn DataCamp về agent swarm nhắc tới việc chia vai: researcher, writer, reviewer, manager. Ý tưởng này đúng trong nhiều workflow, nhưng với coding agent production, chia nhiều vai không tự động làm hệ thống đáng tin hơn.

Agent swarm là nhóm nhiều agent phối hợp theo vai trò. Tradeoff chính là chi phí điều phối tăng lên: càng nhiều agent, càng nhiều trạng thái trung gian, càng nhiều điểm fail.

Nếu task chỉ là sửa một bug có test rõ, một agent với runtime tốt có thể đủ. Nếu task cần gom spec, đọc design, chạy preview, kiểm tra behavior, rồi viết nhận xét review, multi-agent mới đáng cân nhắc.

Một tín hiệu khác từ nghiên cứu được MarkTechPost tóm lược: agent phù hợp hơn với workflow dài, nhiều bước; còn tra cứu ngắn vẫn hợp với search hoặc assistant hội thoại. Con số cụ thể trong nguồn cho thấy agent có thể chạy phiên tự chủ dài hơn rất nhiều so với search, nhưng điều quan trọng với builder là mô hình chi phí: agent có fixed cost cao hơn cho việc giao việc và review, nhưng marginal cost cho từng bước có thể thấp hơn khi workflow đủ dài.

Vì vậy, đừng đưa mọi task vào agent queue. Hãy hỏi: task này có đủ bước để việc ủy quyền đáng công không?

Nếu là mình, mình sẽ chọn thế này

Với team đang build hệ thống AI hoặc platform nội bộ, mình sẽ dùng quyết định sau:

Điều kiện đổi quyết định cũng rõ: nếu số lần can thiệp của con người không giảm, test không pass ổn định, hoặc trace không đủ để debug, hãy hạ cấp lại. Production không thưởng điểm cho hệ thống phức tạp mà không kiểm soát được.

Takeaway của mình: agent không cần được tin tuyệt đối; agent cần được giao bài đúng, giới hạn đúng, và chấm đúng. Còn nếu bạn vẫn phải mở hé laptop để giữ agent sống, thì lớp học này chưa có phòng máy tử tế đâu.

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

Nguồn tham khảo