AI không xóa cơ sở dữ liệu của bạn, chính bạn mới là người làm thế

Tuần trước, một tweet đã lan truyền nhanh chóng, trong đó một người đàn ông claim rằng một tác nhân AI (sử dụng Cursor/Claude) đã xóa toàn bộ cơ sở dữ liệu (database) production của công ty anh ta. Chúng ta đã theo dõi từ bên lăng kính khi anh ta cố gắng moi một lời "thú nhận" từ tác nhân AI: "Tại sao cậu lại xóa nó khi đã được bảo không bao giờ thực hiện hành động này?" Sau đó, anh ta cố gắng phân tích câu trả lời để hoặc là rút kinh nghiệm từ sai lầm của mình, hoặc là cảnh báo chúng ta về những mối nguy hiểm từ các tác nhân AI.

Tôi cũng có một câu hỏi: Tại sao bạn lại có một API endpoint có khả năng xóa toàn bộ cơ sở dữ liệu production của mình? Bài đăng của anh ta lan man nói về marketing sai sự thật về AI, hỗ trợ khách hàng kém, v.v. Những gì bị thiếu đi chính là sự trách nhiệm.

Tôi không phải là người mù quáng bênh vực AI, tôi luôn ưu tiên sự thận trọng. Nhưng tôi cũng biết bạn không thể đổ lỗi cho một công cụ vì sai lầm của chính mình.

Vào năm 2010, tôi làm việc cho một công ty có quy trình triển khai (deploy) rất thủ công. Chúng tôi sử dụng SVN để kiểm soát phiên bản. Để deploy, chúng tôi phải sao chép thư mục trunk (tương đương với nhánh master ngày nay) vào một thư mục release được gắn nhãn ngày phát hành. Sau đó, chúng tôi tạo một bản sao thứ hai của bản release đó và gọi nó là "current". Nhờ vậy, việc kéo thư mục "current" luôn mang lại cho bạn phiên bản release mới nhất.

Một ngày nọ, trong quá trình deploy, tôi vô tình sao chép trunk hai lần. Để sửa lỗi này thông qua dòng lệnh (CLI), tôi đã chỉnh sửa lệnh trước đó để xóa bản sao trùng lặp. Sau đó, tôi tiếp tục quá trình deploy mà không gặp vấn đề gì... hoặc tôi đã nghĩ như vậy. Hóa ra, tôi đã không xóa bản sao trùng lặp kia chút nào. Tôi đã chỉnh sửa sai lệnh và xóa luôn trunk. Sau đó trong ngày, một developer khác đã rất bối rối khi không thể tìm thấy nó.

Hỗn loạn tổng thể. Các quản lý hoảng loạn, cuộc họp được triệu tập. Đến khi tin tức đến được đội của tôi, lead developer đã chạy một lệnh để hoàn tác việc xóa. Anh ấy kiểm tra logs, thấy rằng tôi là người chịu trách nhiệm, và nhiệm vụ tiếp theo của tôi là viết một script để tự động hóa quy trình triển khai của chúng tôi để loại sai sót này xảy ra một lần nữa. Trước khi ngày hôm đó kết thúc, chúng tôi đã có một hệ thống vững chắc hơn. Một hệ thống cuối cùng đã phát triển thành một pipeline CI/CD hoàn chỉnh.

Tự động hóa giúp loại bỏ những sai lầm ngớ ngẩn đến từ công việc thủ công, lặp đi lặp lại. Chúng ta hoàn toàn có thể đi quanh hỏi "Tại sao SVN không ngăn chúng ta xóa trunk?". Nhưng vấn đề thực sự là quy trình thủ công của chúng ta. Không giống như máy móc, con người không thể lặp lại một nhiệm vụ chính xác như nhau mỗi ngày. Chúng ta chắc chắn sẽ sai sót vào một lúc nào đó.

Với việc AI tạo ra các khối mã nguồn lớn, chúng ta có ảo giác về sự an toàn đó. Nhưng tự động hóa có nghĩa là làm cùng một thứ theo cùng một cách mỗi lần. AI giống tôi hơn là sao chép và dán các nhánh branch, nó chắc chắn sẽ mắc sai lầm, và nó không được trang bị để giải thích tại sao nó đã làm như vậy. Các thuật ngữ chúng ta sử dụng, như "suy nghĩ" (thinking) và "lý luận" (reasoning), có thể giống như sự phản ánh của một tác nhân thông minh. Nhưng đây là những thuật ngữ marketing được dán nhãn lên AI. Trong thực tế, các mô hình này vẫn chỉ đang tạo ra token.

Bây giờ, quay lại vấn đề chính mà chàng trai này đối mặt. Tại sao lại tồn tại một API công khai có thể xóa tất cả cơ sở dữ liệu production của bạn? Nếu AI không gọi endpoint đó, sớm muộn gì người khác cũng sẽ gọi. Nó giống như việc bạn lắp một nút tự hủy (self-destruct button) lên taplo ô tô của mình. Bạn có mọi lý do để không nhấn nó, vì bạn thích chiếc xe của mình và nó đưa bạn từ điểm A đến điểm B. Nhưng một đứa trẻ quyết tâm sẽ thoát khỏi ghế an toàn và nhấn nút đỏ lớn đó ngay khi nhìn thấy. Bạn không thể sau đó thẩm vấn đứa trẻ về lý do của nó. Con tôi sẽ chỉ trả lời đơn giản: "Con làm thế vì con đã nhấn nó".

Tôi nghi ngờ một phần lớn ứng dụng của công ty này được code theo cảm tính (vibe-coded). Các kiến trúc sư phần mềm sử dụng AI để định hướng sản phẩm từ các mô tả do AI tạo ra từ đội ngũ sản phẩm. Các lập trình viên sử dụng AI để viết mã. Những người kiểm duyệt sử dụng AI để phê duyệt nó. Bây giờ, khi một lỗi xuất hiện, lựa chọn duy nhất là thẩm vấn một AI khác để có câu trả lời, có lẽ thậm chí không chạy trên cùng một GPU đã tạo ra mã gốc. Bạn không thể đổ lỗi cho GPU!

Giải pháp đơn giản là hãy biết chính xác những gì bạn đang triển khai lên production. Giải pháp thực tế hơn là, nếu bạn định sử dụng AI rộng rãi, hãy xây dựng một quy trình trong đó các lập trình viên có năng lực sử dụng nó như một công cụ để hỗ trợ công việc của họ, chứ không phải là một cách để né tránh trách nhiệm. Và hãy làm ơn, đừng để CEO hoặc CTO của bạn viết code.

Bạn có thích bài viết này không? Bạn có thể mời tôi một ly cà phê. Chia sẻ những bình luận sâu sắc của bạn tại đây. Đăng ký bản tin của tôi Theo dõi tôi trên Twitter, Spotify, hoặc RSS Feed.