Agent production không thắng bằng PR đẹp

Agent production không thắng bằng PR đẹp

Muốn agent tự ship code, đừng chỉ hỏi model nào mạnh. Hãy hỏi ai giao việc, ai chặn lỗi, ai chịu on-call khi PR đó lên production.

“Agent đã mở PR rồi, giờ ai dám bấm merge?”

Mình nghe câu này trong vài team Việt Nam nhiều hơn số lần mình thấy bảng giá API đổi lúc nửa đêm. Demo thì mượt: agent đọc ticket, sửa code, viết test, mở pull request. Nhưng tới lúc PR chạm vào hệ thống thật — nơi có khách hàng, deploy window, on-call, compliance, và một repo đã sống mười năm — không khí bỗng giống đi chợ cuối ngày: hàng nhìn tươi, giá có vẻ mềm, nhưng bạn vẫn phải tự cân lại.

Case của monday.com đáng để mổ vì họ không kể chuyện agent như món đồ chơi trong lab. Họ chạy AI Teammates trên Amazon Bedrock trong một codebase lâu năm, có hàng trăm microfrontends và microservices, nhiều nhóm builder cùng làm việc, và mỗi PR agent mở ra đều có khả năng ảnh hưởng tới sản phẩm đang phục vụ hàng triệu người dùng trả tiền.

Luận điểm của mình: agent production không đáng tin vì nó “thông minh”, mà vì hệ thống quanh nó biết giao việc, giới hạn quyền, đo độ tự tin, và dừng đúng lúc. Sau bài này, nếu bạn đang build agent cho engineering workflow, câu hỏi nên đổi từ “model nào code giỏi hơn?” sang “orchestration và guardrail của mình có đủ rõ để cho agent chạm vào production chưa?”

Sơ đồ minh họa cho bài Agent production không thắng bằng PR đẹp

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

Bối cảnh: agent không ngồi trong IDE nữa

monday.com mô tả hành trình agent theo ba mức.

L1 là assistant: kỹ sư dùng AI như pair programmer. Việc vẫn nằm trong tay người. AI giúp viết, sửa, giải thích, refactor. Đây là mức nhiều team đã quen.

L2 là skills và sub-agents: team đóng gói các năng lực lặp lại thành agent nhỏ. Ví dụ agent tạo migration, agent cập nhật test, agent sửa lỗi lint theo pattern. Kỹ sư vẫn cầm lái, nhưng không phải gõ từng bước.

L3 là multi-agent: nhiều agent phối hợp để nhận task, trao đổi trong công cụ nội bộ, viết code, mở PR, và tiến gần tới delivery end-to-end. Multi-agent ở đây nghĩa là nhiều agent chia vai, không phải một model khổng lồ ôm hết việc.

Điểm thú vị là monday.com không chỉ có “job queue”. Họ xây Sphera như một hệ thống đồng đội AI, nơi agent có profile, manager, scope, performance score. Atlas — agent được nhắc trong case — có vai trò Software Engineer: nhận ticket, viết PR, ship feature. Không cần IDE.

Nói thẳng ra thì: đây không còn là “AI autocomplete”. Đây là một lớp vận hành phần mềm mới, nơi agent được đối xử gần giống một contributor có quyền hạn được quản lý.

Quyết định kiến trúc: đừng mua rau theo tiếng rao

Sai lầm phổ biến là thấy agent mở được PR thì tưởng đã gần xong. Với production, PR chỉ là mặt tiền. Phía sau cần ít nhất bốn lớp.

1. Orchestration: ai điều phối việc gì, theo thứ tự nào

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 workflow coding, nó quyết định agent lấy task từ đâu, đọc context nào, gọi tool nào, chạy test nào, khi nào hỏi người.

Nếu không có orchestration rõ, agent dễ nhảy cóc: đọc ticket chưa đủ đã sửa code, sửa xong không chạy test phù hợp, hoặc mở PR với mô tả rất tự tin nhưng thiếu lý do kỹ thuật.

Ví dụ cụ thể: giả sử team bạn có ticket “thêm field invoice_status vào dashboard”. Một orchestration tử tế nên buộc agent đi qua các bước:

Không phải bước nào cũng cần model “suy nghĩ”. Nhiều bước nên là rule, script, hoặc CI.

2. Guardrail: quyền được làm và quyền không được làm

Guardrail là hàng rào kiểm soát để agent không vượt khỏi phạm vi an toàn. Với builder, guardrail không chỉ là “không nói nội dung xấu”. Nó là quyền ghi file, quyền gọi API, quyền sửa package, quyền chạm database migration, quyền mở PR vào repo nào.

Trong case monday.com, điểm đáng học không phải “agent biết code”, mà là agent có scope như một thành viên trong hệ thống. Scope giúp bạn tránh cảnh agent đi kỳ kèo nhầm sạp: task frontend lại sửa shared auth library, hoặc ticket nhỏ lại động vào pipeline deploy.

Một guardrail thực dụng có thể gồm:

3. Confidence score: độ tự tin phải biến thành hành động

Confidence score là điểm tự tin của hệ thống về việc agent đã làm đúng. Nhưng điểm này chỉ có ý nghĩa nếu nó dẫn tới quyết định.

Điểm cao có thể cho phép agent mở PR bình thường. Điểm trung bình cần reviewer có kinh nghiệm. Điểm thấp thì dừng, yêu cầu làm rõ ticket, hoặc chuyển về human.

Đây là chỗ nhiều team làm nửa vời: họ có eval — bộ đánh giá chất lượng đầu ra — nhưng eval chỉ nằm trên dashboard cho đẹp. Production cần mapping rõ:

| Tín hiệu | Hành động nên làm |
|---|---|
| Test pass, diff nhỏ, module ít rủi ro | Cho mở PR với reviewer thường |
| Test thiếu, chạm nhiều module | Gắn nhãn rủi ro, yêu cầu senior review |
| Đổi auth/billing/permission | Chặn auto-merge, bắt buộc owner duyệt |
| Ticket mơ hồ, plan không ổn | Không viết code, hỏi lại |

Confidence mà không nối với policy thì giống cân điện tử đặt giữa chợ nhưng chẳng ai nhìn số.

4. Merge play: tự động hóa đoạn cuối mới là đoạn khó

Merge play có thể hiểu là kịch bản quyết định khi nào PR được merge, cần ai duyệt, và điều kiện nào phải pass. monday.com nhắc tới hướng confidence-scored merge play để thu hẹp khoảng cách tới autonomy.

Đây là lớp nhiều demo bỏ qua. Agent mở PR thì dễ gây wow. Nhưng để PR đó đi qua review, CI, policy, ownership, release, rollback — khả năng hoàn tác khi deploy lỗi — mới là chỗ production lộ răng.

Nếu bạn để agent tự merge quá sớm, rủi ro nằm ở hệ thống thật. Nếu bạn bắt người review mọi thứ như PR bình thường, lợi ích tự động hóa bị nghẽn. Tradeoff nằm ở việc phân loại rủi ro, không phải ở niềm tin chung chung vào AI.

Hệ quả: năng suất tăng, nhưng trách nhiệm không biến mất

Theo dữ liệu nội bộ được monday.com chia sẻ, chín trên mười Builders dùng AI coding tools hằng tháng, tăng mạnh so với khoảng một nửa vào năm trước. Per-engineer PR throughput cũng tăng hơn một nửa.

Con số này đáng chú ý, nhưng mình không muốn bạn đọc nó như lời hứa “gắn agent vào là throughput tăng”. Nó chỉ nói rằng khi AI được đặt vào workflow thật, có adoption thật, và có lớp vận hành đủ nghiêm, output engineering có thể thay đổi rõ.

Hệ quả quan trọng hơn nằm ở trách nhiệm.

Khi agent viết code, ai là owner của bug? Khi agent mở PR, ai chịu on-call nếu deploy hỏng? Khi agent sửa module không quen, ai đảm bảo context không bị hiểu sai? Những câu hỏi này không thể giao cho model trả lời bằng prose.

Bạn cần ownership map, audit log, observability — khả năng quan sát hệ thống khi chạy — và policy review. Agent càng tự động, dấu vết càng phải rõ. Không có log thì postmortem sau sự cố sẽ thành buổi đoán mò tập thể.

Bài học: framework “4 cửa” trước khi cho agent chạm repo

Nếu là tech lead, mình sẽ không bắt đầu bằng việc chọn model. Mình sẽ dùng framework “4 cửa” này để quyết định agent được đi tới đâu.

Cửa 1: Task có đóng khung được không?

Task tốt cho agent thường có đầu vào rõ, output kiểm được, và scope hẹp. Ví dụ: cập nhật component theo design token mới, thêm test cho endpoint, migrate API client theo pattern có sẵn.

Task xấu: “cải thiện UX dashboard”, “tối ưu performance toàn app”, “refactor module payment”. Không phải agent không giúp được, mà nó cần chia nhỏ trước.

Cửa 2: Context có lấy được bằng máy không?

Nếu context nằm trong đầu một senior, agent sẽ đoán. Nếu context nằm trong ticket, spec, code owner, docs, ADR, test, log lỗi, agent có đất làm việc.

Đây là khác biệt giữa agent production và chatbot coding. Chatbot cần prompt hay. Agent production cần nguồn context có cấu trúc.

Cửa 3: Kết quả có kiểm chứng tự động không?

Không test, không lint, không static check, không snapshot, không contract test thì agent chỉ đang bán cho bạn một bó rau nhìn xanh. Bạn vẫn chưa biết có sâu hay không.

Với mỗi loại task, hãy xác định “definition of done” bằng máy trước:

Cửa 4: Khi sai, hệ thống dừng ở đâu?

Agent không cần đúng tuyệt đối. Nhưng hệ thống phải biết điểm dừng. Dừng ở plan, dừng trước khi ghi file, dừng trước khi mở PR, dừng trước merge, hay dừng sau deploy bằng rollback?

Mỗi điểm dừng càng muộn thì chi phí lỗi càng cao.

Áp dụng cho team Việt Nam trong một buổi chiều

Hình dung thế này: team bạn có 6 developer, một monorepo vừa đủ rối, đang muốn thử agent xử lý bug nhỏ. Đừng nhảy thẳng tới “agent tự ship”. Làm bản mỏng trước.

Trong một buổi chiều, bạn có thể tạo một lane an toàn:

  1. Chọn một nhóm task hẹp: ví dụ sửa lỗi lint, thêm unit test cho util, cập nhật copy trong UI.
  2. Viết policy file: agent được sửa folder nào, không được sửa folder nào, khi nào phải hỏi lại.
  3. Chuẩn hóa template PR: bắt agent ghi “task summary”, “files changed”, “tests run”, “risk notes”.
  4. Gắn CI tối thiểu: lint, unit test liên quan, check diff không chạm file cấm.
  5. Chấm confidence thủ công trước: reviewer đánh nhãn safe, needs-care, blocked trong 20 PR đầu để học pattern.

Sau đó mới tính chuyện tự động hóa thêm. Đừng bắt đầu bằng multi-agent nếu một agent đơn lẻ còn chưa có biên giới rõ.

Điều dễ bị thổi quá tay

Có ba thứ mình sẽ không vội tin.

Thứ nhất, “agent như teammate” không có nghĩa là agent có judgment như người. Nó có thể có profile, scope, performance score, nhưng vẫn cần hệ thống kiểm soát.

Thứ hai, PR throughput tăng không đồng nghĩa chất lượng tăng theo cùng nhịp. Bạn cần nhìn thêm defect rate, review load, incident, rollback, thời gian senior phải sửa lại.

Thứ ba, L3 không phải đích đến cho mọi team. Nhiều team sẽ sống khỏe ở L2 rất lâu: skills tốt, sub-agents rõ, người vẫn quyết định đoạn cuối. Đó không phải thất bại. Đó là biết mình đang mua gì, cân lại ra sao, và trả giá cho rủi ro nào.

Chốt lại: độc giả nên nghĩ khác ở điểm này — agent production là bài toán thiết kế hệ thống chịu trách nhiệm, không phải cuộc thi chọn model viết code hay nhất. Model là động cơ. Nhưng orchestration, guardrail, confidence và merge policy mới quyết định chiếc PR đó có nên đi qua cổng production hay không.

Agent mở PR đẹp thì vui. Agent biết dừng đúng chỗ mới là đáng tiền.

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

Nguồn tham khảo