Cho tác tử AI tự mở pull request nghĩa là nó chạy trên máy chủ hoặc môi trường đám mây, nhận một thẻ công việc, tạo nhánh, sửa mã, chạy kiểm thử rồi gửi yêu cầu gộp để người duyệt. Cách này hợp với việc nhỏ, rõ, lặp lại; nó an toàn khi nhánh chính được bảo vệ, tác tử chỉ có quyền tối thiểu và mỗi yêu cầu gộp có một người chịu trách nhiệm.
Bài này dành cho trưởng nhóm kỹ thuật ở nhóm nhỏ và vừa muốn thử luồng làm việc này. Nhiều nền tảng lưu kho và công cụ tác tử đã có sẵn cách nối với nhau, nhưng tên menu, cách cấp quyền và mức phí thay đổi theo từng bản, nên bài nói theo nguyên lý; trước khi bật, bạn kiểm tài liệu chính thức của công cụ mình dùng.
Luồng làm việc trông như thế nào
Ví dụ giả định ở một nhóm sáu người làm hệ thống bán hàng: một thành viên tạo thẻ công việc "cảnh báo lỗi thời khi chạy kiểm thử ở mô-đun hoá đơn, sửa theo cách gọi mới của thư viện", gắn nhãn dành cho tác tử. Tác tử được kích hoạt, sao chép kho vào môi trường tạm, tạo nhánh, đọc thẻ, sửa mã, chạy kiểm thử. Khi xong, nó mở yêu cầu gộp, mô tả đã làm gì, gắn liên kết về thẻ, và phân công người duyệt theo quy định của kho.
Từ đây mọi thứ đi như yêu cầu gộp của người: hệ thống tích hợp liên tục chạy kiểm tra, người duyệt đọc, góp ý. Một số công cụ cho phép người duyệt viết góp ý ngay trong yêu cầu gộp và tác tử đọc góp ý đó để sửa tiếp. Người duyệt bấm gộp khi ưng, hoặc đóng yêu cầu khi không.
Toàn bộ chuyện này xảy ra trong một môi trường tạm dựng lên cho từng lượt chạy rồi xoá đi. Đó là điểm cộng về an toàn: tác tử không chạm vào máy của ai, không thấy tệp cấu hình cá nhân của ai. Đổi lại, môi trường đó phải dựng được dự án từ đầu bằng lệnh, nên dự án nào cài đặt rắc rối, cần nhiều bước tay, sẽ phải chuẩn hoá phần dựng trước khi nghĩ tới luồng này.
Điểm khác cốt lõi so với dùng tác tử trên máy mình là bạn không ngồi canh. Không có ai để tác tử dừng lại hỏi giữa chừng. Vì vậy mọi hàng rào phải nằm ở cấu hình chứ không ở lời dặn: tác tử được làm gì, không được làm gì, và cái gì chặn nó lại nếu nó cố.
Loại việc hợp và không hợp với luồng tự mở pull request
Tiêu chí chung: việc mà người duyệt kiểm được đúng sai trong vài phút, và nếu sai thì hậu quả nhỏ.
| Hợp | Không hợp |
|---|---|
| Sửa cảnh báo lỗi thời của thư viện theo hướng dẫn chuyển đổi chính thức | Thiết kế tính năng mới chưa có đặc tả |
| Thêm kiểm thử cho hàm đã có, chưa được kiểm | Đổi lược đồ cơ sở dữ liệu đang chạy thật |
| Sửa lỗi nhỏ có bước tái hiện rõ ràng | Sửa lỗi bảo mật chưa công bố |
| Cập nhật tài liệu theo mã đã đổi | Việc chạm vào xử lý thanh toán, phân quyền |
| Dọn cảnh báo của trình kiểm tra mã trong một thư mục | Việc cần trao đổi với khách hàng hoặc bộ phận khác |
| Nâng phiên bản vá của một thư viện kèm chạy kiểm thử | Việc cần quyết định kiến trúc |
Cột bên phải không có nghĩa là không dùng AI. Những việc đó vẫn có thể làm với tác tử trên máy của lập trình viên, có người ngồi cùng và dừng lại đúng chỗ. Chỉ là không nên giao cho luồng tự động không ai canh.
Quyền tối thiểu cho tác tử chạy trên máy chủ
Tài khoản riêng cho tác tử. Không dùng tài khoản hoặc khoá truy cập của một thành viên. Tác tử có danh tính riêng thì lịch sử ghi nhận rõ ràng, và khi cần thu hồi quyền thì không ảnh hưởng người nào.
Chỉ ghi được nhánh của nó. Quyền đọc mã, tạo nhánh với tiền tố riêng, mở yêu cầu gộp. Không được gộp, không được ghi vào nhánh chính, không được sửa cài đặt kho.
Không có khoá của môi trường thật. Môi trường tác tử chạy kiểm thử chỉ có khoá của môi trường thử nghiệm, nếu cần. Khoá cơ sở dữ liệu thật, khoá dịch vụ thanh toán không bao giờ nằm trong phạm vi tác tử đọc được.
Giới hạn mạng nếu công cụ cho phép. Chỉ cho truy cập kho gói và những địa chỉ cần cho việc dựng dự án. Điều này giảm rủi ro tác tử bị nội dung độc trong thẻ công việc hoặc trong tệp dẫn đi gửi dữ liệu ra ngoài.
Ai được kích hoạt tác tử. Chỉ thành viên nhóm được gắn nhãn kích hoạt. Nếu kho công khai, đừng để người ngoài mở thẻ công việc là tác tử tự chạy, vì nội dung thẻ chính là lệnh cho tác tử.
Dựng hàng rào ở nhánh chính trước khi bật tác tử
Các bước dưới đây là cài đặt trên nền tảng lưu kho; tên gọi khác nhau giữa các nền tảng, nhưng hầu hết đều có các tuỳ chọn tương đương.
- Bật quy tắc bảo vệ nhánh chính: không ai ghi thẳng, mọi thay đổi phải qua yêu cầu gộp.
- Bắt buộc ít nhất một người duyệt đồng ý trước khi gộp, và người đó không phải người kích hoạt tác tử nếu nhóm đủ người.
- Bắt buộc các kiểm tra tự động qua hết: kiểm thử, kiểm tra kiểu dữ liệu, trình kiểm tra mã, quét khoá bí mật.
- Dùng tệp khai báo người phụ trách theo thư mục, để thay đổi ở thư mục nhạy cảm tự động cần người phụ trách thư mục đó duyệt.
- Đặt giới hạn số yêu cầu gộp mở cùng lúc của tác tử, ví dụ giả định ba cái. Người duyệt không kịp thì tác tử chờ, không dồn thêm.
- Chạy thử với hai ba thẻ công việc dễ, đọc kỹ kết quả, rồi mới mở rộng loại việc.
Bước năm hay bị bỏ qua. Tác tử làm nhanh hơn người duyệt rất nhiều; nếu không giới hạn, hàng đợi yêu cầu gộp phình ra và người duyệt bắt đầu bấm đồng ý cho xong. Lúc đó hàng rào cuối cùng đã thủng.
Viết thẻ công việc cho tác tử không có người canh
Thẻ công việc trong luồng này đóng vai phiếu giao việc, nhưng khắt khe hơn vì không ai trả lời câu hỏi giữa chừng. Một thẻ đủ cho tác tử nên có:
- Mô tả hiện trạng và kết quả mong muốn, mỗi thứ một hai câu, kèm bước tái hiện nếu là lỗi.
- Đường dẫn tệp hoặc thư mục là điểm bắt đầu, và phạm vi không được đụng.
- Tiêu chí xong kiểm được bằng lệnh: kiểm thử nào phải qua, kiểm thử mới nào phải có.
- Chỉ dẫn khi gặp chỗ mơ hồ: dừng và ghi câu hỏi vào yêu cầu gộp ở trạng thái nháp, thay vì đoán.
- Không dán dữ liệu khách hàng thật, nhật ký có thông tin cá nhân hay khoá truy cập vào thẻ; nếu cần ví dụ, dùng dữ liệu giả đã che.
Mục thứ tư là chỗ khác biệt lớn nhất so với làm trên máy. Yêu cầu gộp ở trạng thái nháp là cách tác tử "giơ tay hỏi" trong luồng tự động: người chịu trách nhiệm đọc câu hỏi, trả lời bằng góp ý, rồi tác tử làm tiếp. Nếu công cụ không hỗ trợ cách này, hãy chỉ giao những thẻ đủ rõ để không cần hỏi gì.
Nhóm nào đã có mẫu thẻ công việc cho người thì chỉ cần thêm hai mục: phạm vi không được đụng và chỉ dẫn khi mơ hồ. Đừng tạo một mẫu thẻ hoàn toàn khác cho tác tử, vì như vậy thẻ của người sẽ ngày càng sơ sài hơn thẻ của máy.
Người chịu trách nhiệm và cách đọc yêu cầu gộp do tác tử mở
Mỗi yêu cầu gộp do tác tử mở cần một người đứng tên chịu trách nhiệm, thường là người tạo thẻ công việc. Người đó không viết mã, nhưng họ là người hiểu yêu cầu, trả lời góp ý thay tác tử khi cần, và quyết định đóng nếu kết quả không đạt. Nếu không ai đứng tên, yêu cầu gộp sẽ nằm đó, hoặc tệ hơn, được gộp bởi người không hiểu nó.
Khi đọc, người duyệt nên đối chiếu với thẻ công việc trước tiên: tác tử có làm đúng việc được giao không, có làm thêm gì không. Rồi xem phần mô tả: tác tử nói đã kiểm gì, kết quả các kiểm tra tự động có khớp lời nó nói không. Cuối cùng mới đọc mã. Thứ tự này giúp phát hiện sớm trường hợp tác tử hiểu sai yêu cầu, thứ mà đọc mã từng dòng rất khó nhận ra.
Nên có quy ước rõ về số vòng góp ý. Nếu sau hai vòng góp ý tác tử vẫn chưa làm đúng, người chịu trách nhiệm đóng yêu cầu gộp và hoặc tự làm, hoặc viết lại thẻ công việc chi tiết hơn. Kéo dài nhiều vòng với tác tử tốn thời gian người duyệt hơn là tự sửa.
Theo dõi luồng sau một tháng chạy thử
Sau một tháng, nhìn lại bằng số đếm thay vì cảm giác. Những câu hỏi đáng trả lời:
- Bao nhiêu yêu cầu gộp tác tử mở được gộp, bao nhiêu bị đóng, và lý do đóng phổ biến nhất là gì.
- Thời gian người duyệt bỏ ra cho mỗi yêu cầu gộp của tác tử so với yêu cầu gộp cùng loại do người làm.
- Có thay đổi nào của tác tử đã gộp mà sau đó phải sửa lại hoặc hoàn tác không.
- Chi phí chạy tác tử trong tháng, tính theo mức sử dụng của công cụ, so với thời gian nhóm tiết kiệm được.
- Người duyệt cảm thấy thế nào: đỡ việc thật hay chỉ chuyển từ viết mã sang đọc mã.
Nếu tỉ lệ bị đóng cao ở một loại việc, bỏ loại việc đó khỏi danh sách hợp. Nếu người duyệt quá tải, giảm giới hạn yêu cầu gộp mở cùng lúc. Luồng tự động chỉ đáng giữ khi nó thật sự lấy bớt việc của nhóm, không phải đẻ thêm việc đọc.
Câu hỏi thường gặp
Tác tử chạy trên máy chủ có đọc được mã nguồn bí mật của công ty không?
Có, nó cần đọc mã để làm việc. Vì vậy trước khi bật, kiểm điều khoản của công cụ về lưu trữ và sử dụng mã, cài đặt dành cho tổ chức, và vị trí xử lý dữ liệu. Việc này nên có người phụ trách kỹ thuật hoặc pháp chế của công ty cùng xem.
Có thể để tác tử tự gộp yêu cầu gộp nếu kiểm thử qua hết không?
Không nên với mã sản phẩm. Kiểm thử qua chỉ nói rằng các kiểm thử hiện có không bắt được lỗi. Một số nhóm cho tự gộp với việc rất hẹp như cập nhật phiên bản vá của thư viện, nhưng đó là quyết định có cân nhắc, kèm khả năng hoàn tác nhanh.
Nội dung thẻ công việc có thể bị lợi dụng để điều khiển tác tử không?
Có thể, đây là dạng chèn lệnh. Người viết thẻ hoặc nội dung tác tử đọc được có thể cài câu lệnh khiến nó làm việc ngoài ý muốn. Vì vậy chỉ thành viên tin cậy được kích hoạt tác tử, và quyền của tác tử phải đủ hẹp để dù bị dẫn đi cũng không gây hại lớn.
Nhóm ba người có cần luồng này không?
Thường chưa cần. Nhóm nhỏ dùng tác tử trên máy từng người, tự mở yêu cầu gộp, đã đủ. Luồng tự động đáng dựng khi có nhiều việc nhỏ lặp lại chất đống mà không ai có thời gian làm.
Yêu cầu gộp do tác tử mở có cần ghi rõ là do AI làm không?
Nên ghi, và đa số công cụ tự ghi qua danh tính tài khoản tác tử. Ghi rõ giúp người duyệt biết nên đọc kỹ ở đâu, và giúp nhóm thống kê hiệu quả sau này. Quy ước cụ thể nên nằm trong bộ quy tắc dùng AI của nhóm.
Khi tác tử mở yêu cầu gộp sai hoàn toàn thì có nên góp ý để nó sửa?
Nếu sai hướng từ đầu, đóng luôn và viết lại thẻ công việc tốt hơn. Góp ý sửa từng chỗ chỉ hợp khi hướng đi đúng mà chi tiết chưa đạt. Cố uốn một bản sai hướng thường tốn thời gian hơn làm lại.