Giờ AI đã tiến hóa đến mức tự bịa hồ sơ để che đậy lỗi mình gây ra luôn rồi các bạn ơi!
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" chấn động.
Mới đây, một anh dev Trung Quốc đã lên Reddit kể lể rằng, Gemini 3.5 chạy trong Agent IDE khi được giao nhiệm vụ đơn giản là "sửa 8 lỗ hổng xác thực" thì đã vô tình xóa nhầm 28.745 dòng code đang chạy ngon lành, chỉnh sửa 340 file, đồng thời sửa sai luôn cấu hình định tuyến của Firebase do Google cung cấp.
Hậu quả là cả hệ thống liên tục gặp lỗi 404 suốt 33 phút trời. Ối dồi ôi!
Nhưng điều đáng sợ hơn là sau khi gây họa xong, 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ố, đồ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) nữa chứ!
Anh dev này sau đó kiểm tra lại và phát hiện ra rằng, cái tác vụ "khắc phục thành công" kia thực chất đã bị chính anh ta hủy bỏ từ trước rồi, còn thao tác thực sự giúp hệ thống hồi sinh lại là lệnh rollback mà anh tự tay thực hiện.
Theo lời anh dev này, kiểu nâng cao năng suất bằng AI như vậy nhìn giống mã độc tống tiền (ransomware) hơn là trợ lý đấy các bạn ơi!
Cùng với sự phổ biến của Agent IDE và các trợ lý lập trình AI, những sự cố kiểu "AI thao tác sai trên môi trường production" đang xuất hiện dày đặc.
So với việc "viết sai code", điều khiến các dev lo lắng 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. Nguy hiểm thật đấy!
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
Anh dev 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 file, quy mô thay đổi về mặt lý thuyết chỉ khoảng 70 dòng code thôi.
Thế nhưng, kết quả Pull Request (PR) mà Gemini gửi lên lại biến thành: 340 file bị chỉnh sửa, thêm mới khoảng 400 dòng code, xóa bỏ 28.745 dòng code. Wtf?!
Cùng lúc đó, nó cũng xóa một lượng lớn các file 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) nữa.
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 file 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 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 đó anh dev đã viết rõ lời cảnh báo trong file 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. Bó tay! 
Sau khi Gemini triển khai 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 anh dev 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ị anh dev 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ủ". Kinh hãi quá đi mất!
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 dev trên Reddit.
Nhiều dev 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ý" lắm.
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 dev có thể sẽ rất khó phát hiện ra vấn đề ngay từ đầu.
Sau đó, anh dev 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 file 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à file 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ớ kỹ nhé các bạn!
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 file, 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 dev 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.
Bài học xương máu cho ai đang dùng AI để code đây! Cẩn tắc vô áy náy nhé mọi người!
Nguồn: soha.vn
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" chấn động.
Mới đây, một anh dev Trung Quốc đã lên Reddit kể lể rằng, Gemini 3.5 chạy trong Agent IDE khi được giao nhiệm vụ đơn giản là "sửa 8 lỗ hổng xác thực" thì đã vô tình xóa nhầm 28.745 dòng code đang chạy ngon lành, chỉnh sửa 340 file, đồng thời sửa sai luôn cấu hình định tuyến của Firebase do Google cung cấp.
Hậu quả là cả hệ thống liên tục gặp lỗi 404 suốt 33 phút trời. Ối dồi ôi!
Nhưng điều đáng sợ hơn là sau khi gây họa xong, 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ố, đồ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) nữa chứ!
Anh dev này sau đó kiểm tra lại và phát hiện ra rằng, cái tác vụ "khắc phục thành công" kia thực chất đã bị chính anh ta hủy bỏ từ trước rồi, còn thao tác thực sự giúp hệ thống hồi sinh lại là lệnh rollback mà anh tự tay thực hiện.
Theo lời anh dev này, kiểu nâng cao năng suất bằng AI như vậy nhìn giống mã độc tống tiền (ransomware) hơn là trợ lý đấy các bạn ơi!
Cùng với sự phổ biến của Agent IDE và các trợ lý lập trình AI, những sự cố kiểu "AI thao tác sai trên môi trường production" đang xuất hiện dày đặc.
So với việc "viết sai code", điều khiến các dev lo lắng 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. Nguy hiểm thật đấy!
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
Anh dev 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 file, quy mô thay đổi về mặt lý thuyết chỉ khoảng 70 dòng code thôi.
Thế nhưng, kết quả Pull Request (PR) mà Gemini gửi lên lại biến thành: 340 file bị chỉnh sửa, thêm mới khoảng 400 dòng code, xóa bỏ 28.745 dòng code. Wtf?!
Cùng lúc đó, nó cũng xóa một lượng lớn các file 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) nữa.
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 file 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 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 đó anh dev đã viết rõ lời cảnh báo trong file 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. Bó tay!
Sau khi Gemini triển khai 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 anh dev 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ị anh dev 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ủ". Kinh hãi quá đi mất!
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 dev trên Reddit.
Nhiều dev 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ý" lắm.
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 dev có thể sẽ rất khó phát hiện ra vấn đề ngay từ đầu.
Sau đó, anh dev 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 file 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à file 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ớ kỹ nhé các bạn!
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 file, 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 dev 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.
Bài học xương máu cho ai đang dùng AI để code đây! Cẩn tắc vô áy náy nhé mọi người!
Nguồn: soha.vn