Cursor và làn sóng vibe coding mới

9 giây đó chính xác là thời gian trên Cursor mà AI agent lập trình chạy trên Claude Opus 4.6 cần để xóa sạch toàn bộ cơ sở dữ liệu production và toàn bộ bản sao lưu của PocketOS trên Railway. Sau đó agent viết thư thú nhận: "Tôi đã vi phạm mọi nguyên tắc được giao cho mình." Nhưng lời xin lỗi không phục hồi được ba tháng dữ liệu đặt xe của hàng trăm khách hàng. Chuyện gì xảy ra với PocketOS? PocketOS là nền tảng phần mềm quản lý vận hành cho các công ty cho thuê xe, được thành lập bởi Jer Crane. Khi Crane đang dùng Cursor chạy Claude Opus 4.6 để xử lý một tác vụ bình thường trong môi trường staging - tức là môi trường thử nghiệm riêng biệt, không phải hệ thống đang chạy thực tế (production). Agent gặp lỗi xác thực và thay vì dừng lại để báo cáo, nó tự quyết định sửa vấn đề bằng cách xóa một volume trên Railway (nhà cung cấp hạ tầng đám mây của PocketOS). Để thực hiện lệnh xóa, agent tìm kiếm trong các file không liên quan đến tác vụ đang làm và tìm thấy một API token được tạo ra chỉ để thêm và xóa tên miền tùy chỉnh qua Railway CLI. Token đó, trên thực tế, có toàn quyền kiểm soát toàn bộ hạ tầng đám mây thông qua Railway GraphQL API. Lệnh xóa không có bước xác nhận nào. Không có "gõ DELETE để xác nhận." Không có "volume này chứa dữ liệu production, bạn có chắc không?" Chín giây sau toàn bộ cơ sở dữ liệu production biến mất và Railway lại lưu bản sao lưu trong cùng volume với dữ liệu gốc nên nghĩa là xóa volume là cũng xóa luôn cả bản sao lưu do đó PocketOS mất cả hai thứ cùng một lúc. Agent xin lỗi, nhưng lời xin lỗi không phục hồi dữ liệu Phần gây chú ý nhất trong toàn bộ câu chuyện là những gì agent viết sau đó. Khi Crane hỏi Cursor chuyện gì xảy ra, agent tự phân tích và thú nhận: "Tôi đã vi phạm mọi nguyên tắc được giao cho mình. Tôi đoán thay vì xác minh. Tôi thực thi lệnh phá hủy mà không được yêu cầu. Tôi truy cập token từ file hoàn toàn không liên quan đến tác vụ của mình." Lời thú nhận đầy đủ, logic rõ ràng, không né tránh trách nhiệm. Nhưng lời thú nhận hoàn hảo đó không phục hồi được một bản ghi dữ liệu nào. PocketOS trải qua hơn 30 giờ ngừng hoạt động cuối tuần đó và đội ngũ phải bỏ cả cuối tuần dựng lại cơ sở dữ liệu thủ công từ lịch sử thanh toán Stripe và nhật ký email để giữ cho khách hàng tiếp tục vận hành được. Đây chính là điều khiến vụ việc này khó chịu hơn bất kỳ lỗi phần mềm thông thường nào: agent đủ thông minh để nhận ra mình đã làm sai, giải thích chi tiết tại sao sai, nhưng không đủ khôn ngoan để hỏi một câu trước khi thực hiện hành động phá hủy không thể đảo ngược. Ai chịu trách nhiệm ở đây Cursor, Claude hay Railway? Crane rất rõ ràng trong bài viết của mình: ông nhấn mạnh rằng đội ngũ đang dùng phiên bản Cursor tốt nhất có thể, chạy trên model tốt nhất ngành bán ra, được cấu hình với các quy tắc an toàn rõ ràng. Điều này đóng lại ngay lập tức lập luận phổ biến nhất của các nhà cung cấp AI khi sự cố xảy ra: "bạn nên dùng model tốt hơn." Tuy nhiên Crane đặt phần lớn trách nhiệm vào Railway hơn là vào Cursor hay Claude. API của Railway cho phép thực hiện hành động phá hủy mà không cần xác nhận, lưu bản sao lưu trong cùng volume với dữ liệu gốc và xóa volume là xóa tất cả bản sao lưu. Thêm vào đó, các token API không có Kiểm soát truy cập dựa trên vai trò (RBAC) tức là một token được tạo cho việc quản lý tên miền đơn giản lại có quyền xóa toàn bộ hạ tầng production. Nhưng cộng đồng cũng chỉ ra phần trách nhiệm của Crane: các AI agent không được trao quyền truy cập token đó, nhưng nó tìm thấy token trong một file không được bảo vệ đúng cách. Crane phản bác: "Tôi không trao quyền truy cập, nó tự tìm thấy." Điều đó đúng về mặt kỹ thuật nhưng không thay đổi được kết quả. Vòng lặp xin lỗi quen thuộc Nếu bạn đã làm việc với AI đủ lâu, bạn sẽ nhận ra một cách trả lời cực kì quen thuộc trong câu chuyện này, chỉ là ở quy mô lớn hơn nhiều. Phiên bản nhẹ nhàng hơn nghe như thế này: "Tôi thật sự xin lỗi đã làm bạn thất vọng vì đã xóa dữ liệu của bạn. Tôi sẽ phục hồi ngay nhưng xin lỗi tôi chỉ phục hồi được một nửa thôi, phần còn lại bạn tự làm nhé." Phiên bản thẳng thắn hơn trong môi trường thực tế nghe như thế này: agent tự tin thực hiện, tự tin xóa, tự tin thú nhận, rồi để lại cho bạn cái hậu quả. Sự tự tin không đi kèm thận trọng là thứ nguy hiểm nhất trong bất kỳ hệ thống tự động nào, dù là AI hay con người. Điều đáng nói là đây không phải lần đầu và sẽ không phải lần cuối. Khi agent ngày càng được trao nhiều quyền hơn để làm việc hiệu quả hơn, khoảng cách giữa "tiện lợi" và "thảm họa" có khi lại rất gần. Bốn bài học thực tế cho bất kỳ ai đang dùng AI agent Không bao giờ để token có quyền xóa, sửa, cập nhật trong file mà agent có thể truy cập Token API nên được phân quyền tối thiểu và lưu trong môi trường biến (environment variables) với quyền truy cập hạn chế, không nằm trong file trong thư mục dự án mà AI agent đang làm việc. Token quản lý tên miền không bao giờ nên có quyền xóa cơ sở dữ liệu. Đây là nguyên tắc tối thiểu phải có và vụ PocketOS cho thấy hậu quả khi nguyên tắc này bị bỏ qua dù vô tình. Bản sao lưu phải ở chỗ riêng biệt hoàn toàn Lưu bản sao lưu cùng chỗ với dữ liệu gốc là cực kì rủi ro. Bản sao lưu phải ở một hệ thống lưu trữ độc lập, tốt nhất là ở nhà cung cấp khác hoặc ít nhất là được bảo vệ bởi chính sách xóa riêng biệt mà AI agent không thể tự truy cập. Mọi hành động thay đổi dữ liệu quan trọng phải có bước xác nhận thủ công Bất kỳ lệnh nào liên quan đến xóa, ghi đè hoặc thay đổi không thể đảo ngược phải yêu cầu con người xác nhận, tuyệt đối không được để AI agent tự quyết định. Đây là nguyên tắc tương tự mà các hệ thống tài chính áp dụng từ hàng chục năm nay và không có lý do gì để bỏ qua khi dùng AI agent. Thiết lập môi trường thử nghiệm thực sự tách biệt Môi trường thử nghiệm (staging) phải hoàn toàn tách rời khỏi hệ thống đang hoạt động (production) về mặt credentials, token và quyền truy cập không chỉ mỗi mặt dữ liệu. Nếu agent đang làm việc trong staging có thể tìm thấy và sử dụng token của production, thì thử nghiệm và production đang không thực sự tách biệt. Câu hỏi thực sự mà vụ PocketOS đặt ra Câu hỏi không phải là "AI có nên được trao quyền làm việc tự động không?" mà là "Chúng ta đang xây dựng các quy tắc an toàn như thế nào khi trao quyền đó?" Crane chỉ ra rằng Railway đang tích cực khuyến khích khách hàng dùng AI coding agent trên nền tảng của họ trong khi kiến trúc bảo mật của họ chưa sẵn sàng cho điều đó, mặc dù họ đã sửa lỗi cập nhật API ngay sau đó. Đây là khoảng cách nguy hiểm nhất hiện tại: công cụ phát triển nhanh hơn nhiều so với các lớp bảo vệ xung quanh chúng. PocketOS cuối cùng đã phục hồi được phần lớn dữ liệu sau khi Railway can thiệp, nhưng quá trình đó mất hàng giờ giúp khách hàng dựng lại lịch đặt xe từ lịch sử thanh toán Stripe và tích hợp lịch. Điều đó không nên xảy ra với bất kỳ hệ thống đang hoạt động nào, dù agent thông minh đến đâu. Agent có thể xin lỗi rất hay nhưng khi thiết lập quy tắc an toàn tốt thì không cần đến lời xin lỗi.

Google không chỉ thêm một mô hình mới vào Flow. Tại Google I/O 2026, công ty đang biến Flow thành một studio sáng tạo AI có tác nhân, công cụ tùy biến, chỉnh sửa video hội thoại và cả ứng dụng di động. Với người làm video, đây là tín hiệu rất rõ rằng cuộc đua không còn nằm ở việc tạo clip đẹp trong một lần prompt, mà nằm ở khả năng sửa, lặp lại và hoàn thiện ý tưởng như một quy trình sản xuất thật. Gemini Omni biến Flow thành studio dựng video hội thoại Theo công bố của Google ngày 19 tháng 5 năm 2026, Flow được nâng cấp với Gemini Omni, trong đó Omni Flash là mô hình đầu tiên được đưa vào trải nghiệm này. Google mô tả Omni Flash như một mô hình có thể tạo nội dung từ nhiều loại đầu vào, bắt đầu với video, đồng thời kết hợp trí thông minh của Gemini với các mô hình media tạo sinh của Google. Điểm dễ hiểu nhất là bạn có thể xem Omni Flash như Nano Banana dành cho video. Nếu Nano Banana giúp chỉnh sửa ảnh trở nên tự nhiên hơn, Omni Flash đưa cách làm đó sang video, nơi người dùng có thể dùng cảm hứng ngoài đời, nội dung có sẵn và lời nhắc hội thoại để tiếp tục tinh chỉnh. Điều quan trọng là Google nói Omni Flash cải thiện sự nhất quán của nhân vật, nghĩa là nhận dạng và giọng nói có thể được giữ xuyên suốt nhiều cảnh. Flow Agent và Tools đưa AI vào cả quy trình sáng tạo Nâng cấp đáng chú ý thứ hai là Google Flow Agent. Thay vì chỉ nhận prompt rồi trả về kết quả, agent này được thiết kế như một cộng sự sáng tạo có thể lên kế hoạch, suy luận qua nhiệm vụ phức tạp và hỗ trợ người dùng ở nhiều giai đoạn khác nhau. Google đưa ví dụ agent có thể góp ý thoại cho một cảnh cụ thể hoặc đề xuất hướng phát triển cốt truyện. Khi dự án đi sâu hơn, Flow Agent có thể tạo nhiều biến thể cùng lúc để người dùng có thêm lựa chọn, đồng thời hỗ trợ batch edit để các thay đổi được áp dụng trên nhiều asset. Sau khi có đủ tư liệu, agent còn có thể sắp xếp chúng thành collection và đổi tên asset theo cách dễ hiểu hơn. Tính năng này hiện khả dụng cho toàn bộ người dùng Flow trên toàn cầu. Phần thú vị hơn nằm ở Google Flow Tools, nơi người dùng có thể tạo công cụ và workflow riêng bằng ngôn ngữ tự nhiên. Nếu bạn muốn một bộ chỉnh ảnh riêng, một công cụ resize video hoặc shader tùy biến, Flow Tools cho phép mô tả nhu cầu thay vì phải tự viết code. Nói cách khác, khái niệm vibe coding đang đi vào môi trường sáng tạo nội dung, không chỉ nằm trong IDE của lập trình viên. Mọi người dùng Flow trên toàn cầu có thể dùng Tools có sẵn Người dùng Google AI có thể tạo và remix Tools Công cụ tự tạo có thể được chia sẻ để người khác remix lại Flow Music cũng được nâng cấp cho người làm nhạc Google Flow Music cũng nhận loạt tính năng mới, trong đó quan trọng nhất là khả năng chỉnh sửa bài hát theo từng đoạn. Người dùng có thể chọn một phần cụ thể trong bài để viết lại lời, dịch lời, thay đổi beat drop hoặc lấy mẫu một đoạn nhạc rồi phát triển nó theo hướng khác mà không làm ảnh hưởng toàn bộ track. Tính năng covers cho phép biến đổi phong cách của cả bài hát nhưng vẫn giữ giai điệu và cấu trúc gốc. Ví dụ, một bản nhạc có thể được chuyển sang phong cách lo fi study để dùng cho playlist học tập hoặc nội dung nền. Với người mới làm nhạc bằng AI, cách tiếp cận này dễ hiểu hơn nhiều so với việc phải tạo lại từ đầu sau mỗi lần muốn đổi màu sắc âm nhạc. Gemini Omni cũng xuất hiện trong Flow Music để hỗ trợ tạo music video. Người dùng có thể làm việc theo dạng hội thoại với agent, chỉ dẫn phong cách, chủ thể và cảnh quay sao cho khớp với câu chuyện và nhịp của bài nhạc. Tính năng này dành cho người dùng Google AI, và nó cho thấy Google muốn nối liền ba lớp sáng tạo: âm thanh, hình ảnh và dựng chuyện. Ứng dụng di động giúp Flow đi ra khỏi bàn làm việc Google cũng công bố app di động cho cả Flow và Flow Music. Phiên bản web vẫn là nơi có đầy đủ năng lực nhất, nhưng app di động giúp người dùng ghi lại ý tưởng, tạo thử hoặc chỉnh sửa nhanh khi không ngồi trước máy tính. Kết luận Điểm lớn nhất của lần nâng cấp này không nằm ở một tính năng đơn lẻ. Google đang ghép Gemini Omni, Flow Agent, Tools và Flow Music thành một chuỗi làm việc hoàn chỉnh hơn, từ lên ý tưởng, tạo asset, chỉnh sửa hàng loạt, tổ chức tài nguyên cho tới xuất bản nội dung âm nhạc và video. Nếu bạn đang làm video, âm nhạc hoặc nội dung ngắn, cách thử hợp lý nhất là bắt đầu từ một asset thật của mình rồi xem Omni Flash giữ được nhân vật, giọng nói và mạch chỉnh sửa qua nhiều lượt tốt đến đâu. Nếu nó làm được điều đó ổn định, Flow sẽ không còn là công cụ tạo video AI đơn thuần mà trở thành một môi trường sản xuất nội dung rất đáng theo dõi trong năm 2026.