"Nhà máy phần mềm tức thời": Khi AI tự vận hành vòng đời phát triển dự án

Minh họa các agent tự động vận hành trong nhà máy phần mềm

Instant Software Factory là một dự án mã nguồn mở trên GitHub, cho phép biến kho mã của bạn thành một "nhà máy" phát triển phần mềm tự động. Thay vì mỗi lần lại mở phiên trò chuyện với AI rồi chờ đợi, bạn thiết lập các agent chạy theo lịch trình với mục tiêu thường trực, tự tìm việc cần làm và ghi kết quả trở lại kho mã.

Điểm đáng chú ý: con người vẫn là người phê duyệt cuối cùng mọi thay đổi trước khi hợp nhất, nhưng phần lớn công việc lặp lại — sửa lỗi, viết kiểm thử, tối ưu hiệu năng — diễn ra trong nền.

Vấn đề: nguyên mẫu không phải là sản phẩm

Lập trình theo kiểu "vibe coding" rất giỏi tạo ra thứ gì đó tồn tại. Giao cho agent một mục tiêu rõ ràng, chỉ một buổi chiều là bạn có nguyên mẫu chạy được.

Nhưng nguyên mẫu không phải sản phẩm. 90% đầu của mã nguồn chiếm 90% thời gian, và 10% cuối chiếm 90% thời gian còn lại. Từ "chạy được trên máy tôi" đến chất lượng production là một chuỗi dài công việc: các trường hợp biên, báo lỗi, suy giảm hiệu năng, tương thích, kiểm thử, CI, phát hành, và dọn dẹp những lối tắt mà nguyên mẫu đã đi.

Công việc đó không có một vạch đích duy nhất. Nó là hàng trăm tác vụ nhỏ rải rác nhiều mối quan tâm, và mối mới lại xuất hiện mỗi khi mã thay đổi. Bạn có thể nhắc agent từng tác vụ, nhưng khi đó sự chú ý của bạn trở thành nút thắt cổ chai.

Cách nhà máy phần mềm vận hành

Mỗi agent là một phiên chạy theo lịch trình với mục tiêu thường trực. Mỗi lần chạy, nó đọc trạng thái hiện tại của kho mã, chọn việc hữu ích, làm, ghi lại kết quả rồi thoát. GitHub giữ trạng thái chia sẻ: issue mang bằng chứng và đề xuất, PR mang triển khai và đánh giá, discussion lưu tiến độ và quyết định.

Bản bootstrap tạo ra tám vai trò chính:

• QA: kiểm thử các khu vực sản phẩm và luồng người dùng, mở issue lỗi có thể tái tạo và đã loại trùng.
• Performance: đo tốc độ, tài nguyên và thời gian CI so với đường cơ sở, mở issue kèm bằng chứng.
• CI: sửa lỗi và flaky test, giữ kiểm tra nhanh, rẻ mà không làm yếu đi.
• Architecture: gộp logic nghiệp vụ trùng lặp, loại bỏ lớp trừu tượng thừa, giảm số thành phần.
• Implementation: sửa issue và mở PR đã kiểm thử.
• PR review: đánh giá độc lập commit mới nhất, không sửa mã.
• Merge: chỉ hợp nhất sau khi kiểm tra bắt buộc, đánh giá độc lập và phê duyệt của con người.
• Manager: ưu tiên và phân công việc, theo đuổi PR cũ và issue bị chặn, theo dõi chi phí mỗi PR đã hợp nhất.

Ba nhóm công việc được bao phủ: khảo sát cơ hội, triển khai và tích hợp thay đổi, và duy trì chính nhà máy. Manager giữ nhịp và phân bổ nguồn lực; mỗi agent tự chọn cách theo đuổi mục tiêu trong khuôn khổ chung.

Vì sao không dùng một agent thật giỏi?

Một agent giỏi có thể lập kế hoạch, chia nhỏ tác vụ và hoàn thành một mục tiêu rõ ràng. Nhưng dự án phần mềm có nhiều mục tiêu cùng lúc: tính năng mới có thể ăn hết ngân sách hiệu năng; bản vá lỗi có thể thêm kiểm thử làm CI chậm đi; một lần dọn dẹp có thể đơn giản hóa hệ thống con này nhưng làm rối hệ thống con khác.

Mục tiêu thường trực buộc agent quay lại những đánh đổi đó. Performance liên tục đo khi tính năng được thêm vào. Architecture liên tục giảm trùng lặp. CI giữ vòng phản hồi đủ nhanh cho mọi người. Các mục tiêu củng cố lẫn nhau: mã đơn giản hơn giúp sửa và đánh giá dễ hơn; CI nhanh hơn giúp mọi agent kiểm tra kết quả sớm hơn.

Bạn vẫn có thể làm việc tương tác song song: khởi tạo một phiên cục bộ trên nhánh riêng cho tính năng lớn, trong khi nhà máy tiếp tục xử lý lỗi, hiệu năng, kiến trúc và CI.

Hạn chế cần lưu ý

Nút thắt chính trong cấu hình này là năng lực CI và độ ổn định của GitHub. Chạy agent thường xuyên hơn chỉ có ích khi khâu kiểm định và hợp nhất đủ sức hấp thụ kết quả đầu ra; nếu không, bạn chỉ tạo ra hàng đợi issue và PR ngày càng dài.

• Các nhà điều tra có thể vượt mặt người triển khai; người triển khai vượt mặt người đánh giá.
• Nhiều bản vá có thể xung đột trên cùng một đoạn mã.
• Chi phí tính bằng lượt dùng agent và số phút GitHub Actions, nên cần đo chi phí trên mỗi PR đã hợp nhất thay vì chỉ đếm số lượng PR.

Số lượng PR cao không tự nó cho biết dự án có đang tiến bộ hay không.

Kiểm soát an toàn và vận hành

Vì nhà máy có quyền thay đổi phần mềm, quy tắc truy cập và dừng phải thật rõ ràng:

• Dùng danh tính riêng và công cụ giới hạn. Xác minh danh tính GitHub gắn với routine, thu hẹp quyền, gỡ connector không dùng. Giữ thông tin đăng nhập của người phê duyệt cách xa agent chạy runtime.
• Bảo vệ nhánh mặc định trước khi chạy không giám sát. Yêu cầu kiểm tra bắt buộc, đánh giá độc lập và phê duyệt của con người cho commit mới nhất. Văn bản viết không tự đánh giá được chính nó.
• Kiểm soát đầu vào từ bên ngoài. Hạn chế ai có thể đưa việc vào nhà máy; issue, PR và mã tải về không được phép thay đổi chỉ dẫn hay quyền của agent.
• Kiểm tra công tắc dừng dùng chung trước mỗi lần ghi. Công tắc khởi đầu ở trạng thái dừng; nếu bị dừng hoặc không đọc được, agent ngừng công việc thường lệ.
• Chứng minh kiểm soát trước khi bật lịch trình. Thiết lập phải kiểm tra truy cập, yêu cầu đánh giá và hợp nhất, quản lý lịch trình và khả năng tắt máy trong lần chạy thật.

Liên hệ với các hướng tiếp cận khác

• Gas Town theo đuổi công việc tự động qua nhiều agent lập trình với bộ công cụ điều phối và sổ cái Beads.
• Minions của Stripe chạy tác vụ lập trình không giám sát trong môi trường phát triển biệt lập rồi tạo PR cho con người đánh giá.
• Software Factory của StrongDM dùng ý định đặc tả và kiểm định kịch bản để dẫn dắt triển khai mà không cần con người đánh giá mã — khác biệt căn bản với Instant Software Factory, nơi mỗi thay đổi vẫn phải qua đánh giá độc lập và phê duyệt của người trước khi hợp nhất.

Thử nghiệm

Chạy prompt thiết lập trong dự án bạn muốn cải thiện liên tục, đặt ngân sách và mục tiêu thông lượng, xác định ai có quyền phê duyệt. Bắt đầu từ PR đã kiểm thử và báo cáo thiết lập để bạn kiểm tra cả công việc lẫn cơ chế kiểm soát trước khi lịch trình chạy thật.

Sau đó theo dõi bản tóm tắt của manager: thay đổi hữu ích, việc bị đình trệ, chi phí agent và chi phí mỗi PR đã hợp nhất. Điều chỉnh mục tiêu và nguồn lực khi bạn nhận ra nút thắt nằm ở đâu.