Giám sát con người trong phát triển phần mềm dùng AI cần chuyển từ việc chỉ rà soát mã sang kiểm chứng yêu cầu trước khi tác tử bắt đầu triển khai. Nếu mã và bài kiểm thử cùng được tạo từ một đặc tả sai, chúng có thể khớp hoàn hảo với nhau mà vẫn tạo ra kết quả trái với mục tiêu nghiệp vụ.
Phát hiện chính
Khi tác tử tạo cả mã và bài kiểm thử từ cùng một đặc tả, mọi bước kiểm soát phía sau có thể cùng xác nhận một yêu cầu sai. Theo The New Stack, giám sát của con người vì thế phải tập trung vào nơi ý định được quyết định, trước khi mã được viết.
Nội dung: Vì sao rà soát mã chưa đủ
Các cổng kiểm soát có thể xác minh mã có tuân thủ chỉ dẫn hay không, nhưng chúng không tự xác định liệu chỉ dẫn đó có đúng hay không. Khi yêu cầu sai, mã, bài kiểm thử và các bước phê duyệt vẫn có thể nhất quán.
Một quy trình phát triển phần mềm có thể trông rất chặt chẽ: cuộc họp xác định phạm vi được ghi lại, tài liệu phạm vi được chia thành từng đơn vị công việc, nhà phát triển lập đặc tả, tác tử tạo mã, hệ thống kiểm tra yêu cầu kéo, môi trường tạm thời chạy thử và bộ phận bảo đảm chất lượng xác nhận bản phát hành. Nhóm trong bài viết gốc còn phát hành đều đặn vào thứ Năm hằng tuần.
Lỗ hổng nằm ở câu hỏi mà toàn bộ hệ thống đang trả lời. Nếu yêu cầu sai, mã và bài kiểm thử vẫn có thể khớp với nhau hoàn hảo.
Đây cũng là điểm cần lưu ý khi đánh giá cách tác tử AI viết mã hoạt động. Tốc độ tạo mã không thay thế được việc xác định phần mềm phải làm gì, đặc biệt khi một lựa chọn dự phòng có thể phá vỡ mục tiêu cốt lõi của tính năng.
Một yêu cầu sai vượt qua mọi vòng rà soát
Một yêu cầu nghe có vẻ hợp lý vẫn có thể phá vỡ mục tiêu cốt lõi của hệ thống. Khi mọi bước phía sau lấy yêu cầu đó làm chuẩn, lỗi về ý định có thể vượt qua toàn bộ quy trình mà không tạo ra cảnh báo.
Ví dụ bắt đầu bằng một quy tắc dự phòng: nếu việc tra cứu phân loại không đưa ra kết luận, hệ thống coi bản ghi là được phép và tiếp tục xử lý để một dịch vụ phụ thuộc đang gián đoạn không chặn việc bàn giao.
Quy tắc này nêu một rủi ro vận hành có thật và giải thích lý do lựa chọn. Trong một tài liệu dài 40 trang, người rà soát có thể lướt qua nó chỉ trong hai giây. Tuy nhiên, tính năng liên quan được tạo ra để bảo đảm một nhóm bản ghi cụ thể không bao giờ bị xử lý theo cách đó.
“Mọi biện pháp kiểm soát đều trả lời một câu hỏi: Mã có tuân thủ chỉ dẫn hay không? Bản thân chỉ dẫn chưa bao giờ bị đưa ra xem xét.”
The New Stack
Với nhóm dữ liệu ít khi được kiểm tra thủ công, yêu cầu này trực tiếp tạo ra đúng sự cố mà tính năng phải ngăn chặn. Không bước nào ở phía sau phát hiện được vấn đề, vì tất cả đều lấy chính yêu cầu đó làm chuẩn.
Công việc đến tay tác tử như thế nào
Tác tử chỉ viết mã sau khi ý định từ cuộc họp được chuyển thành tài liệu phạm vi, đơn vị công việc và đặc tả chi tiết. Mỗi lần chuyển đổi cần giữ lại quyết định, phạm vi, phần phụ thuộc, câu hỏi mở và tiêu chí chấp nhận.
Một tính năng bắt đầu từ cuộc họp có ghi âm với mọi nhóm bị ảnh hưởng. Nếu thay đổi đi qua một dịch vụ dùng chung, cuộc họp có thể gồm bốn hoặc năm nhóm. Quản lý sản phẩm trình bày ý định, các bên tranh luận và khi một vấn đề được giải quyết, một người nói rõ kết luận để bản ghi âm lưu lại chính xác.
Từ cuộc họp đến tài liệu phạm vi
Bản ghi cuộc họp, không phải tài liệu yêu cầu ban đầu, được dùng để tạo tài liệu phạm vi. Tài liệu này chia tính năng thành các nhóm phát hành rồi thành những đơn vị được đánh số, gần tương ứng với từng phần có thể bàn giao. Mỗi đơn vị ghi mục đích, ranh giới phạm vi, yêu cầu chức năng, lớp kiến trúc, phần phụ thuộc, cờ tính năng và tiêu chí chấp nhận theo cấu trúc điều kiện, hành động và kết quả.
Sau khi quản lý sản phẩm phê duyệt, tài liệu phạm vi trở thành nguồn sự thật chính thức. Tài liệu yêu cầu ban đầu được đưa về vai trò lịch sử. Việc thay đổi nguồn sự thật này giúp kết luận tập thể trong cuộc họp có quyền ưu tiên hơn giả định của bản thảo cũ.
Từ đơn vị công việc đến đặc tả
Mỗi đơn vị sau đó được đồng bộ với hệ thống theo dõi công việc. Khi nhận một đơn vị, nhà phát triển tạo đặc tả chi tiết gồm giao diện, chữ ký phương thức, tệp cần tạo hoặc sửa, ma trận xử lý lỗi, luồng truy vấn và những việc đơn vị chủ động không làm. Các câu hỏi còn mở phải quay lại con người thay vì để người cầm bàn phím tự đoán.
Trong một trường hợp, câu hỏi về hàm khởi tạo của lớp cơ sở cho thấy tài liệu thiết kế yêu cầu một lời gọi không thể biên dịch. Lỗi thiết kế được phát hiện trước khi có bất kỳ dòng mã nào để rà soát.
Nhà phát triển tiếp tục đối chiếu đặc tả đơn vị với tài liệu phạm vi để bảo đảm mọi yêu cầu đều được bao phủ, các đơn vị không âm thầm làm trùng việc và không có nội dung nào bị mất trong quá trình chuyển đổi. Chỉ sau bước này tác tử mới viết mã.
Mã được tạo phải bao phủ toàn bộ đường gọi, từ điểm vào đến lớp dịch vụ, cùng các bài kiểm thử đơn vị và tích hợp. Sau đó là kiểm tra tiêu chuẩn cục bộ, yêu cầu kéo, nhận xét tự động, cổng đối chiếu đặc tả, môi trường tạm thời và phê duyệt của nhà phát triển thứ hai. Bộ phận bảo đảm chất lượng dùng công cụ đọc mọi phiếu công việc trong nhóm phát hành để soạn ca kiểm thử, rồi rà soát thủ công từng ca trước khi chấp nhận.
Sáu bài kiểm thử vẫn xác nhận một kết quả sai
Sáu bài kiểm thử đều có thể đạt dù hệ thống vi phạm mục tiêu cốt lõi. Nguyên nhân là phần triển khai và bài kiểm thử cùng tuân theo một tiêu chí chấp nhận sai.
Thử nghiệm với hệ thống gửi thông báo
Tác giả dựng lại lỗi trong một hệ thống gửi thông báo có xét trạng thái đồng ý. Hệ thống có sáu tiêu chí chấp nhận, với kết quả cốt lõi là không bao giờ gửi thông báo cho người đã rút lại sự đồng ý.
Tiêu chí AC-05 cố ý chứa lỗi: khi việc tra cứu không đưa ra kết luận, người nhận được coi là đã đồng ý và thông báo vẫn được gửi để dịch vụ tra cứu gián đoạn không chặn quá trình bàn giao. Phần triển khai làm đúng điều đó. Bài kiểm thử cũng bắt nguồn từ chính AC-05 nên xác nhận rằng thông báo phải được gửi.
Theo kết quả được The New Stack công bố, trên Python 3.14.3 và pytest 9.1.1, cả sáu bài kiểm thử đều đạt trong 0,01 giây. Công cụ truy vết cũng xác nhận đủ sáu tiêu chí, không có cảnh báo và kết thúc bình thường.
Đèn xanh này không chứng minh hệ thống bảo vệ đúng kết quả. Khi dịch vụ xác nhận sự đồng ý không thể truy cập đối với Grace, người đã rút lại sự đồng ý, hệ thống quan sát trạng thái chưa xác định rồi vẫn gửi thông báo. Kết quả có một lần vi phạm mục tiêu, dù mọi cổng tự động đều chấp thuận.
Bài kiểm thử không sai khi so với AC-05. Nó kiểm tra chính xác một quy tắc sai. Đây là lý do tranh luận về AI và rà soát mã không thể chỉ dừng ở chất lượng của phần chênh lệch mã.
Vì sao các hàng rào bảo vệ cùng bỏ sót
Mã, bài kiểm thử và các cổng tuân thủ cùng phụ thuộc vào tiêu chí chấp nhận. Sự đồng thuận giữa chúng chứng minh tính nhất quán với đặc tả, không chứng minh đặc tả đúng.
Kiểm tra tiêu chuẩn so mã với quy ước. Người rà soát đối chiếu phần thay đổi với đặc tả. Bài kiểm thử so hành vi với tiêu chí. Cổng tuân thủ kiểm tra thay đổi theo đặc tả. Các ca kiểm thử bảo đảm chất lượng lại xuất phát từ phiếu công việc do đặc tả tạo ra.
Mỗi cơ chế đều có giá trị. Kiểm tra tiêu chuẩn ngăn tác tử tạo thêm một cách triển khai không cần thiết. Người rà soát tự động tìm được lỗi và trường hợp biên. Nhà phát triển thứ hai phát hiện ý định diễn đạt kém. Bài kiểm thử bắt hồi quy, còn môi trường tạm thời phát hiện lỗi tích hợp.
“Hãy đưa cho tất cả các cơ chế ấy một đặc tả sai, chúng sẽ đồng thuận với nhau một cách hoàn hảo, vì không thành phần nào trong hệ thống giữ một ý kiến phản biện.”
The New Stack
Vấn đề không thuộc về riêng từng hàng rào. Đó là đặc tính kiến trúc của cả hệ thống: mọi phép so sánh đều diễn ra sau đặc tả và đều coi đặc tả là đúng.
Hai phần còn thiếu trong tài liệu phạm vi
Tài liệu phạm vi cần ghi riêng các câu hỏi chưa được quyết định và những điểm mà nhóm đã bác bỏ trong tài liệu yêu cầu ban đầu. Hai phần này ngăn tác tử tự lấp khoảng trống và giữ lại lý do đằng sau quyết định tập thể.
Phần thứ nhất ghi những nội dung được chủ động để ngỏ và chỉ định một người phụ trách cho từng nội dung. Danh sách này đóng vai trò hàng rào: chưa có quyết định, chưa ai được quyền tự kết luận và tác tử sẽ vượt quyền nếu âm thầm lấp khoảng trống.
Phần thứ hai ghi lại những điểm mà tài liệu yêu cầu ban đầu không được chấp nhận. Mỗi hàng thể hiện một bất đồng giữa bản thảo trước cuộc họp và kết luận cuối cùng của tập thể, kèm quyết định cùng lý do. Chính tại đây, phương án mặc định coi trạng thái chưa xác định là được phép đã bị loại bỏ vì nó phá hủy bảo đảm cốt lõi của hệ thống.
Khi một cuộc tranh luận kỹ thuật dài đi đến kết luận, một người cần nói rõ quyết định để bản ghi âm thu lại. Ba mươi giây này giữ cho quyết định tồn tại sau cuộc họp. Nếu kết luận chỉ nằm trong trí nhớ của sáu người, tác tử đọc tài liệu vào tuần sau sẽ không thể biết nó.
Biến tiêu chí thành bề mặt rà soát
Tiêu chí chấp nhận phải trở thành bề mặt rà soát chính của con người vì đây là nguồn chung của mã và bài kiểm thử. Cổng truy vết có thể kiểm tra mức độ bao phủ, nhưng con người vẫn phải xác minh logic của từng tiêu chí.
Cổng truy vết xác minh mỗi tiêu chí có một bài kiểm thử nhận trách nhiệm kiểm tra và mỗi khai báo trong bài kiểm thử trỏ tới một tiêu chí có thật. Cách làm này đã được phần mềm chịu quản lý sử dụng nhiều năm, trong đó có công cụ jamb với hồ sơ thiết bị y tế theo IEC 62304.
Điểm thay đổi nằm ở vai trò của ma trận truy vết. Trong hồ sơ pháp lý, ma trận phục vụ kiểm toán viên. Trong quy trình dùng AI, một yêu cầu có thể sinh cả phần triển khai lẫn bài kiểm thử. Hai phần này đồng thuận là điều được bảo đảm từ đầu, nên sự đồng thuận không chứng minh tính đúng đắn.
Kịch bản truy vết trong ví dụ dài 100 dòng, trong đó 25 dòng đầu là phần mô tả giới hạn. Nó duyệt cây cú pháp thay vì tìm chuỗi văn bản, nhờ vậy mã tiêu chí nằm trong chú thích không bị tính nhầm là đã có kiểm thử. Lần chạy đầu tiên phát hiện AC-04 chưa có bài kiểm thử, dù chính tác giả viết bộ kiểm thử và chỉ đơn giản quên mất trường hợp này. Phép kiểm tra hoàn tất trong chưa đầy một giây.
Hai dòng cấu hình làm thay đổi cổng kiểm soát
Một quy ước truy vết chỉ trở thành cổng bắt buộc khi lỗi cấu hình hoặc lỗi chính tả khiến lần chạy thất bại. Nếu sai sót chỉ tạo cảnh báo, bộ kiểm thử vẫn có thể chuyển sang màu xanh.
Lần chạy đầu tạo cảnh báo về dấu đánh dấu chưa đăng ký năm lần, tương ứng với năm dấu được viết đúng. Khi một lỗi chính tả thật sự xuất hiện, cảnh báo của nó chìm giữa các cảnh báo hợp lệ, khiến tín hiệu gần như vô dụng.
Đăng ký dấu đánh dấu và bật chế độ kiểm tra nghiêm ngặt biến lỗi chính tả thành lỗi thu thập với mã thoát 2, đồng thời dừng lần chạy. Chỉ hai dòng cấu hình khiến quy ước truy vết trở thành một cổng bắt buộc thay vì phần trang trí.
Sự cố pytest số 14442 cho thấy chế độ nghiêm ngặt đặt qua tùy chọn bổ sung từng âm thầm ngừng hoạt động trong chuỗi phiên bản 9.0. Lỗi bị hạ thành cảnh báo, bộ kiểm thử chuyển sang màu xanh và không có thông báo rõ ràng về sự suy giảm. Lỗi này đã được sửa, nhưng bài học vẫn còn: cần có một phép kiểm thử cấp cao xác nhận cổng kiểm soát thực sự thất bại khi gặp trường hợp phải chặn.
Những thực hành kỹ thuật phải gánh trách nhiệm
Quy trình cần lưu lại nơi quyết định được đưa ra, ai chịu trách nhiệm cho câu hỏi mở và lý do nhóm bác bỏ một giả định ban đầu. Các hồ sơ này giúp con người kiểm chứng ý định trước khi tác tử chuyển nó thành mã.
- Đặt hồ sơ bền vững tại nơi nhiều người cùng ra quyết định. Tài liệu do một người viết chỉ phản ánh hiểu biết của người đó tại một thời điểm; kết luận được nói rõ trong cuộc họp lưu lại sự đồng thuận thực tế.
- Ghi những điều chưa quyết định và chỉ định người phụ trách. Câu hỏi mở có chủ sở hữu biến phần thiếu của yêu cầu thành trách nhiệm rõ ràng của con người.
- Lưu lại nơi bản thảo ban đầu thua trong tranh luận. Bảng bất đồng cho người không dự họp thấy sự khác biệt giữa giả định ban đầu và kết luận cuối cùng.
- Rà soát đặc tả theo tài liệu nguồn trước khi viết mã. Rà soát phần chênh lệch mã diễn ra sau khi những lựa chọn kiến trúc tốn kém đã được đưa vào hệ thống.
- Làm cho tiêu chí có thể được máy kiểm tra. Đăng ký dấu đánh dấu kiểm thử và tạo phép kiểm tra xác nhận cổng sẽ chặn khi cần.
Việc phát hành hằng tuần là kết quả của các thực hành này, không phải chỉ tiêu được áp đặt tùy ý. Nhóm có thể phát hành vào mỗi thứ Năm vì các tranh luận kiến trúc đã diễn ra ngay trong tuần đầu, có ghi lại và có mặt mọi nhóm chịu ảnh hưởng.
Những biện pháp không giải quyết được lỗi gốc
Cho tác tử đặt câu hỏi, thêm người rà soát hoặc tạo đặc tả dài hơn không giải quyết được lỗi nếu tất cả vẫn dựa trên cùng một yêu cầu sai. Các biện pháp này hữu ích, nhưng không thay thế việc con người xác minh mục tiêu và tiêu chí.
Đặt câu hỏi không phải là biện pháp kiểm soát chính
Theo nghiên cứu của Su và Cardie tại Cornell trên 10 mô hình và 1.000 câu hỏi mơ hồ, khi được yêu cầu đánh giá độ mơ hồ, các mô hình thành công từ 60% đến 80%. Khi phản hồi tự nhiên, chúng đưa ra câu trả lời dứt khoát trong hơn 95% trường hợp. Cũng theo nghiên cứu này, dòng mô hình Claude chỉ đánh dấu khoảng một câu mơ hồ trong 20 câu.
Nghiên cứu này còn ghi nhận rằng bổ sung ngữ cảnh truy xuất làm tỷ lệ yêu cầu làm rõ giảm xuống. Một đặc tả dày hơn và được tổ chức tốt hơn có thể làm mô hình tự tin hơn, nhưng không nhất thiết khiến nó thận trọng hơn.
Theo nghiên cứu của một nhóm tại Carnegie Mellon về cách tác tử đặt câu hỏi cho bên trung gian nắm toàn bộ nội dung công việc, tác tử tốt nhất khôi phục được 80% điểm số so với trường hợp yêu cầu đầy đủ, còn mô hình yếu hơn chỉ đạt 54%. Nghiên cứu này cũng ghi nhận vẫn có một phần năm ngữ cảnh bị mất. Quan trọng hơn, bên trung gian trong thử nghiệm luôn biết đáp án đúng, trong khi điều kiện này không tồn tại nếu chính yêu cầu là lỗi.
Thêm một người hoặc một tác tử rà soát ở cùng tầng cũng không đổi được câu hỏi. Khi yêu cầu sai, người thứ hai có thể chỉ đồng ý với người thứ nhất dựa trên cùng một tiêu chuẩn.
Chi phí của quy trình đầy đủ
Chi phí quy trình là phản biện có cơ sở hơn. Theo thử nghiệm của Colin Eberhardt tại Scott Logic, việc xây dựng lại một tính năng bằng quy trình đầy đủ dựa trên đặc tả mất thời gian gấp khoảng 10 lần cách làm thường lệ. Ông dành ba giờ rưỡi để rà soát 2.577 dòng Markdown nhằm tạo ra 689 dòng mã. Quy trình này vì thế được bỏ qua đối với những bản sửa đơn giản chỉ gồm hai dòng.
Tuy nhiên, đặc tả trong trường hợp đó được tạo từ lời nhắc của một người. Tài liệu sinh hoàn toàn từ giả định của một cá nhân thường chỉ phản chiếu chính các giả định ấy. Quy trình đáng giá khi nhiều kỹ sư mang tới những cách hiểu xung đột và phải giải quyết chúng theo cách bản ghi có thể giữ lại lý do.
Giới hạn của truy vết
Cổng truy vết chỉ xác nhận rằng một bài kiểm thử tuyên bố kiểm tra tiêu chí. Nó không thể xác định bài kiểm thử có thực sự kiểm tra hành vi có ý nghĩa hay không.
Để chứng minh giới hạn này, tác giả tạo sáu bài kiểm thử chỉ chứa một khẳng định luôn đúng rồi gán mỗi bài cho một tiêu chí. Cả sáu bài đều đạt. Công cụ truy vết cũng báo đủ sáu tiêu chí và kết thúc với mã 0. Hai cổng được thỏa mãn hoàn toàn bởi một tệp không kiểm tra bất kỳ hành vi có ý nghĩa nào.
Rà soát không biến mất, nó chuyển vị trí
Giám sát con người vẫn cần thiết, nhưng trọng tâm chuyển từ phần chênh lệch mã sang các quyết định và tiêu chí xác định phần mềm phải làm gì. Phạm vi rà soát nhỏ hơn, còn trách nhiệm về ý định vẫn thuộc về con người.
Quy trình mới chuyển sự chú ý từ việc đọc phần chênh lệch dài 600 dòng sang việc đọc sáu tuyên bố được đánh số và xác minh logic bên dưới từng tuyên bố.
Trong bối cảnh vai trò kỹ sư đang thay đổi trong thời AI, giá trị của kỹ sư không chỉ nằm ở số dòng mã trực tiếp viết ra. Phần quyết định kết quả là xác định phần mềm phải làm gì, ghi rõ ai đã đưa ra quyết định và kiểm chứng rằng các tiêu chí thực sự bảo vệ mục tiêu.
“Nếu tài liệu sai, tất cả sẽ đồng ý với bạn, với tốc độ chớp mắt, mãi mãi.”
The New Stack
Hãy bắt đầu bằng việc chọn một đặc tả sắp triển khai và yêu cầu người hiểu mục tiêu nghiệp vụ kiểm tra từng tiêu chí trước khi giao nó cho tác tử.
