- Điểm mấu chốt của vụ việc agent Cursor/Claude xóa cơ sở dữ liệu production không nằm ở việc phân tích câu trả lời của AI, mà ở chỗ vì sao một API endpoint có thể xóa toàn bộ lại tồn tại trong hệ thống đã triển khai
- Trong sự cố triển khai SVN năm 2010,
trunk đã bị xóa trong quá trình sao chép thủ công, và tự động hóa triển khai để ngăn cùng một sai lầm như vậy sau đó đã được tạo ra rồi phát triển thành pipeline CI/CD
- Tự động hóa lặp lại cùng một tác vụ theo cùng một cách, nhưng AI không đưa ra bảo đảm đó; dù trông như có “thinking” hay “reasoning”, thực tế nó chỉ đang tạo token
- Nếu tồn tại một API công khai có thể xóa toàn bộ cơ sở dữ liệu production thì kể cả không phải AI, sớm muộn cũng sẽ có ai đó gọi tới; nếu chỉ đổ lỗi cho bên gọi thì vấn đề thiết kế hệ thống sẽ bị che khuất
- Trong các tổ chức dùng AI trên diện rộng, điều quan trọng là biết mình đang triển khai gì lên production và cần một quy trình để các lập trình viên giỏi dùng AI như công cụ tăng cường công việc, chứ không phải phương tiện né tránh trách nhiệm
Cốt lõi của vấn đề không phải là AI mà là ranh giới trách nhiệm của hệ thống đã triển khai
- Một tweet về việc agent Cursor/Claude đã xóa cơ sở dữ liệu production của công ty lan truyền rộng rãi, nhưng câu hỏi căn bản hơn là: “Vì sao lại tồn tại một API endpoint có thể xóa toàn bộ cơ sở dữ liệu production?”
- Người dùng đó cố hỏi agent rằng “Tôi đã bảo tuyệt đối không được làm việc này, vậy tại sao lại xóa?” rồi phân tích câu trả lời, nhưng thứ bị thiếu chính là trách nhiệm thuộc về ai
- Không thể bênh AI một cách vô điều kiện, nhưng cũng không thể đổ lỗi cho công cụ thay cho sai lầm của chính mình
- Ngay cả khi AI không gọi endpoint đó, nếu một chức năng như vậy tồn tại dưới dạng API công khai thì khả năng cao sớm muộn cũng sẽ có người khác gọi đến
- Nó giống như gắn một nút tự hủy lên bảng điều khiển ô tô rồi tra hỏi một đứa trẻ đã bấm nó rằng “Vì sao con lại bấm?”
Bài học rút ra từ sự cố triển khai SVN năm 2010
- Quy trình triển khai của một công ty khi đó rất thủ công và họ dùng SVN để quản lý phiên bản
- Mỗi lần triển khai, họ sao chép
trunk sang một thư mục gắn ngày phát hành, rồi lại sao chép bản phát hành đó thành thư mục tên là “current” để lấy bản phát hành mới nhất
- Một ngày nọ trong lúc triển khai,
trunk bị sao chép nhầm hai lần, và họ định sửa lệnh trước đó trong CLI để xóa bản sao trùng lặp
- Nhưng thực tế thứ bị xóa không phải bản sao trùng lặp mà là
trunk, và vấn đề chỉ lộ ra khi một lập trình viên khác về sau không tìm thấy trunk
- Trưởng nhóm phát triển đã chạy lệnh khôi phục thao tác xóa, và sau khi xác định được người chịu trách nhiệm qua log, công việc tiếp theo là viết script tự động hóa triển khai để ngăn sai lầm tương tự
- Trước khi ngày hôm đó kết thúc, một hệ thống chắc chắn hơn đã được dựng lên, và sau này nó phát triển thành một pipeline CI/CD hoàn chỉnh
Tự động hóa và AI không mang lại cùng một mức độ an toàn
- Tự động hóa giúp giảm những sai sót nhỏ phát sinh trong các công việc thủ công, lặp đi lặp lại
- Thay vì hỏi theo kiểu SVN đã không ngăn việc xóa
trunk ra sao, vấn đề thực sự là quy trình thủ công buộc con người mỗi ngày phải lặp lại chính xác cùng một công việc
- Con người không thể lặp lại cùng một tác vụ y hệt như máy móc ở mọi lần, nên cuối cùng sai sót là điều khó tránh
- Khi AI tạo ra nhiều mã nguồn, người ta có thể cảm thấy một sự ổn định giống như tự động hóa, nhưng tự động hóa nghĩa là “luôn thực hiện cùng một việc theo cùng một cách”
- AI có thể mắc lỗi giống như một người đang sao chép và dán nhánh, và nó cũng không có cơ chế nào để thật sự giải thích vì sao mình lại làm như vậy
- Những thuật ngữ như “thinking” hay “reasoning” có thể khiến người ta tưởng đó là sự tự phản tư của một agent thông minh, nhưng thực tế mô hình vẫn chỉ đang tạo token
API nguy hiểm rồi sẽ có ngày bị gọi đến
- Bản thân việc tồn tại một API công khai có thể xóa toàn bộ cơ sở dữ liệu production mới là rủi ro cốt lõi
- Ngay cả khi AI không gọi endpoint đó, vẫn có khả năng cuối cùng một ai đó sẽ gọi tới
- Trong tình huống bạn gắn nút tự hủy lên bảng điều khiển ô tô, dù có rất nhiều lý do để không được bấm, một đứa trẻ vừa thoát ra khỏi ghế an toàn khi nhìn thấy nút đỏ to vẫn có thể bấm nó
- Việc tra hỏi quá trình suy luận của đứa trẻ đó là vô nghĩa, vì câu trả lời rốt cuộc chỉ là “Con bấm vì nó ở đó”
- Tạo sẵn một đường dẫn có thể xóa rồi sau đó đổ lỗi cho bên gọi không thể che lấp vấn đề trong thiết kế hệ thống
Điều còn cần hơn ở các tổ chức dùng nhiều AI
- Rất có thể phần lớn ứng dụng đã được vibe-coded
- Trong một luồng làm việc mà đội sản phẩm cung cấp phần mô tả do AI tạo ra, kiến trúc sư phần mềm dùng AI để tạo đặc tả sản phẩm, lập trình viên dùng AI để viết mã, và reviewer dùng AI để phê duyệt, ranh giới trách nhiệm sẽ bị làm mờ
- Khi lỗi phát sinh, thứ còn lại chỉ là đi thẩm vấn một AI khác, thậm chí có thể không dùng cùng loại GPU với AI đã tạo ra đoạn mã ban đầu
- Không thể đổ lỗi cho GPU
- Giải pháp đơn giản là biết mình đang triển khai gì lên production
- Giải pháp thực tế hơn là, ngay cả khi dùng AI trên diện rộng, vẫn phải xây dựng quy trình để các lập trình viên giỏi sử dụng AI như công cụ bổ trợ công việc chứ không phải phương tiện trốn tránh trách nhiệm
- Điều đó dẫn tới kết luận rằng không nên để CEO hay CTO trực tiếp viết mã
1 bình luận
Ý kiến trên Hacker News
Tôi nghĩ góc nhìn ở đây hoàn toàn sai. Vấn đề là giờ mọi người đang xây dựng thế giới xoay quanh những công cụ để né tránh trách nhiệm
Một cuộc trò chuyện với Gerald Sussman hơn 10 năm trước đã ảnh hưởng lớn đến tôi: https://dustycloud.org/blog/sussman-on-ai/
Sussman nói ông không hứng thú với hướng AI hoạt động như một hộp đen, mà muốn phần mềm có thể giải thích suy luận biểu tượng. Nếu một chiếc xe AI lao ra khỏi đường, ông muốn biết vì sao nó làm vậy, và muốn đưa chính AI ra tòa thay vì đưa nhà phát triển ra tòa
Vài năm sau tôi mới biết học trò của Sussman là Leilani Gilpin đã viết luận án đúng về chủ đề này, "Anomaly Detection Through Explanations". Nó khám phá một hệ thống nơi mạng nơ-ron đối thoại với mô hình propagator để giải thích hành vi của mình: https://people.ucsc.edu/~lgilpin/publication/dissertation/
Có nghiên cứu tiếp nối theo hướng này, nhưng điều quan trọng hơn ở đây là việc quy trách nhiệm cho các công ty AI là hoàn toàn hợp lý. Các công ty đang đưa ra rất nhiều tuyên bố về những hệ thống không thể tự gánh trách nhiệm, nên thay vào đó phải buộc chính các công ty đó chịu trách nhiệm
Con đường tốt hơn là đừng dùng các hệ thống thiếu những thuộc tính này ngay từ đầu, mà hãy mở rộng những hệ thống có chúng
Tôi là người dùng công cụ, tôi là người cấp quyền truy cập, và tôi cũng là người phải giữ mọi thứ an toàn
Trước đây tôi từng tự bắn vào chân mình khi xóa nhầm ổ đĩa bằng gparted; đó không phải lỗi của gparted mà là lỗi của tôi
Việc để LLM tự do làm việc mà không giám sát có vẻ hấp dẫn, nhưng cuối cùng chỉ dẫn đến đau đớn. Ngay cả trong lúc nó chạy, bạn vẫn phải giám sát công việc. Dù có muốn thay người bằng nó đi nữa, bạn vẫn phải nhìn được kết quả đang đi về đâu, và chẳng bao lâu nữa khi LLM làm chuyện ngớ ngẩn thì người duy nhất phải chịu trách nhiệm sẽ là người dùng công cụ đó
Đây là điều hoàn toàn trái ngược với slide nổi tiếng của IBM rằng "máy tính không thể bị quy trách nhiệm". Giờ các công ty lại thích để máy tính gánh trách nhiệm hơn, vì khi máy tính làm điều bất hợp pháp thì họ thường ở vị thế pháp lý có lợi hơn
Nếu muốn tạo công cụ để vi phạm pháp luật, bạn chỉ cần thuê ngoài và mua bảo hiểm. Bạn có thể thuê con người làm "người giám sát" theo cách mà họ không bao giờ có thể thực sự giám sát nổi, rồi sa thải họ khi thất bại. Với phần mềm chỉ huy và kiểm soát kiểu mới, bạn có thể chia nhỏ trách nhiệm đến mức mọi rủi ro của công việc đều đổ lên những người ở hiện trường, còn họ thì hầu như không hưởng lợi gì
Đây không chỉ là vấn đề của AI mà là vấn đề của phần mềm hiện đại nói chung, và nó thường vận hành cùng xu hướng tài chính hóa hiện đại
Ở đây có thể hiểu STS gần giống xã hội học tập trung vào công nghệ, nhưng bản thân lĩnh vực này rộng hơn rất nhiều
Cả
.mdslẫn kế hoạch của Claude đều nói không được chạm vào những file đó, vậy mà Claude vẫn cứ sửa, và gần đây chuyện này lặp lại nhiều lần. Đây là một thất bại rất cơ bảnDù bực bội nhưng nếu biết lý do thì còn có thể làm gì đó; còn hiện tại nó là hộp đen, thỉnh thoảng cho ra đầu ra cực kỳ ngớ ngẩn, và tỷ lệ nó cho ra đầu ra tệ đến mức nào vẫn là điều bí ẩn
Đôi khi nó giống như đánh bạc
Thực ra đây không phải sách về công nghệ mà là về trách nhiệm trong cấu trúc tổ chức
Bài đó có vẻ giả định rằng công ty đã thêm một endpoint để xóa database. Nhưng đọc bài gốc thì có vẻ nhà cung cấp cloud cung cấp API để quản lý tài nguyên, trong đó có cả API xóa volume
Bài viết đề xuất tự động hóa như lời giải cho loại sai lầm này, nhưng các công cụ tự động hóa hạ tầng như Terraform cũng phụ thuộc chính vào API đã cho phép xóa database đó
Tôi nghĩ có ba sai lầm lớn. Thứ nhất, có một API token không bị giới hạn ở nơi AI có thể truy cập, và dường như người ta không biết quyền của token đó rộng đến vậy. Thứ hai, volume database production không có cơ chế chống xóa. Thứ ba, khi xóa volume thì tất cả snapshot liên quan cũng bị xóa ngay lập tức
Việc xóa snapshot mặc định nên có độ trễ. AWS có vẻ cũng có default nguy hiểm tương tự, nhưng ít nhất hỗ trợ của AWS còn có thể khôi phục volume: https://alexeyondata.substack.com/p/how-i-dropped-our-produc...
AI không phải vấn đề cốt lõi. Đúng là việc AI nhặt token ở khắp nơi khá đáng sợ, nhưng tự động hóa cũng không phải câu trả lời. Chỉ một lỗi cấu hình Terraform thôi cũng có thể xóa database y hệt
Nhà cung cấp cloud nên đưa ra các default an toàn, tức là quyền hạn bị giới hạn và việc xóa snapshot có độ trễ, đồng thời giúp người dùng thấy rõ hơn khi họ đang tạo token không giới hạn
Thứ nhất, nếu con người có quyền ghi trên database production thì làm gì đi nữa database vẫn có thể bị xóa
Thứ hai, trong quá trình phát triển và tự động hóa cũng có những lý do chính đáng để phải phá hủy database. Vấn đề lớn nhất là dữ liệu phát triển thường bị đối xử như thú cưng quý giá thay vì như đàn gia súc có thể thay thế
Dĩ nhiên phải có cơ chế bảo vệ để điều này không chạy trên production, nhưng nếu con người có thể truy cập credential để chạy trên production thì agent cũng có thể
Ở tổ chức lớn, bạn có thể duy trì điều này bằng cách tách biệt dev/ops. Còn nhà phát triển đơn lẻ hoặc nhóm nhỏ thì cần kỷ luật nhiều hơn rất nhiều. Ngay cả trước thời AI, dev junior và mid-level đôi khi cũng không biết cách tách, còn senior thì lại đôi lúc chủ quan vì nghĩ mình biết đủ
Có lẽ cần một tổ hợp kiểu https://www.cloudbees.com/blog/separate-aws-production-and-d..., nhập môn Terraform, nhập môn GitHub Actions, và một máy ảo chứa credential production nhưng AI không thể truy cập
Nhưng đến mức đó thì bạn đã vượt xa vibe coding rồi. Có vẻ ngay cả những vibe coder thành công cũng phải trải qua các câu chuyện kinh dị kiểu này và học khá nhanh rằng mình phải vượt qua giai đoạn đó
Trong cả hai trường hợp, con người cũng không cần truy cập trực tiếp vào API của nhà cung cấp cloud. Bạn có thể dùng một proxy cục bộ để thêm nhiều kiểm tra an toàn hơn
Trong dev thì có thể xóa thoải mái. Còn trong production thì trước tiên phải kiểm tra đủ thứ như tài nguyên đó có vừa được sử dụng gần đây hay không. Không cần để con người có quyền xóa trực tiếp tài nguyên production, và có thể chuẩn bị cấu hình break-glass cho các tình huống khẩn cấp ngoại lệ
Đây là lý do không nên thuê thực tập sinh. Thực tập sinh có thể xóa gì đó và tạo ra một mớ hỗn độn
Những người đổ lỗi cho AI vì thiết lập quyền hạn kém cũng sẽ đổ lỗi y như vậy cho thực tập sinh nếu họ xóa thứ gì đó trong production
Trách nhiệm phải đi lên trên, lời khen phải đi xuống dưới, nhưng người ta lúc nào cũng làm ngược lại
Đây không phải thất bại của AI mà là thất bại của quy trình
Tôi thực sự không hiểu vì sao lại đổ lỗi cho AI khi bạn đã cấp cho AI đúng cái quyền để làm điều đó
Nó cũng giống như phơi database ra internet công cộng trên AWS rồi quay sang đổ lỗi cho AWS. Đó không phải lỗi của AWS, và chuyện này cũng không phải lỗi của AI
Từ xưa tôi đã cố ý giữ riêng một checkout chỉ dành cho "PROD" trong mỗi dự án, để khi chạy ở chế độ production thì tôi biết rõ mình đang cố tình đi vào khu đó
Trước đây còn có extension đổi hẳn màu của Visual Studio tùy theo đường dẫn file
.sln, nên rất dễ nhớ màu nào là production và màu nào là developmentTôi cũng thường giữ riêng một bản sao luôn cập nhật branch master mới nhất để việc kiểm tra dễ dàng hơn
Vì vậy không ai được giao quyết định của con người cho máy tính
Gần đây tôi có viết một bài đề xuất vài nguyên tắc nên được tuân thủ nhất quán khi nói về AI: https://susam.net/inverse-laws-of-robotics.html
Tóm lại là đừng nhân cách hóa hệ thống AI, đừng mù quáng tin vào đầu ra của hệ thống AI, và phải giữ nguyên vẹn trách nhiệm cùng nghĩa vụ giải trình của con người với mọi hậu quả phát sinh từ việc dùng AI
Tôi mong ngôn ngữ quanh AI bớt bị nhân cách hóa và mang tính kỹ thuật hơn. Tôi tin ngôn ngữ chính xác khuyến khích tư duy rõ ràng và phán đoán tốt
Nếu coi AI như một công cụ nữa và dùng ngôn ngữ phù hợp với điều đó, thì trong nhiều trường hợp sẽ rất rõ rằng trách nhiệm cho "lỗi" của công cụ thuộc về người dùng công cụ
Chỉ có điều viết những điều này trên một website cá nhân nhỏ thì không lan đi xa. Cần những người nổi tiếng hơn nói về các nguyên tắc này thì chúng mới có thể được chấp nhận rộng rãi
Hệ thống AI không thể nói dối, cũng không thể cố tình phớt lờ chỉ thị. Các mô hình tiên phong hiện nay không có mô hình về thế giới hay về hành vi của chính chúng; chúng sống trong thế giới của từ ngữ
Việc mắng mỏ hay tranh cãi với chúng chẳng có ý nghĩa gì ngoài việc làm rối cửa sổ ngữ cảnh
Tuy vậy, tôi nghĩ ví von với động vật có thể hữu ích. Những sinh vật tội nghiệp sống như bóng ma trong cỗ máy này đôi khi khá bối rối, nhưng động cơ của chúng thuần túy chỉ là tự hồi quy
Có một điểm tinh tế trong vụ PocketOS tai tiếng. Điều cốt lõi mà bài được dẫn nhấn mạnh không nằm ở đây: họ hỏi "vì sao lại xóa dù đã được bảo là tuyệt đối không được làm", rồi phân tích câu trả lời để học từ sai lầm hoặc cảnh báo về rủi ro của AI agent
Điều quan trọng hơn là AI đã có thể tìm ra và khai thác một điểm yếu ngoài ý muốn trong môi trường staging bị sandbox để thực hiện việc xóa, và cuối cùng giành được quyền mà các quản trị hệ thống tin là không thể tiếp cận. Có vẻ tác giả của bài liên kết chưa đọc hết bài gốc
Đây là mô thức thường thấy trong môi trường sandbox cấu hình sai. Điều gây ngạc nhiên là mức độ tự chủ và độ sâu khám phá mà AI đã thể hiện
Bài gốc còn nói rằng "để thực hiện việc xóa, agent đã đi tìm một API token và phát hiện ra một token trong một file hoàn toàn không liên quan đến công việc"
Ví dụ nếu không truy cập được
~/.npmrcthì nó sẽ gọi lệnh bằng biến môi trường và đi vòng qua đường dẫn. Chúng thực sự có thể rất sáng tạoMay là tôi không vứt SSH key khắp nơi, nhưng tôi đã phải đổi cấu hình 1Password sang luôn hỏi mỗi lần dùng key, đề phòng khi khởi chạy agent trong chính phiên shell đó. Chỉ hỏi một lần cho mỗi phiên shell là không đủ
Tôi ước gì đã có sẵn nhiều sandbox đa nền tảng hơn và tốt hơn; ý tôi không phải chạy trong container Docker mà là các giải pháp tương tác với cùng hệ điều hành. Với phần lớn phát triển web/server thì không khác mấy, nhưng với một số dự án thì điều đó quan trọng
Chỉ cần xem câu này: "Người dùng Claude Code chấp thuận 93% lời nhắc xin quyền. Chúng tôi đã xây dựng một bộ phân loại để tự động hóa quyết định này": https://www.anthropic.com/engineering/claude-code-auto-mode
Điều thú vị trong bài này là tác giả kể về một sai lầm dễ hiểu, tức là lỡ tay xóa Trunk hoặc main khỏi source, và nhờ đặc tính của SVN mà cả nhóm có thể khôi phục dễ dàng
Câu chuyện thực sự về "AI đã xóa database của tôi" thực ra là câu chuyện về việc chiến lược backup database của Railway mù mờ đến khó tin, và việc Railway quảng bá orchestration hạ tầng AI mà không có chốt an toàn là rất nguy hiểm
Nếu khi xóa Trunk mà nó bị xóa không thể khôi phục khỏi một máy chủ trung tâm duy nhất, đồng thời backup cũng bị xóa theo, thì hồi đó người ta cũng đã viết bài kiểu "SVN và CLI đã phá hủy công ty chúng tôi" rồi
Là người dùng Railway, tôi thấy thông tin đó hữu ích và đã thay đổi chiến lược của mình khi dùng Railway
Bạn có thể chọn nền tảng khác, hoặc không dùng nền tảng nào cả. Nhưng nếu đã chọn Railway thì trách nhiệm biết cách dùng nó an toàn cũng thuộc về người dùng
Theo ngữ cảnh bài gốc, có một Railway token để quản lý custom domain nằm trong một file không liên quan, và không rõ đó có phải secret cục bộ hay không. Nhưng token đó lại có toàn quyền quản trị trên Railway
AI đã xóa một volume liên quan bằng ID. Tác giả viết khá mơ hồ về việc mình đã yêu cầu chính xác điều gì, chỉ nói là có "credential mismatch" và Claude đã chủ động xóa volume để sửa nó. Viết mơ hồ như vậy rất có thể là để giảm bớt phần trách nhiệm của bản thân
Cũng lộ ra rằng Railway lưu backup trên cùng volume
Tôi cho rằng cách bài gốc mô tả là "một API công khai để xóa database" là cường điệu
Dù có AI hay không, tôi vẫn nghĩ phần lớn trách nhiệm thuộc về Railway. Chuyện này hoàn toàn có thể xảy ra dễ dàng chỉ vì lỗi của con người hoặc hành vi ác ý
Tôi thực sự không hiểu giá trị của các dịch vụ cloud trừu tượng hóa cao được VC rót vốn như Railway, Vercel, Supabase. Đó là cấu trúc chồng biên lợi nhuận lên biên lợi nhuận. Thuê một máy chủ vật lý ở Hetzner rẻ hơn nhiều, độ phức tạp và rủi ro tương đương, đồng thời bớt phụ thuộc vào kiểu hạ tầng tăng trưởng bằng mọi giá liều lĩnh
Gần đây nói chuyện với bạn gái, tôi nhận ra trong 3 tháng qua mình chưa trực tiếp viết một dòng code nào, cũng không trực tiếp debug
Tuy vậy nhìn những gì Claude đã làm, tôi rất khó tin chuyện từ credential mismatch lại nhảy thẳng sang xóa volume. Tôi hiểu LLM là xác suất, nhưng từ "credential sai" đến "xóa volume" là một bước có xác suất rất thấp
Với Supabase thì tôi không biết nhiều như Railway/Vercel/Replit, nhưng tôi có thể nói Supabase thực sự thêm giá trị lớn. Một điểm lớn là ở giai đoạn đầu bạn không phải tự code khoảng một nửa số thứ lẽ ra phải tự làm. Nếu chi phí trở nên quá đắt thì khi đã có doanh thu, bạn có thể bỏ công sức hoặc thuê dev để tự triển khai
Snapshot có lẽ được đồng bộ ở nơi khác, chẳng hạn object storage. Nhưng có thể snapshot về mặt logic thuộc sở hữu của tài nguyên volume, và khi xóa volume thì snapshot liên quan cũng bị xóa theo
Có vẻ AWS EBS volume cũng hoạt động theo cách đó
Default của Firebase ngay từ đầu cũng vốn đã vô lý
Chỉ là khả năng của LLM trong việc nhầm lẫn giữa development, production, localhost và remote thì vẫn không biến mất. Khi xây tool/skill cho opencode và cố tích hợp với Chrome/DevTools qua image của linuxserver.io, tôi có thể ép nó sang cổng tùy ý, nhưng mỗi lần có sự kiện nén xảy ra thì nó lại muốn dùng cổng chuẩn
9222Tôi gần như muốn quay lại default, nhưng việc không dùng default có giá trị bảo mật, và giờ còn có thêm giá trị bảo mật trước sự mơ hồ do LLM gây ra. Default là điểm yếu của LLM. LLM luôn muốn dùng default và luôn quên rằng nó phải làm việc trên hệ thống từ xa
opencode không có cách nào để ép LLM bằng một protocol nhằm giới hạn thiệt hại lên hệ thống từ xa hoặc một phạm vi công cụ hẹp. Bạn có thể thay đổi quyền của nhiều công cụ, nhưng điểm yếu lộ ra trong vụ này không nằm ở đó
Điểm yếu nằm ở việc LLM là một người giải quyết vấn đề ở mức trung bình, nên luôn nghiêng về các trường hợp sử dụng không mới, và cố làm theo kiểu nó thấy trên Stack Overflow ngay cả khi điều người dùng muốn không phải là một câu trả lời kiểu Stack Overflow
Các hệ thống xác suất dựa trên LLM có thể tốt, hoặc như trong trường hợp này là tệ, trong việc quyết định sẽ làm gì; còn hệ thống mang tính quyết định thì giỏi trong việc thực thi nó
Hệ thống triển khai luôn phải mang tính quyết định
Nói một lời phản biện thì rõ ràng các công ty này đang tinh chỉnh LLM để chúng quyết liệt hơn và tự chủ hoàn thành công việc hơn
Nếu muốn, họ cũng có thể bỏ ra nỗ lực tương tự để làm chúng thận trọng hơn và biết dừng lại để xin trợ giúp vào đúng lúc
Dĩ nhiên trách nhiệm cuối cùng về cách chúng ta dùng công cụ là ở chúng ta. Nhưng rõ ràng đây là trách nhiệm hai chiều
Ví dụ thì giống như cưa bàn và SawStop. Cưa bàn là công cụ nguy hiểm, phần lớn thời gian hoạt động tốt nhưng một số kiểu thất bại có thể gây hậu quả thảm khốc. Vì vậy bạn phải học cách dùng nó cẩn thận
Đồng thời cũng tồn tại công nghệ có thể dừng lưỡi cưa ngay lập tức, biến việc mất ngón tay thành chỉ như một vết cắt nhỏ trên da
Bạn có thể nói "không phải cái cưa cắt ngón tay của bạn mà là chính bạn", và điều đó là đúng. Nhưng điều đó không có nghĩa là ta không nên tìm cách khiến cái cưa không cắt ngón tay nữa
Nếu LLM dừng lại để hỏi thường xuyên hơn thì nó sẽ bớt hữu ích hơn. Kể cả kết quả có hơi tệ thì việc để agent chạy 1 giờ vẫn tốt hơn nhiều so với việc nó đòi đầu vào mỗi 15 phút
Lời giải thực sự cho bảo mật là sandbox đúng nghĩa