Tác tử trí tuệ nhân tạo tạo ra thay đổi nhanh hơn khả năng kiểm chứng của đội kỹ thuật. Điều này tạo nên khoảng trống niềm tin vào mã nguồn. Thu hẹp khoảng trống đòi hỏi bốn thành phần: ý định rõ ràng, rào chắn cụ thể, xác minh độc lập và bằng chứng có thể truy xuất.
Trí tuệ nhân tạo đã thay đổi chi phí và tốc độ làm phần mềm. Một công việc từng mất hàng giờ để triển khai giờ có thể bắt đầu bằng lời giải do tác tử tạo ra trong vài phút. Tác tử cũng đang nhận những nhiệm vụ rộng hơn. Chúng có thể sửa mã trên toàn kho, tái cấu trúc dịch vụ, viết kiểm thử và chuẩn bị yêu cầu hợp nhất mã. Vì vậy, lượng mã được tạo ra sẽ tiếp tục tăng.
Theo bài viết gốc của The New Stack về khoảng trống niềm tin vào mã nguồn, thách thức tiếp theo không còn là tạo thêm mã. Các tổ chức kỹ thuật phải xác lập niềm tin vào phần mã sẽ được đưa vào vận hành. Trong một nhà máy phần mềm dùng tác tử, máy có thể viết, kiểm thử và đề xuất thay đổi nhanh hơn tốc độ con người đọc từng dòng.
Mã nguồn đang trở nên dồi dào, còn niềm tin vào mã thì không.
Yêu cầu hợp nhất mã chưa phải là kết quả đáng tin cậy
Một yêu cầu hợp nhất mã đã hoàn thành chỉ cho biết thay đổi đã đi qua một phần quy trình. Để trở thành kết quả đáng tin cậy, thay đổi còn phải phù hợp với kiến trúc, yêu cầu bảo mật, tiêu chuẩn bảo trì và những điều kiện vận hành của tổ chức.
Nội dung kiểm chứng cần bao phủ
Mã có thể biên dịch thành công và vượt qua một bộ kiểm thử hẹp. Tuy vậy, mã vẫn có thể vi phạm quy ước kiến trúc hoặc tạo ra điểm yếu bảo mật. Nó cũng có thể lặp lại chức năng đã tồn tại hoặc để lại chi phí bảo trì chỉ xuất hiện về sau.
Tốc độ thay đổi càng cao, đội kỹ thuật càng khó dựa vào nỗ lực cá nhân và rà soát thủ công để phát hiện mọi vấn đề. Vì thế, tranh luận về việc trí tuệ nhân tạo làm thay đổi hoạt động rà soát mã không chỉ xoay quanh năng suất. Vấn đề quan trọng hơn là cơ sở để tổ chức tin rằng thay đổi đủ an toàn.
Niềm tin vào mã cần được thiết kế ngay trong hệ thống chuyển giao phần mềm. The New Stack tóm tắt cách tiếp cận này bằng công thức:
“Ý định × Rào chắn × Xác minh × Bằng chứng.”
The New Stack, bài viết về khoảng trống niềm tin vào mã nguồn
Dấu nhân có chủ ý vì cả bốn thành phần đều cần thiết. Sức mạnh của ba phần không thể bù cho điểm yếu của phần còn lại.
Bốn thành phần phụ thuộc lẫn nhau
Ý định rõ nhưng thiếu xác minh không ngăn được sai sót. Xác minh mạnh nhưng không có bằng chứng không tạo ra trách nhiệm giải trình. Rào chắn thiếu ý định rõ ràng chỉ tự động hóa sự mơ hồ. Bằng chứng không đi cùng xác minh độc lập chỉ ghi lại điều tác tử tự tuyên bố.
Ý định phải biến tiêu chuẩn thành yêu cầu rõ ràng
Ý định là tập hợp các mục tiêu, tiêu chuẩn và điều kiện mà tác tử phải hiểu trước khi tạo mã. Ý định rõ giúp tác tử phân biệt một lời giải có vẻ hợp lý với một thay đổi thực sự phù hợp với logic kinh doanh, kiến trúc và yêu cầu vận hành của tổ chức.
Tác tử có khả năng theo đuổi một mục tiêu đã được nêu cụ thể. Tuy nhiên, những yêu cầu như “xây dựng tính năng thanh toán” hoặc “hiện đại hóa dịch vụ này” chưa đủ cho một hệ mã nguồn dùng trong vận hành thực tế.
Định nghĩa về phần mềm tốt của một tổ chức bao gồm nhiều yêu cầu. Trong đó có logic kinh doanh, bảo mật, mẫu thiết kế, hiệu năng, quan hệ phụ thuộc và các quy ước kỹ thuật tích lũy qua nhiều năm. Ý định đưa những kỳ vọng đó thành điều kiện rõ ràng trước khi tác tử bắt đầu.
Bối cảnh càng đầy đủ, tác tử càng ít tạo ra những lời giải có vẻ hợp lý nhưng không phù hợp. Nhờ đó, lập trình viên cũng bớt phải sửa lại về sau. Cách một tác tử viết mã tiếp nhận mục tiêu và thực hiện công việc vì vậy cần được xem cùng với tiêu chuẩn nội bộ mà nó phải tuân thủ.
Rào chắn định hình công việc trước khi rủi ro xuất hiện
Rào chắn chuyển ý định thành giới hạn có thể áp dụng trong quá trình tác tử làm việc. Chúng xác định phạm vi và tài nguyên được phép sử dụng. Rào chắn cũng quy định chính sách phải tuân thủ và những quyết định cần con người phê duyệt trước khi quy trình tiếp tục.
Rào chắn có thể xác định kho mã, quan hệ phụ thuộc, dữ liệu hoặc thao tác nào được phép sử dụng, vị trí nào cần con người phê duyệt và chính sách nào áp dụng cho từng nhóm mã.
Mục tiêu không phải là ngăn cản mọi hành động hữu ích. Rào chắn tạo đủ cấu trúc để tác tử làm việc có năng suất và có thể dự đoán. Khi các điều kiện áp dụng quyền tự chủ đã rõ, đội kỹ thuật có thể giao thêm quyền cho tác tử mà không biến mỗi thay đổi thành một thử nghiệm riêng lẻ.
Kết quả cần hướng tới là quyền tự chủ có thể lặp lại. Các đội áp dụng cùng một hệ giới hạn cho nhiều thay đổi, rồi mở rộng hoạt động phát triển bằng tác tử trên nền tảng đã được kiểm soát.
Xác minh phải độc lập với bên tạo ra thay đổi
Xác minh độc lập đánh giá thay đổi bằng một cơ chế khác với hệ thống đã tạo ra thay đổi đó. Cách tách biệt này giúp đội kỹ thuật áp dụng một chuẩn kiểm tra nhất quán cho tính đúng đắn, độ tin cậy, bảo mật, khả năng bảo trì và mức độ tuân thủ.
Một mô hình có thể hỗ trợ rà soát công việc do chính nó tạo ra. Tuy nhiên, tổ chức không nên chỉ dựa vào cùng hệ thống xác suất đó để quyết định thay đổi có đủ an toàn để phát hành hay không. Các bước kiểm tra độc lập và có thể lặp lại tạo ra một chuẩn chung giữa nhiều mô hình, tác tử và chuỗi công cụ. Điều này càng cần thiết khi công cụ trí tuệ nhân tạo thay đổi nhanh.
Xác minh cũng phải diễn ra ngay trong luồng công việc thay vì trở thành cửa kiểm tra chậm chạp ở cuối quy trình. Vấn đề nên được phát hiện và sửa tại nơi phát sinh, khi tác tử hoặc lập trình viên vẫn còn đủ bối cảnh để xử lý.
Với những đội tiếp nhận lượng thay đổi lớn, năng lực kiểm tra phải tăng cùng năng lực tạo mã. Việc xác minh yêu cầu hợp nhất mã ở quy mô lớn cần dựa trên các bước kiểm tra độc lập, nhất quán và diễn ra ngay trong luồng công việc.
Bằng chứng khiến niềm tin trở nên hữu hình
Bằng chứng là hồ sơ bền vững về tiêu chuẩn đã áp dụng, nội dung đã kiểm tra, vấn đề được phát hiện và cách vấn đề được giải quyết. Hồ sơ này giúp đội kỹ thuật giải thích vì sao một thay đổi được chấp nhận thay vì chỉ khẳng định rằng quy trình đã hoàn tất.
Một thay đổi có thể xuất phát từ ý định đúng, tuân theo rào chắn và đã được kiểm tra kỹ. Dù vậy, lãnh đạo kỹ thuật, kiểm toán viên và đội chịu trách nhiệm vận hành vẫn cần biết chuyện gì đã xảy ra và vì sao.
Bằng chứng đặc biệt quan trọng trong môi trường phức tạp hoặc chịu quy định nghiêm ngặt. Nó vẫn có giá trị với mọi đội phát triển. Khi có bằng chứng, chất lượng có thể được đo lường. Đội kỹ thuật có dữ liệu để cải thiện cách làm theo thời gian. Tổ chức cũng có cơ sở bảo vệ quyết định triển khai nhanh của mình.
Xây nhà máy phần mềm quanh niềm tin
Một nhà máy phần mềm đáng tin cậy phân chia trách nhiệm giữa con người, tác tử và hệ thống xác minh. Tác tử đảm nhận phần thực thi. Kỹ sư đưa ra phán đoán và định hướng. Hệ thống chuyển giao áp dụng tiêu chuẩn, kiểm soát và lưu lại bằng chứng cho từng thay đổi.
Phát triển phần mềm bằng tác tử không đòi hỏi loại con người khỏi quy trình. Mỗi bên đảm nhận phần việc phù hợp với thế mạnh của mình. Cấu trúc này cho phép quyền tự chủ mở rộng mà không buộc tổ chức phải đánh đổi khả năng kiểm soát.
Khi một tác tử mở yêu cầu hợp nhất mã tiếp theo, đội kỹ thuật có thể đánh giá khoảng trống niềm tin bằng bốn câu hỏi:
- Tác tử đã biết các tiêu chuẩn của tổ chức trước khi bắt đầu chưa?
- Tác tử được phép thay đổi những gì, và quyết định nào bắt buộc phải có con người?
- Có hệ thống nào khác với mô hình tạo ra thay đổi thực hiện việc kiểm tra không?
- Đội kỹ thuật có thể chỉ ra vấn đề đã được phát hiện và cách xử lý không?
Bất cứ câu hỏi nào nhận câu trả lời “không” đều chỉ ra nơi khoảng trống niềm tin đang tồn tại. Đó là điểm cần được xử lý trước khi tổ chức mở rộng quyền tự chủ của tác tử.
Hãy dùng bốn câu hỏi này trong lần rà soát mã tiếp theo để xác định quy trình của đội đang thiếu niềm tin ở đâu.
