Karpathy nói đúng: attention của bạn là nút thắt mới

1. Bài đăng của Karpathy: công việc dịch lên oversight và understanding

Ray Amjad mở đầu bằng một bài đăng trên X của Andrej Karpathy. Theo video đăng ngày 20/10/2026, bài này được đăng khoảng hai tuần trước đó. Ray thấy nó thật sự sâu sắc với nhiều engineer, và anh muốn đào sâu vào nó trong video này, xem từ đó mình cải thiện engineering workflow của mình được thế nào.

Bài đăng (theo video đăng ngày 20/10/2026) mở bằng câu: chúng ta sẽ dành nhiều thời gian hơn hẳn để cố hiểu output của các language model, và sau đó là một vài suy nghĩ, mẹo và thủ thuật. Ray kéo xuống tận cuối, phần "In summary". Ở đó Karpathy viết rằng khi LLM tốt lên, chúng sẽ tự làm ngày càng nhiều phần việc nặng nhọc (the legwork) một cách tự động, và phần lớn công việc của chúng ta sẽ "rise up the abstractions", dâng lên các tầng trừu tượng cao hơn, thành việc giám sát (oversight) và hiểu (understanding).

Phần summary trong bài đăng mà video ngày 20/10/2026 trích còn một ý nữa trên màn hình: may là LLM cũng giúp được ở đây, vì khi trí tuệ và code ngày càng dồi dào, bạn có thể yêu cầu những software artifact lớn, tuỳ biến, dùng xong bỏ (ví dụ web app, video explainer) mà trước kia chẳng ai thấy đáng làm. Karpathy kết bằng lời mời: hãy đẩy giới hạn ở đây, bạn sẽ bất ngờ.

2. "Một đội quân Claude", và attention thành nút thắt

Lý do chuyện này quan trọng, theo Ray: chính Anthropic cũng nói điều tương tự trong bài "How employment is changing at Anthropic" (trên màn hình, bài ghi ngày 16/10/2026). Trong đó, một engineer mô tả công việc như đang đối mặt với "an army of Claudes, with every one asking for my attention", một đội quân Claude mà con nào cũng đòi sự chú ý của mình.

Đoạn Ray tô sáng trên trang còn nói rằng một đặc điểm của làm việc trong một tổ chức dùng AI nhiều là áp lực liên tục phải tự đưa mình ra khỏi vị trí nút thắt (bottleneck) bất cứ khi nào có thể. Ray nói (video đăng ngày 20/10/2026) đây là điều mọi người đang nhận ra ngày càng rõ: attention đang trở thành nút thắt.

Nếu bạn có một đội quân Claude làm việc cho mình suốt ngày đêm, thì những người làm được nhiều việc hơn và tốt hơn sẽ là những người phân bổ attention của mình giỏi hơn khi có cả đống agent chạy quanh đồng hồ. Một câu Ray nói anh thích dùng là: code thì rẻ, nhưng attention của bạn thì không ("code is cheap, but your attention is not").

Đó là lý do, theo Ray (video đăng ngày 20/10/2026), bài của Karpathy quan trọng đến vậy: về cơ bản nó dạy ta cách phân bổ attention tốt hơn. Ray muốn đi qua một loạt ví dụ, vì anh thấy khi đọc một bài như thế, người ta thường gật gù "okay, hay đấy" rồi chẳng có gì thay đổi. Anh nghĩ sẽ có ích hơn nhiều khi nhìn một người làm thật trên màn hình của họ, với cả loạt ví dụ mà bạn có thể muốn đưa vào workflow của mình.

3. Từ viết code sang hiểu thứ agent trả về: richer representations

Theo Ray (video đăng ngày 20/10/2026), trong mấy tháng gần đó, nút thắt đã dịch chuyển từ chuyện viết code sang chuyện hiểu thứ agent trả về. Cách anh nghĩ về nó: thời gian của con người là thứ khan hiếm, nhất là khi bạn là engineer, còn token thì tương đối rẻ nếu đem ra so.

Lùi lại nhìn bức tranh lớn, Ray cho rằng thứ ta đang làm về cơ bản là tạo ra những cách biểu diễn phong phú hơn (richer representations), để từ cùng một lượng dữ liệu đang có, ta đưa ra quyết định tốt hơn.

4. Bret Victor và William Playfair: từ bảng số sang biểu đồ

Ý tưởng này làm Ray nhớ tới một trong những talk hay nhất anh từng xem, của Bret Victor, người mà theo Ray (video đăng ngày 20/10/2026) từng là designer ở Apple. Talk đó tên "The Humane Representation of Thought", và Ray khuyên xem nó sau khi xem xong video này.

Trong talk, Bret kể câu chuyện của William Playfair năm 1786. Playfair có một ý tưởng: thay vì đọc một bảng số như thế này, sao ta không dùng khả năng đọc bản đồ của mình để đọc chính những con số đó? Trên bản đồ, lên, xuống, trái, phải là bắc, đông, nam, tây. Playfair đề xuất: sao không để trái phải là thời gian, còn lên xuống là tiền? Kết quả trông như hình dưới, và theo câu chuyện Ray kể lại từ talk (video đăng ngày 20/10/2026), nó trở thành biểu đồ dữ liệu (data graphic) đầu tiên.

Vào thời đó, khi Playfair trình bày cùng một bảng số ấy dưới dạng một kiểu bản đồ, mọi người lập tức thấy đây là một cách cực mạnh để hiểu dữ liệu. Nó giúp họ nghĩ theo những cách mới, và đưa ra những quyết định mà chỉ nhìn bảng số thì họ không làm được. Ray nói thêm (video đăng ngày 20/10/2026): khoa học hiện đại sẽ hoàn toàn không thể hình dung nổi nếu thiếu kiểu công việc Playfair đã làm.

Ray rất thích kết luận của Bret: mỗi cách biểu diễn cho phép chúng ta nghĩ những ý nghĩ mà trước đó ta không thể nghĩ ra.

5. Code của agent là bảng số; bốn định dạng của Karpathy

Ray áp ý đó vào công việc với agent. Theo anh, phần lớn code mà agent của bạn viết về bản chất chính là "bảng số". Điều ta muốn là biến bảng số đó thành đúng cách biểu diễn, để ta ra quyết định thật nhanh, nhờ vậy agent làm việc được lâu hơn và đạt được nhiều hơn.

Và điều đó dẫn về bài của Karpathy (theo video đăng ngày 20/10/2026), nơi ông nêu bốn thứ: writing, diagram, trang web, và explainer video. Đây là phần Ray thật sự quan tâm. Nếu những artifact, những cách biểu diễn này cho ta nghĩ theo những cách trước đây không nghĩ được, nhìn dữ liệu và code của mình theo một cách khác, thì ta sẽ ra được quyết định tốt hơn. Và vì cuộc đời ta, sản phẩm của ta, rốt cuộc là tổng của tất cả những quyết định nhỏ ta phải đưa ra, ta sẽ có một cuộc đời tốt hơn và một sản phẩm tốt hơn.

Ray nghĩ còn nhiều cách biểu diễn khác nữa, nhưng trong video này anh tập trung vào những cái Karpathy nêu: writing, diagram và hình ảnh, HTML, và cuối cùng là video.

6. Bậc một, writing: ASD-STE100 và câu "I didn't read that"

Ở phần writing, theo video đăng ngày 20/10/2026, Karpathy nhắc tới việc bảo model viết theo ASD-STE100, về cơ bản là một dạng tiếng Anh kỹ thuật đơn giản hoá (simplified technical English). Trên bài đăng, Karpathy viết rằng đây là một đặc tả ngôn ngữ có kiểm soát, ban đầu làm cho tài liệu bảo dưỡng ngành hàng không vũ trụ; LLM rành ngôn ngữ này, và đôi khi ông chỉ xin "80% of the way to ASD-STE100" vì đặc tả khá khắt khe.

Ray kể anh đã nhắc tới chuyện này trong một video trước đó, khoảng hai tháng trước, về Opus 5. Nhưng tới lúc quay anh không còn thật sự dùng nó nữa, vì theo anh (video đăng ngày 20/10/2026), Opus 5.5 viết tốt hơn nhiều ngay từ mặc định.

Cái anh thấy thật sự tiện là thế này: khi nhận một output dài từ model, quá nhiều để tiêu hoá một lúc, anh chỉ việc bảo nó đại ý "này, tôi chưa đọc cái đó, dẫn tôi đi qua từng bước một được không?". Trên slide của anh, dòng đầu là "I didn't read that.", dòng sau là "Take me through it step by step.", và model trả lời theo từng bước, kiểu "Step 1 of 5: First, the request hits the cache."

I didn't read that. Take me through it step by step.

Ray nhấn mạnh việc đặt câu "I didn't read that" ngay ở đầu là rất quan trọng. Nếu không, model sẽ mặc định cho rằng bạn đã đọc hết toàn bộ và chỉ đang bối rối ở đâu đó.

7. Bậc hai, diagram: memory diagram, show-me và diagram-pane

Bậc tiếp theo trên thang là bảo Claude Code vẽ diagram cho bạn. Ray nói anh sẽ không dành nhiều thời gian cho phần này. Về cơ bản, bạn có thể bảo Claude Code vẽ một memory diagram để giúp mình hiểu một phần cụ thể của hệ thống. Trong ví dụ của anh, đó là một memory diagram cho thấy SDK của dịch vụ sandbox mà anh làm hoạt động thế nào ở phía sau. Nếu có một thay đổi lớn đang diễn ra trong hệ thống, anh có thể nhanh chóng hình dung nó bằng một memory diagram. Có rất nhiều loại diagram khác bạn có thể muốn làm, nhưng Ray cho rằng memory diagram là một loại khá tốt.

Ray nói (video đăng ngày 20/10/2026) anh có một skill để vẽ memory diagram cho tốt. Ngoài ra còn những skill khác, như skill show-me của HumanLayer: theo Ray, nó thường viết mọi thay đổi hay logic dưới dạng pseudocode hoặc một call tree, rồi vẽ thêm những diagram nhỏ. Trong SKILL.md của show-me (đọc ngày 22/10/2026), ví dụ call tree trông như sau:

submitForm
  createSession
    persistPrompt
    launchAgent
  navigateToSession

Bạn cũng có thể thấy rất tiện với mod diagram-pane cho Claude Code của Ray. Theo Ray (video đăng ngày 20/10/2026), nó hiện một diagram ở phía bên phải, gồm toàn bộ việc Claude đã làm trong phiên đó. Điều này rất có ích khi bạn quay lại một phiên cũ, hoặc khi bạn nhảy qua lại giữa nhiều phiên: bạn hiểu ngay "okay, mình đang ở đây, đây là những gì đã làm tới giờ".

Ray mở một phiên của chính anh trong Claude Code để cho xem: đó là toàn bộ việc anh đã làm trong phiên. Theo Ray (video đăng ngày 20/10/2026), mod này miễn phí, nằm cùng các Claude Code mod miễn phí khác của anh, mà theo lời anh nhiều senior engineer thấy rất hữu ích. README của repo (đọc ngày 22/10/2026) ghi cách cài bằng hai lệnh:

claude plugin marketplace add ray-amjad/claude-code-mods
claude plugin install diagram-pane@claude-code-mods

8. Bậc ba, HTML: đọc Feynman Lectures với demo tương tác

Theo bài đăng mà video ngày 20/10/2026 trích, Karpathy viết rằng còn tốt hơn nữa nếu bạn xin output "in HTML": LLM đang rất giỏi frontend và có thể tạo những trải nghiệm đẹp, có animation.

Ray nêu một ví dụ rất hay: có người trên X kể rằng họ đọc Feynman Lectures "đúng như Feynman muốn", kèm các demo do AI làm cho từng phần. Vì Ray học vật lý, anh đã đọc hết toàn bộ Feynman Lectures hồi đại học. Rồi anh tự hỏi: nếu mình bảo Claude làm một thứ tương tự thì sao? Và Claude làm cho anh một ví dụ rất đẹp.

Trong demo của video đăng ngày 20/10/2026, bấm vào Feynman Lectures, bạn thấy phần một ở bên phải. Claude nhìn các hình Feynman vẽ cùng phần mô tả, chép lại phong cách hình vẽ của Feynman rồi làm cho chúng tương tác được. Ray có thể xem chuyển động Brown (Brownian motion) đang diễn ra, dừng lại ở bất kỳ lúc nào và thấy "okay, phân tử này bay hơi và tách ra rồi". Nếu anh tăng nhiệt độ, ngày càng nhiều phân tử bay hơi và thoát ra, đúng như trên màn hình.

Ray nói thật lòng anh ước gì hồi học vật lý ở đại học, anh đã dùng cách này cho chính ghi chép bài giảng của mình: tự làm một diagram tương tác để giải thích từng ý. Anh tin rằng nếu thế, anh đã có một hiểu biết sâu và vững hơn nữa về vật lý. Anh định bảo Claude làm cả bộ bài giảng, vì tới lúc quay anh mới làm được vài phần.

Ray nghĩ cách này hợp đặc biệt với vật lý, vì hồi đi học anh hoàn toàn có thể biến mọi diagram tĩnh trong sách giáo khoa thành diagram "sống". Anh khuyên (video đăng ngày 20/10/2026): nếu bạn đang học đại học, hoặc có con đang học đại học, hãy mua cho họ một gói Claude Code hoặc Codex để họ học sâu hơn hẳn so với mọi lứa sinh viên trước từng học cùng môn đó, bằng cách tự làm những HTML artifact tương tác như thế này.

9. Builder, clarity reviewer, physics reviewer

Lần đầu Ray làm việc này, một số diagram và demo ra sai, và có những chỗ gây rối. Nên anh để Claude chạy một chuỗi sub-agent trong một dynamic workflow: một builder cho chương đó, sau đó một clarity reviewer, rồi một physics reviewer để đảm bảo phần vật lý vẫn được mô tả chính xác.

10. HTML artifact trong software factory

Với Ray, trong công việc hằng ngày, anh dùng HTML artifact chủ yếu để vận hành các software factory của mình. Theo Ray (video đăng ngày 20/10/2026), trên tất cả các repo của anh, mỗi tháng có khoảng 3.000 tới 4.000 PR được merge. Anh nói mình không thích dùng con số đó như một kiểu thước đo, nhưng nó giúp người xem hình dung khối lượng việc anh đang xử lý.

Phần lớn các PR này là thay đổi vừa và nhỏ, và có thể được merge tự động. Nhưng một số PR cần anh ra quyết định, vì chúng đụng tới bất cứ thứ gì liên quan tới SDK, auth, billing, legal, hoặc một nhóm domain khác trong ứng dụng mà anh đã định nghĩa.

Theo Ray (video đăng ngày 20/10/2026), software factory của anh chạy 24/7 trên Slack. Khi có một quyết định cần đưa ra mà agent không tự quyết được, vì anh đã dặn "những quyết định này để lại cho tôi", nó gửi cho anh một tin nhắn trong một channel, kèm một artifact giải thích nhanh tình huống. Nhờ vậy anh nắm nhanh: đây là thứ mình đang nhìn, đây là việc mình đang xử lý, đây là tất cả các bước kiểm tra đã chạy, và đây là những câu hỏi nó còn muốn hỏi mình. Với ví dụ đầu tiên anh mở, Ray thấy hơi rối, nên anh tìm một ví dụ dễ hiểu hơn.

11. Ví dụ: tính năng sign in with GitHub chờ duyệt

Ví dụ dễ hiểu hơn, trong video đăng ngày 20/10/2026: software factory đang làm tính năng sign in with GitHub. Nó đã chạy cả loạt bước xác minh. Nó đưa cho Ray một mock-up về chính xác những gì member sẽ thấy trên website, tính năng này nằm ở đâu trong bức tranh lớn, những việc nó không tự làm được, và cả câu chữ (copy) nó dùng cho thông báo toast.

Sau đó artifact cho anh một cái nhìn tổng quan nhanh về cách hệ thống hoạt động, và những bước kiểm tra nó thật sự chạy được. Trong demo của video đăng ngày 20/10/2026, Ray thấy nó đã thử hai user flow, và ở review round một nó không tìm thấy vấn đề nào với bản implement này. Vì PR này đụng tới authentication, một vùng khá rủi ro, nó hỏi anh xin duyệt: "này, bạn có muốn merge PR này không?". Anh chỉ cần bấm merge, nó sẽ quay lại phiên làm việc kia để hỏi tiếp rồi merge vào.

12. Không có template chung, mỗi artifact hợp với tình huống

Một điều Ray cố ý làm: mỗi HTML artifact hơi khác nhau. Anh không có một template cố định, vì anh muốn thiết kế của artifact phụ thuộc vào tình huống đang có.

Trong video đăng ngày 20/10/2026, anh mở một artifact khác, cho phần gates. Nó cho anh xem bằng chứng (proof) là thứ đó đang chạy, cùng một số hình minh hoạ giúp anh hiểu rõ hơn, có cả ảnh chụp màn hình từ chính ứng dụng. Ray xem rồi thấy "okay, cái này trông ổn", và chỉ cần bấm merge ở đó, nó sẽ quay lại phiên trước đó.

13. Token thì rẻ, attention thì đắt

Tóm lại, Ray đang dùng HTML artifact như một cách nhanh để tự cập nhật cho mình về tình huống trước mặt. Khi một agent đang chạy nền, làm việc suốt ngày đêm, có câu hỏi, nó hỏi anh ngay trong đó; anh hiểu nhanh tình huống và đưa ra một quyết định có đủ thông tin.

Đúng là như vậy nghĩa là bất cứ lúc nào một agent trong software factory muốn có một quyết định, nó lại làm một artifact để anh xem. Nhưng Ray thường thấy attention của mình mới là thứ đắt, còn token thì tương đối rẻ nếu so sánh. Nên anh không ngại tốn một ít token để làm những artifact này, vì attention của anh là nút thắt ở đây.

14. HTML plan có thể bấm chọn

Theo Ray (video đăng ngày 20/10/2026), một engineer khác trong team Claude Code có nhắc rằng họ đang làm một skill để tạo HTML plan tốt hơn. Nó trông như thế này: bạn có thể bấm qua lại và chọn giữa vài mock-up khác nhau để quyết định mình muốn cái nào. Nó liệt kê một loạt câu hỏi còn mở ở phía bên trái, và bạn giải quyết từng câu chỉ bằng cách bấm chọn giữa các phương án.

Bạn cũng có thể làm như anh ấy làm trong demo mà video đăng ngày 20/10/2026 chiếu lại: bấm quanh để xem các trạng thái khác nhau mà người dùng sẽ thấy. Cuối cùng, khi đã chọn hết các phương án, bạn bấm "Copy response", đưa nó lại cho Claude, và Claude sẽ tiếp tục phần implement.

Theo Ray (video đăng ngày 20/10/2026), anh ấy đã biến nó thành một plugin mà ai cũng tải về được. Bài đăng trên màn hình hướng dẫn cài bằng hai lệnh sau (dấu nối giữa html-plan và claude-community bị con trỏ chuột che; marketplace community của Anthropic, đọc ngày 22/10/2026, có plugin tên html-plan):

claude plugin marketplace add anthropics/claude-plugins-community
claude plugin install html-plan@claude-community

Ray nói anh rất thích cách dùng HTML artifact tương tác như vậy để ra quyết định tốt hơn.

15. Bậc bốn, explainer video: luật chơi Tokyo Highway

Định dạng output cuối cùng, theo bài đăng mà video ngày 20/10/2026 trích, là thứ Karpathy "bullish" nhất: những explainer video hoàn toàn tuỳ biến, may đo riêng. Bài đăng gợi ý thử những câu như "Create a 3b1b style video explainer on X. Use my ElevenLabs API key for audio narration", và viết rằng thứ này "is actually starting to work".

Ray nói (video đăng ngày 20/10/2026) mọi người đã thấy Opus 5.5 rất giỏi làm music video, nhất là một video cần rất nhiều animation mà anh cho xem. Đó là music video anh thích nhất tới lúc đó: anh xem xong và thốt lên "wow, cái này đỉnh thật", khả năng 3D quá ấn tượng. Rồi anh tự nhủ: mình muốn tận dụng khả năng 3D đó của Opus 5.5.

Một trong những explainer video Claude làm cho anh mà anh rất thích là từ khoảng hai tuần trước đó. Ray đi một quán cafe board game với một người bạn, và họ chơi một trò tên Tokyo Highway. Anh nghĩ: nếu mình đưa luật chơi này cho Claude, liệu nó có làm được một video giải thích toàn bộ trò chơi không?

Và Claude làm rất tốt: một video 3D với chuyển động camera đẹp, giải thích nước đi nào trong game được phép và nước nào không. Ray thấy thật khó tin: theo số đo của Ray (video đăng ngày 20/10/2026), sau khoảng bảy phút xem video có animation phong phú đó, anh hiểu trò chơi gần như hoàn hảo. Prompt của anh, đúng nguyên văn, là làm một video giải thích cách chơi bằng ElevenLabs CLI, animation 3D, thật nhiều diagram, không có chữ. Trên bài đăng của anh, prompt ghi:

Make a video explaining how to play the game with ElevenLabs CLI, 3D animations, lots of diagrams, no text.

16. Rebalancer của Meta và một giờ video giải thích mỗi ngày

Ray không làm kiểu explainer video 3D như vậy mỗi ngày. Một trong những use case hằng ngày của anh là để hiểu bất kỳ công nghệ mới nào. Ví dụ, theo video đăng ngày 20/10/2026, Meta vừa open source một thứ tên Rebalancer (bài trên engineering blog của Meta ghi ngày đăng 21/09/2026). Ray đang đọc bài blog đó và muốn có một cái nhìn tổng quan nhanh về cách nó hoạt động trước khi tự mình đào sâu vào bài.

Thế là trong Slack, anh đưa bài đăng đó cho agent của mình, và nó làm cho anh một video đẹp, khoảng bốn phút, giải thích Rebalancer hoạt động thế nào ở phía sau với cả loạt diagram và ví dụ. Trên màn hình (video đăng ngày 20/10/2026), tin nhắn của agent ghi video chạy 4 phút ở tốc độ 1.5x (6 phút ở tốc độ thường), và nó đọc thẳng bài trên blog của Meta cùng hai hình trong đó.

Nhờ video đó, anh có sẵn bức tranh lớn trong đầu, nên khi đi vào chi tiết, anh thấy được mọi thứ khớp với nhau ra sao. Kế hoạch của Ray là đưa cách này vào software factory theo một cách nào đó: có thể mỗi sáng sẽ có một video anh xem về tất cả những thay đổi đã diễn ra trong cả team và trong các project. Nhưng tới lúc quay anh vẫn đang tìm cách.

Điều Ray thích nhất ở chuyện này: theo Ray (video đăng ngày 20/10/2026), mỗi ngày anh xem khoảng một tiếng toàn explainer video do AI làm, về đủ thứ anh quan tâm. Anh khá chắc Karpathy cũng đang làm điều tương tự ở hậu trường, vì ông nói explainer video là thứ ông bullish nhất. Với explainer video, Ray vẫn đang thử nghiệm, và anh sẽ chia sẻ những gì học được.