AI agents phát triển phần mềm: tăng tốc giao hàng, phình to rủi ro
AI agents phát triển phần mềm là các tác tử tự động có khả năng nhận mục tiêu, quyết định cách thực hiện, sử dụng công cụ, quan sát kết quả và điều chỉnh hành động tiếp theo trong toàn bộ vòng đời phát triển phần mềm, từ viết mã, mở pull request đến hỗ trợ kiểm thử và triển khai ở tốc độ vượt xa khả năng xử lý thủ công của con người. Đây chính là lý do cốt lõi khiến chúng ta cần nhiều người kiểm thử hơn, chứ không phải ít hơn. Khi AI tác tử đang viết lại cách phần mềm được phát hành, trợ lý soạn pull request, tác tử mở yêu cầu chuyển đổi, bot rà soát tuyên bố thay đổi là an toàn trước cả khi con người kịp uống xong cà phê, thì vấn đề không còn là “AI có làm được không” mà là “ai kiểm chứng những gì AI vừa làm”. Trong lịch sử, quy trình phát hành phần mềm xoay quanh chuỗi kiểm soát rất rõ: một nhà phát triển thực hiện thay đổi, người khác review, người có thẩm quyền phê duyệt, rồi mới triển khai. Đợt sóng đầu tiên của AI sinh tạo tập trung vào việc giúp nhà phát triển viết mã nhanh hơn, kéo theo số lượng thay đổi ứng dụng, hạ tầng, cơ sở dữ liệu tăng vọt. Nếu vẫn giữ mô hình “mỗi thay đổi phải có một người xem hết”, phép tính nhân lực không còn hợp lý. Tốc độ không phải là bằng chứng; nó chỉ là cách rút ngắn thời gian đi đến một lỗi sản xuất nếu thiếu kiểm thử độc lập.
Nghịch lý năng suất: nhiều mã hơn nghĩa là nhiều kiểm thử hơn
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. Đây không còn là thử nghiệm bên lề, mà là dòng chảy chính. Tuy nhiên, tỷ lệ có quan điểm tích cực chỉ còn 60%, trong khi 46% nhà phát triển chủ động không tin vào độ chính xác của AI, cao hơn nhóm tin tưởng (33%). Nói cách khác, AI agents phát triển phần mềm đang được dùng rộng rãi, nhưng niềm tin vào độ đúng của chúng lại thấp. Đó là mảnh đất màu mỡ cho kiểm thử, không phải lý do để cắt giảm kiểm thử. Các nghiên cứu về chất lượng mã do AI tạo ra cho thấy bức tranh tương tự: 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 logic và tính chính xác phổ biến hơn 75%, còn phát hiện liên quan đến bảo mật cao hơn tới 2,74×. Báo cáo về bảo mật mã do GenAI tạo ra ghi nhận tỷ lệ vượt qua kiểm thử bảo mật trung bình chỉ 56%, 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. Khi công cụ “có ích nhưng không đáng tin”, công việc của người kiểm thử mở rộng, chứ không thu hẹp.
Kiểm thử tự động AI không thay thế kiểm chứng con người
Trong thực tế, kiểm thử tự động AI đang được dùng để xây thêm lớp kiểm soát, không phải để bỏ qua con người. Một kỹ sư chất lượng mô tả việc 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. Nội bộ họ triển khai một công cụ review code AI cho pull request và một công cụ tạo test case; cả hai đều chỉ tạo bản nháp và “không công cụ nào tự chấm bài của mình”. Quy tắc đó quan trọng vì các tác tử luôn nói năng đầy chắc chắn, nhưng chắc chắn không đồng nghĩa với chính xác. Một sự cố điển hình: trong đợ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, bảng thông tin hiển thị mức nhiệt độ vô lý; lỗi đảo chiều quy đổi từ độ C sang độ F nằm trên 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 câu hỏi khó thì chỉ là màn trình diễn. Đó là lời nhắc rằng kiểm thử tự động AI phải được thiết kế như “máy khuếch đại nghi ngờ” cho người kiểm thử, không phải “máy hợp thức hóa” mọi thay đổi.
Quy trình phát hành phần mềm mới: AI mở đường, con người giữ cổng
AI tác tử đang viết lại quy trình phát hành phần mềm: trợ lý soạn pull request, tác tử mở các yêu cầu chuyển đổi, bot rà soát tuyên bố thay đổi là an toàn. Song song, AI agents tham gia sâu hơn vào SDLC, có thể sửa đổi tệp, chạy lệnh, tương tác với kho mã, gọi API, kiểm thử mã hoặc làm việc với hạ tầng. Hôm nay, AI tạo ra nhiều thay đổi hơn, và việc kiểm tra của con người bắt đầu căng thẳng. Tiếp theo, các tác nhân sẽ tham gia vào nhiều hơn các giai đoạn của SDLC, rồi cuối cùng tạo, xác thực, triển khai, quan sát và khắc phục các thay đổi với ít sự tham gia của con người hơn rất nhiều. 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. Vì vậy, các cổng kiểm soát phải được thiết kế để tách quyền truy cập khỏi thẩm quyền. Một tác nhân cần quyền truy cập vào kho mã, hệ thống CI/CD, môi trường đám mây hoặc cơ sở dữ liệu để hữu ích, nhưng không nên có thẩm quyền thực hiện mọi hành động có sẵn. Nếu một tác nhân muốn sửa đổi hạ tầng, dữ liệu hoặc cơ sở dữ liệu sản xuất, các kiểm soát quanh hệ thống đó không nên biến mất chỉ vì người thực hiện đã thay đổi.
Từ “tin tưởng AI” sang “thiết kế kiểm chứng độc lập”
Trong một nghiên cứu về hàng triệu tương tác giữa con người và tác nhân, người dùng Claude Code có kinh nghiệm đã sử dụng việc tự động phê duyệt toàn bộ trong hơn 40% các phiên, khoảng gấp đôi tỷ lệ của người dùng mới. Đồng thời, người dùng phê duyệt khoảng 93% các lời nhắc quyền. Nếu ai đó nhấn phê duyệt 93% thời gian, việc thêm một lần phê duyệt nữa không mang lại nhiều kiểm soát hơn; ở một thời điểm nào đó, con người trở thành một bước nữa trong quy trình, không phải lớp bảo vệ. Điều này buộc chúng ta phải chuyển từ tư duy “thêm người phê duyệt” sang “thiết kế kiểm chứng độc lập có ý nghĩa”. Các cổng kiểm soát chất lượng hiện đại cho mã do AI viết bao gồm đặt mục tiêu điểm đột biến 60–70% cho phần logic được chỉnh sửa, dùng kiểm thử dựa trên thuộc tính cho logic rủi ro cao, kiểm tra nguồn gốc gói phụ thuộc để ngăn gói ảo, theo dõi tín hiệu trùng lặp và biến động mã, và kiểm chứng độc lập mọi tuyên bố của tác tử như “đã hoàn tất chuyển đổi”. Điều này cũng cho phép công nghệ thay đổi mà không buộc các công ty phải xây dựng lại quản trị mỗi khi có thay đổi; các mô hình sẽ thay đổi, các tác nhân sẽ mạnh hơn, nhưng các kiểm soát quanh hệ thống quan trọng có thể vẫn giữ nguyên nhất quán. Kết luận thẳng thắn: nếu muốn AI agents phát triển phần mềm trở thành lợi thế thay vì rủi ro, hãy đầu tư vào người kiểm thử và quy trình kiểm chứng, không phải cắt giảm họ.
