Kỹ sư chuyển từ viết mã sang thiết kế quy trình làm việc của tác nhân AI

Giả định cốt lõi của phát triển phần mềm đã thay đổi. Trong nhiều thập kỷ, ngành công nghiệp tối ưu hóa cho lập trình viên là con người, nhưng tính đến tháng 9 năm 2026, hơn 40% các yêu cầu pull request trên GitHub bắt đầu bằng bản nháp đầu tiên của một tác nhân AI. Việc áp dụng nhanh chóng AI tạo sinh này đã dịch chuyển nút thắt cổ chai từ việc viết mã sang việc triển khai mã, buộc phải có sự thay đổi cấu trúc trong cách các nhóm kỹ thuật vận hành.

Điều gì đã xảy ra

Công việc đang chuyển dần sang máy móc, nhưng các quy trình bao quanh công việc đó chưa theo kịp. Dữ liệu giao hàng năm 2026 của CircleCI cho thấy số lần chạy quy trình làm việc trung bình mỗi ngày tăng 59% so với cùng kỳ năm trước, với top 5% các nhóm ghi nhận mức tăng 97%. Ngược lại, nhóm tứ phân vị thấp nhất không cho thấy cải thiện đáng kể nào. Một nghiên cứu về một công ty yêu cầu tăng gấp đôi sản lượng pull request phát hiện rằng khối lượng công việc của người xem xét (reviewer) cũng tăng gấp đôi, và việc xem xét tự động nhanh chóng vượt qua xem xét bởi con người về phạm vi phủ sóng.

Sự gia tăng khối lượng này phơi bày những hạn chế của mô hình sprint và release truyền thống. Khi công việc được tự động hóa, con người không biến mất; họ ngừng thực hiện các công việc thủ công và bắt đầu thiết kế hệ thống mà công việc đó chạy qua. Kỹ sư phần mềm đang trở thành kỹ sư quy trình, chịu trách nhiệm xây dựng một "nhà máy phần mềm" nơi các tác nhân AI xử lý việc thực thi, còn con người định nghĩa các quy tắc, ràng buộc và tiêu chuẩn chất lượng.

Cách thức hoạt động

Một nhà máy phần mềm hoạt động như một mạng lưới các tác nhân chuyên biệt, mỗi tác nhân đảm nhận một giai đoạn cụ thể trong vòng đời phát triển. Một tác nhân nghiên cứu chuyển đổi dữ liệu khách hàng thành các bản tóm tắt, một tác nhân đặc tả viết các yêu cầu, và một tác nhân lập trình tạo ra thay đổi mã. Các tác nhân tiếp theo xử lý việc xem xét, kiểm thử và phát hành ẩn sau các feature flag. Khác với việc bàn giao giữa con người vốn dựa vào ngữ cảnh chung, việc bàn giao giữa các tác nhân đòi hỏi các hợp đồng nghiêm ngặt xác định rõ cấu trúc đầu vào, tiêu chí chấp nhận và bằng chứng về tính chính xác.

Kiểm soát chất lượng chuyển từ thanh tra cuối dây chuyền sang xác minh tích hợp ở mọi bước. Lấy cảm hứng từ các nguyên lý sản xuất như khung cửi tự động của Sakichi Toyoda, vốn dừng lại khi sợi chỉ bị đứt, các pipeline hiện đại phải kiểm tra ngay lập tức từng thay đổi. Điều này đòi hỏi các môi trường tạm thời (ephemeral environments) mô phỏng môi trường production, cho phép các tác nhân kiểm thử xác minh thay đổi dựa trên các dịch vụ thực tế thay vì mock. Nếu một bước kiểm tra thất bại, dây chuyền sẽ dừng lại, và tác nhân lập trình sẽ cố gắng sửa lỗi trước khi thay đổi được tiến hành.

Các rào chắn bảo vệ (guardrails) thay thế prompt trở thành cơ chế an toàn chính. Thay vì dựa vào các chỉ dẫn mà các tác nhân có thể bỏ qua, hệ thống thực thi các ranh giới quyền hạn và sự cô lập. Mỗi tác nhân chỉ giữ quyền truy cập cần thiết cho trạm làm việc của nó, ngăn chặn tác nhân lập trình truy cập vào thông tin đăng nhập production. Niềm tin không lan truyền xuống chuỗi; việc phê duyệt của tác nhân xem xét không mở rộng quyền hạn của tác nhân phát hành, đảm bảo rằng các lỗi không chồng chéo qua các giai đoạn.

Chi tiết quan trọng

• Tính đến tháng 9 năm 2026, hơn 40% các yêu cầu pull request trên GitHub bắt đầu bằng bản nháp đầu tiên của tác nhân, tăng từ 17% vào tháng 3.
• Dữ liệu của CircleCI cho thấy mức tăng trưởng 59% hàng năm về số lần chạy quy trình làm việc hàng ngày, với các nhóm hàng đầu tăng 97%.
• Việc bàn giao giữa các tác nhân đòi hỏi các hợp đồng rõ ràng, bao gồm tiêu chí chấp nhận và bằng chứng kiểm thử, thay vì ngữ cảnh không chính thức.
• Đảm bảo chất lượng chuyển từ thanh tra cuối cùng bởi con người sang xác minh tự động cho từng thay đổi trong môi trường giống production.
• Các cổng kiểm soát của con người được dành riêng cho các quyết định đòi hỏi phán đoán cao, chẳng hạn như ranh giới bảo mật và chiến lược sản phẩm, chứ không phải xem xét mã thường lệ.
• Mọi lỗi lọt qua đều được coi là lỗi quy trình, đòi hỏi phân tích lý do tại sao hệ thống cho phép nó đi qua thay vì đổ lỗi cho tác nhân.

Tại sao điều này quan trọng

Đối với các nhà phát triển, sự thay đổi này có nghĩa là mô tả công việc đang chuyển từ viết cú pháp sang thiết kế luồng. Các kỹ sư phải định nghĩa thế nào là "tốt" dưới dạng các thuật ngữ mà máy có thể đọc được, chẳng hạn như ngân sách hiệu suất và hợp đồng API. Giá trị nằm ở việc xây dựng một hệ thống bền vững nơi các tác nhân có thể hoạt động an toàn và hiệu quả. Điều này mang tính kỹ thuật cao hơn, chứ không ít hơn, vì nó đòi hỏi hiểu biết sâu sắc về cách mã tương tác với hạ tầng và nơi các lỗi xảy ra.

Các nhóm không thích ứng sẽ gặp phải nút thắt cổ chai trong khâu xem xét và xác minh. Chỉ đơn thuần thêm nhiều tác nhân mà không thiết kế lại pipeline sẽ dẫn đến công việc tồn đọng và lỗi chồng chéo. Lợi thế cạnh tranh không còn đến từ mô hình được sử dụng để tạo mã, mà từ hiệu quả và độ tin cậy của nhà máy phần mềm được xây dựng xung quanh nó. Những kỹ sư làm chủ thiết kế quy trình sẽ quyết định nhóm nào có thể tăng tốc độ phát triển mà không hy sinh sự ổn định.

Bạn có thể làm gì

• Lập bản đồ pipeline giao hàng hiện tại của bạn và xác định bước chậm nhất, rất có thể là khâu xem xét hoặc xác minh.
• Định nghĩa rõ ràng các tiêu chí chấp nhận và hợp đồng API cho việc bàn giao giữa các tác nhân để giảm thiểu sự mơ hồ.
• Thay thế staging cuối dây chuyền bằng các môi trường tạm thời, giống production cho mỗi pull request.
• Triển khai các ranh giới quyền hạn nghiêm ngặt cho từng tác nhân, đảm bảo quyền truy cập tối thiểu (least-privilege) tại mỗi trạm.
• Chuyển việc xem xét của con người sang các lĩnh vực đòi hỏi phán đoán cao như quyết định kiến trúc và sắc thái trải nghiệm người dùng.
• Coi mọi lỗi lọt qua là sự thất bại của quy trình, không phải của tác nhân, và điều chỉnh các bước kiểm tra tương ứng.