Quy trình phát triển VM0: Quản lý AI agent như một đội nhóm

Trong đội phát triển VM0, mỗi lập trình viên làm việc với nhiều phiên bản Claude Code cùng lúc. Thường là hơn tám.

Chúng tôi đối xử với Claude Code giống như một lập trình viên thực thụ. (Vâng, công ty chúng tôi nửa đùa nửa thật có tên là AI Colleagues Co!)

Vì vậy, triết lý thiết kế đằng sau quy trình phát triển VM0 phản chiếu các thực tiễn quản lý đội nhóm kinh điển trong kỹ thuật phần mềm.

Chúng tôi sử dụng GitHub Issues để theo dõi công việc, Pull Requests để rà soát và hợp nhất mã, cùng GitHub Actions để tự động hóa. Trong hai tháng, thiết lập này đã giúp chúng tôi phát hành 404 phiên bản và viết hơn 230,000 dòng mã.

Bài viết này giải thích cách chúng tôi biến điều đó thành khả thi, và tại sao vấn đề then chốt chưa bao giờ là năng lực AI, mà là sự phối hợp của con người.

Quy trình phát triển ứng dụng AI trong thực tế

Khi bạn phối hợp nhiều AI agent song song, điểm nghẽn không phải là mô hình có thể viết mã hay không. Điểm nghẽn thực sự là tải nhận thức của con người

Quy trình này gồm 14 lệnh slash, tổ chức thành ba lớp: Phân tích sâu, Quản lý Issue và Quản lý PR.

Hãy cùng xem quy trình làm việc của tôi trông như thế nào và một tính năng thường được xây dựng ra sao.

Thống nhất yêu cầu

Một người mở phiên Claude và bắt đầu với /deep-research. Claude thu thập thông tin từ mã nguồn, tài liệu và ngữ cảnh liên quan. Chúng tôi thảo luận kết quả và thống nhất vấn đề cần giải quyết.
Khám phá giải pháp

Sử dụng /deep-innovate, Claude đề xuất nhiều hướng đi khả thi, cùng các đánh đổi. Chúng tôi thảo luận, thu hẹp và chọn một hướng.
Tạo Issue

Chúng tôi tạo một GitHub issue bằng /issue-create. Người dùng rà soát issue để đảm bảo yêu cầu được ghi nhận rõ ràng.
Lập kế hoạch và phê duyệt

Dùng /issue-plan để Claude tiếp tục công việc. Claude sẽ tự động chạy toàn bộ quy trình phân tích sâu và đăng kết quả lên issue, bao gồm:
1. phát hiện từ /deep-research
2. so sánh từ /deep-innovate
3. kế hoạch triển khai cụ thể từ /deep-plan
Triển khai

Sau khi phê duyệt, /issue-action cho phép Claude thực hiện kế hoạch, viết kiểm thử, mở PR và đảm bảo CI thành công.
Rà soát và hợp nhất

Chúng tôi dùng /pr-review để rà soát có cấu trúc, sau đó thực hiện rà soát cuối cùng trước khi hợp nhất.

Người dùng can thiệp tại ba điểm kiểm: yêu cầu, hướng đi và chấp nhận. Mọi thứ khác đều tự động.

Thay đổi tư duy: bạn đang dẫn dắt một đội lập trình viên AI

Khoảnh khắc tôi nhận ra cần một quy trình có cấu trúc là khi thêm nhiều phiên Claude thực tế lại khiến mọi thứ tệ hơn. Càng chạy nhiều phiên song song, tôi càng khó theo dõi từng phiên đang làm gì, trạng thái công việc ra sao và những gì đã được quyết định.

Nếu không có công cụ bên ngoài, tôi không thể quản lý nhiều phiên Claude cùng lúc. Đó là lúc tôi nhận ra: đây không phải vấn đề AI, mà là vấn đề quản lý.

GitHub vốn là công cụ tự nhiên cho hợp tác phát triển phần mềm, nên thay vì sáng tạo thứ mới, tôi bắt đầu đối xử với Claude như một đồng đội thực thụ. Khi làm vậy, khả năng quản lý của tôi bỗng dưng mở rộng.

Mười năm kinh nghiệm quản lý dự án và đội nhóm cuối cùng cũng có ý nghĩa trong bối cảnh mới này. Khi coi Claude là thành viên đội nhóm và GitHub là không gian giao tiếp và quản lý chung của chúng tôi, toàn bộ hệ thống lại trở nên kiểm soát được.

Một trưởng nhóm giỏi biết khi nào nên can thiệp và khi nào nên lùi lại:

Điểm kiểm	Tôi làm gì	AI làm gì
Yêu cầu	Thống nhất vấn đề, làm rõ phạm vi	Nghiên cứu mã nguồn, thu thập ngữ cảnh
Hướng đi	Rà soát phát hiện, duyệt hướng tiếp cận	Đề xuất các hướng 2-3, đánh giá đánh đổi
Chấp nhận	Rà soát PR, kiểm tra chất lượng	Triển khai, kiểm thử, sửa CI

Điều này phản ánh cách các đội phần mềm hiệu quả vận hành. Tôi không vi mô hóa lập trình viên mà đặt ra yêu cầu rõ ràng, rà soát các quyết định then chốt và xác nhận kết quả cuối cùng. Nguyên tắc này cũng áp dụng khi quản lý AI agent.

Quy trình phân tích sâu buộc phải suy nghĩ có cấu trúc, chậm rãi

Quy trình phân tích sâu buộc phải suy nghĩ kỹ lưỡng trước khi triển khai. Đôi khi Claude gặp ngõ cụt. Khi đó, chúng tôi buộc Claude dừng lại suy nghĩ, rồi cùng thảo luận. Quy trình gồm ba giai đoạn:

Giai đoạn	Lệnh	Mục đích	Kết quả
Nghiên cứu	/deep-research	Thu thập thông tin, hiểu ngữ cảnh	research.md
Đổi mới	/deep-innovation	Khám phá nhiều hướng tiếp cận	innovate.md
Lập kế hoạch	/deep-plan	Định nghĩa các bước cụ thể	plan.md

Mỗi giai đoạn đều có ranh giới rõ ràng.

Nghiên cứu: không được đề xuất giải pháp
Đổi mới: không đi vào chi tiết
Lập kế hoạch: không triển khai

Những ràng buộc này buộc Claude phải suy nghĩ chậm rãi, có chủ đích thay vì nhảy ngay vào viết mã. Nếu không, các trường hợp biên và vấn đề kiến trúc thường bị bỏ sót!

Ví dụ sử dụng

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude researches, analyzes 12 related files, finds 3 similar patterns]

/deep-innovate what are our options for fixing this?

[Claude presents 3 approaches with trade-offs, you pick one]

/issue-create let's track this fix

Với các tác vụ đơn giản, bạn có thể bỏ qua phân tích sâu và đi thẳng tới /issue-create.

Với các tác vụ phức tạp, chưa rõ kỹ thuật, các giai đoạn phân tích sâu giúp bạn và Claude thống nhất trước khi bắt đầu triển khai.

Sử dụng GitHub làm bộ nhớ chung

Hầu hết công cụ AI coi ngữ cảnh là tạm thời. Khi phiên kết thúc, bộ nhớ biến mất.

VM0 dùng GitHub làm bộ nhớ lâu dài:

Tính năng GitHub	Lưu trữ gì
Issue body	Yêu cầu và quyết định
Issue comments	Nghiên cứu, lựa chọn, kế hoạch
PR comments	Rà soát và tóm tắt
Labels	Trạng thái quy trình

Điều này cũng giải quyết một vấn đề của con người: khôi phục ngữ cảnh.

Khi tôi quản lý 8+ phiên Claude, tôi nhận thông báo khi công việc hoàn thành. Nhưng tôi không thể tái dựng từ cuộc trò chuyện của Claude là nó đã làm gì, quyết định gì, hay trạng thái hiện tại ra sao.

GitHub issues giải quyết điều này. Mỗi issue hiển thị:

Yêu cầu gốc
Kết quả nghiên cứu (đã phát hiện gì)
Giai đoạn đổi mới (đã cân nhắc lựa chọn nào)
Kế hoạch đã duyệt (sẽ triển khai gì)

Định dạng có cấu trúc này giúp rà soát hiệu quả. Tôi có thể nhanh chóng lướt qua các giai đoạn, hiểu hướng tiếp cận và duyệt hoặc yêu cầu thay đổi mà không cần nhớ lại cuộc trò chuyện gốc.

Khi công việc kết thúc, tôi không cần nhớ chuyện gì đã xảy ra trong cửa sổ chat. Tôi chỉ cần mở issue và xem toàn bộ câu chuyện, có cấu trúc, được ghi lại rõ ràng.

Bàn giao giữa các agent

Vì toàn bộ ngữ cảnh nằm trên GitHub, công việc có thể chuyển giao giữa các agent một cách liền mạch:

Một agent tạo issue hoặc PR
Agent khác tiếp tục sau đó bằng /deep-research issue 123 hoặc /issue-plan 123 hoặc /deep-research PR 124

Với các thảo luận dài, /issue-compact tổng hợp mọi thứ thành nội dung issue gọn gàng. Điều này giúp bàn giao dễ dàng cho cả con người lẫn AI.

Tổng kết các mẫu quy trình

Sau tất cả, tôi xin tóm tắt một số mẹo thực tế.

Tác vụ đơn giản

/issue-create → /issue-plan → /issue-action → /pr-check-and-merge

Dùng khi yêu cầu rõ ràng và công việc đơn giản.

Tác vụ phức tạp

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check

Điều này giúp tránh lãng phí công sức vào hướng đi sai.

Làm việc song song

Nhiều agent có thể làm việc cùng lúc trong khi người dùng rà soát các điểm kiểm đã hoàn thành. Đây là lúc quy trình phát huy hiệu quả nhất.

Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements

Tham khảo lệnh

Lệnh phân tích sâu

Lệnh	Mục đích
`/deep-research`	Thu thập thông tin, hiểu mã nguồn. Không được đề xuất giải pháp.
`/deep-innovate`	Khám phá các hướng 2-3, đánh giá đánh đổi. Không được viết mã.
`/deep-plan`	Tạo các bước triển khai cụ thể. Không được triển khai.

Lệnh Issue

Lệnh	Mục đích
`/issue-create`	Tạo issue từ ngữ cảnh cuộc trò chuyện
`/issue-bug`	Tạo báo cáo lỗi kèm bước tái hiện
`/issue-feature`	Tạo yêu cầu tính năng tập trung vào yêu cầu
`/issue-plan`	Thực hiện toàn bộ quy trình phân tích sâu, đăng kết quả lên issue
`/issue-action`	Tiếp tục triển khai sau khi người dùng phê duyệt
`/issue-compact`	Tổng hợp nội dung issue + bình luận để bàn giao

Lệnh PR

Lệnh	Mục đích
`/pr-check`	Theo dõi pipeline CI, tự động sửa lỗi, thử lại tối đa 3 lần
`/pr-review`	Rà soát PR từng commit theo tiêu chuẩn dự án
`/pr-comment`	Tóm tắt thảo luận vào bình luận PR

Bắt đầu

Bắt đầu đơn giản: Dùng /issue-create → /issue-plan → /issue-action cho tác vụ đầu tiên của bạn
Thêm phân tích sâu cho tác vụ phức tạp: Khi yêu cầu chưa rõ hoặc phức tạp về kỹ thuật, hãy bắt đầu với /deep-research
Mở rộng dần: Thêm nhiều phiên Claude khi bạn đã quen với nhịp rà soát
Tin vào quy trình: Để Claude tự động làm việc giữa các điểm kiểm

Quy trình này được thiết kế để áp dụng từng bước. Bạn không cần dùng hết 14 lệnh ngay từ đầu. Hãy bắt đầu với quy trình issue cơ bản, rồi bổ sung các giai đoạn phân tích sâu và làm việc song song khi bạn tự tin hơn.

Lưu ý khi mở rộng: Làm gì khi có nhiều agent hơn

Quy trình đã được kiểm thử với 10+ phiên Claude đồng thời. Khuyến nghị của chúng tôi:

Tối đa 10 agent: Phù hợp để hợp tác sâu với từng agent
Vượt quá 10: Không khuyến khích

Yếu tố giới hạn không phải quy trình, mà là sự chú ý và chất lượng quyết định của con người. Khi quản lý hơn 10 agent, bạn có nguy cơ trở thành điểm nghẽn ở các điểm rà soát, và chất lượng quyết định sẽ giảm.

Nguyên tắc "đội hai pizza" kinh điển cũng áp dụng ở đây. Những ràng buộc giới hạn quy mô đội nhóm con người cũng giới hạn số AI agent mà một người có thể quản lý hiệu quả.

Hiện tôi đang thử nghiệm cấu trúc đội hai tầng 8×8 để mở rộng vượt 10 agent, nhưng chưa phát triển được thực tiễn hiệu quả. Tôi sẽ chia sẻ thêm khi có kết quả cụ thể…

Quy trình phát triển VM0 thay đổi cách chúng ta nghĩ về phát triển phần mềm khi AI trở thành một phần của đội nhóm.

Khi bạn coi AI agent là thành viên đội nhóm thay vì công cụ, mọi thứ sẽ trở nên hợp lý. GitHub trở thành bộ nhớ chung của đội. Issue là đầu việc. PR là sản phẩm bàn giao. Và bạn trở thành trưởng nhóm, tập trung vào kiến trúc, định hướng và chất lượng, trong khi đội AI đảm nhận triển khai.

Đó là cách chúng tôi phát hành 404 phiên bản trong 2 tháng. Và cũng là cách bạn có thể mở rộng phát triển với AI.