Augment chia sẻ kinh nghiệm xây dựng 'nhà máy phần mềm': Tăng năng suất gấp 4,5 lần nhờ AI

Đến tháng 11 năm 2025, AI đã viết gần 100% mã nguồn mới của Augment. Tuy nhiên, việc tạo ra mã nguồn không đồng nghĩa với việc cung cấp phần mềm đáng tin cậy. Khi tốc độ lập trình tăng lên, điểm nghẽn sẽ chuyển sang các phần khác của SDLC: đánh giá, xác minh, lập kế hoạch, phản hồi sự cố hoặc giải quyết phản hồi.

Một "nhà máy phần mềm" (software factory) giải quyết điểm nghẽn này bằng cách luân chuyển công việc kỹ thuật nhanh hơn giữa các yêu cầu, ticket, pull request và môi trường production (đọc thêm về mô hình software-factory). Các tác nhân (agent) chuyên biệt tự động hóa các công việc mang tính cơ học tại mỗi bước chuyển tiếp, trong khi con người vẫn giữ quyền quyết định đối với các vấn đề quan trọng. Chúng tôi xây dựng hệ thống của mình trên Augment Cosmos, nền tảng để vận hành và điều phối các agent. Chúng tôi bổ sung từng thành phần khi một điểm nghẽn mới xuất hiện.

Từ tháng 11 năm 2025 đến tháng 7 năm 2026, trên toàn bộ đội ngũ kỹ thuật của Augment:

Những thành quả đạt được theo thời gian khi chúng tôi dần mở rộng tự động hóa từ việc tạo mã nguồn sang lập kế hoạch, đánh giá, xác minh, phản hồi và vận hành.

Đến đầu tháng 8, nhà máy phần mềm của chúng tôi đã bao phủ bốn trạng thái kết nối của công việc kỹ thuật: Yêu cầu (Requirements), Ticket, PR và Prod. Các vòng lặp của nhà máy kết nối Linear cho ticket, GitHub cho pull request, Slack cho phản hồi sản phẩm và Slack + PagerDuty cho phản hồi sự cố. Các agent chuyên biệt vận hành tại các điểm chuyển tiếp giữa các trạng thái đó, tự động hóa công việc cơ học cần thiết để thúc đẩy ý tưởng, đồng thời duy trì quyền quyết định của con người đối với các vấn đề quan trọng. Sau khi một PR được hợp nhất (merge), quy trình triển khai xác định (deterministic deployment pipeline) hiện có của chúng tôi sẽ đưa thay đổi đó lên production. Chúng tôi không tự động hóa các bước chuyển tiếp này theo thứ tự vòng đời; chúng tôi bắt đầu ở bất cứ nơi nào công việc bị tồn đọng. Vòng lặp vận hành của chúng tôi rất đơn giản: tìm điểm nghẽn, tự động hóa nó và lặp lại.

Trước khi giới thiệu các quy trình làm việc của agent này, các kỹ sư của chúng tôi đã sử dụng các agent lập trình AI tương tác trong IDE và CLI, cùng với một công cụ đánh giá mã nguồn AI cũ. Thay đổi lớn nhất là chuyển từ các công cụ vận hành riêng lẻ sang các quy trình làm việc của agent bền bỉ, áp dụng cho toàn đội, giúp quản lý công việc trên các hệ thống và chỉ cần sự tham gia của con người tại các điểm cần đưa ra phán quyết cụ thể.

Vòng lặp từ PR đến production làm cho sự khác biệt trở nên cụ thể. Trước đây, một PR thông thường đòi hỏi khoảng 10–15 lần con người phải can thiệp: người đánh giá yêu cầu agent giải thích PR, tác giả nhắc agent sửa lỗi CI, nhắc agent sửa các bình luận đánh giá, cấu hình môi trường thử nghiệm, tự tay kiểm tra tính năng, xem xét các cập nhật nhiều lần, v.v. Đến đầu tháng 8, quy trình đánh giá tự động đã giảm con số đó xuống còn ba lần can thiệp chính: xem xét báo cáo thiết kế và kiến trúc của Pair Reviewer, kiểm tra bằng chứng runtime của Verifier và đưa ra quyết định hợp nhất cuối cùng. Nó cũng thay thế các quy trình làm việc tùy chỉnh của nhà phát triển bằng một quy trình đánh giá tiêu chuẩn hóa.

Điều này giúp giảm bớt sự can thiệp trực tiếp của con người trên mỗi PR. Trong cùng khoảng thời gian đó, thời gian trung bình để hợp nhất giảm từ 11,2 xuống 3,1 giờ, trong khi tỷ lệ hoàn tác (revert rate) trong 14 ngày giảm từ 1,9% xuống 0,4%.

Nhà máy đã tích lũy được hơn chín tháng:

Phân tích dưới đây cho thấy các chỉ số về năng suất và chất lượng của chúng tôi trên 17.200 pull request đã được hợp nhất trên toàn bộ đội ngũ kỹ thuật của Augment từ tháng 11 năm 2025 đến tháng 7 năm 2026. Chúng tôi tạo báo cáo này bằng Cosmos ROI Analyst, một agent chỉ đọc (read-only) giúp truy xuất hoạt động của các PR đã hợp nhất từ GitHub, xác định các lần hoàn tác và tính toán các chỉ số về lưu lượng, thời gian chu kỳ, chất lượng và sản lượng có trọng số theo độ phức tạp.

Số lượng pull request thô trên mỗi nhà phát triển hoạt động tăng 2,7 lần, từ 16,6 lên 45,5. Vì số lượng PR đơn thuần có thể bị sai lệch do thay đổi về quy mô PR, chúng tôi đã xây dựng một chỉ số sản lượng điều chỉnh theo quy mô để kiểm tra xem mức tăng này có phải do chia nhỏ công việc thành các PR nhỏ hơn hay không. Chỉ số này tính trọng số cho mỗi PR dựa trên số tệp và dòng mã thay đổi, với các giới hạn để hạn chế ảnh hưởng của những thay đổi cực đoan.

Chỉ số đó đã tăng từ 12,3 lên 55,7 pull request hiệu dụng trên mỗi nhà phát triển hoạt động: gấp 4,5 lần. Số dòng mã thay đổi trên mỗi nhà phát triển hoạt động cũng tăng tương tự 4,5 lần, cung cấp thêm một tín hiệu dù có phần nhiễu hơn.

Thời gian trung bình từ khi tạo pull request đến khi hợp nhất giảm từ 11,2 giờ xuống 3,1 giờ, giảm 72%, ngay cả khi sản lượng trên mỗi nhà phát triển tăng 4,5 lần. Sự sụt giảm này rất quan trọng đối với nhà phát triển. Thời gian hợp nhất kéo dài dẫn đến tồn đọng đánh giá, và một nhà phát triển có thể phải làm đa nhiệm với 20 PR đang mở cùng lúc, điều này nhanh chóng trở nên quá tải đối với hầu hết chúng ta; các lỗi có thể tồn tại mà không được sửa trong nhiều ngày hoặc nhiều tuần. Thời gian hợp nhất ngắn (như 3 giờ) đảm bảo rằng một nhà phát triển chỉ xử lý một vài PR cùng một lúc và các bản sửa lỗi được áp dụng chỉ trong vài giờ.

Tỷ lệ pull request bị hoàn tác trong vòng 14 ngày giảm từ 1,9% xuống 0,4%. Tỷ lệ hoàn tác không phải là thước đo đầy đủ về chất lượng (nhiều lỗi được sửa bằng cách tiến lên phía trước hoặc được phát hiện sau đó), nhưng nó cung cấp một tín hiệu nhất quán rằng sản lượng cao hơn và việc hợp nhất nhanh hơn không đi kèm với việc phải quay lại trạng thái cũ ngay lập tức nhiều hơn.

Những con số này là một nghiên cứu tình huống theo chiều dọc, không phải là một thí nghiệm có kiểm soát. Tháng 11 bao gồm việc tiếp cận Opus 4.5 (mô hình đầu tiên mà chúng tôi thấy đủ tin cậy để hoàn thành các tác vụ kỹ thuật thông thường từ đầu đến cuối) và triển khai bot đánh giá AI cũ của chúng tôi. Các mô hình tiếp tục cải thiện, nhưng chúng tôi không thấy một bước thay đổi tương đương nào khác trong thời gian nghiên cứu. Việc áp dụng, quy trình làm việc và sự kết hợp công việc cũng phát triển, vì vậy các cột mốc cho thấy những gì chúng tôi đã xây dựng và thời điểm thực hiện—không phải sự đóng góp mang tính nhân quả của từng thành phần.

Những gì xu hướng này cho thấy là sản lượng tiếp tục tăng khi tự động hóa mở rộng ra ngoài việc tạo mã nguồn sang lập kế hoạch, đánh giá, xác minh, phản hồi và vận hành.

[ Báo cáo miễn phí]

Hướng dẫn dành cho lãnh đạo kỹ thuật về việc xây dựng nhà máy phần mềm

Cách các nhóm phần mềm chuyển từ các agent lập trình cá nhân sang cung cấp phần mềm ở cấp độ nhóm.

Tải xuống hướng dẫn

Theo dõi các điểm nghẽn, không phải thứ tự vòng đời

Thứ tự triển khai tuân theo các điểm nghẽn mà chúng tôi gặp phải, không phải thứ tự của vòng đời phần mềm. Chúng tôi bắt đầu với việc tự động hóa đánh giá mã nguồn vì tồn đọng đánh giá của chúng tôi tăng nhanh vào tháng 1. Tương tự, chúng tôi chỉ tự động hóa việc phân loại phản hồi khi các kênh phản hồi trên Slack bắt đầu tiêu tốn quá nhiều thời gian của nhà phát triển.

Lưu lượng chỉ tăng khi toàn bộ hệ thống có thể hấp thụ công việc

Chỉ riêng việc tăng sản xuất mã nguồn sẽ tạo ra một hàng đợi đánh giá lớn hơn. Kết quả quan trọng không chỉ đơn thuần là số lượng PR trên mỗi nhà phát triển tăng lên. Mà là sản lượng điều chỉnh theo quy mô tăng lên trong khi thời gian hợp nhất trung bình và tỷ lệ hoàn tác đo được lại giảm xuống.

Chúng tôi coi công việc tích lũy như hàng tồn kho. Một hàng đợi ngày càng tăng ở bất kỳ giai đoạn nào—ticket chờ triển khai, PR chờ đánh giá, thay đổi chờ xác minh hoặc phản hồi chờ điều tra—đều cho chúng tôi thấy nơi cần đầu tư tiếp theo.

Các agent cần bằng chứng và môi trường giống như các kỹ sư

Quyền truy cập kho lưu trữ là chưa đủ. Các agent của chúng tôi trở nên hữu ích hơn khi chúng có thể làm việc với CI, môi trường thử nghiệm, nhật ký, chỉ số, ticket, tài liệu, trạng thái triển khai và các quy trình vận hành được mã hóa trong các kỹ năng và runbook.

Điều đó đặc biệt quan trọng đối với Verifier và Incident Investigator. Giá trị của chúng đến từ việc thu thập bằng chứng runtime có thể kiểm tra được, chứ không phải từ việc đưa ra các giải thích hợp lý chỉ dựa trên mã nguồn.

Duy trì quyền quyết định của con người

Chúng tôi không thiết kế nhà máy để tự chủ hoàn toàn. Giống như các kỹ sư mới, các agent không phải lúc nào cũng có bối cảnh tổ chức cần thiết để lựa chọn giữa nhiều thiết kế hợp lý. Các hướng dẫn kho lưu trữ và thông số kỹ thuật sản phẩm có thể thu hẹp khoảng cách đó, nhưng các vấn đề mới lạ vẫn đòi hỏi sự phán đoán của con người. Do đó, chúng tôi đã thiết kế từng quy trình làm việc để tự động hóa công việc cơ học trong khi vẫn duy trì quyền sở hữu của con người.

Các agent đưa ra các lựa chọn kiến trúc, thu thập bằng chứng, thực hiện phân tích lặp đi lặp lại, triển khai công việc đã được phê duyệt, chạy và sửa lỗi kiểm thử, cũng như giải quyết các phản hồi mang tính cơ học. Các kỹ sư đưa ra các quyết định về sản phẩm và kiến trúc, đánh giá các sự đánh đổi mơ hồ, phê duyệt rủi ro sản xuất và chịu trách nhiệm về các hệ thống sau khi triển khai.

Việc áp dụng theo sau việc triển khai

Việc triển khai một agent không làm thay đổi hành vi kỹ thuật ngay lập tức. Các nhóm cần thời gian để hiểu thế mạnh của nó, kiểm tra bằng chứng, sửa hành vi của nó và tin tưởng giao cho nó những công việc dài hơi hơn. Chúng tôi cũng phải tinh chỉnh từng agent dựa trên phản hồi để đảm bảo nó có các rào chắn, xác thực và cấu hình phù hợp cho quy trình làm việc độc đáo của mỗi nhóm. Do đó, một số hiệu quả có thể đo lường được đã xuất hiện vài tuần sau cột mốc triển khai tương ứng.

Chúng tôi bắt đầu vào tháng 11 với các agent lập trình IDE và CLI, quyền truy cập vào một mô hình mạnh hơn và một bot đánh giá AI cũ. Đến đầu tháng 8, các agent chuyên biệt đã vận hành trên khắp các khâu lập kế hoạch, triển khai, đánh giá, xác minh, phản hồi và phản hồi sự cố.

Không có agent hay bản phát hành mô hình đơn lẻ nào giải thích được mức tăng 4,5 lần sản lượng điều chỉnh theo quy mô trên mỗi nhà phát triển. Sự thay đổi này trùng hợp với việc liên tục xác định nơi công việc kỹ thuật đang bị đình trệ và xây dựng thành phần tiếp theo cần thiết để thúc đẩy nó qua hệ thống.

Nhà máy không loại bỏ các kỹ sư khỏi quá trình phát triển phần mềm. Nó chuyển sự chú ý của họ khỏi việc điều tra và thực thi lặp đi lặp lại sang các quyết định, quyền sở hữu và học hỏi. Mục tiêu của chúng tôi rất đơn giản: tiếp tục tăng tốc độ kỹ thuật trong khi vẫn giữ nguyên tiêu chuẩn chất lượng.

Nếu bạn đang xây dựng nhà máy của riêng mình, hãy bắt đầu từ nơi công việc đang tồn đọng. Bạn có thể thử Cosmos với một quy trình làm việc và mở rộng khi nó chứng minh được tính hữu ích.