Bởi Kwame Boateng

Lập trình có sự hỗ trợ của AI thường được mô tả là phiên bản nhanh hơn của lập trình đôi. So sánh đó giờ đây đã trở nên quá hạn hẹp. Khi một tác tử có thể kiểm tra một kho mã, thay đổi nhiều tệp, chạy công cụ, tạo bản xem trước và mở một pull request, vấn đề cộng tác cốt lõi không còn đơn giản là “Nó có thể viết mã không?” mà là “Mọi người có thể thấy, xem xét, phê duyệt và sau này tái dựng những gì đã xảy ra không?”

Đó là lý do sự chuyển dịch thiết kế quan trọng nhất trong các nhóm phần mềm có tác tử hỗ trợ có thể là chuyển từ các lời nhắc riêng tư sang những không gian làm việc hiển thị. Chẳng hạn, Slack Code được mô tả là kết hợp các kênh dự án với các tác tử lập trình, kiểm toán khác biệt mã, bản xem trước HTML trực tiếp, quy trình phản hồi và phê duyệt, lưu trữ tự động cùng nhật ký kiểm toán. Ứng dụng Copilot của GitHub cũng đã bổ sung ngăn “My work” để sắp xếp các issue và pull request trên nhiều dự án. Những tính năng này hướng tới một nguyên tắc thực tế: công việc của tác tử nên trông ít giống một câu trả lời khó nhìn thấu hơn và giống một tập hợp thay đổi đang đi qua một quy trình sản xuất được kiểm soát.

Cuộc trò chuyện không phải là hồ sơ công việc

Một cuộc trò chuyện với tác tử có thể hữu ích khi khám phá một ý tưởng, nhưng là một hệ thống lưu hồ sơ yếu. Những chi tiết quan trọng có thể bị chôn vùi trong một chuỗi dài: những tệp nào đã thay đổi, các lệnh nào đã chạy, tác tử đã đưa ra những giả định nào, người xem xét đã bác bỏ điều gì và kết quả cuối cùng có khác với đề xuất ban đầu hay không.

Một không gian làm việc bền vững giúp các chi tiết đó có thể được kiểm tra. Nó nên liên kết yêu cầu với một kho mã hoặc dự án cụ thể, lưu lại kế hoạch của tác tử, hiển thị các thao tác công cụ và thay đổi tệp, liên kết tới các bài kiểm thử và bản xem trước, đồng thời ghi lại ai đã phê duyệt kết quả. Giao diện cụ thể có thể khác nhau—trình theo dõi issue, pull request, kênh cộng tác hoặc bảng điều khiển tác tử—nhưng thông tin phải vẫn tồn tại sau khi phiên làm việc kết thúc.

Điều này quan trọng vì những lý do kỹ thuật thông thường, không chỉ vì tuân thủ. Nếu một lỗi xuất hiện hai tuần sau, nhóm cần nhiều hơn khác biệt cuối cùng. Họ có thể cần biết yêu cầu ban đầu, kế hoạch được tạo ra, bằng chứng kiểm thử, nhận xét của người xem xét và liệu một con người có trực tiếp chấp nhận một đánh đổi rủi ro hay không. Một hồ sơ bền vững giúp rút ngắn quá trình điều tra đó.

Năm lớp công việc hiển thị

Các nhóm áp dụng tác tử lập trình có thể coi mỗi thay đổi như một hồ sơ vụ việc nhỏ, có thể kiểm tra. Năm lớp đặc biệt hữu ích là:

  1. Ý định: issue, tiêu chí chấp nhận, các ràng buộc và phạm vi được yêu cầu.
  2. Kế hoạch: cách tiếp cận do tác tử đề xuất trước khi chỉnh sửa tệp. Với một nhiệm vụ không tầm thường, đây là một điểm kiểm tra phê duyệt, không phải phần trang trí.
  3. Khác biệt: các phần bổ sung, xóa bỏ, thay đổi phụ thuộc, chỉnh sửa cấu hình và tài sản được tạo ra một cách chính xác.
  4. Bằng chứng: kết quả kiểm thử, đầu ra lint, kiểm tra bảo mật, ảnh chụp màn hình và bản xem trước trực tiếp hoặc có thể triển khai khi phù hợp.
  5. Bản ghi quyết định: nhận xét của người xem xét, các thay đổi được yêu cầu, phê duyệt, từ chối, khôi phục hoặc công việc tiếp nối.

Mục đích không phải là buộc mọi thay đổi phải đi qua một hội đồng cồng kềnh. Một lỗi đánh máy và một thay đổi trong luồng thanh toán không nên chịu các biện pháp kiểm soát giống hệt nhau. Mục đích là làm cho mức độ xem xét tương xứng với tác động tiềm tàng.

Phê duyệt nên gắn với hành động

“Con người trong vòng lặp” quá mơ hồ để trở thành một biện pháp kiểm soát hữu ích. Một người có thể phê duyệt kế hoạch mà không thấy khác biệt kết quả, hoặc phê duyệt một thay đổi mã mà không nhận ra rằng tác tử cũng đã sửa đổi một tệp triển khai. Các quy trình tốt hơn nêu rõ việc phê duyệt cho phép làm gì.

Chẳng hạn, một nhóm có thể cho phép tác tử tự động đọc một kho mã và chạy các bài kiểm thử cục bộ, yêu cầu phê duyệt trước khi ghi ra ngoài một nhánh được chỉ định, và yêu cầu một phê duyệt riêng trước khi hợp nhất hoặc triển khai. Tác tử có thể đề xuất một migration cơ sở dữ liệu nhưng bị cấm thực thi nó trong môi trường production. Cách tiếp cận được đề xuất của UAE về việc phân loại những nhiệm vụ mà tác tử được phép hoàn thành so với chỉ được phép đề xuất phản ánh mô hình rộng hơn này: quyền tự chủ nên được phân công theo nhiệm vụ, không nên được mặc định trên toàn cục.

Phê duyệt cũng cần có phạm vi và thời hạn. Phê duyệt cho việc “cập nhật nội dung trang đích” không nên âm thầm cho phép bổ sung một gói analytics mới. Một kế hoạch được phê duyệt hôm qua không nên tự động bao quát một khác biệt đã thay đổi đáng kể hôm nay. Giao diện phải làm cho những ranh giới đó hiển thị rõ ràng.

Bản xem trước biến việc xem xét thành kiểm tra trực tiếp

Việc xem xét mã thường dễ hơn khi mọi người có thể kiểm tra kết quả thay vì suy ra từ các tệp mã nguồn. Một bản xem trước HTML trực tiếp có thể bộc lộ khoảng cách bị hỏng, các trạng thái bị thiếu, điều khiển không thể truy cập hoặc một thay đổi ngoài ý muốn trong điều hướng mà người xem xét có thể bỏ sót trong một khác biệt dạng văn bản.

Bản xem trước không phải là bằng chứng về tính đúng đắn. Chúng nên nằm bên cạnh, chứ không thay thế, các bài kiểm thử và việc xem xét mã nguồn. Nhưng chúng tạo ra một đối tượng chung để thảo luận: người xem xét có thể chỉ vào một màn hình, trạng thái hoặc tương tác cụ thể và để lại phản hồi gắn với thay đổi được đề xuất.

Điều này đặc biệt có giá trị khi những người không chuyên cũng tham gia xem xét. Một quản lý sản phẩm có thể không đánh giá được một thay đổi framework, nhưng có thể là người phù hợp để xác nhận rằng quy trình khớp với yêu cầu. Một nhà thiết kế có thể xác thực một hồi quy trực quan. Một chuyên gia bảo mật có thể tập trung vào quyền hạn và việc xử lý dữ liệu. Không gian làm việc có tác tử hỗ trợ có thể chuyển từng câu hỏi tới người phù hợp nhất để trả lời.

Khác biệt cần có bối cảnh, không chỉ màu sắc

Một khác biệt đỏ-xanh lá quen thuộc vẫn rất cần thiết, nhưng các thay đổi do tác tử tạo ra có thể đủ rộng để khiến người xem xét quá tải. Các nhóm nên yêu cầu tác tử giữ cho các commit hoặc nhóm thay đổi có phạm vi hẹp, giải thích lý do mỗi tệp quan trọng bị thay đổi và xác định riêng các tệp được tạo ra hoặc tệp của nhà cung cấp.

Các câu hỏi gợi ý hữu ích khi rà soát bao gồm:

  • Hành vi mà người dùng nhìn thấy đã thay đổi như thế nào?
  • Những tệp nào chỉ được thay đổi để hỗ trợ việc triển khai?
  • Tác nhân đã đưa ra những giả định nào về hành vi hiện có?
  • Những bài kiểm thử nào đã được thêm, chỉnh sửa hoặc chưa được chạy?
  • Thay đổi này có thể ảnh hưởng đến quyền hạn, việc lưu giữ dữ liệu, thanh toán hoặc các API bên ngoài không?

Những câu hỏi này biến việc rà soát từ một yêu cầu mơ hồ kiểu “xem qua giúp tôi” thành một cuộc kiểm tra có thể lặp lại. Chúng cũng giúp phơi bày một chế độ thất bại phổ biến: một tính năng có vẻ hợp lý đi kèm với việc cập nhật kiểm thử chưa đầy đủ hoặc một thay đổi cấu hình ngoài ý muốn.

Lưu trữ những phần lý luận quan trọng

Việc bảo toàn mọi token trong mọi cuộc trò chuyện với mô hình không tự động mang lại ích lợi. Lịch sử dài có thể tốn kém khi lưu trữ và khó tìm kiếm, trong khi các nghiên cứu về việc rút gọn ngữ cảnh cảnh báo rằng bản tóm tắt có thể làm mất thông tin quan trọng. Vì vậy, một dấu vết kiểm toán thực tế nên bảo toàn các hiện vật liên quan đến quyết định thay vì lưu indiscriminately mọi thứ.

Tối thiểu, hãy lưu giữ yêu cầu, kế hoạch đã được phê duyệt, diff cuối cùng, kết quả của công cụ và bài kiểm thử, tham chiếu đến bản xem trước hoặc triển khai, các quyết định của người rà soát và mọi ngoại lệ được cấp. Nếu một tác nhân sử dụng các nguồn bên ngoài hoặc truy xuất tài liệu nội bộ, hãy ghi lại các tham chiếu nguồn liên quan và thời điểm chúng góp phần định hướng thay đổi. Đối với công việc có rủi ro cao, việc lưu giữ toàn bộ nhật ký tương tác và thực thi có thể là chính đáng.

Hãy khiến hồ sơ có thể phát hiện việc bị sửa đổi ở mức phù hợp với mức độ quan trọng, và xác định các quy tắc lưu giữ trước khi khủng hoảng xảy ra. Một dấu vết kiểm toán biến mất khi một kênh được lưu trữ—hoặc không thể phân biệt kết quả đã sửa đổi với bản gốc—sẽ không thể hỗ trợ một cuộc điều tra nghiêm túc.

Điều này thay đổi nghề nghiệp phần mềm như thế nào

Kỹ năng đang nổi lên không chỉ đơn thuần là viết prompt tốt hơn. Đó là thiết kế công việc để một người khác có thể kiểm tra và tin cậy. Các nhà phát triển sẽ cần thành thạo việc nêu rõ tiêu chí chấp nhận, phân rã nhiệm vụ, rà soát diff ở quy mô lớn, xây dựng các bài kiểm thử có ý nghĩa và quyết định thời điểm tác nhân phải dừng lại để hỏi.

Các chuyên gia sản phẩm và thiết kế sẽ đóng vai trò lớn hơn trong việc rà soát bản xem trước và làm rõ ý định. Kỹ sư QA có thể giúp xác định các cổng phê duyệt và các trường hợp thất bại. Các quản lý kỹ thuật sẽ cần đo lường năng suất mà không khuyến khích việc chấp nhận rủi ro không nhìn thấy. Những người viết tài liệu kỹ thuật và các chuyên gia vận hành có thể đóng góp bằng cách khiến các quyết định, ngoại lệ và runbook trở nên bền vững.

Một bài tập hữu ích là chọn một tính năng thường lệ và lập bản đồ chuỗi bằng chứng của nó: yêu cầu, kế hoạch, nhánh, diff, bài kiểm thử, bản xem trước, phê duyệt, phát hành và khôi phục. Sau đó hãy hỏi xem đồng đội tương lai sẽ buộc phải đoán ở đâu. Mỗi phỏng đoán là một ứng viên cho một workspace tốt hơn, một quyền hạn rõ ràng hơn hoặc một hồ sơ bền vững hơn.

Một quy tắc vận hành đơn giản

Hãy để các tác nhân di chuyển nhanh trong một phạm vi hiển thị và có thể đảo ngược. Cung cấp cho chúng một workspace được xác định rõ, hạn chế các hành động nhạy cảm, yêu cầu phê duyệt tại những ranh giới có ý nghĩa, đính kèm bằng chứng vào thay đổi và lưu giữ quyết định cuối cùng. Mục tiêu không phải là làm chậm tự động hóa cho đến khi nó giống với việc viết mã thủ công. Mục tiêu là khiến tốc độ tương thích với trách nhiệm giải trình.

Trong quá trình phát triển có sự hỗ trợ của tác nhân, cộng tác viên tốt nhất không phải là hệ thống tạo ra nhiều mã nhất một cách biệt lập. Đó là hệ thống có công việc có thể được hiểu, chất vấn, phê duyệt, hoàn tác và rút kinh nghiệm.