Ở hầu hết các nhóm áp dụng lập trình tác nhân, nút thắt chuyển từ khâu tạo mã sang khâu đánh giá; nếu không cải thiện vòng lặp này, mức tăng tốc độ ròng gần như bằng không.
Trong các môi trường CI quy mô lớn với hàng triệu lượt kiểm thử mỗi đêm và hàng trăm kỹ sư, nhiệm vụ mang lại giá trị cao nhất cho tác nhân là xác định nhóm chịu trách nhiệm và phân loại sự cố, chứ không phải tạo mã.
Đầu ra hữu ích của tác nhân phải vượt qua quá trình thẩm định và giải thích được quan hệ nhân quả, chứ không chỉ đối chiếu mẫu.
Việc thiết kế lớp thu thập bằng chứng và tập hợp ngữ cảnh quan trọng hơn lớp tạo sinh.
Phần lớn thảo luận về lập trình tác nhân vẫn bắt đầu bằng một lời hứa đơn giản: viết nhiều mã hơn, nhanh hơn.
Đôi khi, lời hứa ấy phát triển thành một viễn cảnh tham vọng hơn: các tác nhân lập kế hoạch công việc, mở PR và triển khai thay đổi với sự can thiệp tối thiểu của con người. Nhưng với hầu hết các nhóm kỹ thuật, giá trị rõ ràng nhất trong tương lai gần có phạm vi hẹp hơn. Đó là giảm chi phí của mỗi vòng lặp cải tiến.
Phân phối phần mềm không chỉ là tạo mã. Viết mã chỉ là một giai đoạn trong vòng lặp dài hơn, bao gồm đánh giá, kiểm thử, triển khai và điều tra khi có sự cố. Phần lớn các nhóm áp dụng lập trình tác nhân mà không thiết kế lại vòng lặp đánh giá chỉ đơn thuần đẩy nút thắt sang công đoạn sau.
Chỉ đẩy nhanh khâu tạo mã không tự động giúp cả nhóm làm việc nhanh hơn. Điều đó có thể chỉ khiến khâu đánh giá, xác minh và xây dựng niềm tin tốn nhiều công sức hơn.
Trong nhiều môi trường kỹ thuật, phần tốn kém không phải là tạo ra bản nháp đầu tiên mà là đạt được mức độ tin cậy cần thiết.
Thay đổi đó có thực sự khắc phục vấn đề hoặc cải thiện hệ thống không? Nó có gây ra lỗi hồi quy ở nơi khác không? Lỗi nằm trong mã, môi trường, các bài kiểm thử hay một phần phụ thuộc? Bản sửa lỗi được đề xuất giải quyết nguyên nhân hay chỉ xử lý triệu chứng nhìn thấy được?
Tác nhân có thể hỗ trợ ở đây, không phải vì chúng thay thế kỹ sư, mà vì chúng có thể thực hiện bước rà soát đầu tiên một cách có hệ thống trên lượng bằng chứng hỗn tạp: kiểm tra nhật ký, so sánh các thay đổi gần đây, tóm tắt tín hiệu liên quan, truy vết nguyên nhân có khả năng xảy ra, chạy các bước kiểm tra và trả về kết quả để con người xem xét kỹ.
Ở nhiều nhóm, cách sử dụng tác nhân mang lại hiệu quả cao nhất không phải là tạo mã từ đầu. Đó là thu hẹp phạm vi tìm kiếm quanh một vấn đề trước khi con người phải bỏ ra hàng giờ xử lý thủ công.
Điều này đặc biệt rõ ràng trong các quy trình gỡ lỗi quy mô lớn. Hãy hình dung hệ thống CI mỗi đêm chạy hàng triệu bài kiểm thử trên các cơ sở mã được hàng trăm kỹ sư chỉnh sửa—đây là thực tế tại một khách hàng của chúng tôi. Khi có lỗi, việc xác định nhóm chịu trách nhiệm rất khó khăn. Vấn đề có thể nằm trong mã ứng dụng, một phần phụ thuộc, hệ thống điều khiển kiểm thử hoặc một vị trí khác trong ngăn xếp. Nhật ký có thể lên đến hàng gigabyte, và nhóm đầu tiên phát hiện vấn đề không phải lúc nào cũng là nhóm chịu trách nhiệm về nó.
Loại quy trình đó không phù hợp với cách giao cho một tác nhân tự viết bản sửa lỗi. Nó phù hợp với một hệ thống có thể nhanh chóng thu hẹp phạm vi vấn đề.
Một quy trình hữu ích có thể truy xuất nhật ký, chọn bằng chứng liên quan, tóm tắt những điểm quan trọng, kiểm tra mã trong môi trường cô lập và đưa ra bản phân tích nguyên nhân gốc có cấu trúc, kèm điểm tin cậy, khả năng truy vết và các bước tiếp theo được đề xuất. Để tạo điểm tin cậy, một chuyên gia trong lĩnh vực sẽ chấm đầu ra ban đầu của tác nhân. Kết quả này sau đó được đưa vào một LLM đóng vai trò giám khảo để tự động hóa việc chấm điểm về sau mà vẫn nhất quán với đánh giá của con người.
Mục tiêu không phải là loại bỏ đánh giá chuyên môn của kỹ sư, mà là mang đến cho người đánh giá một điểm xuất phát tốt hơn. Phân loại lỗi hồi quy, đánh giá PR, sửa bài kiểm thử, xác thực bản phát hành và điều tra sau triển khai đều có chung một đặc điểm. Tất cả đều đòi hỏi nhiều bằng chứng, nhiều công sức đánh giá và chứa đầy điểm mơ hồ. Chúng không yêu cầu tác nhân thay thế quy trình kỹ thuật, mà chỉ hỗ trợ thúc đẩy quy trình tiến triển.
Đây cũng là lý do các nhóm cần thận trọng khi đánh giá những hệ thống này.
Câu hỏi sai là liệu một tác nhân có thể tự mình tạo ra thứ gì đó ấn tượng hay không. Câu hỏi phù hợp hơn là liệu nó có cải thiện một quy trình thực tế mà không gây thêm trở ngại ở nơi khác hay không.
Điều đó đòi hỏi phải xem đầu ra có đủ cụ thể để xác minh hay không, có giải thích quan hệ nhân quả thay vì chỉ đối chiếu mẫu hay không, và có giúp việc đánh giá dễ dàng hơn thay vì khó khăn hơn hay không. Một câu trả lời nghe có vẻ hợp lý chưa chắc đã hữu ích. Trên thực tế, các nhóm chỉ tin tưởng đầu ra của tác nhân khi nó vượt qua quá trình thẩm định và cung cấp nội dung cụ thể để kiểm chứng.
Bài học sâu xa hơn là các hệ thống tác nhân hữu ích cần nhiều yếu tố hơn là khả năng tạo sinh. Chúng phụ thuộc vào cách thu thập bằng chứng, tập hợp ngữ cảnh, kiểm tra đầu ra và trình bày những điểm chưa chắc chắn cho người đánh giá.
Đó là lý do tương lai gần của kỹ thuật tác nhân khó có thể là một bước nhảy vọt duy nhất tới trạng thái tự chủ hoàn toàn. Nhiều khả năng đó sẽ là một tập hợp các vòng lặp được thiết kế chặt chẽ, trong đó tác nhân giúp các nhóm kiểm tra, đánh giá, xác minh và tinh chỉnh công việc, đồng thời giảm công sức lãng phí giữa các bước.
Điều đó có thể kém ấn tượng hơn viễn cảnh tự chủ rộng lớn, nhưng lại gần hơn nhiều với cách các hệ thống hữu ích thực sự được áp dụng.