Google I/O 2026: Antigravity 2.0 cải tiến lớn nhưng giao diện lại giống Codex

Bạn có bao giờ mở một bài viết dài 3.000 chữ trên web trong điện thoại rồi không biết nên đọc hay thoát ra không? Mozilla có câu trả lời: lắc điện thoại. Tính năng "Shake to Summarize" từng được TIME vinh danh là một trong những phát minh tốt nhất năm 2025 vừa chính thức ra mắt trên Android cùng với Firefox 150. Shake to Summarize là gì và nó hoạt động ra sao? Shake to Summarize là tính năng AI tích hợp sẵn trong trình duyệt Firefox, cho phép người dùng nhận ngay bản tóm tắt nội dung của bất kỳ trang web nào mà không cần rời khỏi trình duyệt hay mở thêm ứng dụng nào khác. Để kích hoạt, người dùng có ba cách: Lắc điện thoại trong khi đang xem trang web Nhấn biểu tượng sấm sét trên thanh địa chỉ Vào menu ba chấm → Summarize Page Sau vài giây, Firefox mở một bảng nhỏ và hiển thị các ý chính của trang. Điểm đáng chú ý là bản tóm tắt thích nghi theo loại nội dung — công thức nấu ăn thì rút ra các bước cần làm, bài thể thao thì tập trung vào tỷ số và thống kê, bài tin tức thì làm nổi bật những diễn biến then chốt. Tính năng hoạt động với các trang dưới 5.000 từ. Với các trang dài hơn, Firefox sẽ không thể tạo tóm tắt. Hành trình từ iOS đến Android Shake to Summarize ra mắt lần đầu trên iOS vào tháng 9 năm 2025, ban đầu chỉ dành cho người dùng tại Mỹ với giao diện tiếng Anh. Phản hồi tích cực đến mức Mozilla nhận được đề cử đặc biệt từ TIME Best Inventions 2025 một giải thưởng hiếm khi dành cho tính năng của trình duyệt. Phiên bản Android đi qua giai đoạn thử nghiệm kỹ lưỡng trên Firefox Nightly trước khi được đưa vào bản chính thức Firefox 150, phát hành tháng 4 năm 2026. Trước đó, muốn dùng thử trên Android, người dùng phải mở Settings → About Firefox Nightly → nhấn logo ba lần để vào "Secret Settings" rồi bật thủ công — một quy trình rõ ràng là chỉ dành cho người dùng kỹ thuật. AI nào đứng sau tính năng này? Mozilla không dùng một mô hình duy nhất mà phân chia theo thiết bị: Với iPhone 15 Pro trở lên chạy iOS 26+, tóm tắt được tạo hoàn toàn trên máy nhờ Apple Intelligence dữ liệu không rời khỏi thiết bị. Với các thiết bị còn lại, nội dung trang được gửi đến máy chủ AI của Mozilla, xử lý xong rồi trả kết quả về. Về phía Mozilla, đội ngũ kỹ thuật đã thử nghiệm nhiều mô hình gồm Mistral Nemo, Mistral Small, Jamba 1.5 Mini, Gemini Flash 2.0 và Llama 4 Maverick trước khi chọn Mistral Small làm mô hình chính. Lý do: Mistral Small có trọng số mở (open weights), tốc độ xử lý nhanh và chi phí inference thấp hơn đáng kể so với các đối thủ — trong khi chất lượng tóm tắt vẫn ở mức cao. Mozilla cung cấp Shake to Summarize miễn phí và tự chịu toàn bộ chi phí inference, không tính phí người dùng. Người dùng không muốn AI thì sao? Đây là điểm Mozilla xử lý khá khéo. Sau khi bị phản ứng từ cộng đồng người dùng lâu năm những người lo ngại Firefox đang rời bỏ giá trị cốt lõi về quyền riêng tư Mozilla đã thêm nút tắt toàn bộ tính năng AI trong cài đặt trình duyệt. Trên desktop, tùy chọn "Block AI enhancements" cho phép tắt tất cả tính năng AI hiện tại lẫn tương lai, hoặc chọn lọc từng tính năng muốn giữ. Trên Android, Shake to Summarize được liên kết với bộ điều khiển AI Controls mới cả khi tắt AI, cả cử chỉ lắc và nút tóm tắt đều bị vô hiệu hóa đồng thời. Tính năng hiện chỉ hỗ trợ nội dung tiếng Anh. Người dùng tại Việt Nam muốn dùng cần chuyển ngôn ngữ hệ thống hoặc chờ Mozilla mở rộng hỗ trợ thêm ngôn ngữ. Firefox 150 còn có gì khác? Bên cạnh Shake to Summarize trên Android, Firefox 150 đem theo một số cập nhật đáng chú ý: Mở link trong chế độ split view (xem hai trang song song) Sao chép URL từ nhiều tab cùng lúc Dịch riêng tư theo thời gian thực trên trang chuyên dụng VPN tích hợp miễn phí mở rộng sang Canada (trước đó chỉ có ở một số thị trường) Hệ thống quản lý profile mới dành cho tất cả người dùng Firefox 151 dự kiến ra mắt ngày 19 tháng 5 năm 2026 và có thể sẽ tiếp tục mở rộng AI Controls trên di động. Đánh giá thực tế từ người dùng Shake to Summarize giải quyết đúng một vấn đề thực sự: đọc lướt trên điện thoại rất khó chịu, nhưng đọc toàn bộ thì tốn thời gian. Thay vì mở thêm một ứng dụng AI khác, Mozilla nhúng khả năng tóm tắt thẳng vào luồng duyệt web cử chỉ lắc điện thoại tuy trông có vẻ "vui", nhưng thực ra là lối tắt nhanh nhất có thể nghĩ ra trên mobile. Hạn chế lớn nhất hiện tại là giới hạn tiếng Anh, điều này làm giảm đáng kể giá trị với người dùng Việt Nam. Nhưng nếu Mozilla tiếp tục lộ trình mở rộng ngôn ngữ như đã làm với tính năng dịch thuật, đây sẽ là một trong những lý do thuyết phục nhất để quay lại dùng Firefox trên điện thoại.

Ba triệu người dùng Codex mỗi tuần, tăng gấp 6 lần chỉ trong 3 tháng đầu năm 2026. Con số đó nói lên một điều Codex chính là ngôi sao đang lên. OpenAI đang biến nó thành công cụ gom tất cả trong một điều đó làm cho Codex sẽ không chỉ là sân chơi của mỗi riêng lập trình viên thôi. Codex là gì? Đây là công cụ không chỉ dành cho lập trình viên Hãy thử nghĩ đến tình huống này: bạn muốn tạo một bảng theo dõi chi tiêu tự động cập nhật mỗi tuần, hoặc một trang web nhỏ để nhận đặt lịch từ khách hàng, hoặc đơn giản hơn là muốn có một công cụ tự tổng hợp email báo cáo mỗi sáng mà không cần mở hàng chục tab. Trước đây, những việc này cần một developer. Với Codex, bạn chỉ cần gõ yêu cầu bằng tiếng Anh hoặc tiếng Việt và chờ kết quả. Codex là AI agent của OpenAI, ra mắt tháng 5/2025 và được tích hợp rất sâu vào hệ sinh thái của ChatGPT. Điểm khác biệt cốt lõi so với ChatGPT thông thường là Codex không chỉ trả lời, nó thực sự làm việc thông qua môi trường code. Bạn giao một nhiệm vụ, Codex tự lên kế hoạch, tự thực hiện từng bước, tự kiểm tra kết quả và trả về sản phẩm hoàn chỉnh để bạn dùng ngay. Không cần bạn hiểu code là gì, không cần bạn giám sát từng dòng lệnh. Codex đã có thể hoạt động qua ứng dụng desktop riêng, có sẵn cho cả Windows và macOS hoặc mới đây Codex đã có thể mở rộng sang Android và iOS trên điện thoại, tất nhiên bạn có thể sử dụng ngay tài khoản ChatGPT hiện có để đăng nhập. Codex hiện có trong các gói ChatGPT Plus,Pro, Business và Enterprise tuy nhiên người dùng gói Free và Go cũng được dùng thử với hạn mức giới hạn. Những việc Codex có thể làm thay bạn Tạo ứng dụng hoặc trang web nhỏ từ mô tả Bạn không cần biết HTML hay JavaScript. Chỉ cần mô tả: "Tạo cho tôi một trang đặt lịch hẹn đơn giản, có ô nhập tên, số điện thoại và chọn ngày giờ, gửi thông báo về email khi có người đặt." Codex sẽ tự tạo toàn bộ giao diện, logic xử lý và hướng dẫn bạn đưa lên internet. Một nhóm startup ở Mỹ từng chia sẻ rằng họ hoàn thành trong một cuối tuần những gì trước đây mất cả quý, và đó không phải nhóm toàn developer. Tự động hóa các tác vụ lặp lại Đây là phần nhiều người dùng không phải lập trình viên sẽ thấy hữu ích nhất. Ví dụ: mỗi tuần bạn phải tổng hợp doanh thu từ ba file Excel khác nhau, gộp lại và gửi báo cáo cho sếp. Codex có thể tạo một quy trình tự động làm việc này cho bạn, lên lịch chạy định kỳ và gửi kết quả mà không cần bạn mở máy tính. Với tính năng Automations ra mắt trong bản cập nhật tháng 4/2026, Codex có thể nhận task dài hạn, tạm dừng, tiếp tục và hoàn thành trong nhiều ngày mà không cần bạn nhắc lại từ đầu. Tạo ảnh và prototype trực tiếp trong app Codex tích hợp khả năng tạo ảnh bằng mô hình GPT Image 2.0 cực kì mạnh mẽ trực tiếp trong app luôn. Bạn có thể yêu cầu Codex tạo mockup giao diện, banner sản phẩm, hay hình ảnh minh họa cho tài liệu ngay trong cùng một luồng làm việc mà không cần chuyển sang công cụ khác. Với người làm nội dung, marketer hay founder solo, đây là điểm cộng thực sự vì toàn bộ quy trình từ ý tưởng đến sản phẩm có thể xảy ra trong một cửa sổ duy nhất. Điều khiển máy tính để làm việc trong nền Từ tháng 4/2026, Codex có thể vận hành các ứng dụng trên Mac bằng con trỏ riêng của nó, nhìn màn hình, click và gõ phím để hoàn thành tác vụ trong khi bạn vẫn đang dùng máy bình thường. Hình dung đơn giản hơn: bạn đang họp online, còn Codex đang mở Figma, chỉnh sửa thiết kế và lưu file theo yêu cầu bạn đặt ra từ trước. Hai việc diễn ra song song, không ai cản trở ai. Tính năng điều khiển máy tính (computer use) hiện chỉ khả dụng trên macOS và chưa có ở EU, UK. Bạn cần cấp quyền Accessibility và Screenshot cho ứng dụng Codex khi cài lần đầu. Cách bắt đầu dùng Codex Codex yêu cầu cài đặt ứng dụng desktop trên Windows hoặc macOS, không chạy trực tiếp trên trình duyệt web. Quá trình cài đặt khá đơn giản và chỉ mất vài phút. Bước 1: Truy cập openai.com/codex, tải về bản phù hợp với hệ điều hành của bạn. Với macOS, có hai bản riêng cho chip Apple Silicon (M1 trở lên) và chip Intel. Với Windows, chỉ có một bản duy nhất. Bước 2: Cài đặt ứng dụng và đăng nhập bằng tài khoản ChatGPT hoặc API key OpenAI hiện có của bạn. Bước 3: Chọn thư mục dự án bạn muốn Codex làm việc trong đó có thể chọn liên kết với Github, hoặc bỏ qua bước này nếu bạn chỉ muốn giao task độc lập như tạo file, tạo ảnh hay tự động hóa quy trình. Bước 4: Gõ yêu cầu bằng ngôn ngữ tự nhiên, càng cụ thể càng tốt. Thay vì "làm cho tôi một cái gì đó về báo cáo", hãy gõ "Tạo file Excel tổng hợp doanh thu theo tháng từ dữ liệu tôi cung cấp, thêm biểu đồ cột so sánh từng tháng và tô màu tháng có doanh thu cao nhất." Yêu cầu càng cụ thể, kết quả càng tốt. Codex hoạt động tốt nhất khi bạn mô tả rõ đầu vào, đầu ra mong muốn và bất kỳ ràng buộc nào bạn cần, ví dụ như định dạng file, ngôn ngữ hiển thị hay quy tắc tính toán. So sánh Codex với Claude Code, Antigravity và Cursor dưới góc nhìn người dùng phổ thông Nếu bạn không phải developer, câu hỏi thực tế không phải là "công cụ nào mạnh hơn về mặt kỹ thuật" mà là "công cụ nào tôi có thể dùng ngay mà không cần học thêm gì". Dưới góc nhìn đó, bốn công cụ này khác nhau rõ rệt. Codex và Claude Code Claude Code của Anthropic là đối thủ trực tiếp và đáng gờm nhất của Codex. Về chất lượng đầu ra thuần kỹ thuật, Claude Code hiện đứng đầu trong nhóm này, tạo ra code sạch hơn, logic chặt chẽ hơn và xử lý tốt hơn với các codebase lớn và phức tạp. Tuy nhiên, Claude Code được thiết kế rõ ràng cho developer: giao diện terminal, cần cài đặt qua dòng lệnh và đặc biệt không có khả năng tạo ảnh . Nếu bạn không quen với terminal, Claude Code sẽ là rào cản ngay từ bước đầu. Ngược lại, Codex có giao diện desktop thân thiện hơn, tích hợp khả năng tạo ảnh ngay trong cùng một luồng làm việc và dễ tiếp cận hơn rõ rệt với người dùng không chuyên kỹ thuật. Codex và Antigravity Cả hai đều yêu cầu cài ứng dụng desktop, nhưng triết lý sử dụng lại khác nhau hoàn toàn. Codex được thiết kế theo mô hình "giao việc và chờ kết quả": bạn mô tả yêu cầu, agent chạy trong cloud sandbox riêng biệt và trả về sản phẩm hoàn chỉnh mà không ảnh hưởng gì đến máy bạn đang dùng. Phù hợp với người muốn tự động hóa quy trình, tạo file hay xây dựng sản phẩm mà không cần theo dõi từng bước. Antigravity hoạt động theo hướng ngược lại: agent chạy trực tiếp trên máy bạn, nhìn màn hình, mở ứng dụng và phối hợp với bạn theo thời gian thực trong khi bạn đang làm việc. Nếu bạn muốn một đồng nghiệp AI làm việc song song cùng mình, quan sát và phản ứng với những gì đang xảy ra trên màn hình, Antigravity phù hợp hơn. Codex và Cursor Cursor được xây dựng trên nền VS Code và hướng đến developer muốn giữ nguyên môi trường làm việc quen thuộc. Với người không biết code, Cursor gần như không phù hợp vì toàn bộ trải nghiệm xoay quanh việc chỉnh sửa code trong editor. Cursor mạnh ở khả năng hiểu toàn bộ codebase và linh hoạt trong việc chọn model AI, nhưng đó là lợi thế dành cho developer, không phải cho người dùng phổ thông cần tự động hóa quy trình hay tạo sản phẩm từ đầu. Tóm lại theo góc nhìn người dùng không chuyên kỹ thuật: Codex: Giao diện desktop thân thiện trên Windows và macOS, tạo được ảnh, phù hợp với người muốn dùng AI như một công cụ workflow tự động. Claude Code: Chất lượng đầu ra kỹ thuật tốt nhất, nhưng thiên về developer và không tạo được ảnh. Antigravity:Agent làm việc trực tiếp trên máy theo thời gian thực, phù hợp với người muốn phối hợp cùng AI trong lúc đang làm việc . Cursor: Tốt nhất cho developer giữ nguyên workflow VS Code, không phù hợp với người dùng phổ thông. Codex phù hợp nhất với ai? Nếu bạn là người làm nội dung muốn tự tạo landing page cho chiến dịch thì Codex khá phù hợp. Nếu bạn là marketer cần tự động hóa báo cáo hàng tuần từ nhiều nguồn dữ liệu, Codex phù hợp. Nếu bạn là founder solo đang cần ra sản phẩm nhanh mà chưa có team kỹ thuật, Codex phù hợp. Nếu bạn là giáo viên muốn tạo một ứng dụng trắc nghiệm nhỏ cho học sinh mà không muốn học lập trình, Codex phù hợp. Ngược lại, nếu bạn là developer cần kiểm soát chi tiết từng dòng code trong một codebase lớn và phức tạp, Claude Code sẽ cho chất lượng đầu ra tốt hơn. Codex là công cụ tối ưu cho những người muốn kết quả nhanh mà không cần hiểu cách nó hoạt động bên trong. Một giới hạn thực tế cần biết: Codex hiện chỉ hỗ trợ đầy đủ với Python, JavaScript, TypeScript và Ruby. Với các tác vụ không liên quan đến code như tạo ảnh, tự động hóa quy trình hay tạo tài liệu, giới hạn ngôn ngữ này không ảnh hưởng gì đến bạn. Ranh giới biết code đang mờ dần Câu hỏi "bạn có biết lập trình không" đang dần mất đi sức nặng khi các công cụ như Codex tiếp tục phát triển. Điều quan trọng hơn bây giờ là bạn có thể mô tả rõ ràng những gì mình muốn không, vì đó chính xác là kỹ năng về mặt tư duy khi bạn muốn làm việc với Codex hay các công cụ khác AI Agent tương tự. Nếu muốn thử ngay hôm nay, hãy bắt đầu bằng một tác vụ nhỏ và cụ thể: yêu cầu Codex tạo một file Excel tổng hợp dữ liệu bạn đang làm thủ công mỗi tuần. Đó là bài kiểm tra nhanh nhất để bạn tự đánh giá xem Codex có thực sự tiết kiệm thời gian cho mình hay không.

Markdown đã là chuẩn mặc định khi làm việc với AI suốt nhiều năm nhưng một kỹ sư đến từ Claude Code tại Anthropic vừa đặt ra câu hỏi đáng suy nghĩ: liệu thói quen đó có thực sự là lựa chọn tốt nhất? Bài viết ngắn của Thariq Shihipar thu hơn 15.000 lượt thích trên X chỉ trong vài ngày, và lý do thuyết phục hơn bạn nghĩ. Markdown ra đời từ thời AI còn nghèo token Nhìn lại thời GPT-4 với cửa sổ ngữ cảnh chỉ 8.192 token, Markdown là lựa chọn hoàn toàn hợp lý trong khi đó HTML cồng kềnh hơn, tốn tài nguyên hơn và trong bối cảnh hạn chế đó, sự tối giản của Markdown là một ưu điểm thực sự chỉ để tiết kiệm. Vì vậy Markdown trở thành chuẩn ngầm định, và thói quen đó theo chúng ta đến tận bây giờ.Ngay cả khi Anthropic tạo ra khái niệm Skill trên Claude họ cũng đã lấy Markdown làm tiêu chuẩn với file SKILL.md, những ai hay làm việc với skill chắc chắn hiểu rõ điều mặc định này. Tuy nhiên, các mô hình AI hiện tại đã vận hành ở quy mô hoàn toàn khác. Nhiều mô hình đang hỗ trợ cửa sổ ngữ cảnh từ 200.000 đến 1 triệu token, và chi phí xử lý không còn là rào cản đáng lo (theo lời của Thariq Shihipar) và anh ấy lập luận rằng đây chính là thời điểm để xem lại mặc định đó. HTML làm được gì mà Markdown không thể? Lý do cốt lõi Thariq đưa ra khá đơn giản: một số loại thông tin vốn có tính không gian nhưng Markdown buộc chúng phải trở thành văn bản tuyến tính. Khi bạn so sánh ba hướng tiếp cận kỹ thuật thì bạn cần nhìn chúng cạnh nhau, không phải đọc lần lượt rồi cố giữ trong đầu. Khi bạn xem lại một đoạn code bạn cần thấy cấu trúc thay đổi tất nhiên không phải một bức tường chữ. HTML giải quyết đúng vấn đề đó vì vậy Thariq đã liệt kê 9 nhóm tình huống cụ thể mà HTML vượt trội hơn Markdown: Khám phá và lên kế hoạch: So sánh nhiều hướng tiếp cận cạnh nhau thay vì đọc tuần tự, rồi chuyển thành kế hoạch triển khai có sơ đồ luồng và mốc thời gian. Xem lại mã nguồn và hiểu cấu trúc dự án: Phần thay đổi được chú thích trực tiếp bằng màu sắc theo mức độ nghiêm trọng, sơ đồ mô-đun dạng hộp và mũi tên — thay vì văn bản thuần túy. Thiết kế giao diện: Bảng màu hiển thị thực tế có thể sao chép ngay, các biến thể thành phần giao diện được dựng trực tiếp thay vì mô tả bằng chữ. Tạo nguyên mẫu nhanh: Bảng điều chỉnh hiệu ứng chuyển động có thanh kéo thông số, màn hình có thể nhấp thực sự, đây là thứ Markdown không thể biểu đạt. Sơ đồ và hình minh họa: Đồ họa véc-tơ nội tuyến cho phép vẽ lưu đồ thực sự, không phải ký tự ASCII ghép lại. Bộ trình chiếu: Vài thẻ <section> và 20 dòng mã JavaScript là một bộ slide điều hướng bằng phím mũi tên mà không cần phần mềm chuyên dụng hay bước xuất file. Nghiên cứu và học tập: Tài liệu có phần thu gọn, tab mã, bảng chú giải thuật ngữ — thay vì đổ toàn bộ nội dung theo một chiều dọc. Báo cáo định kỳ: Bản tóm tắt trạng thái hàng tuần với biểu đồ nhỏ và màu sắc phân biệt tiến độ khiến người đọc thực sự đọc, không chỉ lướt qua. Giao diện chỉnh sửa tùy chỉnh: Bảng phân loại nhiệm vụ kéo thả, trình chỉnh cờ tính năng có cảnh báo phụ thuộc đây là công cụ thực sự, không phải văn bản đọc rồi thôi. Thariq đã tập hợp 20 file minh họa tất cả các nhóm này tại thariqs.github.io/html-effectiveness mỗi file mở thẳng trên trình duyệt, không cần cài đặt gì thêm. Dùng HTML với AI như thế nào trong thực tế? Cách áp dụng không phức tạp mà chỉ cần thay đổi cách bạn viết prompt. Thay vì để mô hình tự chọn định dạng đầu ra, hãy chỉ định rõ HTML khi nội dung cần được xem xét, tương tác, hoặc chia sẻ với người khác. Ví dụ câu lệnh Thariq gợi ý để xem lại một đoạn mã: Giúp tôi xem xét PR này bằng cách tạo một tài liệu HTML mô tả nó. Tôi không quen lắm với logic streaming/backpressure nên hãy tập trung vào phần đó. Hiển thị diff thực tế với các chú thích lề nội tuyến, mã màu các phát hiện theo mức độ nghiêm trọng và bất cứ thứ gì khác cần thiết để diễn đạt khái niệm một cách rõ ràng. Tương tự, bạn có thể yêu cầu AI tạo kế hoạch triển khai dưới dạng HTML với mốc thời gian và sơ đồ luồng dữ liệu, hoặc bản báo cáo trạng thái hàng tuần với biểu đồ nhỏ và màu sắc phân biệt tiến độ. Simon Willison tác giả blog kỹ thuật nổi tiếng cũng đã thừa nhận bài viết này khiến ông nhìn lại thói quen dùng Markdown từ thời GPT-4 cho đến tận thời điểm hiện tại. Khi các mô hình AI hiện đại có thể nhúng đồ họa véc-tơ, tiện ích tương tác và điều hướng nội trang, Markdown không còn là lựa chọn mặc định hiển nhiên nữa. Markdown vẫn còn chỗ đứng tất nhiên không phải ở mọi nơi Thariq không nói luôn luôn sử dụng HTML mà anh ấy phân biệt khá rõ: Markdown phù hợp cho trò chuyện thông thường, đoạn mã ngắn, câu trả lời vài dòng, và bất cứ thứ gì thuần văn bản trong khi đó HTML phát huy sức mạnh khi đầu ra cần bố cục không gian, màu sắc, khả năng tương tác, hoặc cấu trúc phức tạp đó là khi nội dung đủ nhiều chiều để Markdown bắt đầu làm phẳng thông tin thay vì truyền tải nó. Cộng đồng đã phản ứng khá nhanh: một skil mang tên html-artifacts đã xuất hiện trên GitHub, giúp AI tự nhận biết khi nào nên tạo file HTML thay vì Markdown bao gồm 9 nhóm tình huống từ bài viết gốc của Thariq hoàn toàn có thể sử dụng với bất cứ model nào hỗ trợ đọc skill. Đặc biệt skill này phần loại trừ rõ ràng cho câu trả lời ngắn và đầu ra chỉ có mã code. Mọi người có thể tham khảo tại github.com/dogum/html-artifacts. Trong bài Thariq không nhắc đến JSON nhưng đây cũng là định dạng hay sử dụng với AI đặc biệt đối với những ai hay dùng n8n, Make hay Zapier. Mặc dù vậy mỗi định dạng mang đến một màu sắc riêng trong những tình huống riêng. Markdown, HTML và JSON phân chia sử dụng như thế nào Cuộc tranh luận thực ra không chỉ là Markdown hay HTML. JSON cũng là định dạng phổ biến khi làm việc với AI, đặc biệt trong các luồng xử lý dữ liệu và tích hợp hệ thống. Ba định dạng này phục vụ ba mục đích khác nhau, và hiểu rõ ranh giới đó giúp bạn chọn đúng công cụ cho từng tình huống. Markdown tốt nhất cho văn bản đọc trực tiếp trong chat: ghi chú, giải thích ngắn, đoạn mã, tài liệu đơn giản. Nhanh, nhẹ, không cần mở thêm gì. HTML tốt nhất khi đầu ra cần được nhìn, tương tác hoặc chia sẻ: báo cáo có bố cục, sơ đồ, bảng so sánh, bộ trình chiếu, giao diện tùy chỉnh. Mở bằng trình duyệt là xong. JSON tốt nhất khi đầu ra cần được máy đọc tiếp: lưu trữ dữ liệu có cấu trúc, truyền giữa các hệ thống, hoặc làm đầu vào cho bước xử lý tiếp theo. Con người đọc được nhưng không phải để đọc. Nói cách khác, JSON không cạnh tranh với HTML hay Markdown về mặt trình bày mà nó phục vụ một mục đích hoàn toàn khác. Vấn đề thực sự nằm ở chỗ nhiều người dùng AI mặc định nhận đầu ra dưới dạng Markdown ngay cả khi họ cần HTML để xem, hoặc cần JSON để xử lý tiếp. Chỉ cần chỉ định rõ trong câu lệnh, AI sẽ điều chỉnh theo. Quy tắc chọn nhanh: Đầu ra để đọc trong chat → Markdown. Đầu ra để xem trên trình duyệt → HTML. Đầu ra để máy xử lý tiếp → JSON. Điều này có làm thay đổi gì với người dùng AI thông thường? Nếu bạn dùng AI chủ yếu để hỏi đáp hoặc viết lách, thay đổi này ít tác động hơn. Nhưng nếu bạn đang dùng AI để làm nhiều việc hơn như phân tích dữ liệu, lên kế hoạch dự án, xem lại tài liệu, tổng hợp nghiên cứu, hay tạo báo cáo cho đồng nghiệp đây là điều chỉnh nhỏ trong cách prompt nhưng tạo ra khoảng cách rõ rệt về chất lượng đầu ra, dù bạn đang dùng công cụ AI nào. Bạn nên thử một lần: lần tới khi cần AI so sánh các lựa chọn hoặc tóm tắt một tài liệu phức tạp, thêm vào cuối câu lệnh "tạo dưới dạng file HTML ". Mở file đó trên trình duyệt và so sánh với cách bạn vẫn làm với Markdown hay JSON thì kết quả thường nói lên tất cả.

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.