AI tác tử cần nhiều người kiểm thử hơn, chứ không phải ít hơn

AI tác tử đang viết lại cách phần mềm được phát hành. Trợ lý soạn bản yêu cầu hợp nhất (pull request), tác tử mở các yêu cầu chuyển đổi, còn bot rà soát tuyên bố một thay đổi là an toàn trước cả khi con người kịp uống xong cà phê. Ngành công nghiệp thường xem đây là con đường giúp giảm nhân sự làm công tác chất lượng. Cách nhìn đó hoàn toàn ngược lại. Khi máy móc viết ngày càng nhiều mã nguồn, kỹ năng khan hiếm không phải là tạo mã. Đó là kiểm chứng độc lập.

Khảo sát Nhà phát triển Stack Overflow năm 2025 cho thấy 84% người trả lời đang sử dụng hoặc dự định sử dụng công cụ AI trong quá trình phát triển, và 51% nhà phát triển chuyên nghiệp sử dụng chúng hằng ngày. Tỷ lệ có quan điểm tích cực giảm còn 60%; số nhà phát triển chủ động không tin vào độ chính xác của AI (46%) cao hơn số người tin tưởng (33%). Điều khiến nhiều người bức xúc nhất, được 66% nêu ra, là các giải pháp gần đúng nhưng vẫn chưa chính xác. Nghiên cứu DORA năm 2025 của Google Cloud cho biết tỷ lệ ứng dụng AI trong giới chuyên môn phát triển phần mềm là 90%, trong đó hơn 80% nói rằng AI cải thiện năng suất, nhưng chỉ 24% cho biết họ rất tin tưởng hoặc tin tưởng AI ở mức cao. Có ích nhưng không đáng tin chính là điều kiện khiến công việc của người kiểm thử mở rộng, chứ không thu hẹp.

Tốc độ không phải là bằng chứng

Tôi là Kỹ sư Chất lượng Phần mềm, tập trung vào kiểm thử tác tử và các cổng kiểm soát CI cho mã do AI viết. Trong nội bộ, chúng tôi đã triển khai một công cụ rà soát PR và một công cụ tạo trường hợp kiểm thử. Cả hai đều chỉ tạo bản nháp. Không công cụ nào tự chấm bài của mình. Quy tắc đó rất quan trọng vì các tác tử luôn nói năng đầy chắc chắn. Chắc chắn không đồng nghĩa với chính xác.

Chúng tôi đã phải trả giá đắt để rút ra bài học đó. Trong một đợt thử nghiệm công cụ rà soát PR do AI xây dựng, một thay đổi vượt qua CI trong chưa đầy 4 phút. Hai ngày sau, một bảng thông tin ở khâu tiếp theo hiển thị những mức nhiệt độ vô lý. Một lỗi đảo chiều quy đổi từ độ C sang độ F nằm trên một nhánh mã mà bộ kiểm thử chưa bao giờ chạy qua. Pipeline vẫn báo xanh. Sản phẩm lại sai. CI xanh mà không đặt ra câu hỏi khó thì chỉ là màn trình diễn.

Sự cố đó nằm trong một xu hướng rộng hơn. Báo cáo Thực trạng tạo mã bằng AI so với con người của CodeRabbit phân tích 470 yêu cầu hợp nhất trên GitHub trong các dự án mã nguồn mở (320 yêu cầu do AI cùng viết, 150 yêu cầu chỉ do con người viết). Các thay đổi do AI viết tạo ra nhiều vấn đề hơn khoảng 1,7× xét tổng thể; lỗi về logic và tính chính xác phổ biến hơn 75%, còn số phát hiện liên quan đến bảo mật cao hơn tới 2,74×. Báo cáo Bảo mật mã do GenAI tạo ra năm 2026 của Veracode đã kiểm thử các mô hình qua nhiều tác vụ bảo mật và ghi nhận tỷ lệ vượt qua kiểm thử bảo mật trung bình là 56%, hầu như không thay đổi so với mức 55% trong báo cáo trước, trong khi khoảng 44% tác vụ tạo mã bằng AI đưa vào một lỗ hổng đã biết. Cú pháp gần như đã được giải quyết. Hành vi an toàn và chính xác thì chưa. Người kiểm thử là những người không đánh đồng hai điều đó.

Các gói phụ thuộc ảo là vấn đề kiểm thử

Việc tạo mã cũng có thể bịa ra các gói phụ thuộc. Nghiên cứu tại USENIX Security 2025, Chúng tôi có gói dành cho bạn!, đánh giá hiện tượng ảo giác về tên gói trên 16 mô hình ngôn ngữ lớn tạo mã và 576.000 mẫu. Trung bình, các mô hình thương mại bịa ra tên gói trong ít nhất 5,2% số lần; tỷ lệ trung bình của các mô hình mã nguồn mở là 21,7%, với 205.474 tên bịa khác nhau. Những gói ảo dai dẳng tạo cơ hội sẵn có cho hành vi chiếm dụng tên gói bịa: kẻ tấn công đăng ký tên được bịa ra rồi chờ nhà phát triển hoặc tác tử cài đặt gói đó.

Các bước kiểm tra nguồn gốc của gói phụ thuộc cần được xếp cùng cấp với kiểm thử chức năng. Nếu tác tử bịa ra một gói NuGet hoặc npm, quy trình hợp nhất phải thất bại trước khi có ai tranh luận liệu các bài kiểm thử đơn vị đã đủ kỹ lưỡng hay chưa. Xác minh nguồn gốc không phải là việc vệ sinh tùy chọn. Đó là một cổng kiểm soát chất lượng đối với các thay đổi do AI viết.

Các cổng kiểm soát có thể mở rộng theo số lượng tác tử

Khi chúng tôi triển khai nâng cấp trên toàn tổ chức từ .NET 8 lên .NET 10 trong khoảng hai tuần bằng tự động hóa có AI hỗ trợ, tôi phụ trách các cổng kiểm soát chất lượng. Tốc độ đạt được là có thật. Nhu cầu về những bước kiểm tra không tin ngay vào bản tóm tắt của tác tử cũng vậy. Các cổng kiểm soát tôi áp dụng cho mã được thay đổi bao gồm:

• Đặt mục tiêu điểm đột biến trong khoảng 60% đến 70% đối với phần logic được chỉnh sửa, để bộ kiểm thử phải phát hiện được các đột biến thực sự thay vì chỉ bao phủ các dòng mã
• Kiểm thử dựa trên thuộc tính cho phần logic có rủi ro cao, nơi chỉ dùng ví dụ thì chưa đặc tả đầy đủ hành vi
• Kiểm tra nguồn gốc của gói phụ thuộc để ngăn chặn hành vi chiếm dụng tên gói bịa và các gói bị ảo giác tạo ra
• Các tín hiệu về trùng lặp và biến động mã để phát hiện tình trạng tác tử liên tục sao chép rồi chỉnh sửa
• Kiểm chứng độc lập các tuyên bố của tác tử, chẳng hạn như “đã hoàn tất chuyển đổi”, vì một tuyên bố chỉ là giả thuyết cho đến khi có bằng chứng

Điểm đột biến không phải là chỉ số phù phiếm. Nó cho biết liệu các bài kiểm thử có phát hiện được một lỗi được cố ý đưa vào hay không. Độ bao phủ có thể tăng trong khi bộ kiểm thử vẫn bỏ sót nhánh chuyển đổi từ độ C sang độ F. Kiểm thử dựa trên thuộc tính buộc mô hình của hệ thống phải đúng trong cả một dải giá trị, chứ không chỉ trên một luồng xử lý thuận lợi. Kiểm tra nguồn gốc giúp khóa chặt kho chứa các gói. Các tín hiệu về biến động và trùng lặp giúp phát hiện thói quen viết lại cùng một ý theo ba cách của tác tử. Kết hợp lại, chúng tạo nên một nguyên tắc: cứ cho rằng tác tử sai cho đến khi bộ kiểm thử chứng minh điều ngược lại. Tôi luôn giữ nguyên tắc hiệu chỉnh đó trong quá trình rà soát.

Không điều nào trong số này thay thế việc kiểm thử API, kiểm thử xác thực, kiểm thử nhanh smoke hay tự động hóa giao diện người dùng. FlaUI và PowerShell vẫn phát hiện được những gì API bỏ sót. Việc đóng gói bằng NuGet, MSI và MSM vẫn cần được kiểm tra quy trình cài đặt và cài đặt im lặng. Quy trình làm việc với AI tác tử làm tăng khối lượng công việc. Chúng không khiến những lĩnh vực chuyên môn đó trở nên lỗi thời.

Nhiều người kiểm thử hơn, công việc khác đi

Nỗi lo là các tác tử sẽ viết bài kiểm thử, khiến con người trở nên không còn cần thiết. Tác tử có thể soạn các trường hợp kiểm thử. Nhưng chúng không nên tự chứng nhận những bản nháp của mình. Những người trả lời khảo sát của Stack Overflow, dù dự định sẽ dùng AI để kiểm thử trong tương lai, vẫn xem sự thiếu tin tưởng của con người là vấn đề cốt lõi: lý do hàng đầu khiến họ tìm người khác giúp đỡ là không tin vào câu trả lời của AI. Bản năng ấy chính là thế mạnh của nghề này.

Việc tuyển dụng và tạo điều kiện cho những người đi lên từ các con đường khác thường rất quan trọng trong lĩnh vực này. Tôi chuyển sang làm về chất lượng sau khi có sự nghiệp trong mảng vận hành nhân sự và dữ liệu, hoàn thành bằng thạc sĩ ngành Hệ thống thông tin tại UMBC vào tháng 5 năm 2024, và hiện dành cả ngày để biến các cổng kiểm soát dành cho AI tác tử thành giải pháp thiết thực. AI tác tử sẽ không chờ đợi những người chỉ có một lộ trình nghề nghiệp duy nhất. Lĩnh vực này cần thêm người có thể thiết kế bằng chứng, chứ không phải ít đi những người chỉ đóng dấu thông qua cho các bản dựng báo xanh.

Câu hỏi về sản phẩm rất đơn giản. Nếu các tác tử phát hành nhanh hơn khả năng suy xét của quy trình kiểm chứng, thì đó không phải là lợi ích về năng suất. Đó là một sự cố chỉ bị trì hoãn. Hãy đầu tư vào những người kiểm thử luôn xem mọi khẳng định của tác tử là đáng ngờ, tích hợp kiểm thử đột biến và khả năng truy xuất nguồn gốc vào CI, đồng thời duy trì phán đoán độc lập ở những điểm mô hình trôi chảy nhất nhưng cũng kém đáng tin cậy nhất. AI tác tử cần thêm người kiểm thử, chứ không phải ít đi.