Trong một thời gian dài, câu hỏi về các tác nhân lập trình là liệu chúng có thực sự làm được việc hay không. Câu hỏi đó đang dần khép lại một cách âm thầm. Với những nhiệm vụ được xác định phạm vi rõ ràng, có kho mã nguồn ngay trước mặt và khả năng chạy các bài kiểm thử, các tác nhân tốt sẽ tạo ra những thay đổi thực sự vượt qua được review. Và ngay khoảnh khắc bạn bắt đầu tin tưởng điều đó, bạn sẽ gặp phải một vấn đề mà không ai cảnh báo trước: bạn không thể nghĩ ra việc đủ nhanh để giữ cho chúng luôn bận rộn.
Việc thực thi không còn là điểm nghẽn nữa
Luôn luôn có vô số việc phải làm trên một sản phẩm phần mềm. Backlog không bao giờ trống rỗng; danh sách những thứ có thể làm tốt hơn là vô tận. Vì vậy, nghe có vẻ lạ khi nói rằng một đội có thể hết việc để giao cho một tác nhân. Nhưng "tồn tại vô số việc" và "tồn tại việc dưới một hình thức mà tác nhân có thể tiếp nhận và hoàn thành" là hai phát biểu rất khác nhau, và khoảng cách giữa hai điều đó chính là nơi các đội bị mắc kẹt.
Một tác nhân có thể thực thi một nhiệm vụ rõ ràng chỉ trong vài phút. Nhưng viết ra nhiệm vụ rõ ràng đó — nhiệm vụ có đủ bối cảnh, phạm vi đúng đắn và định nghĩa hoàn thành — vẫn tốn của một người hai mươi phút như trước nay. Khi việc thực thi là phần chậm, điều đó không sao cả; đặc tả chỉ chiếm năm phần trăm công sức, còn chín mươi lăm phần trăm còn lại là thực thi. Đẩy chi phí thực thi về gần bằng không, tỷ lệ đó sẽ đảo ngược. Giờ đây đặc tả trở thành nửa tốn kém, và một đội từng đủ sức nuôi một tác nhân nhận ra rằng họ không thể nuôi nổi ba.
Điểm nghẽn đã di chuyển ngược dòng, đến chính bạn
Đây chính là vấn đề nguồn cung nhiệm vụ: ràng buộc của phát triển phần mềm dựa trên tác nhân không còn nằm ở khả năng làm việc của tác nhân nữa, mà nằm ở khả năng của tổ chức trong việc tạo ra những việc được định hình tốt để làm. Và ràng buộc đó rơi xuống đúng những người khan hiếm nhất mà bạn có — những người có đủ bối cảnh để nói điều gì nên xảy ra tiếp theo và tại sao.
Bạn cảm nhận điều này như một loại áp lực kỳ lạ. Tác nhân nhanh và đáng tin cậy, nên hàng đợi cạn kiệt nhanh hơn tốc độ bạn có thể bổ sung, và việc bổ sung đó chính là phần đòi hỏi khả năng phán đoán, cảm quan sản phẩm và hiểu biết về hướng đi của hệ thống. Điểm nghẽn không hề biến mất. Nó chỉ chuyển từ bàn phím sang đầu óc của người biết bàn phím nên làm gì.
Tác nhân phải giúp cung cấp công việc
Cách duy nhất để vượt qua vấn đề nguồn cung là tăng nguồn cung, và người định nghĩa nhiệm vụ thì không thể mở rộng quy mô. Vì vậy, tác nhân thực thi công việc phải bắt đầu giúp tạo ra công việc đó — không phải bằng cách bịa ra những việc vặt vô nghĩa, mà bằng cách biến những tín hiệu đã và đang chảy qua hệ thống của bạn thành những nhiệm vụ cụ thể, sẵn sàng để thực hiện.
Ngày nay TaskGoblin đã làm một phiên bản của điều này, ở hai nơi mà có thể bạn chưa từng nghĩ đến như là "tạo nhiệm vụ":
- Các phát hiện từ review trở thành công việc. Mỗi merge request mà tác nhân review đều tạo ra những phát hiện cụ thể, được định vị rõ ràng — hàm này có lỗi về tính đúng đắn, đường dẫn này chưa được kiểm thử, cái này có mùi của vấn đề bảo mật. Mỗi phát hiện, trên thực tế, là một nhiệm vụ được viết sẵn kèm định nghĩa hoàn thành. Trả lời
@taskgoblin fixvà phát hiện đó biến thành một thay đổi. Không ai phải ngồi xuống viết ticket đó cả; review đã cung cấp nó rồi. - Các vòng lặp thường trực trở thành công việc. Một nhiệm vụ theo lịch là một bộ tạo nhiệm vụ chạy theo đồng hồ: "mỗi ngày làm việc, tìm những công việc đã merge mà issue liên quan vẫn còn mở và đóng chúng lại", "theo dõi CI bị đỏ quá lâu". Chỉ thị được viết một lần, và nó tiếp tục tạo ra công việc cụ thể — hoặc đúng đắn không tạo ra gì khi không có việc gì phải làm — mà không cần ai bổ sung hàng đợi bằng tay.
Trong cả hai trường hợp, tác nhân không chờ được bảo phải làm gì. Nó đọc trạng thái của hệ thống và đề xuất bước tiếp theo cụ thể, có thể hoàn thành được.
Vì sao bối cảnh là toàn bộ cuộc chơi
Lý do khiến công việc do tác nhân đề xuất thường có giá trị thấp không phải vì mô hình không đủ thông minh. Mà vì tác nhân không biết điều gì quan trọng với bạn. Khi bị mù trước ý định sản phẩm, một tác nhân sẽ vui vẻ đề xuất hai mươi việc tái cấu trúc mà nó nhìn thấy được, nhưng không đề xuất cái thay đổi duy nhất thực sự thúc đẩy công việc kinh doanh — bởi vì mã nguồn chỉ cho nó biết điều gì là khả thi, chứ không phải điều gì là quan trọng.
Đó là lý do vì sao những bề mặt tạo nhiệm vụ hữu ích là những bề mặt neo vào ý định thực sự. Một phát hiện từ review quan trọng vì nó nằm trên một thay đổi mà ai đó đã chọn thực hiện. Một vòng lặp theo lịch quan trọng vì một con người đã quyết định rằng việc giữ cho issue và merge đồng bộ là đáng làm mỗi ngày. Bối cảnh khiến một nhiệm vụ được đề xuất đáng để thực hiện không chỉ nằm trong mã nguồn; nó nằm trong các issue, các cuộc thảo luận và các quyết định xung quanh mã nguồn — và một tác nhân sống trong những hệ thống đó, như tác nhân của chúng tôi, có thể đọc được ý định ấy thay vì phải đoán mò.
Giá trị hiện đang nằm ở đâu
Đáng để nói rõ điều này để lại lợi thế ở đâu. Khi các mô hình hội tụ về khả năng thực thi gần như mọi thứ, giá trị không cân xứng sẽ không còn tích lũy về phía ai sở hữu tác nhân thông minh nhất nữa, mà bắt đầu tích lũy về phía ai có thể liên tục cung cấp cho các tác nhân tốt công việc thực sự có ý nghĩa. Nước cờ chiến thắng không phải là một mô hình khôn ngoan hơn. Đó là khép kín vòng lặp giữa ý định rải rác trong các công cụ của bạn và tác nhân có thể hành động dựa trên ý định đó, để "chúng ta nên làm gì tiếp theo" không còn là một điểm nghẽn mà chính bạn phải gánh vác.
Đó chính là vấn đề mà chúng tôi thực sự đang xây dựng để đối đầu. Làm cho tác nhân có thể lập trình là nửa đầu. Đảm bảo nó luôn biết điều gì đáng làm — và có thể biến bối cảnh của bạn thành nhiệm vụ cụ thể tiếp theo mà không cần chờ đợi bạn — là nửa còn lại quyết định nửa đầu đáng giá bao nhiêu.
