Cách mở rộng coding agent AI ra cả một đội phát triển

Một lập trình viên với một coding agent là một câu chuyện năng suất. Dễ kể, demo rất đẹp, và hoàn toàn có thật.

Năm lập trình viên với hai mươi agent lại là chuyện khác hẳn. Đó là một bài toán phối hợp, mà bài toán phối hợp thì không được giải bằng chính công cụ đã tạo ra nó. Đây là phần chẳng ai viết, vì nó chỉ lộ ra sau giai đoạn hào hứng: lợi ích cá nhân là có thật, đến ngay lập tức, rồi đâu đó quanh người thứ ba hoặc thứ tư, cả đội bắt đầu tiêu tốc độ mới có được vào việc dọn dẹp sau chính mình.

Dưới đây là thứ tự đổ vỡ. Không phải một danh sách best practice trừu tượng, mà là trình tự mọi thứ thực sự hỏng, vì sửa sai thứ tự thì mất trắng cả một quý.

Thứ vỡ đầu tiên: context dùng chung

Mỗi lập trình viên chạy agent đều đang lặng lẽ dạy nó phiên bản codebase của riêng mình.

Người này bảo agent rằng dự án dùng server action chứ không bao giờ dùng API route. Người kia chẳng nhắc gì, nên agent của họ viết API route. Người thứ ba có nhắc, đúng một lần, trong một phiên đã kết thúc từ ba hôm trước. Chẳng ai sai, chẳng ai nói dối, và giờ repo chứa ba cách hiểu khác nhau về cùng một quy ước. Bạn sẽ nhận ra điều đó ở hàng đợi review, đúng chỗ không nên nhận ra: đến lúc ấy thì code đã tồn tại rồi.

Cách sửa thì nhàm chán, và nó là thứ có đòn bẩy lớn nhất trên trang này. Đưa quy ước vào một file, rồi commit file đó.

CLAUDE.md cho Claude Code, AGENTS.md cho Codex và hầu hết các agent CLI khác, và trên thực tế nhiều đội giữ một file context di động duy nhất thay vì duy trì hai file rồi để chúng trôi dạt khỏi nhau. Cơ chế quan trọng hơn cái tên file: chỉ dẫn nằm trong repo, nên nó đến cùng một lệnh git pull thay vì đến qua bất kỳ ai tình cờ có mặt trong phòng.

Những gì nên nằm trong đó:

• Các quy ước mà agent không thể suy ra từ việc đọc code, nhất là những quy ước mà chính codebase đang vi phạm ở vài chỗ
• Các lệnh: chạy test, build, linter thế nào, và lệnh nào được phép chạy tự động
• Những phần của repo nguy hiểm khi đụng vào, và vì sao
• Những gì đội không muốn: cuộc refactor không ai yêu cầu, thư viện không được phép thêm vào, pattern đang được rời bỏ

Những gì không nên nằm trong đó, và đây là chỗ các đội bị bỏng: bất cứ thứ gì gắn với một máy cụ thể. Đường dẫn tuyệt đối, token API cá nhân, cổng local, editor ưa thích của ai đó. Ngay khi một giá trị gắn với máy lọt vào file context đã commit, mọi lập trình viên khác thừa hưởng một thiết lập sai với họ, mà agent thì cực kỳ giỏi trong việc tuân thủ trung thành những chỉ dẫn đã không còn đúng.

Một phép thử hữu ích trước khi thêm một dòng: nếu đồng nghiệp pull về, dòng này giúp họ hay làm hỏng việc của họ?

Thứ vỡ thứ hai: hai agent, một file

Agent không thương lượng. Chúng không kiểm tra xem có ai đang sửa dở hay không. Hai agent cùng nhắm vào một module sẽ ghi đè lên nhau, và chẳng con nào nói gì, vì đứng từ góc nhìn của mỗi con, công việc đã hoàn tất tốt đẹp.

Làm một mình thì không thấy. Bạn chạy từng agent một, hoặc chạy vài con và tình cờ chúng đụng vào những chỗ khác nhau. Ở quy mô đội, chuyện này thành cấu trúc, và nó sinh ra loại bug tệ nhất: công việc biến mất trong im lặng giữa hai lần chạy test đều xanh.

Hai cơ chế giải quyết chuyện này, và bạn cần cả hai.

Cô lập. Git worktree cho mỗi tác vụ một bản checkout riêng của repo, nên các agent song song không thể va vào nhau về mặt vật lý. Đây là nửa rẻ tiền của giải pháp và không có lý do gì để không làm.

Quyền sở hữu. Cô lập chặn được việc ghi đè, nhưng nó không chặn được hai người giải cùng một bài toán hai lần, trên hai nhánh, theo hai cách không tương thích. Chuyện đó được giải ở lúc giao việc, bằng cách khoanh mỗi tác vụ vào một tập file và nói rõ điều đó ngay trong chính tác vụ. Không phải "cải thiện luồng thanh toán" mà là "sửa bước thanh toán, trong ba file này, đừng đụng vào giỏ hàng".

Nửa thứ hai là nửa các đội hay bỏ qua, và nó quyết định việc merge là một thủ tục hình thức hay là cả một buổi chiều.

Thứ vỡ thứ ba: review

Mọi chuyện về review ở quy mô đội đều bắt nguồn từ một con số: mỗi giờ có bao nhiêu diff đổ về.

Một lập trình viên đọc từng dòng thì ổn. Năm lập trình viên, mỗi người chạy bốn agent, tạo ra nhiều diff mỗi ngày hơn mức cả đội đọc nổi, và kết cục trung thực không phải là review kỹ, mà là diễn kịch phê duyệt. Một con người lướt qua diff chín trăm dòng lúc sáu giờ chiều thì tạo ra một chữ ký chứ không tạo ra hiểu biết, và như thế còn tệ hơn không review, vì nó chế tạo ra sự yên tâm ở nơi chẳng có gì để yên tâm.

Chính sách trụ được không phải "review tất cả", cũng không phải "cứ tin agent". Nó là dời việc review về hai đầu ranh giới của công việc: đọc kế hoạch trước khi agent bắt đầu, vì một kế hoạch sai được thực thi hoàn hảo là kiểu thất bại đắt nhất có thể có, rồi đọc diff tương ứng với mức độ thay đổi đó có thể làm hỏng thứ gì. Nội dung marketing và CSS thì lướt qua. Xác thực, thanh toán, phân quyền, dữ liệu cá nhân và migration thì con người đọc từng dòng, lần nào cũng vậy, bất kể diff trông sạch đến đâu.

Chuyện này xứng đáng có một bài riêng, và chúng tôi đã viết tách ra: bạn có nên vẫn xem lại mã của AI agent không đi qua mười dấu hiệu khách quan cho thấy một thay đổi đã đi chệch, cùng bảng bán kính vụ nổ mà các đội có thể áp dụng nguyên trạng.

Một bổ sung dành riêng cho đội. Khi nhiều agent dùng chung một repo, review cần thông tin quy trách nhiệm: agent nào, tác vụ nào, lập trình viên nào. Thiếu nó, một diff không có tác giả và review biến thành khảo cổ học. Đây là thứ đáng sửa nhất trong thiết lập của bạn một khi vượt quá ba hoặc bốn agent chạy đồng thời.

Thứ vỡ thứ tư: chi phí, và cuộc trò chuyện về chi phí

Tiền token thôi không còn là chuyện riêng của mỗi người ngay khi nó xuất hiện trên hóa đơn của cả đội.

Cái bẫy là hóa đơn ra theo tháng và ở dạng tổng gộp, nên cuộc trò chuyện nó tạo ra cũng theo tháng và tổng gộp, nghĩa là nó đẻ ra một chính sách thay vì một cách sửa. Người này đề xuất dùng mô hình rẻ hơn cho tất cả. Người kia đề xuất giới hạn số phiên. Cả hai đều là phỏng đoán.

Phân bố thực tế gần như không bao giờ đều. Đó là một số ít phiên chạy dài, trên một hai dự án, với context phình ra suốt cả ngày mà chẳng bao giờ được reset. Đó là một hành vi có thể sửa được, và bạn chỉ sửa được nếu nhìn thấy chi tiêu theo từng phiên và từng dự án thay vì theo tháng. Chúng tôi đã nói về cơ chế của việc này trong cách kiểm tra mức sử dụng token và cách cắt giảm mà không chậm lại.

Hãy để con số đó hiện ra trước mắt chính những người tạo ra nó, trước khi nó thành chủ đề của ban quản lý. Một lập trình viên nhìn thấy một phiên tốn hơn cả ngày làm việc hôm trước của mình sẽ tự thay đổi thói quen, và điều đó chẳng tốn của đội đồng nào về mặt chính trị.

Điều thực sự thay đổi trong các nghi thức của đội

Ba điều, theo kinh nghiệm của chúng tôi và theo những gì các đội phản hồi.

Standup chuyển từ báo cáo trạng thái sang gỡ vướng. Hôm qua mỗi người làm gì thì phần lớn đã thấy trong các nhánh. Thứ đáng dành năm phút là agent nào đang kẹt, và kẹt ở đâu.

Prompt trở thành tài sản chung. Câu chỉ dẫn cho ra kết quả tốt với một lập trình viên có giá trị với cả đội hơn cả đoạn code nó tạo ra, mà nó đúng là loại thứ bốc hơi trong lịch sử terminal riêng tư. Những đội giữ một thư viện prompt dùng chung trong repo sẽ thôi phải khám phá lại cùng một cách diễn đạt mỗi tuần.

Chuyên môn hóa dịch từ con người sang vai trò. Một khi agent lo phần viết, câu hỏi thú vị là ai review cái gì, và các đội tự nhiên trôi về phía gán vai trò cho agent giống hệt cách họ gán cho người: một con lo triển khai, một con lo review, một con lo test. Đó là ý tưởng đằng sau Agent Teams, nơi một tác vụ được chuyển từ vai Dev sang vai QA kèm theo diff, các rủi ro và gợi ý test, còn cổng chất lượng thì do bộ test của bạn quyết định chứ không phải do agent tự đánh giá công việc của chính nó.

Thiết lập trụ được

Cô đọng lại, theo thứ tự quan trọng:

Bốn dòng đầu chẳng tốn gì ngoài sự đồng thuận. Hai dòng cuối là lý do một đội rồi cũng muốn có thứ gì đó nằm trên terminal: không phải vì terminal dở, mà vì terminal chỉ hiện một agent tại một thời điểm và không cho bạn cách nào trả lời câu hỏi "ai đang chạy cái gì, trên dự án nào, ngay lúc này".

Đó chính là bài toán mà AgentsRoom cho đội nhóm được xây quanh: mọi agent trên mọi dự án trong một màn hình duy nhất, kèm vai trò, trạng thái và chi phí của nó, cùng một ứng dụng đồng hành trên di động cho những lúc cả đội không ngồi ở bàn. Nó hoạt động y hệt với Claude Code và với Codex, điều này quan trọng hơn vẻ ngoài của nó: phần lớn các đội rốt cuộc đều chạy cả hai, và một thiết lập mặc định chỉ một provider sẽ lặng lẽ trở thành thứ hỏng tiếp theo.

Nhưng hãy bắt đầu từ file context. Nó miễn phí, mất một buổi chiều, và gỡ được nhiều ma sát hơn bất kỳ công cụ nào bạn có thể cài trong quý này.

Câu hỏi thường gặp

Làm thế nào để dùng coding agent trên cả một đội kỹ thuật?

Bắt đầu từ context, không phải từ công cụ. Commit một file chỉ dẫn dùng chung (CLAUDE.md hoặc AGENTS.md) vào repo để mọi agent trên mọi máy đều đọc cùng một bộ quy ước. Sau đó xác định mỗi tác vụ sở hữu những file nào, để không bao giờ có hai agent sửa cùng một module cùng lúc. Việc chọn công cụ ít quan trọng hơn hai quyết định này rất nhiều.

Có nên commit CLAUDE.md hoặc AGENTS.md vào repo không?

Có. Toàn bộ mục đích là để một đồng nghiệp mới, hay một agent mới, thừa hưởng quy ước của đội mà không phải hỏi ai. Hãy giữ các giá trị gắn với máy ra ngoài: đường dẫn tuyệt đối, token cá nhân, cổng local và sở thích riêng của từng người thuộc về một file local không được theo dõi, không phải file dùng chung.

Làm thế nào để ngăn hai agent sửa cùng những file giống nhau?

Cho mỗi tác vụ một cây làm việc riêng bằng git worktree, và khoanh mỗi tác vụ vào một tập file ngay lúc giao việc. Các agent không thương lượng với nhau, nên nếu hai con cùng chạm tới được một module, sớm muộn chúng sẽ ghi đè lên công việc của nhau theo cách chẳng con nào báo lại.

Việc review code có thay đổi khi cả đội chạy coding agent không?

Khối lượng thay đổi, nên chính sách cũng phải đổi. Đọc từng dòng không sống sót nổi khi đụng vào năm agent chạy song song. Những đội giữ được quyền kiểm soát sẽ review kế hoạch trước khi công việc bắt đầu, rồi review diff tương ứng với mức độ thay đổi đó có thể làm hỏng thứ gì, dồn sự chú ý vào xác thực, thanh toán, phân quyền, dữ liệu cá nhân và migration.

Làm thế nào để theo dõi chi phí coding agent AI trên mỗi lập trình viên?

Theo từng phiên và từng dự án, không phải theo tháng. Một hóa đơn hàng tháng cho bạn biết tổng số và chẳng có gì hành động được. Thứ bạn cần là dự án nào và loại tác vụ nào đốt token, vì câu trả lời thường là một số ít phiên chạy dài với context phình to chứ không phải cả đội.

Điều gì vỡ đầu tiên khi một đội mở rộng quy mô coding agent?

Context dùng chung, trước mọi thứ khác. Mỗi lập trình viên tích lũy quy ước riêng trong đầu mình và trong prompt của mình, nên cùng một repo lại nhận ba cách hiểu xung khắc về việc mọi thứ được làm ra sao. Hàng đợi review code là nơi bạn nhận ra điều đó, nhưng nguyên nhân nằm ở phía trên.