Claude 4.6 có thực sự tệ hơn lúc ra mắt không?

Andrej Karpathy — đồng sáng lập OpenAI, cựu giám đốc AI tại Tesla và người đặt ra thuật ngữ "vibe coding" — đã chia sẻ trên X cách ông đang dùng AI, và câu trả lời không phải là viết code nhanh hơn mà là xây một hệ thống kiến thức cho bộ não thứ hai có khả năng tự duy trì, tự liên kết và tự cập nhật — đó là LLM Wiki. Wiki nghiên cứu của anh ấy viết về một chủ đề đã đạt 100 bài viết và 400.000 từ và điều đáng chú ý là toàn bộ do AI viết mà không cần ông gõ một chữ nào. Vấn đề với cách chúng ta đang dùng AI để tổ chức kiến thức RAG có tích lũy kiến thức theo thời gian như bộ não chúng ta không Hầu hết công cụ AI hiện tại xử lý tài liệu theo mô hình RAG — bạn tải lên tài liệu, đặt câu hỏi, hệ thống tìm đoạn văn bản liên quan rồi AI tổng hợp câu trả lời. NotebookLM của Google, ChatGPT với file upload, và hầu hết các quy trình AI đều dùng cách này vì nó rất đơn giản và dễ triển khai. Tuy nhiên Karpathy chỉ ra vấn đề cốt lõi mà ít người chú ý: RAG không tích lũy kiến thức. Mỗi lần bạn hỏi, hệ thống bắt đầu lại từ đầu — đọc lại tài liệu, tìm đoạn liên quan, ghép câu trả lời — rồi hỏi lại câu đó hôm sau thì nó lặp lại toàn bộ quá trình như chưa từng xảy ra. Tài liệu từ tháng 3 và tài liệu từ tháng 10 không tự kết nối với nhau tất nhiên là không có gì tích lũy và không có gì học được từ lần trước hoàn toàn không giống như cách bộ não chúng ta hoạt động. Karpathy mô tả sự thay đổi trong tư duy của mình bằng một câu rất ngắn nhưng nói lên nhiều thứ: phần lớn lượng token ông tiêu tốn gần đây không còn đi vào việc thao tác code mà đi vào việc thao tác kiến thức. LLM Wiki hoạt động như thế nào? LLM Wiki không phải phải phần mềm mà đây là một kiến trúc tư duy Obsidian Ý tưởng của Karpathy không phải là một phần mềm hay thư viện mới mà anh ấy công bố nó dưới dạng "idea file" để tạo ra kiến trúc giống với Obsidian — Anh ấy đã tạo ra file GitHub Gist được thiết kế để copy-paste trực tiếp vào một AI agent như Claude Code hoặc OpenAI Codex, rồi để agent tự xây hệ thống theo kiến trúc đó kết hợp với người dùng. Điều này có nghĩa là bạn không cài gì cả, mà thay vào đó bạn mô tả kiến trúc cho AI rồi AI tự triển khai nó cho bạn. Ba lớp kiến trúc cốt lõi của Wiki Hệ thống được tổ chức theo ba lớp rõ ràng và mỗi lớp có vai trò không thể thay thế cho nhau: Thư mục nguồn thô (raw/): Nơi bạn thả bất cứ tài liệu nào vào — PDF, bài báo, transcript, ghi chú, đoạn tweet — và AI đọc nhưng không bao giờ sửa thư mục này. Nguyên tắc thiết kế ở đây rất quan trọng: thu thập trước, tổ chức sau, tức là bạn không cần phải phân loại hay chuẩn bị tài liệu trước khi đưa vào. Wiki (wiki/): Thư mục chứa toàn bộ các file markdown do AI tạo và duy trì, và đây là nơi kiến thức được biên dịch, liên kết và tổng hợp. Mỗi tài liệu trong raw/ được AI đọc và tích hợp vào wiki — cập nhật các trang liên quan, ghi chú mâu thuẫn, tạo backlink sang các khái niệm liên quan. File cấu hình (CLAUDE.md hoặc tương đương): Bộ quy tắc nói cho AI biết cách tổ chức wiki, format bài viết, xử lý mâu thuẫn và duy trì nhất quán xuyên suốt toàn bộ hệ thống. Karpathy mô tả mối quan hệ giữa các thành phần bằng một câu rất hình ảnh: "Obsidian là IDE. LLM là lập trình viên. Wiki là codebase." Bạn không tự viết wiki mà thay vào đó bạn đặt câu hỏi, khám phá, trong khi AI làm phần việc tẻ nhạt là duy trì và cập nhật cơ sở dữ liệu. Vòng lặp tự duy trì là điểm khác biệt thực sự Ba thao tác chạy liên tục không cần can thiệp Điều làm LLM Wiki khác với các công cụ ghi chú AI thông thường là vòng lặp hoạt động tích cực sau khi Wiki đã được xây dựng và AI không chỉ tóm tắt tài liệu một lần rồi thôi mà nó chạy ba thao tác liên tục: Ingest (thu thập): Khi bạn thả một tài liệu mới vào thư mục nguồn, AI đọc nó, trích xuất thông tin quan trọng và tích hợp vào wiki — cập nhật các trang đã có, tạo trang mới nếu cần, đồng thời ghi chú chỗ nào thông tin mới mâu thuẫn với cái cũ thay vì xóa đi một cách tùy tiện. Query (truy vấn): Bạn hỏi bằng ngôn ngữ tự nhiên và vì wiki đã được biên dịch và cấu trúc sẵn nên AI trả lời với độ chính xác cao và có thể trích dẫn đến từng trang cụ thể, thay vì ghép câu trả lời từ các đoạn rải rác như RAG thông thường. Lint (kiểm tra chất lượng): AI định kỳ quét toàn bộ wiki để phát hiện link bị hỏng, trang cô lập không được liên kết với phần còn lại, thông tin mâu thuẫn giữa các trang, và lỗ hổng kiến thức chưa được bao phủ. Karpathy gọi đây là "CI/CD cho knowledge base" — tức là hệ thống tự kiểm tra chất lượng của chính mình. Karpathy giải thích lý do hệ thống này bền vững hơn wiki truyền thống do con người duy trì bằng một nhận xét đơn giản nhưng rất chính xác: "Con người bỏ cuộc với wiki vì gánh nặng bảo trì tăng nhanh hơn giá trị nó mang lại. LLM không chán, không quên cập nhật tài liệu đối chiếu và có thể chỉnh 15 file trong một lần chạy." Tại sao không cần RAG ở quy mô cá nhân? Context window đã đủ lớn để thay thế vector database Lập luận gây tranh cãi nhất trong đề xuất của Karpathy là tuyên bố RAG không cần thiết ở quy mô cá nhân, và logic của anh ấy như sau: một bộ não thứ hai toàn diện — dù bao phủ toàn bộ lĩnh vực nghiên cứu của bạn — thường chỉ khoảng 500.000 đến 2 triệu token sau khi biên dịch thành markdown. Với các model có context window dài hiện tại, toàn bộ Wiki đó có thể đưa vào context trong một lần truy vấn mà không cần hệ thống tìm kiếm vector phức tạp nào. Karpathy báo cáo rằng ở quy mô khoảng 100 bài viết và 400.000 từ, hệ thống xử lý câu hỏi phức tạp tốt mà không cần vector database hay RAG infrastructure nào, vì AI tự xây và duy trì các file index và tóm tắt rồi điều hướng qua toàn bộ tập hợp văn bản hiệu quả nhờ cấu trúc tự xây đó. Tuy nhiên cần lưu ý một điểm quan trọng: giới hạn này có thực. Khi wiki vượt qua một ngưỡng nhất định có thể là vài triệu token thì context window bắt đầu trở thành nút thắt cổ chai thực sự, và lúc đó các công cụ tìm kiếm như qmd (hybrid BM25/vector search cho markdown) sẽ cần được tích hợp thêm để duy trì hiệu suất. Cách bắt đầu thực tế trong 15 phút Các bước đầu tiên để có wiki đầu tiên như thế nào Karpathy thiết kế hệ thống này để bất kỳ ai có Claude Code hoặc công cụ AI agent tương đương đều có thể triển khai ngay mà không cần kiến thức kỹ thuật chuyên sâu. Quy trình cơ bản gồm bốn bước: Tạo một vault Obsidian mới — đây chỉ là một thư mục trên máy tính, nơi toàn bộ file markdown sẽ được lưu và Obsidian chỉ là giao diện để bạn đọc và điều hướng. Tạo hai thư mục con: raw/ để chứa tài liệu nguồn và wiki/ để AI viết và duy trì — hai thư mục này là tất cả những gì bạn cần thiết lập thủ công. Copy GitHub Gist của Karpathy tại Github và paste vào Claude Code hoặc AI agent bạn đang dùng, vì Gist được viết như một bộ hướng dẫn cho agent và để agent tự xây phần chi tiết cùng bạn thay vì bạn phải làm tất cả. Thả vài tài liệu đầu tiên vào raw/ và để agent bắt đầu biên dịch wiki — từ đây mọi thứ sẽ tự chạy. Cả hệ thống chạy hoàn toàn trên máy local với chỉ hai phụ thuộc là Obsidian để xem và điều hướng, và một AI agent để viết và duy trì. Điều này có nghĩa là không có vendor lock-in, không có dữ liệu gửi lên cloud nếu bạn dùng model local, và không có phí thuê bao nào ngoài chi phí gọi API của model bạn chọn. LLM Wiki so với MemPalace, Mem0 và Zep Bốn triết lý khác nhau cho cùng một vấn đề Cùng thời điểm LLM Wiki của Karpathy được chú ý, cộng đồng AI cũng đang thảo luận về MemPalace là một hệ thống bộ nhớ mã nguồn mở do diễn viên Milla Jovovich và kỹ sư Ben Sigman xây dựng, đạt 96.6% trên benchmark LongMemEval. Cả bốn hệ thống LLM Wiki, MemPalace, Mem0 và Zep đều giải quyết vấn đề AI không nhớ ngữ cảnh giữa các session, nhưng theo bốn triết lý rất khác nhau và phù hợp với bốn nhu cầu khác nhau. Cách dễ nhất để hình dung sự khác biệt là qua một tình huống cụ thể: bạn đã có 6 tháng hội thoại với AI về một dự án nghiên cứu — mọi quyết định, mọi lý luận, mọi phương án bị loại bỏ. Mở session mới và hỏi lại "Tại sao lúc đó mình chọn hướng A thay vì B?" — mỗi hệ thống sẽ trả lời theo cách hoàn toàn khác nhau. Mem0 hoạt động như người thư ký ghi tóm tắt cuộc họp, nghĩa là nó dùng AI để đọc hội thoại, trích xuất các "facts" quan trọng như sở thích và quyết định đã đưa ra, rồi lưu vào vector database. Khi bạn hỏi lại, nó tìm fact gần nhất với câu hỏi và trả về — nhanh, dễ tích hợp và phù hợp với chatbot thương mại, nhưng lý do đằng sau quyết định cùng chuỗi lập luận dẫn đến kết quả thường đã biến mất vì AI đã tự quyết định thứ đó không quan trọng. Zep tinh vi hơn một bước với knowledge graph có yếu tố thời gian, tức là nó không chỉ nhớ "bạn thích X" mà nhớ "tháng 1 bạn nghĩ X, tháng 3 bạn đổi sang Y vì lý do Z". Điểm mạnh là hiểu được sự thay đổi theo thời gian và phù hợp cho ứng dụng cần track tiến trình người dùng, tuy nhiên Zep vẫn dùng AI để quyết định thông tin nào được đưa vào graph nên vẫn có nguy cơ mất context quan trọng — đặc biệt là những lý luận phức tạp mà AI đánh giá là không cần thiết. MemPalace theo triết lý ngược hoàn toàn: "lưu tất cả, rồi làm cho nó tìm được". Thay vì để AI quyết định cái gì đáng nhớ, MemPalace lưu nguyên văn toàn bộ hội thoại vào ChromaDB rồi tổ chức theo cấu trúc phân cấp lấy cảm hứng từ kỹ thuật ký ức cung điện của người Hy Lạp cổ: Wing → Hall → Room → Closet → Drawer. Không có gì bị lọc bỏ nhưng mọi thứ đều có địa chỉ rõ ràng để tìm lại, và hệ thống chạy hoàn toàn trên máy local mà không gửi dữ liệu ra ngoài. LLM Wiki của Karpathy giải quyết bài toán khác hẳn so với ba hệ thống trên. Thay vì nhớ hội thoại, nó biên dịch tài liệu thành kiến thức có cấu trúc — bạn không đưa vào lịch sử chat mà đưa vào bài báo, transcript, ghi chú nghiên cứu, rồi AI xây một wiki markdown có liên kết, tóm tắt và có thể truy vấn. Mỗi tài liệu mới không chỉ được lưu mà được tích hợp vào kiến thức đã có, tạo ra kết nối mới giữa các khái niệm và làm giàu thêm những gì đã biết. Bảng so sánh để chọn đúng công cụ cho đúng nhu cầu table { width: 100%; border-collapse: collapse; margin: 20px 0; font-family: Arial, sans-serif; } th, td { border: 1px solid #ddd; padding: 12px; text-align: left; } th { background-color: #f4f4f4; font-weight: bold; } tr:nth-child(even) { background-color: #fafafa; } tr:hover { background-color: #f1f1f1; } Tiêu chí LLM Wiki MemPalace Mem0 Zep Nguồn dữ liệu Tài liệu nghiên cứu, bài báo, transcript Lịch sử hội thoại với AI Lịch sử hội thoại Lịch sử hội thoại Cách lưu trữ Markdown có cấu trúc, AI biên dịch Nguyên văn toàn bộ, phân cấp không gian Facts được trích xuất bởi AI Knowledge graph có thời gian AI có lọc thông tin? Có — AI quyết định cách tổ chức Không — lưu tất cả Có — AI chọn facts quan trọng Có — AI chọn entities và relations Chạy local? Có — chỉ cần Obsidian + model Có — ChromaDB + SQLite trên máy Không — cloud service Không — cloud service Phù hợp nhất với Nghiên cứu, học tập, tổng hợp tài liệu Nhớ ngữ cảnh AI theo thời gian dài Chatbot, ứng dụng thương mại App cần track tiến trình người dùng Điểm yếu Không nhớ hội thoại, cần setup ban đầu Tốn dung lượng, chưa có UI trực quan Mất lý luận phức tạp Phụ thuộc cloud, vẫn có thể mất context Điểm quan trọng nhất cần nhớ khi chọn: LLM Wiki và MemPalace giải quyết hai vấn đề khác nhau và hoàn toàn có thể dùng song song thay vì phải chọn một. MemPalace nhớ lịch sử các cuộc trò chuyện của bạn với AI — tức là nó biết bạn đã nói gì, đã quyết định gì và đã thay đổi quan điểm như thế nào. LLM Wiki thì tổ chức kiến thức từ thế giới bên ngoài đó có thể là bài báo bạn đọc, video bạn xem, tài liệu bạn thu thập. Kết hợp cả hai cho phép AI vừa hiểu bạn là ai vừa hiểu lĩnh vực bạn đang nghiên cứu và cả 2 kết hợp mới thành bộ não thứ hai đầy đủ hơn. Insight đáng suy nghĩ nhất từ LLM Wiki Phần đông chúng ta đang dùng AI như một công cụ tạo ra câu trả lời nhất thời — mỗi session bắt đầu từ đầu và không có gì tích lũy. LLM Wiki của Karpathy gợi ý một hướng khác: dùng AI như một bộ biên dịch kiến thức, nơi mỗi tài liệu mới không chỉ được lưu trữ mà được tích hợp vào một cấu trúc đã có, tạo ra kết nối mới và làm giàu những gì đã biết. Nếu bạn đang nghiên cứu một lĩnh vực cụ thể — AI, công nghệ, tài chính hay bất kỳ thứ gì — đây là thứ đáng thử ngay hôm nay: tạo một thư mục, thả vào đó 5 bài viết bạn đã đọc gần đây, và để Claude Code bắt đầu xây wiki đầu tiên. Sau một tuần thêm tài liệu đều đặn, bạn sẽ thấy sự khác biệt giữa một kho lưu trữ và một cơ sở kiến thức thực sự. Nếu bạn đang nghiên cứu một lĩnh vực cụ thể — AI, công nghệ, tài chính, bất kỳ thứ gì — đây là thứ đáng thử ngay hôm nay: tạo một thư mục, thả vào đó 5 bài viết bạn đã đọc gần đây, và để Claude Code bắt đầu xây wiki đầu tiên. Sau một tuần thêm tài liệu đều đặn, bạn sẽ thấy sự khác biệt giữa một kho lưu trữ và một cơ sở kiến thức thực sự.

Milla Jovovich (nếu ai đã xem series Resident Evil chắc chắn quen mặt với Alice và cả Leeloo trong The Fifth Element nữa) Cô đã gây bất ngờ lớn cho cộng đồng AI khi ra mắt MemPalace – một hệ thống bộ nhớ AI mã nguồn mở, miễn phí, đạt điểm cao nhất từ trước đến nay trên benchmark LongMemEval. Mọi người đang nói đùa rằng cô vẫn chưa hề thoát vai khi vẫn tiếp tục làm cho tổ chức Umbrella để xây dựng Red Queen mới. Dự án này được cô hợp tác phát triển cùng lập trình viên Ben Sigman, lấy cảm hứng từ kỹ thuật “Memory Palace” (Cung điện ký ức) cổ xưa của người Hy Lạp. Thay vì chỉ tóm tắt hay lưu trữ thông tin một cách rời rạc, MemPalace xây dựng một “cung điện ảo” có cấu trúc rõ ràng: các cánh, hành lang, phòng, tủ, ngăn kéo… để tổ chức toàn bộ cuộc trò chuyện, ý tưởng và kiến thức một cách logic và dễ tìm kiếm. Điều đó cho ta thấy tiềm năng của AI cực lớn như thế nào khi mà nó hỗ trợ từ diễn viên, giáo sư bác sĩ tạo ra những nền tảng AI mạnh mẽ hoàn toàn có thể sử dụng được trong công việc. Tại sao MemPalace gây bất ngờ? Điều bất ngờ đầu tiên là tài khoản Github của cô là chính chủ mọi người có thể xem tại https://github.com/milla-jovovich/ và điều thứ hai là Milla Jovovich không hoạt động như một KOL tham gia vào MemPalace hoàn toàn nghiêm túc, cô ấy commit code bằng chính tài khoản Github chính chủ đó, quá bất ngờ nếu mọi người không tin có thể xem ở Commit này. Còn nếu nói về thuần kĩ thuật thì MemPalace hiện đang xuất hiện những ưu điểm sau Hoàn toàn cục bộ (local): Chạy trên máy tính cá nhân của bạn, không cần cloud, không gửi dữ liệu ra ngoài, bảo mật cao và không tốn phí. Lưu trữ 100% thông tin: Không tóm tắt (summarization) nên không mất mát chi tiết quan trọng. Tích hợp dễ dàng: Hỗ trợ nhiều mô hình AI như Claude, ChatGPT, Gemini, Llama… và có thể nhập dữ liệu từ lịch sử chat, Slack, v.v. Benchmark ấn tượng: Đạt điểm cao nhất (gần perfect score) trên LongMemEval – một bài kiểm tra khả năng nhớ dài hạn, truy vấn đa bước và cập nhật kiến thức theo thời gian. MemPalace không chỉ là một công cụ lưu trữ, mà là cách tiếp cận mới giúp AI “nhớ như người thật” – tổ chức thông tin theo không gian thay vì chỉ dựa vào vector search hay tóm tắt. Phân tích công nghệ AAK ngôn ngữ bí mật giúp nén bộ nhớ Một điểm nổi bật trong MemPalace là công nghệ AAK (experimental Abbreviation-As-A-Key). Đây là lớp nén thông minh, hoạt động như một “ngôn ngữ rút gọn” mà bất kỳ LLM nào cũng có thể đọc được mà không cần decoder riêng. AAK là gì và nó có dễ hiểu không? Hãy tưởng tượng bạn có một cuốn sổ tay dày cộm ghi chép hàng tháng cuộc trò chuyện. Thay vì giữ nguyên từng chữ (tốn nhiều dung lượng và token), AAK sẽ rút gọn thông tin lặp lại một cách khéo léo: Sử dụng mã viết tắt cho các thực thể thường gặp (entity codes). Thêm dấu cấu trúc để giữ mối quan hệ. Cắt ngắn câu nhưng vẫn giữ ý chính. Ví dụ đơn giản: Thay vì lặp lại “Người dùng thích dùng PostgreSQL vì nó ổn định, mã nguồn mở và hiệu suất cao”, AAK có thể nén thành dạng ngắn gọn nhưng vẫn dễ hiểu như “User prefers Postgres [reason: stable, open-source, high perf]” và tất nhiên nó có thể tiết kiệm token. Ưu điểm của AAK là gì Nén mạnh (có thể lên đến 30x ở một số trường hợp), giúp đưa hàng tháng dữ liệu vào context window mà không vượt giới hạn. Vẫn readable (đọc được) trực tiếp bởi mọi mô hình AI. Hoàn toàn cục bộ, không phụ thuộc cloud. Nhược điểm hiện tại của AAK Đây là tính năng thử nghiệm. Trên benchmark LongMemEval, phiên bản dùng AAK đôi khi cho điểm thấp hơn chế độ raw (không nén) vì tính “lossy” (mất một phần thông tin). Đội ngũ đang tiếp tục cải tiến. Tóm lại, AAK giống như việc bạn viết “ngắn gọn nhưng vẫn đủ ý” trong ghi chú cá nhân, giúp AI đọc nhanh và nhớ nhiều hơn mà không cần mô hình siêu lớn. So sánh Mem0 và Zep các ông lớn bộ nhớ AI hiện nay Mem0 và Zep là hai framework bộ nhớ AI phổ biến nhất cho agent và ứng dụng chat. Chúng giải quyết vấn đề “AI hay quên” theo cách khác nhau. Mem0 (như “người bạn cá nhân hóa”) Cách hoạt động: Tự động trích xuất thông tin quan trọng từ cuộc trò chuyện rồi lưu vào vector database + tùy chọn knowledge graph. Ưu điểm: Dễ dùng, tiết kiệm token, tốt cho cá nhân hóa lâu dài. Nhược điểm: Có thể bỏ sót chi tiết nếu tóm tắt quá mạnh. Điểm benchmark LongMemEval khoảng 49%. Zep hoạt động như nhà sử học chuyên nghiệp Cách hoạt động: Xây dựng temporal knowledge graph – mọi sự kiện đều có mốc thời gian rõ ràng. Ưu điểm: Mạnh về truy vấn phức tạp, theo dõi sự thay đổi theo thời gian. Điểm benchmark khoảng 64%. Nhược điểm: Xây dựng graph tốn thời gian và tài nguyên hơn. Bảng so sánh nhanh table { width: 100%; border-collapse: collapse; /* Gộp các đường kẻ lại thành một */ margin: 20px 0; font-family: Arial, sans-serif; } th, td { border: 1px solid #ddd; /* Màu đường kẻ xám nhạt */ padding: 12px; text-align: left; } th { background-color: #f4f4f4; /* Màu nền cho tiêu đề bảng */ font-weight: bold; } tr:nth-child(even) { background-color: #fafafa; /* Tô màu xen kẽ cho dễ đọc */ } tr:hover { background-color: #f1f1f1; /* Hiệu ứng khi di chuột qua hàng */ } Tiêu chí Mem0 Zep MemPalace (Milla Jovovich) Phong cách Cá nhân hóa, tiết kiệm Temporal (thời gian), sâu sắc Cung điện ký ức – tổ chức không gian Lưu trữ Vector + Graph (tùy chọn) Temporal Knowledge Graph Toàn bộ dữ liệu + cấu trúc phòng + AAK nén Benchmark ~49% ~64% Cao nhất (gần 100% ở một số config) Chi phí/Tài nguyên Thấp Trung bình – cao Rất thấp (chạy local, miễn phí) Dễ dùng Rất dễ Trung bình Dễ, một lệnh cài đặt Bảo mật Tốt (có self-host) Tốt (có cloud) Xuất sắc (100% local) MemPalace mang lại điều gì cho cộng đồng AI MemPalace của Milla Jovovich mang đến làn gió mới cho lĩnh vực AI memory: chứng minh rằng không cần mô hình khổng lồ hay cloud đắt tiền, chỉ cần ý tưởng sáng tạo từ kỹ thuật cổ xưa kết hợp công nghệ hiện đại cũng có thể tạo ra kết quả vượt trội. Nếu bạn đang xây dựng AI agent hoặc muốn AI cá nhân của mình “nhớ dai” hơn, MemPalace đáng để thử ngay (cài qua pip và chạy local). Đây không chỉ là công cụ, mà là bước tiến thú vị trong việc làm AI gần gũi và đáng tin cậy hơn với con người.

Boris Cherny — kỹ sư đứng sau Claude Code — không thích giải thích công cụ mình làm ra bằng slide mà anh ấy chia sẻ 13 tip thực chiến từ cách chính đội Anthropic đang dùng nó mỗi ngày. Dưới đây là 7 nguyên tắc cốt lõi mình đã đúc rút ra từ đó và điểm chung của tất cả là anh ấy không dùng Claude Code như một chatbot viết code hộ mà dùng như workflow thông minh, điều này anh ấy chia sẻ từ nhiều tháng trước có thể một số thứ cũ những vẫn còn rất nhiều điều để học hỏi từ những con người tài năng này. Nhân bản bản thân bằng cách chạy nhiều session song song Claude Code tất nhiên không hề được thiết kế để dùng chỉ một tab duy nhất. Boris chạy 5 tab terminal cùng lúc, kết hợp 5–10 session trên claude.ai/code và cả ứng dụng di động trong đó mỗi session xử lý đúng một nhiệm vụ độc lập. Lý do thực tế: nếu nhét quá nhiều việc vào một context, Claude bắt đầu xung đột ưu tiên và chất lượng đầu ra giảm rõ rệt. Thay vào đó: Dùng tính năng hand-off (&) để chuyển task giữa terminal và web. "Teleport" context từ máy tính sang điện thoại khi cần tiếp tục công việc lúc di chuyển. Đây là tính năng đã ra mắt từ lâu Một session là một nhiệm vụ là nguyên tắc sống còn khi dùng Claude Code để tránh việc bị tràn context. Chọn model mạnh nhất và luôn bắt đầu bằng Plan Mode Boris dùng Claude Opus 4.5 (do thời điểm tháng 1/2026 thì Opus 4.6 chưa ra mắt) kết hợp Thinking cho hầu hết công việc nghiêm túc. Trước khi để Claude tự chạy code, ông gần như luôn bắt đầu bằng Plan Mode — nhấn Shift + Tab hai lần. Plan Mode buộc Claude lập kế hoạch thành văn bản trước khi thực thi và đây là lúc phát hiện vấn đề sớm nhất với chi phí sửa thấp nhất. Theo Boris: "A good plan is really important." để Claude code có bước lập kế hoạch là cực kì quan trọng giống như để thợ xây đổ móng mà chưa có bản vẽ. Xây CLAUDE.md như một bộ nhớ chung của cả nhóm CLAUDE.md là file duy nhất toàn team check vào git, chứa mọi quy ước, context và bài học tích lũy. Nguyên tắc vận hành: Mỗi lần Claude làm sai ví dụ như sai convention, sai luồng xử lý, sai cấu trúc thư mục thì bắt Claude không chỉ sửa lần đó mà thêm ngay vào CLAUDE.md để lần sau nó không lặp lại. Trong code review, tag @.claude để bổ sung context trực tiếp từ PR vào file này. Boris gọi đây là "compounding engineering": hệ thống không đứng yên, nó cải thiện mỗi ngày theo từng lỗi được ghi nhận. Sau 3 tháng dùng nghiêm túc, CLAUDE.md của một team thực sự trở thành tài sản kỹ thuật — không phải chỉ là file config. Tự động hóa mọi việc lặp lại bằng Slash commands và Subagents Bất kỳ thứ gì bạn gõ hơn 3 lần trong ngày thì nên thành Slash command. Đặt chúng trong .claude/commands/. Ví dụ: /commit-push-pr — gom toàn bộ luồng commit, push và tạo PR thành một lệnh duy nhất. Với các bước chuẩn trong quy trình PR, Boris dùng Subagents như code-simplifier hay verify-app để xử lý tự động mà không cần can thiệp thủ công. Kết quả là thời gian từ "code xong" đến "PR sẵn sàng review" rút ngắn đáng kể và ít lỗi do bỏ sót bước hơn. Dùng Hooks và Permissions để hệ thống tự vận hành Ba cơ chế quan trọng Boris cấu hình Claude Code: PostToolUse hook — tự động format code sau mỗi lần Claude dùng tool. Bạn không cần nhớ chạy linter thủ công nữa. /permissions — khai báo trước các lệnh bash an toàn để Claude không hỏi xác nhận mỗi lần. Boris không khuyến khích dùng --dangerously-skip-permissions vì nó bỏ qua kiểm soát mà không có lý do thực sự tốt. Agent Stop hook hoặc plugin ralph-wiggum — với task chạy nền dài, hook này cho phép Claude tự xác minh kết quả khi hoàn thành mà không cần bạn ngồi chờ. Thay vì canh một session 20 phút, bạn để nó tự báo cáo khi xong. Kết nối Claude với toàn bộ công cụ của team Claude Code không phải công cụ hoạt động riêng lẻ. Boris cấu hình để Claude có quyền dùng Slack (qua MCP), BigQuery, Sentry, terminal và bất kỳ công cụ nào team đang dùng tất nhiên tất cả cấu hình MCP và các quyền chia sẻ chung để mọi người trong team có cùng môi trường. Thực tế, khi Claude có thể query trực tiếp Sentry để lấy stacktrace và đồng thời xem BigQuery để hiểu data pattern, chất lượng debug khác hẳn so với dán dữ liệu thủ công vào chat. Tạo vòng lặp kiểm tra là bước quan trọng nhất Boris nhấn mạnh đây là "có lẽ là điều quan trọng nhất" trong toàn bộ 13 tip. Ý tưởng cốt lõi: thay vì bạn ngồi kiểm tra đầu ra của Claude, hãy cho Claude cách tự kiểm tra. Vòng lặp kiểm tra có thể là: Một extension trình duyệt web tự chụp màn hình và so sánh UI. Một bộ test chạy sau mỗi thay đổi. Một bash script kiểm tra endpoint. Một simulator tái hiện luồng người dùng. Khi vòng lặp feedback hoạt động tốt, Claude biết ngay đầu ra của mình đúng hay sai mà không cần bạn làm trọng tài. Có thể từ đây chất lượng đầu ra tăng 2–3 lần không phải vì model tốt hơn mà vì Claude có thông tin để tự điều chỉnh. Bài học từ cách Boris dùng Claude Code Nhìn lại 7 nguyên tắc, điểm chung không phải là "dùng tính năng này, bật tính năng kia"mà là tư duy sử dụng Claude Code như một agent có context, có công cụ, có cách tự kiểm tra kết quả và có bộ nhớ tích lũy theo thời gian. Nếu bạn đang dùng một tab duy nhất và gõ prompt rồi chờ — bạn đang dùng khoảng 10% năng lực của công cụ này. Bước thực tế ngay hôm nay: tạo file CLAUDE.md trong dự án đang làm, ghi vào đó một quy ước hoặc một lỗi Claude vừa mắc. Đó là điểm khởi đầu của một hệ thống tích lũy, và nó bắt đầu từ một dòng đầu tiên. Còn nếu muốn tham khảo 13 tip của Boris thì bạn có thể tham khảo bài viết thực tế ở đây https://x.com/bcherny/status/2007179832300581177

Nhận việc xong rồi ngồi nhìn màn hình cả tiếng không biết bắt đầu từ đâu đây là điều này xảy ra với người dùng Antigravity không kém gì người làm việc thông thường. Vấn đề không phải bạn kém hay lười mà là não bạn không sợ việc khó, nó sợ việc không rõ ràng và khi bạn giao cho AI một yêu cầu mơ hồ thì kết quả Antigravity tạo ra cũng sẽ mơ hồ không kém. Tại sao giao việc cho Antigravity mà vẫn ra kết quả tệ? Antigravity là agent thực sự vì nó có thể lên kế hoạch, viết code, chạy lệnh và tự kiểm tra kết quả. Nhưng đây chính xác là lý do khiến nhiều người thất vọng lần đầu dùng, họ bắt tay ngay giao cho Antigravity một việc cực lớn và mơ hồ, agent chạy 30 phút theo hướng sai quota tiêu hao hết mà kết quả không dùng được. Các nhà khoa học nhận thức gọi trạng thái đóng băng trước việc lớn là quá tải nhận thức - cognitive overload. Não không biết xử lý từ đâu nên chọn cách an toàn nhất là không làm gì cả và vòng lặp quen thuộc trông như thế này: Não sợ làm sai → đóng băng Không bắt đầu được → hạn chót đến gần Càng sợ hơn → lại đóng băng tiếp Với Antigravity, quá tải nhận thức của người dùng trực tiếp tạo ra prompt tệ, và prompt tệ tạo ra agent chạy sai hướng tất nhiên vòng lặp này tốn token và thời gian hơn bất kỳ lỗi kỹ thuật nào. Có ba cách tiếp cận để phá vỡ vòng lặp đó, tùy vào mức độ bạn đã hiểu yêu cầu và đã thiết lập quy trình đến đâu. Ba cách tiếp cận việc hiệu quả với Antigravity Cách 1: Tải source code của người đã có kinh nghiệm Đây là cách nhanh nhất để bắt đầu mà không mất thời gian thiết lập từ đầu, đặc biệt phù hợp khi bạn chưa biết quy trình của mình nên trông như thế nào. Antigravity hoạt động tốt nhất khi có đủ ngữ cảnh về dự án dó là khi nó có thể nhìn thấy các rules, workflow, skills và thư mục bộ nhớ ghi lại kiến thức cũ. Thay vì tự xây dựng tất cả, bạn sao chép source code của người đã thiết lập đầy đủ, tải về và để agent đọc toàn bộ cấu hình có sẵn và điều tất nhiên là phải được người đó đồng ý hoặc đã public . Lưu ý: Rất nhiều người đã tận dụng điều này để phát tán mã độc vậy nên chỉ cài những source code từ chính thức từ Anthropic, Google, xAI, OpenAI,... hay những người có uy tín. Khi bạn sao chép kho code của người đã thiết lập đầy đủ, tải về và để agent đọc toàn bộ cấu hình có sẵn, bạn nhận được hai lợi ích cùng lúc: Agent hiểu ngay phong cách viết skills, workflow, nền tảng kỹ thuật và các rules của dự án từ ngày đầu mà không cần bạn giải thích lại. Bạn học được cách người có kinh nghiệm thiết lập quy trình — từ cách tổ chức thư mục bộ nhớ đến cách viết quy tắc cho agent mà không cần tự mày mò từ đầu. Tuy nhiên khi bạn không hiểu các ý đồ của người viết thì hoàn toàn không thể sử dụng hết chức năng của source code này giống như một mặc một chiếc áo quá rộng vậy. Cách 2: Tự giải quyết từng bước nhỏ trước khi giao việc lớn Đây là cách tiết kiệm hạn mức nhất và cũng là bài học mình học được sau nhiều lần lãng phí vì giao việc quá to ngay từ đầu. Bộ khung 4C — Làm rõ (Clarify), Tách nhỏ (Chunk), Tham khảo (Consult), Cam kết (Commit) vốn dùng để giải quyết việc của con người, nhưng áp dụng vào Antigravity lại cực kỳ hiệu quả vì lý do đơn giản: bạn càng rõ ràng trước khi giao việc, agent càng ít phải đoán. Bước làm rõ: Trước khi gõ bất cứ thứ gì vào Antigravity, hãy tự trả lời 4 câu hỏi sau: Kết quả cuối cùng trông như thế nào? Ai sẽ dùng cái này? Hạn chót thật sự là khi nào? Thế nào là hoàn thành tốt việc này? Năm phút ngồi trả lời sẽ thay đổi hoàn toàn chất lượng câu lệnh. Thay vì "xây cho mình một hệ thống đăng nhập", bạn sẽ viết được "xây hệ thống đăng nhập bằng Google OAuth cho ứng dụng Next.js, lưu phiên làm việc vào Firestore, chuyển hướng về trang chính sau khi đăng nhập thành công, chạy thử trên máy và chụp ảnh màn hình để mình xem". Bước tách nhỏ: Dựa trên hiệu ứng Zeigarnik một khi bạn bắt đầu dù chỉ một bước nhỏ, não tự động muốn hoàn thành những bước tiếp theo. Hãy hỏi agent "chia task thành các bước nhỏ nhất để bắt đầu ?" và đi qua từng bước một. Dành khoảng thời gian nhất định để tìm hiểu cấu trúc, kiểm tra xem agent hiểu đúng yêu cầu chưa trước khi để nó chạy việc lớn. Nhưng hãy nhớ là chỉ giành một khoảng thời gian nhất định thôi nhé vì chỉ khi thực hiện thì nhiều vấn đề mới thực sự lộ ra chúng ta mới tìm ra cách giải quyết. Ở bước này chúng ta có thể sử dụng luôn chế độ Fast Mode cho agent thực hiện luôn mà không cần phải tạo khung sườn hay suy nghĩ sâu hoặc thậm chí nếu không có gì đặc biệt thì Gemini Flash hoàn toàn có thể đảm nhiệm tốt phần này cực kì tiết kiệm token cho Gemini Pro và Claude Opus. Bước tham khảo: Đừng tự làm khó bản thân khi đã có người đi trước. Tương tự như cách 1 tải mã nguồn người khác về dùng, bước này là chủ động tìm và đọc cách họ tiếp cận vấn đề xem họ chia việc ra sao, viết câu lệnh như thế nào, thiết lập quy trình ra sao rồi chắt lọc những phương pháp phù hợp để áp dụng vào việc của mình. Bạn không cần sao chép nguyên xi, chỉ cần học từ cấu trúc tư duy của họ. Điều này đặc biệt có giá trị với những loại việc bạn chưa từng giao cho agent bao giờ vì người đã làm trước thường đã tìm ra cả những điểm dễ đi sai mà bạn chưa biết. Bước cam kết: Thay vì cố lên kế hoạch hoàn hảo cho toàn bộ việc trước khi bắt đầu hãy chỉ cam kết 10 đến 15 phút đầu tiên để tìm hiểu. Hỏi agent một câu nhỏ, xem nó phản hồi thế nào và lúc nào cũng thêm câu prompt “Nếu vấn đề không rõ hoàn toàn có thể hỏi lại không được tự ý quyết định”. Chắc chắn sẽ có những thiếu sót nhưng chúng ta sẽ cảm thấy được chúng ta đã đi được một quãng đường xa với Antigravity với task thay vì ngồi viết prompt hoàn hảo hàng giờ mà chưa làm được gì chắc chắn sẽ rất chán. Cách 3: Giao việc lớn ngay khi đã có quy trình thiết lập sẵn Cách này chỉ hoạt động khi bạn đã qua hai cách trên — đã có quy trình rõ ràng, bộ nhớ ngữ cảnh skills, và agent đã quen với các rules, workflow. Đây có thể coi là bước cam kết trong bộ khung 4C: thay vì lo lắng về toàn bộ việc, bạn cần hướng agent vào một kết quả cụ thể và để agent tự xử lý phần còn lại. Lúc này, chế độ Plan Mode là lựa chọn tốt hơn chế độ Fast Mode vì agent phải tạo kế hoạch thực hiện chi tiết trước khi thực hiện task, từ đó bạn có thể xem lại kế hoạch đó để lại ghi chú nếu cần điều chỉnh rồi mới để agent chạy. Cách này kết hợp tốc độ của agent với tầm nhìn chiến lược của bạn vì quy trình đã có sẵn nên bước làm rõ nên được tích hợp vào các rules, workflow, skills để agent không cần bạn giải thích lại ngữ cảnh mỗi lần. Đặc biệt đây là cách cực kì ưa thích đối với các Pro khi mà họ dùng Claude để lên kế hoạch cực xịn rồi sau đó họ đưa vào cho GLM để thực thi taks để tiết kiệm token. Chúng ta nên chọn cách nào cho công việc của chúng ta Ba cách này sử dụng trong Antigravity không loại trừ nhau mà theo thứ tự từ ít đến nhiều ngữ cảnh: Việc mơ hồ, chưa biết bắt đầu từ đâu: Sao chép source code người khác hoặc dùng bộ khung 4C để làm rõ trước. Việc đã hiểu nhưng lớn và phức tạp: Đi qua từng bước nhỏ, dùng Flash cho bước đơn giản và dành Pro cho bước cần suy nghĩ sâu. Việc đã có quy trình rõ ràng: Giao thẳng với chế độ Plan Mode, để agent tự xử lý trong khi bạn làm việc khác. Điểm chung của cả ba cách là bạn phải làm một việc trước khi mở Antigravity: suy nghĩ. Không phải suy nghĩ dài — chỉ cần 5 đến 10 phút ngồi làm rõ yêu cầu trước khi giao cho agent. Khoảng thời gian đó tiết kiệm nhiều hạn mức hơn bất kỳ kỹ thuật tối ưu prompt nào khác.