Một coding agent có thể biến một ticket thành pull request trong lúc bạn đi pha cà phê. Tốc độ đó đặt ra một câu hỏi lặng lẽ hơn mà các công cụ chưa bao giờ trả lời giúp bạn: khi diff đã tồn tại, ai là người sở hữu nó? Không phải ai đã gõ ra nó — agent làm việc đó. Mà là ai chịu trách nhiệm xem nó có được phát hành hay không, đó có phải là thay đổi đúng hay không, và điều gì xảy ra khi nó hỏng lúc 2 giờ sáng. Việc thực thi đã chuyển sang agent. Quyền sở hữu thì không, và cũng không thể chuyển được.
Sự mờ nhạt ấy càng tệ hơn ngay khi bạn chạy nhiều hơn một agent. Giao một bug cho Claude Code và một bug khác cho Codex, thế là bạn có hai nhánh, hai bản tóm tắt, và không có câu trả lời chung cho một câu hỏi đơn giản: khi chúng được merge, tên ai sẽ đứng trên mỗi thay đổi? Quyền sở hữu nằm trong lịch sử cuộn của terminal không phải là quyền sở hữu. Đó chỉ là một phỏng đoán tồn tại được cho tới lần git log tiếp theo.
Đây là bài toán mà Sharkly được xây dựng để giải quyết. Sharkly nằm phía trên các coding agent của bạn như một tầng ghi lại ai đã giao việc, agent nào đã chạy nó, ai review kết quả và ai nghiệm thu nó. Bài viết này trình bày mô hình vận hành đó dưới dạng bốn vai trò cùng một tập hợp các trạng thái, rồi dẫn một ticket đi từ lúc được giao đến khi PR được merge. Về các cơ chế review bên dưới, hướng dẫn của chúng tôi về agent lập trình có con người trong vòng lặp trình bày năm cổng kiểm soát dùng để thực thi những quyết định này.
TL;DR
Con người sở hữu công việc do agent làm ra nghĩa là trách nhiệm đối với một thay đổi không bao giờ chuyển sang agent, kể cả khi việc thực thi đã chuyển. Mô hình vận hành gồm bốn vai trò: một người giao việc, một Agent thực thi, một người được nêu đích danh review, và chính người đó nghiệm thu. Agent chỉ có thể đưa một Task tới mức Ready for review; chỉ con người mới chuyển nó sang Done. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, trao quyền và nghiệm thu kết quả.
Ai sở hữu công việc mà agent tạo ra
Quyền sở hữu và việc thực thi là hai công việc khác nhau, và nhầm lẫn giữa chúng chính là sai lầm gốc rễ. Thực thi là tạo ra thay đổi: đọc codebase, sửa file, chạy test, mở PR. Agent làm việc đó tốt và nhanh. Sở hữu là chịu trách nhiệm về kết quả: rằng thay đổi đó đáng để làm, rằng nó đáp ứng tiêu chí nghiệm thu, và rằng ba tháng nữa vẫn có người để hỏi về nó. Trách nhiệm đó thuộc về con người, bởi không thể yêu cầu một agent giải trình về một đánh đổi sau khi sự việc đã rồi, cũng không thể bắt nó gánh chịu hậu quả.
Cách gọn gàng nhất để diễn đạt sự phân chia này là khế ước giữa con người và agent: agent nghiên cứu, thực thi, kiểm thử và báo cáo; con người định hướng, trao quyền và nghiệm thu kết quả. Tự động hóa dừng lại ở đúng chỗ cần đến phán đoán của đội ngũ. Mọi thứ cho tới bước “nghiệm thu kết quả” đều có thể giao cho agent. Riêng việc nghiệm thu thì không, và quyết định phát hành cũng vậy. Bài viết của chúng tôi về trợ lý AI và đồng đội AI cũng vạch ra ranh giới tương tự từ hướng ngược lại.
Mô hình vận hành: giao việc, chạy, review, nghiệm thu
Khi đã tách quyền sở hữu khỏi việc thực thi, quy trình sẽ chia thành bốn vai trò, mỗi vai trò một nhiệm vụ. Việc gọi tên chúng chính là điều giữ cho năm agent chạy song song không biến thành năm nhánh mồ côi.
| Bước | Ai hành động | Họ sở hữu điều gì |
|---|---|---|
| Giao việc | Một con người | Quyết định công việc đáng làm, viết tiêu chí nghiệm thu và nêu đích danh người chịu trách nhiệm |
| Chạy | Một Agent, thông qua Runtime trên Computer | Tạo ra thay đổi, chạy test, và báo cáo những gì đã làm cùng những điểm còn chưa chắc chắn |
| Review | Assignee là con người | Đánh giá kết quả dựa trên tiêu chí nghiệm thu và bằng chứng |
| Nghiệm thu | Cũng chính Assignee đó | Quyết định merge và phát hành |
Chi tiết quan trọng nằm ở hàng đầu và hàng cuối: cùng một người sở hữu cả việc giao việc lẫn việc nghiệm thu. Đó là cách vòng lặp khép lại. Ai là người quyết định công việc đáng làm thì cũng chính là người xác nhận nó đã hoàn thành. Sharkly hỗ trợ điều này bằng cách giữ đồng thời hai ô giao việc trên một Task — một Assignee là con người và một assignee là Agent — nhờ đó trách nhiệm và việc thực thi được ghi nhận thành hai sự kiện riêng biệt thay vì gộp vào một trường “assigned to” mơ hồ. Về cách công việc đến được với agent, xem hướng dẫn của chúng tôi về giao, theo dõi và review công việc của agent tại một nơi.
Trạng thái và các cổng: agent chỉ tới được Ready for review, con người mới đưa công việc tới Done
Mô hình vận hành chỉ trở nên thực tế khi được ánh xạ lên các trạng thái của Task, bởi mỗi lần đổi trạng thái là một quyết định mà sau này bạn có thể chỉ ra được. Ở đây quy tắc rất nghiêm ngặt và đáng nói thẳng: agent chỉ có thể đẩy công việc tới Ready for review; chỉ con người mới chuyển một Task sang Done.
| Nhóm trạng thái | Ai chuyển | Ý nghĩa |
|---|---|---|
| Backlog | Con người | Chưa bắt đầu. Gán một Agent ở đây sẽ không chạy gì cả |
| Ready for work | Con người | Chuyển một Task vào nhóm này chính là thứ khởi động lượt chạy của Agent |
| In progress | Agent | Lượt chạy đang thực thi trong một worktree tách biệt |
| Ready for review | Agent | Lượt chạy đã xong và đang chờ người được nêu đích danh |
| Done / Accepted | Con người | Một người đã đọc bằng chứng và nghiệm thu kết quả |
Có hai ranh giới bảo vệ điều này. Thứ nhất, một Agent không thể chọn trạng thái mà Task Workflow của nó không cấp quyền, nên nó không thể tự đánh dấu công việc của mình là đã nghiệm thu. Nó để Task lại trong trạng thái chờ con người review, và tín hiệu đó rơi vào Inbox của người chịu trách nhiệm chứ không phải một kênh chẳng ai đọc. Thứ hai, việc merge một pull request được liên kết không làm thay đổi trạng thái của Task. Merge là một sự kiện Git, không phải một quyết định nghiệm thu, và Sharkly tách riêng hai thứ đó để “PR đã merge” không bao giờ bị nhầm với “một người đã đánh giá điều này là đúng”. Nếu bạn lo về năng lực review, bài phân tích của chúng tôi về vì sao review của con người mới là điểm nghẽn thật sự sẽ nói về cách thiết kế cho phù hợp.
Từ ticket đến PR đã merge: một ví dụ xuyên suốt
Đây là mô hình chạy trọn vẹn từ đầu đến cuối trên một Task duy nhất, SH-312, “Thêm rate limiting cho endpoint tìm kiếm công khai”.
- Giao việc. Một kỹ sư viết Task: endpoint, giới hạn mục tiêu và tiêu chí nghiệm thu (trả về 429 khi vượt ngưỡng, các test hiện có vẫn pass, có thêm một test mới cho giới hạn này). Cô ấy đặt mình làm Assignee là con người và chọn assignee là Agent. Task nằm ở Backlog. Chưa có gì chạy cả.
- Chạy. Cô ấy chuyển
SH-312sang trạng thái Ready for work. Chính lần đổi trạng thái đó khởi động lượt chạy. Agent nhận Task, chuẩn bị một worktree mới để công việc này không đụng độ với bất cứ thứ gì khác, đọc phần mô tả và các bình luận gần đây, sửa endpoint, thêm test và chạy toàn bộ bộ test. - Báo cáo. Agent mở một pull request và đăng bình luận trên Task: tóm tắt thay đổi, các test đã chạy cùng kết quả, và một ghi chú trung thực rằng nó chưa load-test giới hạn này dưới lưu lượng thật. Nó chuyển
SH-312sang Ready for review. Nó dừng ở đó. Nó không thể đi xa hơn. - Review. Tín hiệu chờ review đến Inbox của người kỹ sư. Cô đọc theo thứ tự: tiêu chí nghiệm thu, bình luận của Agent, log thực thi, rồi đến diff. Log cho thấy vì sao lượt chạy được xếp hàng và nó đã gọi những tool nào, nên cô đang review chính thay đổi chứ không phải một câu chuyện kể về nó. Khoảng trống về load-test là có thật, nên cô bình luận yêu cầu bổ sung một test ở đúng ngưỡng đã ghi trong tài liệu. Bình luận đó đưa một lượt chạy tiếp theo vào hàng đợi cho chính Agent đó; cô không mở Task thứ hai.
- Nghiệm thu. Agent thêm test, báo cáo lần nữa và đưa Task trở lại Ready for review. Lần này bằng chứng khớp với tiêu chí. Cô merge PR và chuyển
SH-312sang Done — hai hành động có chủ đích của chính người đã sở hữu công việc này ngay từ đầu.
Mọi bước đều quay về Task: lượt chạy, liên kết PR, các bình luận review, việc nghiệm thu. Không có gì chỉ tồn tại trong terminal. Hướng dẫn của chúng tôi về review code do AI tạo ra với bằng chứng ở cấp độ task đi sâu hơn vào những gì cần đọc trước khi bạn nghiệm thu.
Những chỗ quyền sở hữu âm thầm đổ vỡ
Bạn không cần nghi thức đầy đủ này cho mọi Task, và giả vờ rằng cần thì chỉ biến việc review thành một màn trình diễn. Hãy dùng phiên bản nhẹ khi công việc chỉ đọc hoặc có thể đảo ngược dễ dàng: một đợt rà soát repository hay một lần nâng cấp dependency với test xanh đều có thể đi thẳng từ lượt chạy tới nghiệm thu nhanh. Còn hãy dùng vòng lặp đủ bốn vai trò, với một người được nêu đích danh ở cả hai đầu, mỗi khi thay đổi động đến dữ liệu, làm thay đổi giao diện công khai, hoặc không thể hoàn tác bằng một câu lệnh.
Kiểu thất bại cần đề phòng không phải là agent làm quá nhiều. Mà là quyền sở hữu bị bỏ trống. Một Task có assignee là Agent mà không có Assignee là con người thì có thực thi mà không có trách nhiệm giải trình: đúng kiểu vấn đề nhánh mồ côi được khoác áo tiến độ. Cách khắc phục là một quy tắc áp dụng ở mọi nơi: mọi Task của Agent đều phải nêu đích danh một người sở hữu nó. Khi bạn điều phối việc bàn giao giữa nhiều agent, hướng dẫn của chúng tôi về các mẫu bàn giao agent-với-agent và agent-với-con-người sẽ cho thấy người sở hữu nằm ở đâu trong chuỗi.
Kết luận
Con người sở hữu công việc của agent không phải là một cái phanh hãm tự động hóa. Đó chính là điều khiến việc tự động hóa có thể mở rộng một cách an toàn. Hãy để agent làm phần thực thi, tất cả phần đó, với tốc độ nhanh nhất mà chúng có thể. Hãy giữ lại bốn quyết định thuộc về con người: giao việc gì, có trao quyền chạy hay không, kết quả có đạt chuẩn hay không, và có phát hành nó hay không. Hãy ghi lại những quyết định đó dưới dạng các lần đổi trạng thái trên một Task chung, để trách nhiệm giải trình là một sự thật ai cũng đọc được, chứ không phải một phỏng đoán nằm trong lịch sử cuộn của một người nào đó.
Nếu bạn đang chạy nhiều coding agent cùng lúc, Sharkly cho bạn một nơi để giao việc cho chúng, theo dõi chúng chạy và ghi lại ai đã review và nghiệm thu từng kết quả. Bạn có thể tự ghép mô hình này bằng tay với worktree và bảng tính, hoặc tải Sharkly để Task đảm nhiệm việc đó. Để hiểu trọn vẹn hình hài của tầng này, hãy bắt đầu với quản lý coding agent ở tầng trên Claude Code và Codex.
Câu hỏi thường gặp
Con người sở hữu có nghĩa là một người phải ngồi nhìn mọi lượt agent chạy không? Không. Sở hữu là chịu trách nhiệm, không phải giám sát. Một người giao việc và nghiệm thu kết quả; ở khoảng giữa, agent chạy mà không cần ai trông. Dù sao thì việc ngồi nhìn terminal cũng không thể mở rộng quá một agent.
Agent có thể tự đánh dấu công việc của mình là hoàn thành không? Không. Một Agent có thể đưa Task tới Ready for review, nhưng Task Workflow của nó không cấp cho nó trạng thái đã nghiệm thu. Một người sẽ đọc bằng chứng và chuyển Task sang Done.
Merge pull request có phải là nghiệm thu task không? Không. Merge một PR được liên kết chỉ là một sự kiện Git và không làm thay đổi trạng thái Task trong Sharkly. Nghiệm thu là một lần đổi trạng thái riêng do người sở hữu thực hiện sau khi review.
Ai nên sở hữu task của một agent? Người đã quyết định rằng công việc đó đáng làm. Sharkly giữ một ô Assignee là con người song song với assignee là Agent, nhờ đó tín hiệu review được định tuyến đến đúng người đó và chính họ nghiệm thu.
Điều gì xảy ra nếu không có con người nào được gán? Bạn sẽ có thực thi mà không có trách nhiệm giải trình. Quy tắc an toàn là mọi Task của Agent đều phải nêu đích danh một người sở hữu, để một lượt chạy đã xong luôn có người chịu trách nhiệm về nó.
