Sự xuất hiện của các agent đang biến hệ thống CI thành nút thắt cổ chai mới trong quy trình phát triển phần mềm. Tuy nhiên, việc chỉ đơn thuần cố gắng tăng tốc pipeline không phải là cách tiếp cận đúng đắn để giải quyết vấn đề.

Bài viết này phân tích cách các công cụ tự động (agents) đã biến quy trình tích hợp liên tục (CI) thành nút thắt trong việc phát triển phần mềm, chỉ ra rằng việc chỉ làm cho CI nhanh hơn không giải quyết gốc rễ vấn đề và đề xuất một hướng tiếp cận mới cho việc xác thực mã nguồn.
Các bài đăng vào tháng Chín của Anthropic, Linear và CEO Depot đều mô tả hiện tượng này. Anthropic cho biết khối lượng công việc CI tăng 25 lần trong sáu tháng và các kỹ sư của họ đã đẩy lượng mã lên khoảng 8 lần so với giai đoạn 2021‑2025; họ đã áp dụng phân tích tác động kiểm thử để chỉ chạy những test có thể bị ảnh hưởng. Linear báo rằng bộ test của họ gần như tăng gấp bốn kể từ tháng Giêng và phần lớn các test hiện do agents viết, dẫn đến việc họ phải tái cấu trúc toàn bộ pipeline. CEO Depot nhấn mạnh tương lai CI sẽ là “cung cấp cho agents cách xác thực mã và duy trì niềm tin khi chúng làm việc”. Cả ba đều đồng ý rằng CI đang trở thành điểm yếu, nhưng chỉ có Anthropic thực sự giải quyết lớp vấn đề đúng, trong khi Linear và Depot tập trung vào việc tăng tốc CI mà không thay đổi những gì được kiểm chứng. CI truyền thống được thiết kế cho năng suất con người: vài PR mỗi tuần, thời gian chạy khoảng 20 phút là chấp nhận được. Agents phá vỡ công thức này bằng hai cách: tăng khối lượng (Anthropic 25‑x, Blacksmith báo tăng 5‑10 % hàng tuần) và thay đổi thời điểm chạy (CI chỉ bắt đầu sau khi PR đã tồn tại, khiến agents mất ngữ cảnh khi chờ kết quả). Ngay cả khi cải thiện tốc độ runner, lựa chọn test thông minh, cache lớn hơn hoặc pipeline có thể gọi trước khi commit, giả định vẫn còn là “kiểm chứng một repository”. Trong môi trường đám mây‑native, một repository chỉ là một trong khoảng bốn mươi dịch vụ; các test thường mô phỏng các dịch vụ còn lại, vì vậy một thay đổi có thể vượt qua tất cả các unit test, CI và sandbox nhưng vẫn gây lỗi khi thực tế giao tiếp qua ranh giới dịch vụ (ví dụ đổi tên trường, thu hẹp timeout, thay đổi schema). Không có gì trong CI – nhanh hay chậm – có thể phát hiện những lỗi ở “seam” này vì CI chỉ nhìn vào repository. DORA cũng đã chỉ ra rằng việc tăng cường AI đồng thời làm tăng tốc độ giao hàng phần mềm và mức độ không ổn định. Do đó, vòng xác thực cần di chuyển lên phía trước và mở rộng phạm vi. Cursor cho biết hơn 30 % PR hiện được hợp nhất từ agents chạy trong sandbox cloud; GitHub Copilot, Codex, Devin và Greptile đều triển khai các môi trường tạm thời để chạy test, nhưng chúng chỉ chứa repository và các phụ thuộc cài đặt qua script, chưa bao gồm các dịch vụ phụ. Việc này khiến vòng phản hồi khép lại quanh bản sao mã nguồn chứ không phải toàn bộ hệ thống. Đối với các hệ thống phân tán, xác thực trước PR phải diễn ra trên toàn hệ thống, không chỉ trên repository, và câu hỏi cần trả lời là “thay đổi có hoạt động tốt với mọi thành phần khác chưa?” chứ không phải “có vượt qua các test trong repository chưa?”. Vấn đề chi phí có thể giải quyết bằng cách multiplex: một cụm Kubernetes duy nhất chạy một phiên bản ổn định của mọi dịch vụ và tạo hàng nghìn môi trường test nhẹ, mỗi môi trường chỉ triển khai dịch vụ đã thay đổi, các yêu cầu được gắn nhãn để đi qua dịch vụ này trong khi các phần còn lại dùng phiên bản ổn định chung. Một môi trường test chỉ tốn mức chi phí của một pod và khởi tạo trong vài giây, cho phép nhiều agents chia sẻ cùng một môi trường thay vì nhân bản 50 môi trường cho 50 agents. Ngoài môi trường, agents còn cần một quy trình kiểm soát: gửi yêu cầu, ghi lại log, kiểm tra hợp đồng, báo cáo kết quả. Đội nền tảng nên định nghĩa một chuỗi hành động được phê duyệt, các agents gọi qua các skill và hook (như Claude Code, Cursor), giúp kiểm thử diễn ra trong vòng lặp của agent và đồng thời đảm bảo an toàn trong cluster chia sẻ. Kết quả chi tiết (yêu cầu, dịch vụ được truy cập, hợp đồng được duy trì) sẽ được lưu lại để các công cụ review và cổng merge có thể xác nhận thay đổi đã được thử nghiệm trên dịch vụ thực trước khi con người kiểm tra, biến CI thành bước xác nhận cuối cùng thay vì nơi phát sinh lỗi đầu tiên. Tôi dự đoán các nhà cung cấp CI sẽ tiếp tục tăng tốc và các agents sẽ cải thiện khả năng chạy code trong sandbox, nhưng khoảng trống giữa repository và hệ thống sẽ vẫn tồn tại cho đến khi xác thực được đưa vào bên trong vòng lặp của agent. Các nhóm thành công sẽ không còn hỏi “pipeline có thể xác nhận repository nhanh bao nhiêu?” mà sẽ hỏi “agent có thể chứng minh thay đổi hoạt động tốt với toàn bộ hệ thống sớm nhất ở đâu?”. Câu trả lời nằm trong việc tích hợp kiểm thử hệ thống vào vòng lặp của agent, trước PR; Signadot được xây dựng để cung cấp khả năng kiểm tra này với chi phí thấp và được quản lý.