An

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.

Anthropic đã cho ra mắt Claude Opus 4.7 với hàng loạt cải tiến thực chất nhưng có một cảnh báo mà Anthropic ghi thẳng vào tài liệu migration: tokenizer mới có thể tạo ra nhiều hơn 1.0–1.35 lần token so với cùng nội dung đó trên Claude Opus 4.6, và model suy nghĩ nhiều hơn ở các mức effort cao. Nếu bạn đang dùng API và chưa đọc kỹ điều này trước khi nâng cấp, hóa đơn tháng tới sẽ là bài học đắt giá nhất bạn nhận được từ AI. Opus 4.7 cải thiện gì so với 4.6? Các con số thực tế từ tester Anthropic cho phép nhiều công ty tiếp cận sớm và thu thập phản hồi trước khi phát hành. Đây không phải marketing một chiều — các công ty ghi lại kết quả đo lường cụ thể Cursor: Opus 4.7 đạt 70% trên CursorBench, tăng đáng kể so với 58% của Opus 4.6 — một bước nhảy hiếm thấy giữa hai phiên bản liên tiếp. Notion: Tăng 14% so với Opus 4.6 trong các workflow nhiều bước, đồng thời tiêu ít token hơn và chỉ còn 1/3 số lỗi tool. Đây là trường hợp hiếm gặp khi model mới tốt hơn đồng thời trên cả ba chiều: chất lượng, chi phí và độ ổn định. XBOW: Benchmark visual acuity tăng từ 54.5% lên 98.5% — gần như tăng gấp đôi. Đây là cải thiện lớn nhất được ghi nhận và là lý do XBOW có thể mở rộng sang cả lớp công việc computer-use mà trước đây không thể dùng Opus. Rakuten: Giải quyết được gấp 3 lần số task production so với Opus 4.6 trên benchmark riêng của họ. Tuy nhiên những con số này đến từ các công ty đã được chọn để test sớm và có động lực công bố kết quả tốt. Benchmark nội bộ của từng công ty không thể so sánh trực tiếp với nhau và chưa chắc phản ánh đúng workflow của bạn. Ba thay đổi hành vi đáng chú ý nhất Tuân thủ hướng dẫn theo nghĩa đen — cả tốt lẫn xấu. Anthropic ghi rõ trong tài liệu phát hành: Opus 4.7 thực thi hướng dẫn chính xác hơn đến mức "các prompt viết cho model cũ có thể tạo ra kết quả ngoài mong đợi vì chỗ nào model cũ bỏ qua hoặc diễn giải linh hoạt thì Opus 4.7 làm đúng nghĩa đen". Với developer, điều này có nghĩa là nếu system prompt của bạn có rule mơ hồ hay mâu thuẫn, Opus 4.7 sẽ đề cập ngay thay vì tự giải quyết trong im lặng như trước. Đây là cải thiện về độ tin cậy, nhưng đòi hỏi bạn phải xem lại lại toàn bộ prompt trước khi deploy. Ví dụ từ Vercel: "Opus 4.7 thậm chí tự viết proof cho systems code trước khi bắt đầu làm — đây là hành vi mới chưa thấy ở các Claude trước." Model không chỉ làm việc theo yêu cầu mà tự thêm bước xác nhận đầu ra trước khi báo cáo kết quả. Ít nịnh bợ và phản hồi sáo rỗng hơn. Hex đã xác nhận: "Nó báo cáo đúng khi dữ liệu bị thiếu thay vì đưa ra câu trả lời nghe có vẻ đúng nhưng thực ra là bịa." thực sự mình đã thử thật sự là không hề thấy xuất hiện những câu nịnh bợ sáo rỗng như “bạn thật tuyệt vời” hoặc “bạn thực sự hơn 95% người trên thế giới này” và thiếu thông tin chắc chắn nó sẽ hỏi lại bạn, vậy là Opus 4.7 có vẻ cải thiện đáng kể điểm này trong khi Opus 4.6 nhiều lúc vẫn bị những câu nịnh bợ hoặc bịa ra thông tin không chính xác, điều này giúp cho nó hoàn toàn có thể trở thành đồng nghiệp mới của mình giống như Replit mô tả: "Nó phản bác trong các cuộc thảo luận kỹ thuật để giúp tôi đưa ra quyết định tốt hơn. Thực sự cảm giác như một đồng nghiệp tốt hơn." Xử lý hình ảnh độ phân giải cao gấp 3 lần. Opus 4.7 chấp nhận ảnh lên đến 2.576 pixel trên cạnh dài (khoảng 3.75 megapixel), tăng hơn 3 lần so với các model Claude trước. Điều này không phải là tham số API mà là thay đổi ở cấp độ model, nghĩa là ảnh bạn gửi lên sẽ tự động được xử lý ở độ phân giải cao hơn so với trước đây. Điều này có nghĩa là Opus 4.7 có thể phân tích tài liệu có biểu đồ nhỏ, đọc code từ screenshot, hay computer-use với màn hình độ phân giải cao hơn so với các model trước. Ví dụ mình đã thử với file pdf nhiều trang và có những chữ kí nhỏ thì Opus 4.7 hoàn toàn có thể nhận diện được chính xác những chữ kí nhỏ này, rồi sau đó là sử dụng chrome để nhận diện các kí tự nhỏ ở web thì nó có thể nhận diện chính xác hơn. Tuy nhiên điều này tốn token cực kì có thể khoảng 3 hoặc 4 lần chat là hết quota ngay lập tức vì vậy mọi người có thể cân nhắc giảm kích thước ảnh trước khi gửi nếu không cần độ chi tiết cao. Vấn đề token vẫn là thứ đáng lo nhất với người dùng Tokenizer mới tạo ra nhiều token hơn từ cùng nội dung Anthropic thừa nhận thẳng thắn trong migration guide: Opus 4.7 dùng tokenizer mới được cải tiến, nhưng trade-off là cùng một đoạn text có thể tạo ra nhiều hơn 1.0–1.35 lần token so với Opus 4.6. Hệ số 1.35 nghe có vẻ nhỏ nhưng trên quy mô production thì không phải vậy — nếu hệ thống của bạn đang tiêu 10 triệu token mỗi ngày với Opus 4.6, sau khi nâng cấp bạn có thể tiêu 13.5 triệu token mà không thay đổi gì về nội dung hay workflow. Vì vậy những ai chỉ chạy bản Pro thì có vẻ quota sẽ hoàn toàn không đủ có lẽ Anthropic đang ép người dùng phải nâng cấp lên Max để làm việc. Kết hợp với việc model suy nghĩ nhiều hơn ở các mức effort cao (đặc biệt ở `xhigh` — effort level mới được thêm vào giữa `high` và `max`), và mặc định Claude Code đã nâng lên `xhigh` cho tất cả các plan vì vậy người dùng API cần đo lường thực tế trên traffic thật trước khi nâng cấp toàn bộ, không nên dựa vào ước tính lý thuyết. Task budgets là công cụ kiểm soát mới cho API Song song với Opus 4.7, Anthropic ra mắt tính năng task budgets (public beta) trên Claude Platform, cho phép người dùng đặt giới hạn token cho từng task thay vì toàn bộ session. Đây là phản hồi trực tiếp với vấn đề nhiều pipeline bị "cháy" quota vì agent chạy quá lâu trên các task phức tạp mà không có cơ chế dừng. Với Opus 4.7 suy nghĩ nhiều hơn, task budgets sẽ trở thành công cụ cần thiết để kiểm soát chi phí thay vì tùy chọn. Nhìn nhận lại Claude Opus 4.7 Trong khi cộng đồng đang bàn về Opus 4.7 với khả năng đốt token khủng khiếp hay việc Opus 4.6 đang gặp lỗi. Đặc biệt với người dùng API đang vận hành workflow thì sự ổn định thường quan trọng hơn khả năng benchmark đi kèm thêm chi phí phải được tối ưu và không có bất ngờ nào vượt quá tầm kiểm soát. Cho nên đừng nói đến việc nâng cấp Opus 4.7 ngay lập tức vì một model mới tốt hơn nhưng thỉnh thoảng đầu ra không nhất quán thực sự quá khó để kiểm soát so với các model cũ đã được kiểm chứng. Nếu bạn đang cân nhắc nên dùng model nào trong tháng tới, đây là hướng dẫn thực tế: thử Opus 4.7 trên 10–20% traffic với task budgets bật lên, đo lường chi phí token thực tế so và chỉ chuyển toàn bộ sau khi có đủ dữ liệu. Đừng để điểm số hoặc những bài test ban đầu quyết định thay trong công việc lựa chọn của bạn. Có một điều cũng đáng lưu ý: Opus 4.7 nên để ở 200k token thay vì đẩy lên 1 triệu token ngay vì ở context window lớn, model suy nghĩ nhiều hơn ở mỗi lượt sau và token tích lũy nhanh hơn bạn nghĩ — đặc biệt trong các agentic workflow nhiều lượt thực hiện, khi đó chi phí đi kèm sẽ tăng lên cấp số nhân nên bạn phải rất cẩn thận.

On Reddit, Hacker News, and Anthropic's GitHub, hundreds of developers are reporting the same issue: Claude Opus 4.6 and Sonnet 4.6 are performing significantly worse in real-world tasks compared to their launch. One GitHub user recorded their performance score dropping from 92/100 to 38/100 when using Opus 4.6. The question is whether this is due to ongoing business losses, a technical issue at Anthropic, or a more complex story? What the Community is Reporting About Claude Opus 4.6 The Most Clearly Documented Complaints Most of the most reliable complaints might come from social media, but when they come from Anthropic's own GitHub repository – where developers report bugs with Claude Code – it's truly an issue. These are professional users with measured processes, not subjective feelings. A developer reported that a production automation pipeline, which had been running stably for over 2 weeks, suddenly produced chaotic results on March 6th with the same Opus 4.6 model. According to this person, when asked to self-evaluate the conversation quality, the model consistently scored itself as Sonnet 4, not Opus 4.6. In other words, Opus 4.6 is also recognizing that it is performing below expectations. (Source: GitHub Issue #31480 — Anthropic/claude-code) Another report documented more specifically with a real-world example: requesting Opus 4.6 to generate 3 emails based on a template for 3 insurance companies, the result was only 1 email. When prompted again, the model generated all 3, but when the user made a minor edit, the model reverted to generating 1 email. This loop repeated without any consistent logic — the reporter noted their performance score dropped from 92/100 to 38/100 after switching to Opus 4.6. (Source: GitHub Issue #24991 — Anthropic/claude-code) In addition to the two reports above, a compiled thread on Hacker News noted many independent developers confirming similar situations and stating they reverted to using Claude 4.5 while awaiting a response from Anthropic. (Source: Hacker News thread) Real-world Comparison Between Opus 4.6 at Launch and Recently Below are some specific examples from the community, and I have also had time to compare the behavior of the two versions: Example 1 — Instruction Adherence: Prompt: "Write an email to a customer. NEVER mention the price in this email." Previous Opus 4.6: Complied correctly, with no mention of price. Opus 4.6 (after some point in March 2026): Mentioned "suitable pricing package" in the second paragraph despite the clear "NEVER" rule. Example 2 — Reading Reference Files: Prompt requested reading a style guide file and applying it to the output. Previous Opus 4.6: The ability to read the file was quite accurate and applied the specified style correctly. Opus 4.6 (at the time of the report above): Ignored reading the file while creating a completely different format. Example 3 — Multi-part Task Handling: Prompt: "Create 3 scenarios for 3 different situations." Previous Sonnet 4.6: Generated all 3 scenarios in one go, with a clear structure. Opus 4.6 (according to the February 2026 report): Generated 1 scenario, when prompted to continue, forgot the previous 2 scenarios, leading to an endless loop. Is Reverting to Opus 4.5 the Best Solution? Reverting to Opus 4.5 Even Though Opus 4.6 is Still Quite Good Many people have suggested reverting to Opus 4.5 as a temporary solution to this problem. However, if we only look at official benchmarks, Opus 4.6 outperforms Opus 4.5 in almost all important criteria, especially for those who need long contexts. Opus 4.5 currently only has 200k context, which cannot be compared to Opus 4.6's ability to expand to 1M context. Regarding scores, on BrowseComp – a benchmark evaluating multi-step web research capabilities – Opus 4.6 achieved 84.0% while Opus 4.5 only reached 67.8%, an improvement of 16.2 percentage points. On SWE-bench Verified, which assesses real-world coding, Sonnet 4.6 achieved 79.6% compared to Sonnet 4.5's 77.2%. ARC-AGI 2 – a test of new problem-solving abilities – Opus 4.6 nearly doubled its score compared to 4.5. However, there's an interesting point: on the SWE-Bench Multi-Agent benchmark, which measures the ability to coordinate multiple tools simultaneously, Opus 4.5 achieved 62.3% while Opus 4.6 only reached 59.5% – a small but real decline, which seems to be the scenario most users are complaining about. Subjective and Objective Causes for Opus 4.6's Poor Experience? This is the most important part to correctly understand the problem. There are at least three different reasons leading to the same symptom of "model performing worse": Temporary Technical Issues: Anthropic has confirmed multiple official incidents on its status page, including "Elevated errors on Claude Opus 4.6" on February 28, 2026, a similar incident on March 31, 2026, and "Opus 4.6 and Sonnet 4.6 error rate elevated" on the same day. These are not subjective complaints — these are officially recorded technical incidents, and many "regression" reports occurred precisely during these periods. Default Behavior Changes: Opus 4.6 is designed to think more by default through "adaptive thinking" — meaning it decides when to engage in deep reasoning and when not to. This makes it slower and sometimes feel more cumbersome on simple tasks, making users accustomed to 4.5 feel like the model is "overthinking" instead of performing quickly. Anthropic is Still Profit-Oriented: (This is a personal opinion) It seems Anthropic's biggest goal is still profit, as they might adjust to reduce Opus 4.6's computational capacity to lessen the cost burden, just as OpenAI had to shut down Sora to reduce cost burdens, which everyone knows. So, Are People Mentioning Other Solutions? First, Switching to Codex Based on what Opus has demonstrated previously, Opus 4.6's current issues appear temporary, but this inadvertently benefits OpenAI's Codex significantly as people flock to Codex with GPT-5.3 Codex. Codex currently offers more generous quotas than Claude Code, but I don't think this will significantly threaten Anthropic, as my experience with Opus 4.6 on both Antigravity and Claude Code is much better than with Codex. For instance, when I only needed to modify one file, Opus 4.6 did it correctly and precisely, but Codex also modified other files, messing up my entire website, which was truly frustrating. Deep Edits in the Settings File Someone has shown how to modify Claude Code to address Claude Opus 4.6's "thinking" part by editing the ~/.claude/settings.json file. Anyone who has tried it, please comment on your experience so others know. Is This an Industry Standard? Yes. OpenAI, Google, and Anthropic all have a history of releasing new models with better benchmarks but causing complaints about real-world experience — often because optimization for a benchmark set doesn't reflect the full diversity of actual workflows. This is why large companies often don't upgrade models immediately upon a new version release but thoroughly test them on their specific workloads first. If you are using Claude Opus 4.6 for research workflows, computer use, or long-term reasoning tasks, the best approach currently is still to revert to Opus 4.5 to continue your work without interruption.

Boris Cherny — the engineer behind Claude Code — doesn't like to explain the tool he created with slides; instead, he shares 13 practical tips from how the Anthropic team itself uses it daily. Below are 7 core principles I've extracted from that, and the common thread is that he doesn't use Claude Code as a code-writing chatbot but as an intelligent workflow. He shared this many months ago, so some things might be old, but there's still a lot to learn from these talented individuals. Clone Yourself by Running Multiple Parallel Sessions Claude Code is certainly not designed to be used in just a single tab. Boris runs 5 terminal tabs simultaneously, combining 5–10 sessions on claude.ai/code and the mobile app, with each session handling exactly one independent task. The practical reason: if too many tasks are crammed into one context, Claude starts to have priority conflicts, and output quality significantly decreases. Instead: Use the hand-off feature (&) to transfer tasks between terminal and web. "Teleport" context from computer to phone when needing to continue work on the go. This is a feature that has been available for a long time. One session, one task is a vital principle when using Claude Code to avoid context overflow. Choose the Strongest Model and Always Start with Plan Mode Boris uses Claude Opus 4.5 (as Opus 4.6 had not been released by January 2026) combined with Thinking for most serious work. Before letting Claude run code autonomously, he almost always starts with Plan Mode — pressing Shift + Tab twice. Plan Mode forces Claude to plan in writing before execution, and this is when problems are detected earliest with the lowest correction cost. According to Boris: "A good plan is really important." for Claude Code to have a planning step, it's extremely crucial, just like a builder laying a foundation without a blueprint. Build CLAUDE.md as a Shared Team Memory CLAUDE.md is the single file the entire team checks into git, containing all accumulated conventions, context, and lessons. Operating principles: Every time Claude makes a mistake, such as a convention error, incorrect processing flow, or wrong directory structure, Claude is made to not only fix that instance but immediately add it to CLAUDE.md so it doesn't repeat next time. During code review, tag @.claude to add context directly from the PR to this file. Boris calls this "compounding engineering": the system doesn't stand still; it improves daily with every recorded error. After 3 months of serious use, a team's CLAUDE.md truly becomes an engineering asset — not just a config file. Automate All Repetitive Tasks with Slash Commands and Subagents Anything you type more than 3 times a day should become a Slash command. Place them in .claude/commands/. For example: /commit-push-pr — combines the entire commit, push, and PR creation flow into a single command. For standard steps in the PR process, Boris uses Subagents like code-simplifier or verify-app to handle them automatically without manual intervention. The result is a significantly shortened time from "code finished" to "PR ready for review" and fewer errors due to missed steps. Use Hooks and Permissions for Self-Operating Systems Three important mechanisms Boris configures for Claude Code: PostToolUse hook — automatically formats code every time Claude uses a tool. You no longer need to remember to run the linter manually. /permissions — pre-declares safe bash commands so Claude doesn't ask for confirmation every time. Boris does not recommend using --dangerously-skip-permissions because it bypasses control without a truly good reason. Agent Stop hook or ralph-wiggum plugin — for long-running background tasks, this hook allows Claude to self-verify results upon completion without you having to wait. Instead of monitoring a 20-minute session, you let it report when it's done. Connect Claude with All Team Tools Claude Code is not a standalone tool. Boris configures Claude to have access to Slack (via MCP), BigQuery, Sentry, terminal, and any other tools the team is using. Of course, all MCP configurations and shared permissions are set up so everyone on the team has the same environment. In practice, when Claude can directly query Sentry for stacktraces and simultaneously view BigQuery to understand data patterns, the debugging quality is vastly different from manually pasting data into chat. Creating a Testing Loop is the Most Important Step Boris emphasizes this as "perhaps the most important thing" among all 13 tips. Core idea: instead of you checking Claude's output, give Claude a way to check itself. The testing loop can be: A web browser extension that automatically takes screenshots and compares UI. A test suite that runs after every change. A bash script that checks endpoints. A simulator that recreates user flows. When the feedback loop works well, Claude immediately knows whether its output is correct or incorrect without you acting as an arbiter. From this, output quality can increase 2–3 times, not because the model is better, but because Claude has the information to self-adjust. Lessons from How Boris Uses Claude Code Looking back at the 7 principles, the common thread isn't "use this feature, enable that feature" but rather the mindset of using Claude Code as an agent with context, tools, a way to self-check results, and accumulated memory over time. If you're using a single tab, typing prompts, and waiting — you're only utilizing about 10% of this tool's capabilities. A practical step today: create a CLAUDE.md file in your current project, and write down a convention or an error Claude just made. That's the starting point of an accumulating system, and it begins with the first line. If you want to refer to Boris's 13 tips, you can find the actual article here https://x.com/bcherny/status/2007179832300581177

Bạn gõ một câu lệnh, AI tự lên kế hoạch, mở terminal, viết code, mở trình duyệt web kiểm tra rồi báo lại kết quả, Antigravity làm tất cả trong khi bạn đang uống cà phê. Đó không phải viễn cảnh tương lai, đó là cách Google Antigravity hoạt động và nó vừa thay đổi hoàn toàn cách mình tiếp cận việc xây dựng sản phẩm và quy trình tự động. Google Antigravity là gì? Antigravity là IDE thế hệ mới do Google ra mắt cuối tháng 11 năm 2025 cùng lúc với Gemini 3, được xây dựng trên nền VS Code nhưng với kiến trúc hoàn toàn khác: thay vì AI ngồi ở sidebar gợi ý từng dòng code, AI trong Antigravity làm việc như một agent thực sự một khi đã được cấp quyền thì chúng ta có thể giao task và Antigravity tự hoàn thành task đó để cho ra kết quả rất giống với Manus và Flowith nhưng ở đây Antigravity thiên về màn hình làm việc với code hơn. Điểm khác biệt lớn nhất so với Cursor hay GitHub Copilot là Antigravity không hỏi bạn từng bước mà hoạt động bất đồng bộ đó là khi bạn giao task, agent chạy ngầm trong nền trong khi bạn làm việc khác rồi quay lại xem kết quả. Antigravity hoàn thành một feature Next.js + Supabase điển hình trong 42 giây so với 68 giây của Cursor, và độ chính xác khi refactor đạt 94% so với 78% của Cursor. Antigravity đã có phần mềm hỗ trợ macOS, Windows và Linux nên mọi người không lo về vấn dề phần mềm mà chỉ nên lo về chi phí gọi API. Ngoài sử dụng Gemini 3 và Gemini 3 pro mặc định, Antigravity còn hỗ trợ Claude Sonnet, Claude Opus và GPT-OSS thật tốt khi không bị khoá vào nền tảng của Google khi mà Claude Sonnet, Claude Opus đang dẫn đầu thị trường. Các tính năng tiêu biểu của Antigravity IDE Chỉnh sửa trực tiếp với sự hỗ trợ của AIVới giao diện quen thuộc như VS Code, nơi các lập trình viên có thể chỉnh sửa code tay hoặc nhờ AI hỗ trợ từng đoạn cụ thể. Phù hợp khi bạn muốn kiểm soát từng bước hoặc xử lý những đoạn code cần sự chú ý cao. Điều phối agent chạy song song Đây là điểm khác biệt thực sự của Antigravity thực sự với "mission control" bạn không cần viết code ở đây mà điều phối nhiều agent chạy song song. Ví dụ một agent đang refactor module A, agent khác đang viết test cho module B, agent thứ ba đang debug lỗi UI trên trình duyệt web. Bạn theo dõi tiến độ, để lại comment như trên Google Docs và agent tự điều chỉnh mà không cần dừng lại chờ. Truy cập và điều khiển trình duyệt web Đây là tính năng mình thấy ấn tượng nhất khi mới dùng khi mà Antigravity có thể mở trình duyệt web như Chrome, Firefox,... khi được cấp quyền từ đó nó có thể điều hướng trang web, điền form và kiểm tra giao diện hoàn toàn tự động. Tuy nhiên cần lưu ý rằng Antigravity hoạt động giống hệt như Puppeteer nên chỉ tương tác được với các tác vụ trên trình duyệt và khi cần có thể xử lý ảnh và chụp ảnh màn hình và tất nhiên chưa hoạt động được với những trang web đã cài đặt chặn bot truy cập. Logic của Antigravity rất rõ ràng Đây là tính năng mình thích nhất khi làm việc với Antigravity đó là thay vì đổ raw code ra màn hình, agent tạo ra các deliverable có thể đọc được như task list, implementation plan, screenshot màn hình app đang chạy để bạn kiểm tra logic của agent cả trước và sau khi hoàn thành task, điều này giúp bạn luôn nắm được agent đang làm gì để đánh giá. Antigravity đang được dùng để làm những gì trong thực tế? Nhiều người nghe đến Antigravity và nghĩ ngay đây là công cụ dành riêng cho lập trình viên chuyên nghiệp. Thực tế thì không phải vậy vì phạm vi ứng dụng rộng hơn nhiều so với vẻ ngoài kỹ thuật của nó. Xây dựng và triển khai website Đây là use case phổ biến nhất. Bạn mô tả trang web muốn xây — stack kỹ thuật, tính năng, phong cách thiết kế — agent tự viết code, tự kiểm tra trên browser và tự sửa lỗi. Kết hợp với Google Stitch qua MCP, bạn có thể đi từ thiết kế UI đến sản phẩm chạy thực sự mà không cần chuyển qua lại giữa nhiều công cụ. Ví dụ prompt dùng trong Antigravity: "Xây cho mình một landing page bằng Next.js và Tailwind CSS cho sản phẩm SaaS quản lý công việc nhóm. Có section hero, bảng giá 3 gói và form đăng ký email. Deploy lên localhost và chụp screenshot kết quả." Tự động hóa quy trình lặp lại Một trong những điểm mạnh thực tế nhất. Bạn có thể nhờ Antigravity tự động crawl dữ liệu từ nhiều nguồn, tổng hợp và gửi báo cáo theo lịch, hoặc tự động điền form và thực hiện các thao tác lặp đi lặp lại trên trình duyệt — những việc trước đây cần viết script riêng hoặc dùng công cụ automation phức tạp. Ví dụ prompt: "Mỗi sáng 8 giờ, vào trang thống kê của website mình tại [URL], lấy số liệu pageview và top 5 bài viết và xem thông tin 5 bài viết của trang fanpage Facebook của mình ở trang [URL], tổng hợp thành file markdown và lưu vào thư mục /reports/daily." Lưu ý: Facebook hoàn toàn không thích bot truy cập vào trang của họ cho nên hãy làm sao để bot thao tác gần như con người trên trình duyệt để không bị dính lỗi checkpoint của Facebook có thể dẫn đến khóa tài khoản. Xây dựng hệ thống AI agent Đây là use case mà Antigravity thực sự vượt trội so với các công cụ khác. Thay vì chỉ viết một đoạn code đơn lẻ, bạn có thể mô tả cả một pipeline — ví dụ "tạo hệ thống phân tích review sản phẩm từ nhiều nguồn, phân loại sentiment và tự động tag vào database" — rồi để Antigravity thiết kế kiến trúc agent, phân chia nhiệm vụ và triển khai từng bước. Ví dụ prompt: "Tạo một hệ thống gồm 3 agent: agent 1 crawl review sản phẩm từ Shopee và Lazada mỗi ngày, agent 2 phân tích sentiment và phân loại theo chủ đề, agent 3 tổng hợp thành báo cáo tuần và lưu vào Google Sheets." Refactor và cải thiện codebase có sẵn Nếu bạn có một dự án cũ cần nâng cấp, Antigravity đặc biệt hữu ích khi cần refactor quy mô lớn có thể thay đổi toàn bộ cấu trúc file, cập nhật dependencies, viết test coverage cho code chưa có test. Agent đọc toàn bộ codebase, hiểu ngữ cảnh và thực hiện thay đổi nhất quán trên nhiều file cùng lúc thay vì sửa từng chỗ một. Ví dụ prompt: "Đọc toàn bộ codebase trong thư mục /src, đóng vai chuyên gia bảo mật xem có dính lỗi SQL injection, các lỗ hổng owasp không đề xuất chỉnh sửa sao cho vẫn giữ nguyên logic và đảm bảo không có lỗi sau khi refactor." Nghiên cứu và tổng hợp thông tin từ web Vì Antigravity có thể điều khiển trình duyệt, bạn có thể dùng nó để tự động truy cập nhiều trang web, trích xuất thông tin theo cấu trúc bạn định sẵn và tổng hợp lại thành báo cáo hoặc database — phù hợp với các tác vụ research cần thu thập dữ liệu từ nhiều nguồn mà làm thủ công sẽ rất tốn thời gian. Ví dụ prompt: "Vào 10 trang web tin tức AI này [danh sách URL] và các trang fanpage [danh sách URL] tìm các bài đăng trong 7 ngày qua, trích xuất tiêu đề, tóm tắt 2 câu và link gốc, lưu vào file CSV theo thứ tự mới nhất trước." Các câu hỏi thường gặp khi sử dụng Antigravity Antigravity có miễn phí không? Có cả gói miễn phí và trả phí. Gói miễn phí có quota reset theo tuần với rate limit hạn chế, đủ để thử nghiệm và làm project nhỏ. Gói Pro/Ultra có quota reset mỗi 5 giờ và được ưu tiên cao nhất rất phù hợp nếu bạn dùng Antigravity hàng ngày cho công việc thực tế. Antigravity có làm được việc với file Word, Excel, PDF không? Antigravity cài Puppeteer nên hoạt động chủ yếu qua trình duyệt web và chưa thể tác động trực tiếp vào các loại file như Word, Excel hay PDF. Nếu cần xử lý những file này, bạn phải thêm vào workflow và mention trong phần cấu hình để agent biết cách tiếp cận đúng. AI không phản hồi hoặc bị treo phải làm gì?Đây là lỗi khá phổ biến, đặc biệt vào giờ cao điểm khi nhiều người dùng đồng thời. Trong hầu hết trường hợp, chỉ cần restart lại Antigravity là được hoàn toàn không cần lo mất dữ liệu hay phải thiết lập lại từ đầu. Ngoài ra, nên dùng git và commit thường xuyên trước khi giao task lớn để tránh mất code nếu agent bỏ dở giữa chừng. Antigravity thực sự là công cụ quá mạnh mẽ vì sao chúng ta không thử ngay. Người dùng có thể tải về tại antigravity.google/download và bắt đầu với một project nhỏ — không phải để thử tính năng mà để hiểu tư duy làm việc mới này trước khi đưa vào dự án thực tế.

Bạn đã dùng NotebookLM để lưu tài liệu, nghiên cứu và ghi chú tuy nhiên mỗi lần cần AI xử lý thêm thì lại phải mở Gemini, copy-paste thủ công rồi hy vọng AI không bịa số liệu không chính xác. Giờ đây sau khi khám phá ra thì mình có thể xóa bỏ hoàn toàn bước thừa đó khi mà NotebookLM giờ có thể kết nối trực tiếp vào Gemini, biến toàn bộ tài liệu thành bộ não cho AI xử lý tức thì. NotebookLM và Gemini đã từng như hai ốc đảo NotebookLM rất giỏi một việc bám chặt vào tài liệu bạn cung cấp và trả lời chính xác dựa trên đó. Ví dụ như bạn có thể upload báo cáo tài chính 200 trang có thể hỏi bất kỳ con số nào, NotebookLM trích dẫn đúng trang đúng đoạn. Tuy nhiên nó bị cô lập trong từng note riêng biệt và không thể tìm kiếm thông tin mới ngoài internet. Gemini thì ngược lại có tư duy linh hoạt, kết nối web thời gian thực, có sự sáng tạo nhưng lại cực kì dễ ảo giác khi làm việc với dữ liệu chuyên sâu mà không có nguồn rõ ràng. Kết quả là nếu người dùng biết đến 2 công cụ này đều phải dùng song song, chuyển dữ liệu qua lại thủ công vừa mất thời gian vừa dễ mắc lỗi. Tích hợp này giải quyết đúng vấn đề đó bằng cách đưa NotebookLM vào thẳng giao diện Gemini, để hai công cụ bổ trợ cho nhau thay vì hoạt động độc lập. Một vài điều cần biết trước khi kết nối Gemini và NotebookLM Vì cùng hệ sinh thái Google cho nên tích hợp Gemini và NotebookLM hoạt động rất mượt mà, nhưng có một vài điểm cần lưu ý để tránh kỳ vọng sai. Gemini ưu tiên dữ liệu từ notebook trước, nhưng khi notebook không đủ thông tin, nó sẽ tự động tìm kiếm web mà không cần bạn ra lệnh thêm. Điều này tiện lợi, nhưng cũng có nghĩa là bạn cần kiểm tra nguồn trích dẫn để biết câu trả lời đến từ tài liệu của bạn hay từ tìm kiếm web. Khả năng phân tích chéo nhiều notebook cùng lúc là điểm mạnh lớn mà NotebookLM đơn thuần chưa làm được. Với càng nhiều notebook được kết nối, Gemini càng có thể xử lý được sự khác nhau và nhiều góc của vấn đề hơn nhưng vẫn bám sát được toàn bộ ngữ cảnh. Ngoài ra mọi câu trả lời từ dữ liệu notebook đều có trích dẫn nguồn cụ thể, đây là điểm khác biệt quan trọng so với Gemini thông thường và giúp bạn kiểm chứng nhanh khi cần. Kết nối NotebookLM vào Gemini trong 4 bước Tính năng hiện đã có thể dùng được cho cả tài khoản miễn phí lẫn Google AI Pro, không cần cài thêm gì. Bạn thực hiện theo thứ tự sau. Đầu tiên, mở Gemini trên web hoặc ứng dụng di động và vào khung nhập liệu như bình thường. Tiếp theo, nhấp vào biểu tượng dấu "+" ở góc khung chat và chọn NotebookLM từ danh sách nguồn. Sau đó chọn một hoặc nhiều notebook bạn đã tạo sẵn để làm ngữ cảnh cho cuộc hội thoại. Cuối cùng, nhập prompt của bạn như bình thường, lưu ý rằng Gemini sẽ ưu tiên dữ liệu từ notebook trước, và chỉ tìm kiếm thêm trên web khi thông tin trong notebook chưa đủ. Toàn bộ quá trình thiết lập mất chưa đến 60 giây, và bạn có thể chuyển đổi giữa các notebook khác nhau ngay trong cùng một cuộc hội thoại. Notebook + Gemini có thể làm được những gì mà trước đây không làm được? Điểm thay đổi lớn nhất không phải là tốc độ mà là độ tin cậy của đầu ra. Khi Gemini có nguồn dữ liệu cụ thể từ notebook, mọi câu trả lời đều được gắn nhãn trích dẫn rõ ràng giúp bạn biết chính xác thông tin đó đến từ trang nào, tài liệu nào, thay vì phải tự đi kiểm chứng lại. Về mặt ứng dụng thực tế có 4 trường hợp mà sự kết hợp này tạo ra khác biệt rõ nhất. Nghiên cứu và tổng hợp tài liệuThay vì đọc hết một cuốn sách giáo khoa 500 trang, bạn upload vào NotebookLM rồi yêu cầu Gemini tóm tắt thành bộ sách hoặc cũng có thể là infographic hoặc bộ slide thuyết trình qua chế độ Canvas. Và đây là kết quả của mình với prompt thông thường tạo thành cuốn sách từ tất cả các notebook được chọn. Bạn có thể tham khảo ở link Gemini sau đây Viết content không lo ảo giác Đây là use case hữu ích nhất với người làm nội dung. NotebookLM đảm nhiệm phần "đúng" đó là giữ chặt số liệu, tên người, sự kiện từ tài liệu gốc. Gemini đảm nhiệm phần "hay" đó là viết văn, tạo hook, chọn góc độ hấp dẫn. Tuy nhiên kết quả vẫn chưa so được với Claude nhưng cũng là một tham khảo để đưa sang Claude viết lại thì bạn sẽ nhận được kết quả thật sự rất tốt. Gems tự cập nhật kiến thức Gems là các trợ lý AI tùy chỉnh trong Gemini. Khi bạn gắn notebook vào một Gem, điểm đặc biệt là notebook đồng bộ tự động khi bạn thêm tài liệu mới vào NotebookLM, Gem cập nhật ngay mà không cần thiết lập lại từ đầu. Ví dụ bạn có một Gem chuyên hỗ trợ khách hàng, mỗi khi chính sách công ty thay đổi bạn chỉ cần cập nhật notebook, Gem tự hiểu luôn. Audio Overview kết hợp tìm kiếm web NotebookLM đã có tính năng chuyển tài liệu thành podcast đối thoại khá hay. Khi kết hợp với Gemini, bạn có thể yêu cầu AI bổ sung thêm thông tin mới nhất từ web vào bản tóm tắt âm thanh đó, phù hợp để nghe khi di chuyển mà vẫn có đủ những tin tức cập nhật mới nhất. Bắt đầu từ đâu nếu bạn chưa quen dùng NotebookLM và Gemini? Nếu bạn chưa từng dùng NotebookLM, hãy bắt đầu bằng cách upload một tài liệu bạn hay phải tra cứu có thể là quy trình nội bộ công ty, giáo trình học, hoặc báo cáo ngành bạn đang theo dõi. Tạo notebook từ tài liệu đó, rồi mở Gemini và kết nối notebook đó vào. Thử đặt một vài câu hỏi mà trước đây bạn phải đọc cả tài liệu mới trả lời được. Khi AI trả lời đúng và trích dẫn rõ nguồn, bạn sẽ hiểu ngay tại sao sự kết hợp này đáng để dùng thường xuyên. Không phải vì nó "cách mạng" hay "đột phá" mà vì nó giải quyết đúng một việc phiền phức cụ thể mà bạn vẫn phải làm thủ công mỗi ngày.

Bạn có ý tưởng cho một app hoặc website trong đầu nhưng không biết Figma, không biết code — và không muốn mất hàng tuần để học cả hai. Google Stitch được tạo ra để giải quyết đúng tình huống đó: bạn mô tả giao diện bằng tiếng Anh hoặc tiếng Việt thông thường, AI tạo ra màn hình hoàn chỉnh trong vòng dưới một phút. Google Stitch là gì? Google Stitch là công cụ AI thiết kế UI miễn phí do Google Labs phát triển, ra mắt tại Google I/O 2025 và hiện chạy trên nền Gemini. Bạn truy cập hoàn toàn qua trình duyệt tại stitch.withgoogle.com, không cần cài đặt gì thêm, chỉ cần đăng nhập bằng tài khoản Google. Điểm khác biệt so với Figma hay Canva là Stitch không yêu cầu bạn kéo thả hay chọn từng component. Bạn chỉ cần mô tả những gì bạn muốn — ví dụ "trang landing page cho ứng dụng công nghệ vũ trụ, dùng màu tím chủ đạo" — và Stitch tạo ra giao diện hoàn chỉnh với đầy đủ màu sắc, font chữ và bố cục. Kết quả là HTML và CSS thực sự, không phải ảnh chụp màn hình. Bắt đầu vibe design với Google Stitch AI trong 3 bước Bước 1: Viết prompt hiệu quả Chất lượng vibe -desgin phụ thuộc rất nhiều vào cách bạn mô tả prompt vì vậy một prompt tốt cần có đủ ba yếu tố: loại màn hình, đối tượng người dùng và cảm xúc hoặc phong cách muốn truyền tải. Ví dụ prompt yếu: "Tạo trang chủ cho app." Ví dụ prompt mạnh: "Thiết kế một trang đích hiện đại cho SaaS cho một công ty khởi nghiệp về công nghệ vũ trụ có tên là LaunchPad. Sử dụng bảng màu xanh dương thẫm và tím neon. Thêm một phần nổi bật có nút "Bắt đầu", một lưới tính năng gồm 3 cột và một bảng giá theo hiệu ứng kính mờ." và đây là kết quả của mình Ngoài ra, Stitch hỗ trợ cả việc upload ảnh phác thảo tay hoặc ảnh chụp màn hình tham khảo hoặc thậm chí là giọng nói của chính bán luôn để AI hiểu đúng hơn định hướng của bạn. Bước 2: Chọn mode Flash hay Pro? Google Stitch hiện có hai chế độ tạo ảnh. Flash dùng Gemini Flash, tạo kết quả nhanh hơn và phù hợp với các màn hình đơn giản hoặc khi bạn muốn thử nhiều ý tưởng nhanh. Pro dùng Gemini Pro, cho ra giao diện chi tiết và phức tạp hơn nhưng tốn nhiều quota hơn. Với tài khoản miễn phí hiện tại, bạn có giới hạn 350 lượt tạo tiêu chuẩn và 50 lượt thử nghiệm mỗi tháng. Với người mới bắt đầu thì đây là mức dư dả để thử nghiệm thoải mái, tuy nhiên nếu dùng để làm dự án thực tế thì nên cân nhắc tiết kiệm quota pro cho các màn hình quan trọng. Bước 3: Export ra đâu? Sau khi có giao diện ưng ý, Stitch cho bạn bốn lựa chọn xuất file. Dán vào Figma: Stitch tạo sẵn đoạn code để bạn copy và paste trực tiếp vào Figma. Phù hợp nếu bạn đang làm việc trong nhóm có designer hoặc cần chỉnh sửa chi tiết hơn trong môi trường quen thuộc. Tải về dạng ZIP: Bạn nhận được toàn bộ file HTML, CSS và hình ảnh đóng gói sẵn, có thể mở trực tiếp trên máy hoặc đưa vào bất kỳ môi trường phát triển nào. Export qua MCP sang Antigravity: Đây là cách tốt nhất nếu bạn muốn đi từ thiết kế đến sản phẩm chạy thực sự. Antigravity cùng hệ sinh thái Google nên hoàn toàn có thể kết nối được với Stitch qua MCP mà không phải cài đặt gì nhiều từ đó AI agent sẽ đọc trực tiếp toàn bộ thiết kế và tự sinh ra code React hoặc Flutter hoàn chỉnh mà không cần bạn copy-paste bất kỳ file nào. Mình sẽ có bài hướng dẫn chi tiết về luồng kết nối này sau. Copy prompt cho AI agent: Google Stitch đã hỗ trợ MCP cho nên bất cứ nền tảng nào hỗ trợ MCP đều có thể tải chi tiết mô tả thiết kế của Google Stitch ví dụ như Claude Code, ChatGPT, Grok. Google Stitch design làm tốt gì và chưa tốt gì? Điểm mạnh rõ nhất là tốc độ và độ hoàn thiện của output. Một màn hình phức tạp với nhiều component có thể ra đời trong 30 đến 60 giây, với HTML và CSS sạch, có thể dùng được ngay. Khả năng giữ nhất quán màu sắc, font chữ và spacing trong cùng một dự án cũng khá tốt, giúp các màn hình trông như thuộc về cùng một hệ thống thiết kế. Tuy nhiên có một vài điểm cần lưu ý thực tế. Layout đôi khi bị lệch hoặc các component chồng lên nhau, đặc biệt với các màn hình có nhiều tầng thông tin, vì vậy bạn nên kiểm tra kỹ trước khi đưa vào production. Code đầu ra là HTML thuần và Tailwind CSS, không phải React component hay Vue, nên nếu dự án của bạn dùng framework cụ thể thì sẽ cần thêm bước chuyển đổi trừ khi bạn dùng Antigravity để làm bước đó tự động. Ngoài ra tính năng upload ảnh để đưa vào thiết kế vẫn còn khá giới hạn so với Figma. Bắt đầu với Google Stitch từ đâu ? Đừng cố thiết kế toàn bộ app trong một lần thay vào đó hãy bắt đầu với một màn hình đơn giản nhất trong ý tưởng của bạn — trang đăng nhập, trang chủ, hoặc một màn hình chi tiết sản phẩm. Viết prompt mô tả chi tiết như đã hướng dẫn ở trên, chạy thử cả Flash và Pro để so sánh, rồi chỉnh sửa bằng cách tiếp tục chat với AI trong cùng giao diện Stitch. Khi bạn đã có một màn hình ưng ý, đó là lúc tốt nhất để thử luồng export sang các nền tảng AI agent khác để có thể tự biến thiết kế đó thành hiện thực. Toàn bộ quy trình từ prompt đến sản phẩm demo có thể hoàn thành trong khoảng 3 đến 4 tiếng nếu đã quen thuộc, tất nhiên sau đó công chỉnh sửa sau đó sẽ rất mất thời gian nhưng vẫn tốt hơn nhiều so với cách làm truyền thống đúng không.

Wordpress.com vừa làm điều mà nhiều người chờ đợi 43% số website trên toàn cầu đang chạy trên Wordpress và giờ đây AI có thể tự mình quản lý tất cả chúng. Wordpress.com vừa chính thức cho phép AI agent truy cập, chỉnh sửa và xuất bản nội dung trực tiếp trên website của người dùng thông qua giao thức MCP. Đây chắc chắn phải là thay đổi cực lớn kể từ khi Wordpress đã mở MCP nhưng chỉ cho phép phân tích và báo cáo về website năm 2025. Trước đây để cập nhật, viết mới một bài viết, bạn phải dùng quá nhiều thao tac đăng nhập - tìm đúng bài- chỉnh sửa từng trường rồi nhấn lưu, hoặc nếu dùng AI thì phải kết nối qua các công cụ bên thứ ba phải cài đặt khá rắc rối. Giờ thì bạn chỉ cần nhắn cho AI một câu: "Cập nhật tiêu đề bài mới nhất thành X và thêm đoạn trích này vào." AI sẽ chỉnh sửa trực tiếp ở Wordpress và thực hiện hết phần còn lại mà không phải chuyển qua các nền tảng khác. MCP là gì và nó là thứ đứng sau toàn bộ kết nối? MCP viết tắt của Model Context Protocol là giao thức giúp AI nhìn thấy và tương tác với các ứng dụng bên ngoài. MCP được ông lớn Anthropic tạo ra và hậu thuẫn cho nên nó đã và đang trở thành chuẩn chung cho rất nhiều nhà phát triển AI cho nên mọi người rất yên tâm về sự lâu dài của nó. MCP khác với API ở chỗ nếu API là cái cổng để lập trình viên kết nối hai hệ thống với nhau thì MCP là cái cổng được thiết kế riêng cho AI, giúp mô hình ngôn ngữ hiểu được ngữ cảnh của từng ứng dụng thay vì chỉ nhận dữ liệu thô. WordPress.com đã triển khai MCP từ cuối năm ngoái và tính năng AI agent lần này được xây dựng hoàn toàn trên nền tảng đó. Điểm mạnh là bạn không bị gắn chặt với một AI cụ thể mà có thể kết nối Claude, ChatGPT, Cursor hoặc bất kỳ AI client nào hỗ trợ MCP với cùng một tài khoản WordPress.com. Để kích hoạt, chỉ cần truy cập wordpress.com/mcp và phải bật các tính năng MCP mong muốn rồi các AI như Claude, Gemini, ChatGPT mới có thể kết nối được vào MCP. AI agent làm được gì trên Wordpress Danh sách tính năng Wordpress hỗ trợ chắc chắn dài hơn bạn nghĩ khá nhiều đấy. Tất nhiên sau khi kết nối, bạn có thể ra lệnh bằng ngôn ngữ tự nhiên để thực hiện hầu hết mọi tính năng trong phần cập nhật MCP mới này. Quản lý nội dung: Bạn có thể yêu cầu AI tạo bài viết mới, chỉnh sửa tiêu đề hoặc thêm đoạn trích hoặc chuyển bản nháp sang trạng thái đã xuất bản và ngược lại. AI thậm chí có thể viết một bài blog theo phong cách thường thấy của bạn rồi lưu dưới dạng bản nháp chờ duyệt trước khi đăng chính thức. Quản lý bình luận: Bạn có thể duyệt các bình luận đang chờ xử lý, đánh dấu spam, xóa comment không phù hợp và thậm chí trả lời bình luận mới nhất trên một bài cụ thể, tất cả chỉ bằng một câu lệnh. Tổ chức nội dung: AI có thể tạo danh mục mới, thêm tag vào bài viết và sắp xếp lại cấu trúc phân loại nội dung mà không cần bạn phải mò mẫm qua từng menu trong dashboard. Cập nhật media: Sửa alt text cho ảnh vừa tải lên hoặc cập nhật chú thích theo tên ảnh là những việc nhỏ nhặt nhưng tốn thời gian nếu làm thủ công trên hàng chục bài viết, và AI xử lý điều này chỉ trong vài giây. Theo dõi và khám phá: Bạn có thể hỏi trang nào có lượng truy cập nhiều nhất hoặc đơn giản là yêu cầu tóm tắt các bình luận gần đây hoặc đề xuất 10 chủ đề bài viết tiếp theo dựa trên nội dung hiện có của blog. Dọn dẹp hàng loạt: Xóa tất cả bản nháp đã để quá một năm hoặc chuyển một loạt bài từ trạng thái này sang trạng thái khác là những việc mà trước đây cần plugin hoặc phải làm tay từng bài một. Cần lưu ý gì trước khi dùng AI cho Wordpress? Mặc dù nghe có vẻ tiện lợi, trao quyền cho AI chỉnh sửa trực tiếp website vẫn là việc cần suy nghĩ kỹ. Wordpress.com đã xây dựng một số rào chắn cơ bản đó là bài viết do AI tạo mặc định được lưu dưới dạng bản nháp và không tự xuất bản, trong khi mọi thay đổi đều được ghi lại trong Activity Log để bạn có thể kiểm tra lại bất cứ lúc nào. Tuy nhiên với một số tác vụ như xóa bài hàng loạt hay chuyển trạng thái bài viết lại không có cơ chế hoàn tác đơn giản, vì vậy bạn cần kiểm tra kĩ trước khi ra lệnh tất nhiên phải rõ ràng và có chủ đích. Về chất lượng nội dung, AI có thể viết bài theo phong cách của bạn dựa trên các bài cũ, nhưng "theo phong cách" không có nghĩa là đạt chất lượng tương đương. Bài nháp do AI tạo vẫn cần một lượt đọc lại của con người trước khi đăng, đặc biệt với những chủ đề chuyên sâu hoặc cần độ chính xác cao. Ngoài ra, tính năng xem danh sách người dùng và kiểm tra trạng thái plugin chỉ khả dụng cho tài khoản quản trị viên, đây là giới hạn hợp lý để tránh rủi ro bảo mật không đáng có. Bức tranh rộng hơn khi các nền tảng mở cửa cho AI agent Wordpress.com hiện ghi nhận 20 tỷ lượt xem trang và 409 triệu khách truy cập mỗi tháng. Khi nền tảng chiếm 43% web toàn cầu chính thức mở cửa cho AI agent, câu hỏi không còn là liệu AI có thay đổi cách nội dung được tạo ra không? mà là nội dung do AI tạo sẽ chiếm bao nhiêu phần trăm web trong 2 năm tới ?. Xu hướng này đang diễn ra đồng thời ở nhiều nơi như Meta mua lại Moltbook là mạng xã hội nơi AI agent có thể đăng bài và tương tác, trong khi Anthropic cũng thử nghiệm cho AI viết blog dưới sự giám sát của con người. Wordpress.com không phải người tiên phong về ý tưởng, nhưng họ là người đầu tiên triển khai nó ở quy mô đủ lớn để tạo ra tác động thực sự. Với người dùng phổ thông động thái của Wordpres giúp rào cản vận hành một website đang tiến gần về 0 và bạn không cần biết Wordpress hoạt động như thế nào mà chỉ cần biết mình muốn gì rồi nói ra điều đó. Tuy nhiên chính vì rào cản thấp, nội dung kém chất lượng cũng sẽ xuất hiện tràn lan và khả năng phân biệt nội dung đáng đọc sẽ ngày càng trở thành kỹ năng quan trọng của người dùng web. Nếu bạn đang dùng Wordpress.com, hãy thử truy cập Wordpress và bắt đầu sử dụng các skils viết bài của mình để kết nối tới Wordpress ngay.