Báo cáo hé lộ 97% lập trình viên đã dùng trợ lý AI, nhưng chính năng suất ảo đang 'ngốn' thời gian của họ

• Rà soát code thủ công (52%) — người rà soát hiện đang phải xử lý một lượng code do AI tạo ra lớn hơn code do con người viết, và khối lượng đó vẫn đang tăng lên .
• Kiểm tra bảo mật (51%) — code do AI tạo ra làm xuất hiện những lỗ hổng bảo mật mới vốn không có trong code viết tay, đặc biệt là xung quanh vấn đề chèn mã độc phụ thuộc (dependency injection), khóa bảo mật bị lộ cứng trong code (hardcoded secrets), và các đề xuất thư viện đã lỗi thời .
• Làm lại code đã tạo (48%) — gần một nửa số nhóm cho biết họ dành thời gian đáng kể để sửa lỗi, tái cấu trúc hoặc viết lại đầu ra của AI trước khi có thể đưa vào sử dụng .

Khuôn mẫu này nay đã có tên gọi chính thức: sự chuyển dịch gánh nặng công việc vô nghĩa (toil shift). Thay vì triệt tiêu công việc, AI đang chuyển nó từ giai đoạn tạo code sang các giai đoạn xác minh, kiểm tra và xử lý sự cố .

Black Duck ví von rất thẳng thắn: "hầu hết tổ chức đang sản xuất code do AI tạo ra nhanh hơn tốc độ họ có thể rà soát, bảo mật hoặc quản trị nó" .

Quản trị: Hệ số nhân lợi tức đầu tư thực sự

Nếu có một phát hiện nào từ báo cáo mà các lãnh đạo kỹ thuật cần hành động ngay, thì đó là: quản trị chính là hệ số nhân cho lợi tức đầu tư (ROI) . Sự khác biệt giữa những nhóm quản trị việc sử dụng AI và những nhóm không không chỉ là rất nhỏ – đó là sự khác biệt giữa việc nắm bắt được lợi ích thực sự và nhìn chúng 'rò rỉ' ra ngoài.

Black Duck nhận thấy các tổ chức có khuôn khổ quản trị đầy đủ báo cáo 90% mức cải thiện năng suất đáng kể từ các công cụ lập trình AI. Còn các nhóm không có sự giám sát có cấu trúc thì sao? Con số này tụt xuống chỉ còn 44% .

Quản trị trong bối cảnh này không có nghĩa là quan liêu, giấy tờ. Nó có nghĩa là phải có các chính sách được xác định rõ ràng về việc công cụ nào được dùng, code do AI tạo sẽ được rà soát ra sao, phải vượt qua những 'cửa ải' bảo mật nào, và ai là người chịu trách nhiệm cho đầu ra. Đó là sự khác biệt giữa việc "lập trình viên muốn dùng gì thì dùng" và "lập trình viên dùng các công cụ đã được phê duyệt trong một quy trình có cấu trúc, có thể kiểm toán được".

Vấn nạn "AI Ngầm"

Một yếu tố khác khiến việc quản trị thêm phức tạp là sự trỗi dậy của AI Ngầm (Shadow AI) – tình trạng các lập trình viên sử dụng công cụ AI trái với chính sách của công ty. Black Duck phát hiện ra rằng 18% tổ chức báo cáo AI Ngầm là một rủi ro đáng kể và không được kiểm soát . Khi những công cụ như Cursor, Windsurf hay Claude Code được từng cá nhân lập trình viên sử dụng mà không qua quy trình mua sắm hay rà soát bảo mật, thì tổ chức đó mất hoàn toàn khả năng kiểm soát và hình dung về bề mặt tấn công (attack surface) của chính mình .

Rủi ro chuỗi cung ứng: Code AI kế thừa những gì?

Những tác động đến chuỗi cung ứng chính là nơi mà các lỗ hổng quản trị biến thành những lỗ hổng bảo mật cụ thể. Các nghiên cứu của Black Duck – bao gồm cả báo cáo liên quan OSSRA 2026 – chỉ ra ba rủi ro có mối liên hệ với nhau, đặc thù của các trợ lý lập trình AI:

Rửa giấy phép (License laundering). Các trợ lý AI được huấn luyện từ các kho mã nguồn mở và có thể tạo ra các đoạn code từ các nguồn có bản quyền 'copyleft' mà không giữ lại thông tin giấy phép gốc . Báo cáo OSSRA 2026 cho thấy hai phần ba các kho code (codebase) được kiểm toán chứa xung đột giấy phép – mức cao nhất trong lịch sử của báo cáo này . Các tổ chức có thể đang xuất xưởng những đoạn code mà họ không có quyền sử dụng mà chẳng hề hay biết.

Sự bùng nổ phụ thuộc (Dependency explosion). Số lượng thành phần mã nguồn mở trên mỗi kho code đã tăng 30% so với cùng kỳ năm trước, và số lỗ hổng trung bình trên mỗi kho code tăng vọt 107% . Các trợ lý lập trình AI càng đẩy nhanh xu hướng này vì chúng soạn thảo giải pháp nhanh hơn và từ kho ngữ liệu huấn luyện rộng hơn – có nghĩa là mỗi hàm do AI tạo ra có thể kéo theo những thành phần phụ thuộc (dependencies) mà lập trình viên không hề chủ đích lựa chọn.

Khoảng trống tuân thủ. Chỉ có 24% tổ chức thực hiện đánh giá toàn diện về sở hữu trí tuệ, giấy phép, bảo mật và chất lượng đối với code do AI tạo ra . Điều đó có nghĩa là ba phần tư số tổ chức không thể trả lời một cách đáng tin cậy cho câu hỏi: "Chúng ta vừa cam kết những nghĩa vụ pháp lý và bảo mật nào?"

Niềm tin của lập trình viên: Tỷ lệ sử dụng tăng trong khi niềm tin sụt giảm

Những phát hiện của Black Duck không tồn tại một cách đơn lẻ. Nhiều cuộc khảo sát độc lập được công bố trong cùng giai đoạn này đã củng cố và mở rộng bức tranh về niềm tin bằng những dữ liệu chi tiết:

• Khảo sát Tình trạng Code dành cho Lập trình viên năm 2026 của Sonar (1.100+ lập trình viên) phát hiện ra rằng 96% lập trình viên không hoàn toàn tin tưởng vào độ chính xác về mặt chức năng của code do AI tạo ra . Ấy vậy mà chỉ có 48% luôn xác minh code đó trước khi tích hợp vào hệ thống – nghĩa là thứ code mà chính các lập trình viên còn không tin tưởng vẫn thường xuyên được xuất xưởng .
• Khảo sát Lập trình viên năm 2025 của Stack Overflow (49,009 người trả lời) cho thấy niềm tin vào độ chính xác của AI đã giảm từ 40% xuống còn 29% chỉ trong một năm. Mức độ mất lòng tin chủ động tăng lên 46%, trong khi mức độ yêu thích giảm từ 72% xuống còn 60% .
• Tình hình Phát hành Phần mềm bằng AI năm 2026 của Harness (500 lãnh đạo kỹ thuật) cho thấy 57% vẫn yêu cầu quy trình rà soát có người thật tham gia (human-in-the-loop) cho mỗi dòng code do AI tạo ra, và 29% đang dành nhiều thời gian hơn cho việc rà soát code so với trước khi sử dụng trợ lý AI .

Sự đồng thuận giữa các cuộc khảo sát này là nhất quán một cách đáng chú ý: các lập trình viên không thể làm việc mà thiếu các công cụ AI, nhưng họ cũng không thể tin tưởng chúng hoàn toàn. Khoảng cách giữa việc tạo code và xác minh code đã trở thành điểm nghẽn mới.

Diana Kelley, Giám đốc An ninh Thông tin (CISO) tại Noma Security, đã nắm bắt được mâu thuẫn cốt lõi này: "Viết code nhanh hơn không đồng nghĩa với việc code an toàn hơn" .

Quản trị thực sự trong thực tế trông như thế nào?

Giải pháp của Black Duck đưa ra không phải là những lý thuyết mơ hồ. Báo cáo chỉ ra một loạt các biện pháp cụ thể giúp phân biệt 30% tổ chức có quản trị đầy đủ với phần còn lại:

1. Khuôn khổ quản trị AI có cấu trúc — không phải là những hướng dẫn không chính thức, mà là các chính sách được văn bản hóa và thực thi, bao quát việc phê duyệt công cụ, rà soát đầu ra và trách nhiệm giải trình .
2. Các cổng rà soát tích hợp trong quy trình (pipeline) — chuyển từ cách bàn giao thủ công cho hàng đợi kiểm tra bảo mật (tình trạng mà 46% công ty vẫn đang áp dụng), sang các bước kiểm tra chất lượng và bảo mật tự động chạy trên mỗi lần tích hợp code có sự hỗ trợ của AI .
3. Giám sát liên tục sau khi triển khai — Black Duck lưu ý rằng "chiến lược 'dịch trái' (shift-left) đơn thuần là không còn đủ" vì rủi ro được đưa vào, phát hiện ra và phải được quản lý xuyên suốt toàn bộ vòng đời phát triển phần mềm (SDLC) .
4. Tinh gọn bộ công cụ bảo mật — hơn 71% người trả lời cho biết sự phân mảnh công cụ (tool sprawl) là nguồn cơn gây ra xung đột và chậm trễ lớn, và việc hợp nhất về một nền tảng ít công cụ hơn, tích hợp tốt hơn là điều kiện tiên quyết để mở rộng AI một cách an toàn .

Điểm mấu chốt

Báo cáo của Black Duck không phản đối việc sử dụng các trợ lý lập trình AI. Nó chỉ ra rằng sử dụng chúng mà không có một cơ chế quản trị tương xứng chính là tự chuốc lấy thất bại. Khi 97% các nhóm đang tạo code với tốc độ chưa từng thấy, nhưng chỉ 30% có hạ tầng giám sát để quản lý, thì toàn ngành đang cùng nhau 'ký những tấm séc' mà mình không thể chi trả.

Mối tương quan chặt chẽ giữa quản trị và mức tăng hiệu quả – 90% so với 44% – khiến cho bài toán kinh doanh trở nên rõ ràng không thể chối cãi. Những tổ chức nào xây dựng 'lan can' bảo vệ trước sẽ là những người nắm bắt được năng suất mà AI hứa hẹn. Còn những tổ chức không làm vậy sẽ liên tục khám phá ra một thực tế phũ phàng: thời gian tiết kiệm được trên bàn phím sẽ lại 'bốc hơi' trong hàng chờ rà soát code.