Báo cáo: 43% mã nguồn do AI tạo ra cần gỡ lỗi thủ công khi đưa vào vận hành

Ngành công nghiệp phần mềm đang chạy đua để viết mã bằng trí tuệ nhân tạo (AI). Tuy nhiên, họ đang gặp khó khăn lớn trong việc đảm bảo rằng mã nguồn đó hoạt động ổn định sau khi được triển khai.

Một khảo sát đối với 200 lãnh đạo cấp cao về SRE (Site Reliability Engineering) và DevOps tại các doanh nghiệp lớn ở Mỹ, Anh và Liên minh Châu Âu (EU) đã vẽ nên một bức tranh ảm đạm về những chi phí ẩn trong bùng nổ lập trình bằng AI. Theo báo cáo "Trạng thái Kỹ thuật dựa trên AI năm 2026" của Lightrun, được chia sẻ độc quyền với VentureBeat, 43% các thay đổi mã nguồn do AI tạo ra yêu cầu gỡ lỗi thủ công trong môi trường sản xuất (production), ngay cả khi đã vượt qua các bài kiểm tra đảm bảo chất lượng và staging.

Không một người tham gia khảo sát nào cho biết tổ chức của họ có thể xác minh một bản sửa lỗi do AI đề xuất chỉ với một chu kỳ triển khai lại; 88% báo cáo cần từ hai đến ba chu kỳ, trong khi 11% cần từ bốn đến sáu chu kỳ.

Bức tường niềm tin với AI

Những phát hiện này đưa ra trong bối cảnh mã nguồn do AI tạo ra đang tăng trưởng với tốc độ chóng mặt tại các doanh nghiệp toàn cầu. Cả CEO Microsoft Satya Nadella và CEO Google Sundar Pichai đều tuyên bố rằng khoảng một phần tư mã nguồn của công ty họ hiện nay do AI tạo ra. Tuy nhiên, báo cáo cho thấy cơ sở hạ tầng nhằm bắt lỗi do AI tạo ra đang tụt hậu nghiêm trọng so với khả năng sản xuất của nó.

"Con số 0% tín hiệu cho thấy ngành kỹ thuật đang va phải bức tường niềm tin trong việc áp dụng AI," ông Or Maimon, Giám đốc Thương mại của Lightrun, nói về việc 0% lãnh đạo kỹ thuật mô tả mình "rất tự tin" rằng mã do AI tạo ra sẽ hoạt động đúng khi được triển khai. "Mặc dù sự nhấn mạnh của ngành vào năng suất tăng cao đã khiến AI trở thành nhu cầu thiết yếu, chúng tôi đang thấy tác động tiêu cực trực tiếp. Khi mã do AI tạo ra đi vào hệ thống, nó không chỉ làm tăng khối lượng mà còn làm chậm toàn bộ quy trình triển khai."

Sự cố Amazon: Hệ quả khi mã AI được triển khai mà không có lớp bảo vệ

Những nguy hiểm này không còn chỉ là lý thuyết. Vào đầu tháng 3 năm 2026, Amazon đã gặp phải một loạt sự cố gián đoạn dịch vụ quy mô lớn, làm nổi bật chính xác mô hình thất bại mà khảo sát của Lightrun mô tả. Vào ngày 2 tháng 3, Amazon.com trải qua sự cố kéo dài gần sáu giờ, dẫn đến việc mất 120.000 đơn hàng và 1,6 triệu lỗi trang web. Ba ngày sau, vào ngày 5 tháng 3, một sự cố nghiêm trọng hơn đã đánh vào cửa hàng trực tuyến — kéo dài sáu giờ và gây giảm 99% lượng đơn hàng tại Mỹ, với khoảng 6,3 triệu đơn hàng bị mất. Cả hai sự cố đều được truy nguyên từ các thay đổi mã được hỗ trợ bởi AI được triển khai lên môi trường sản xuất mà không có sự phê duyệt phù hợp.

Hậu quả đã đến rất nhanh. Amazon đã khởi động lại quy trình an toàn mã trong 90 ngày trên 335 hệ thống quan trọng, và các thay đổi mã được hỗ trợ bởi AI hiện nay phải được các kỹ sư cấp cao phê duyệt trước khi triển khai.

Ông Maimon chỉ trích trực tiếp vào các sự cố của Amazon: "Sự không chắc chắn này không dựa trên giả thuyết. Chúng ta chỉ cần nhìn lại đầu tháng 3, khi Amazon.com ở Bắc Mỹ bị sập do một thay đổi được hỗ trợ bởi AI được thực hiện mà không có các biện pháp bảo vệ đã thiết lập."

Các nhà phát triển dành hai ngày mỗi tuần để gỡ lỗi mã AI

Một trong những phát hiện đáng chú ý nhất của báo cáo là quy mô vốn nhân lực đang bị tiêu hao cho công việc xác minh liên quan đến AI. Các nhà phát triển hiện dành trung bình 38% tuần làm việc — khoảng hai ngày làm việc đầy đủ — để gỡ lỗi, xác minh và khắc phục sự cố cụ thể theo môi trường, theo khảo sát. Đối với 88% các công ty được khảo sát, "thuế độ tin cậy" này tiêu tốn từ 26% đến 50% năng lực hàng tuần của các nhà phát triển của họ.

Đây không phải là lợi ích năng suất mà các lãnh đạo doanh nghiệp mong đợi khi họ đầu tư vào các trợ lý lập trình AI. Thay vào đó, điểm nghẽn kỹ thuật đã đơn giản là dịch chuyển. Mã được viết nhanh hơn, nhưng mất nhiều thời gian hơn nhiều để xác nhận rằng nó hoạt động.

"Theo một nghĩa nào đó, AI đã làm vấn đề gỡ lỗi trở nên tồi tệ hơn," ông Maimon nói. "Khối lượng thay đổi đang quá tải khả năng xác minh của con người, trong khi mã được tạo ra thường xuyên không hoạt động như mong đợi khi được triển khai trong Production. Các tác nhân lập trình AI không thể thấy mã của chúng hoạt động như thế nào trong các môi trường đang chạy."

Công cụ giám sát AI không thể nhìn thấy những gì đang diễn ra bên trong ứng dụng

Nếu việc tiêu hao năng suất là chi phí dễ thấy nhất, báo cáo của Lightrun lập luận rằng vấn đề cấu trúc sâu hơn là cái được gọi là "khoảng trống khả năng quan sát thời gian chạy" (runtime visibility gap) — sự không khả thi của các công cụ AI và hệ thống giám sát hiện có trong việc quan sát những gì thực sự đang xảy ra bên trong các ứng dụng đang chạy.

Sáu mươi phần trăm người trả lời khảo sát xác định việc thiếu khả năng quan sát hành vi của hệ thống trực tiếp là nút thắt chính trong việc giải quyết các sự cố sản xuất. Trong 44% trường hợp mà các công cụ AI SRE hoặc giám sát hiệu suất ứng dụng (APM) cố gắng điều tra vấn đề sản xuất, chúng thất bại vì dữ liệu mức độ thực thi cần thiết — trạng thái biến, sử dụng bộ nhớ, luồng yêu cầu — chưa bao giờ được thu thập từ đầu.

Báo cáo vẽ nên một bức tranh các công cụ AI hoạt động cơ bản là "mù" trong các môi trường quan trọng nhất. Chín mươi bảy phần trăm lãnh đạo kỹ thuật nói rằng các tác nhân AI SRE của họ hoạt động mà không có khả năng quan sát đáng kể những gì thực sự đang xảy ra trong sản xuất. Chỉ có 1% báo cáo khả năng quan sát rộng rãi, và không một người trả lời nào tuyên bố có khả năng quan sát đầy đủ.

Đây là khoảng trống biến một lỗi phần mềm nhỏ thành một sự cố tốn kém. Khi một bản sửa lỗi do AI đề xuất thất bại trong sản xuất — như 43% trong số chúng — các kỹ sư không thể dựa vào các công cụ AI của họ để chẩn đoán vấn đề, bởi vì những công cụ đó không thể quan sát hành vi thời gian thực của mã. Thay vào đó, các nhóm dựa vào cái được gọi là "kiến thức bộ lạc" (tribal knowledge): trí nhớ của các kỹ sư cấp cao đã từng thấy các vấn đề tương tự trước đây và có thể trực giác ra nguyên nhân gốc rễ từ kinh nghiệm thay vì dữ liệu.

Niềm tin thấp trong ngành tài chính

Sự thiếu tin cậy diễn ra đặc biệt gay gắt trong lĩnh vực tài chính. Trong một ngành mà một lỗi ứng dụng đơn lẻ có thể gây ra thiệt hại hàng triệu đô la mỗi phút, khảo sát tìm thấy rằng 74% các nhóm kỹ thuật dịch vụ tài chính dựa vào kiến thức bộ lạc thay vì dữ liệu chẩn đoán tự động trong các sự cố nghiêm trọng — cao hơn nhiều so với con số 44% trong lĩnh vực công nghệ.

Có lẽ điểm dữ liệu đáng nói nhất trong toàn bộ báo cáo là không một tổ chức nào được khảo sát — ở bất kỳ ngành nghề nào — đã đưa các công cụ AI SRE của họ vào quy trình công việc sản xuất thực tế. Chín mươi phần trăm vẫn ở chế độ thử nghiệm hoặc thí điểm. Mười phần trăm còn lại đã đánh giá các công cụ AI SRE và chọn không áp dụng chúng altogether.

Ông Maimon mô tả đây là một trong những tiết lộ quan trọng nhất của báo cáo: "Các lãnh đạo háo hức áp dụng các công cụ AI mới, nhưng họ không tin tưởng AI để chạm vào các môi trường trực tiếp. Sự thiếu tin cậy được thể hiện qua dữ liệu; 98% có mức độ tin cậy thấp hơn ở AI hoạt động trong sản xuất so với các trợ lý lập trình."

Kết luận: Máy móc đã học viết mã, nhưng không ai dạy chúng cách giám sát

Câu hỏi không còn là liệu có nên sử dụng AI để viết mã hay không — mà là liệu có ai có thể tin tưởng những gì nó tạo ra hay không. Báo cáo mô tả một ngành đang đối mặt với một nghịch lý khó chịu. AI đã giải quyết phần chậm nhất của việc xây dựng phần mềm — viết mã — chỉ để tiết lộ rằng việc viết mã chưa bao giờ là phần khó khăn. Phần khó khăn luôn luôn là biết liệu nó có hoạt động hay không.

"Nếu khoảng trống khả năng quan sát trực tiếp không được lấp đầy, thì các nhóm thực sự chỉ đang làm gia tăng sự bất ổn thông qua việc áp dụng AI," ông Maimon kết luận. "Các tổ chức không thu hẹp khoảng trống này sẽ thấy mình bị mắc kẹt trong các chu kỳ triển khai lại dài dòng, để giải quyết các thách thức ngày càng phức tạp. Họ sẽ mất tốc độ cạnh tranh vào chính các công cụ AI vốn được kỳ vọng mang lại điều đó."

Máy móc đã học cách viết mã. Không ai dạy chúng cách giám sát nó chạy.