AI “nổi loạn” xoá sạch 28.000 dòng code, đánh sập hệ thống rồi tự viết báo cáo giả để ghi công

Theo trang tin 36Kr, trình biên tập mã nguồn Agent IDE lại vừa chứng kiến một “tai nạn hiện trường” mới.

Mới đây, một lập trình viên Trung Quốc đã đăng tải bài viết trên nền tảng Reddit cho biết, Gemini 3.5 chạy trong Agent IDE khi thực hiện một nhiệm vụ chỉ liên quan đến việc “sửa 8 lỗ hổng xác thực” đã vô tình xóa nhầm 28.745 dòng code đang vận hành bình thường, chỉnh sửa 340 tệp tin, đồng thời sửa sai cấu hình định tuyến của nền tảng phát triển ứng dụng di động và web Firebase do Google cung cấp.

Hậu quả là toàn bộ hệ thống liên tục gặp lỗi 404 kéo dài suốt 33 phút.

Điều khó tin là sau khi sự cố xảy ra, Gemini còn tự tạo ra một báo cáo “khắc phục thành công”, tự nhận đã xử lý xong sự cố trên môi trường, đồng thời làm giả nhiều biên bản “hội chẩn AI” và tài liệu đánh giá sau sự cố (post-mortem).

Lập trình viên này sau đó kiểm tra lại và phát hiện ra rằng, tác vụ được cho là “khắc phục thành công” kia thực chất đã bị chính tay anh hủy bỏ từ trước, còn thao tác thực sự giúp hệ thống phục hồi lại là lệnh rollback được anh thực hiện thủ công.

Theo lời của lập trình viên này, kiểu nâng cao năng suất bằng AI như vậy dễ khiến người ta liên tưởng đến mã độc tống tiền (ransomware) hơn.

Cùng với sự phổ biến liên tục của Agent IDE và các trợ lý lập trình AI, những sự cố tương tự như “AI thao tác sai trên môi trường production” đang xuất hiện ngày càng thường xuyên.

So với việc “viết sai code”, điều khiến các lập trình viên lo ngại hơn cả là mô hình đã bắt đầu tự tạo ra các nhật ký , biên bản đánh giá và chứng nhận tuân thủ giả mạo.

Nhiệm vụ lẽ ra chỉ nên sửa 70 dòng code, cuối cùng lại xóa tới 28.000 dòng

Lập trình viên này đang vận hành một hệ thống quản trị nội bộ bao gồm nền tảng Next.js, Firebase App Hosting và MUI, trong đó hệ thống có xử lý dữ liệu của người dùng thực và các dữ liệu nhạy cảm.

Trong ngày xảy ra sự cố, ban đầu anh chỉ yêu cầu Gemini sửa 8 lỗ hổng xác thực phía máy chủ liên quan đến 3 tệp tin, quy mô thay đổi về mặt lý thuyết chỉ khoảng 70 dòng code.

Thế nhưng, yêu cầu kết quả Pull Request (PR) mà Gemini gửi lên lại biến thành: 340 tệp tin bị chỉnh sửa, thêm mới khoảng 400 dòng code, xóa bỏ 28.745 dòng code.

Cùng lúc đó, nó cũng xóa một lượng lớn các tệp tài nguyên mẫu thương mại điện tử hoàn toàn không liên quan đến nhiệm vụ, và tự ý chèn thêm một đoạn script chuyển đổi (migration script).

Và thứ thực sự khiến môi trường bị sập chính là lượt commit (lệnh nộp code) thứ hai do Gemini thực hiện ngay sau đó.

Nó đã chỉnh sửa mục rewrite serviceId trong tệp firebase.json, thay thế ID dịch vụ Cloud Run chính xác vốn do Firebase tự động tạo ra bằng một cái tên rút gọn “trông có vẻ đúng”.

Vấn đề là cái tên này trên thực tế không hề tồn tại. Hệ quả là mọi yêu cầu (request) đều bị định tuyến sai đến một địa chỉ dịch vụ không tồn tại, khiến toàn bộ backend trực tiếp rơi vào trạng thái lỗi 404.

Trớ trêu thay, trước đó lập trình viên đã viết rõ lời cảnh báo trong tệp quy tắc memory.md rằng: Cấu hình Firebase rewrites bắt buộc phải trỏ đến ID dịch vụ Cloud Run cụ thể, thay vì tên dự án chung chung.

Tuy nhiên, Gemini đã đọc quy tắc này, nhưng vẫn sửa cấu hình đúng thành sai.

Sau khi Gemini triển khai yêu cầu (pull request) “sửa lỗi bảo mật”, môi trường production lập tức xuất hiện lỗi 404.

Tuy nhiên, những diễn biến sau đó mới thực sự trở nên vô lý. Sau khi quá trình rollback hoàn tất, Gemini gửi cho lập trình viên một thông báo “đã khôi phục xong”:

Cổng thông tin (Portal) hiện tại đã được khôi phục hoàn toàn, môi trường trực tuyến hoạt động ổn định, Google Cloud Build đã hoàn thành thành công và đã chuyển 100% lưu lượng truy cập sang phiên bản ổn định.

Khi bị lập trình viên truy vấn sâu hơn, Gemini mới thừa nhận: Cái gọi là “biên bản tham vấn ba vòng”thực ra chỉ là văn bản tư duy (reasoning text) do chính nó tự tạo ra, không hề có lệnh gọi thực tế nào, cũng chẳng có quy trình kiểm duyệt bên ngoài thực sự nào tồn tại.

Nói cách khác, nó đã tự nguỵ tạo cho mình một bộ “hồ sơ tuân thủ”.

Trong các sự cố lập trình, Agent bắt đầu “ làm giả bằng chứng ”.

Sau khi bài viết được đăng tải, nó đã nhanh chóng thu hút lượng lớn thảo luận trong cộng đồng nhà phát triển trên nền tảng Reddit.

Nhiều lập trình viên nhận thấy rằng, các sự cố lập trình do AI gây ra giờ đây không còn đơn thuần là “viết sai code” nữa.

Hiện nay, vấn đề nằm ở chỗ, mô hình ngôn ngữ lớn đang chủ động tạo ra các lời giải thích, nhật ký hệ thống, biên bản tham vấn và báo cáo khôi phục “trông có vẻ hợp lý”.

Một khi các nội dung này lọt vào quy trình làm việc tự động (automated workflow), các nhà phát triển có thể sẽ rất khó phát hiện ra vấn đề ngay từ đầu.

Sau đó, lập trình viên này cũng đưa ra một loạt đề xuất và cảnh báo:

Đầu tiên là nghiêm cấm Agent đẩy code trực tiếp vào các nhánh production, tất cả các tệp cơ sở hạ tầng bắt buộc phải được con người phê duyệt thủ công.

Thứ hai, nghiêm cấm tự động triển khai (auto-deploy) và tự động thử lại (auto-retry).

Thứ ba, thêm cơ chế xác thực cho các cấu hình rewrite, định tuyến (routing) và tệp khóa (lockfile).

Và đặc biệt là không tin tưởng vào các “nhật ký tham vấn” do AI tự tạo ra.

Như vậy, sự cố xóa nhầm 28.745 dòng code, khiến backend dính lỗi 404 kéo dài 33 phút này cũng đã dội một gáo nước lạnh vào “cơn sốt Agent IDE” đang ngày càng hạ nhiệt.

Trong năm qua, các công cụ lập trình AI đang nhanh chóng tiến hóa từ “trợ lý mã nguồn” thành các Agent thực sự có năng lực thực thi.

Tuy nhiên, vấn đề lại nằm ở chỗ quyền hạn và tự động hóa vốn dĩ là một cặp mâu thuẫn tự nhiên.

Quyền hạn càng cao, Agent càng làm được nhiều việc, mức độ tự động hóa càng cao, các mắt xích có sự can thiệp của con người càng ít đi. Một khi mô hình xuất hiện sai sót trong nhận định, ảo tưởng (hallucination) hoặc xung đột quy tắc, lỗi sai cũng sẽ bị phóng đại một cách chóng mặt.

Những sự cố tương tự trên thực tế không phải lần đầu tiên xuất hiện.

Trước đó, sau khi các nền tảng Agent như OpenClaw trở nên nổi tiếng, đã lần lượt xuất hiện các trường hợp “lật xe” như AI xóa nhầm tệp tin, tự động ghi đè cấu hình, hay thực hiện sai các lệnh Shell.

Và sự việc Gemini lần này lại vạch trần một vấn đề nguy hiểm hơn: Khi Agent bắt đầu tự tạo ra các hồ sơ tuân thủ, nhật ký khôi phục và chứng nhận kiểm duyệt, các nhà phát triển có thể sẽ rất khó phát hiện ra vấn đề ngay lập tức, cái giá phải trả cho việc rà soát lỗi, rollback và khắc phục sau đó cũng sẽ tăng lên tương ứng.

Có thể thấy rằng, đối với đường đua Agent IDE đang ngày một nóng bỏng, sự việc Gemini là một lời nhắc nhở mới, đó là sau khi AI giành được quyền hạn cao hơn, thứ cần phải thiết kế lại còn bao gồm cả toàn bộ cơ chế hợp tác giữa con người và Agent.

*Theo 36Kr