Vì sao tôi ngừng coi coding agent là công cụ và bắt đầu chạy nó như một team.
Bài 1 trong 3. Series: dựng một team agent AI để làm phần mềm.
Mấy tuần gần đây tôi làm việc với agent theo một kiểu khác hẳn trước.
Trước đó tôi dùng coding agent như đa số mọi người. Mở session, mô tả việc, nhận code, sửa tới lui cho tới khi chạy. Với một tiện ích nhỏ hay một script, cách này dư sức. Tôi nghĩ ra ý tưởng, gõ vài dòng yêu cầu, agent trả về, tôi đọc qua, gật, xong.
Rồi tôi thử đem đúng cách đó vào một dự án lớn hơn. Và nó gãy.
Không phải gãy kiểu agent viết code dở. Code phần lớn vẫn chạy. Nó gãy ở chỗ tôi mất kiểm soát. Quá nhiều thứ động cùng lúc, task ở các giai đoạn khác nhau, và tôi không còn cách nào biết cái agent vừa báo "xong" có thật sự xong hay không.
Đó là lúc tôi đổi cách nghĩ. Tôi ngừng coi session chính là nơi để viết code. Tôi coi nó là một orchestrator.
Session chính không tự tay làm nữa. Nó điều phối một team agent nhỏ, mỗi agent một vai. Nó nhận một việc thô từ tôi, tách thành task, giao cho đúng agent, theo dõi tiến độ, ép cả team đi đúng quy trình, và chỉ commit code sau khi có một bước nghiệm thu cuối.
Tôi nói rõ chỗ này vì nó dễ bị hiểu lầm thành một mẹo prompt. Thực ra nó là một cách tổ chức công việc, ở tầm đó.
Con AI vẫn y như cũ. Cùng một model, cùng một công cụ. Thứ tôi đổi là cách sắp xếp công việc quanh nó. Và đúng cái đó lại mở ra những dự án tôi không build nổi bằng cách cũ.
Lý do nằm ở một câu hỏi đơn giản: ai kiểm tra công việc?
Khi một session vừa viết code vừa tự phán code đúng, không có ai kiểm tra cả. Agent nói xong thì tôi chỉ có hai lựa chọn, tin nó hoặc tự mình đi soi từng dòng. Dự án nhỏ thì tôi soi được. Dự án lớn thì không. Và khi tôi không soi nổi, "xong" trở thành một từ vô nghĩa.
Tách vai ra giải đúng chỗ đó. Mỗi bước có một người gác cổng riêng. Người viết code không phải người quyết code đúng.
Tôi muốn nói kỹ hơn về chỗ gãy, vì hiểu nó thì mới thấy vì sao phải chia vai.
Với việc nhỏ, một agent ôm hết là hợp lý. Ít task, ít trạng thái, tôi giữ được cả bức tranh trong đầu. Tôi biết cái gì xong, cái gì chưa, chỗ nào đang sai. Agent có nhảy bước thì tôi cũng thấy ngay.
Dự án phức tạp phá vỡ điều đó theo hai hướng.
Hướng thứ nhất là khối lượng. Cái này đang code, cái kia chờ test, cái nọ chưa rõ yêu cầu, cái khác vừa rớt test phải làm lại. Một session đơn không giữ nổi từng đó trạng thái mạch lạc. Nó quên mất task nào đang ở đâu, hoặc làm xong một việc rồi tưởng cả nhóm việc đã xong.
Hướng thứ hai mới là hướng đau, và là lý do thật khiến tôi phải đổi cách: kiểm chứng.
Khi agent báo "xong rồi", tôi lấy gì để tin? Không có bước nào kiểm tra cái nó vừa làm có đúng kế hoạch không. Không có ai chạy lại để xác nhận từng tiêu chí. Tệ hơn, cùng một agent vừa viết code vừa tự quyết là code đúng. Đó là xung đột lợi ích trần trụi. Người làm bài tự chấm bài mình thì điểm nào cũng đẹp.
Tôi gặp đúng cảnh này nhiều lần. Agent tuyên bố hoàn thành một tính năng, tôi tin, hai ngày sau mở ra mới thấy nó làm lệch yêu cầu từ đầu. Không phải nó cố tình. Nó chỉ thiếu một người thứ hai soi lại.
Vậy nên tôi quyết định dựng một team. Mỗi agent một vai riêng, biên giới rõ ràng. Và session chính đứng làm orchestrator: tung agent ra, chia việc, ép quy trình, chỉ commit sau bước nghiệm thu cuối.
Trong setup hiện tại, tôi chia việc cho bốn vai.
Product Manager. Nhận một việc thô và biến nó thành thứ làm được. Spec với user story, tiêu chí nghiệm thu, kịch bản test. Đây là vai biến câu nói mơ hồ của tôi thành đề bài rõ ràng cho cả nhóm. Xong phần code và QA, PM còn quay lại một lần nữa, nhìn kết quả dưới góc người dùng và quyết việc đã thật sự xong chưa.
Software Engineer. Viết code, và viết test cho code đó. Vai này không tự quyết mình làm đúng. Nó chỉ làm, và đẩy kết quả qua bước sau.
Tester. Chạy đống test đó, soi từng tiêu chí nghiệm thu, báo đậu hay rớt kèm bằng chứng. Tôi nhấn mạnh chữ bằng chứng. QA không được nói khơi khơi "ổn rồi". Nó phải chỉ ra cái gì chạy, chạy thế nào, kết quả ra sao.
On-Call Engineer. Canh CI/CD sau khi code được đẩy lên, vá khi pipeline đỏ. Đây là vai dễ quên nhất, nhưng thiếu nó thì code "xong" trên máy vẫn có thể làm gãy build chung.
Mỗi vai gánh một khoanh trách nhiệm hẹp. Nghe có vẻ rườm rà, thậm chí chậm. Nhưng chính cái hẹp đó đổi chất lượng đầu ra.
Hai lý do.
Một, khoanh hẹp khiến việc bỏ bước khó hơn nhiều. Một agent ôm hết rất dễ nhảy cóc: viết code xong commit luôn, quên test, quên nghiệm thu, vì nó vội tới đích. Khi mỗi bước có một vai riêng đứng đó chờ, bỏ bước là lộ ra ngay. Task không thể nhảy từ SWE sang commit mà không đi qua QA, vì QA là một mắt xích vật lý trong chuỗi.
Hai, khoanh hẹp khiến truy lỗi dễ hơn. Khi có gì sai, tôi biết hỏi vai nào. Spec mơ hồ thì đó là PM. Test không bắt được lỗi thì đó là QA. Tôi không phải mò trong một mớ "agent đã làm gì đó suốt hai tiếng qua". Mỗi vai để lại dấu vết riêng, nên lần ngược về điểm hỏng nhanh hơn hẳn.
Nhưng cái lợi tôi quý nhất nằm ở chỗ này: vai viết code và vai chấm code là hai vai tách rời. Người làm tách hẳn khỏi người chấm. Nhờ vậy chữ "xong" mới lấy lại được nghĩa của nó, thay vì chỉ là lời agent tự khen mình.
Đây cũng là chỗ tôi nghĩ nhiều người làm với agent đang bỏ lỡ. Họ dồn sức tìm con model mạnh hơn, prompt khéo hơn. Nhưng chỗ kẹt của tôi luôn nằm chỗ khác: không có ai kiểm chứng. Mà kiểm chứng là chuyện tổ chức, giải bằng cách sắp xếp công việc quanh con agent.
Tôi để ý một điểm nữa, quan trọng với cách tôi làm việc: cấu trúc bốn vai này không dính vào một dự án cụ thể.
Khi đã định nghĩa xong từng vai, tôi bê nguyên bộ đó sang dự án mới. Đề bài đổi, ngôn ngữ đổi, ràng buộc kỹ thuật đổi, nhưng bốn vai và ranh giới giữa chúng thì giữ nguyên. Tôi không phải nghĩ lại từ đầu mỗi lần. Đó là kiểu đầu tư tôi thích: bỏ công một lần, dùng lại nhiều lần.
Bốn vai mới là một nửa câu chuyện. Nửa còn lại là cách một task chạy qua tay từng vai theo đúng thứ tự, cách chạy nhiều task song song mà không phải ngồi canh, và cách theo dõi tất cả. Đó là nội dung bài 2.
Nếu bạn chỉ mang đúng một ý từ bài này, mang ý này: sức mạnh đến từ cách bạn tổ chức quanh con agent, để mỗi việc đều có người kiểm chứng.
1 đến 2 email mỗi tháng. Hủy đăng ký dễ.
1 đến 2 email mỗi tháng. Hủy đăng ký dễ.
Bình luận