Viết lại TypeScript bằng Rust với 420.000 đô token

1. TSC-RS: toàn bộ TypeScript viết lại bằng Rust

Theo mở đầu bằng một lời công bố: TSC-RS, còn gọi là TypeScript Rust (ts-rust), là bản viết lại hoàn toàn của TypeScript compiler, type checker và LSP, tất cả bằng Rust. Đây là project anh đã để agent làm suốt năm tháng (tính đến video đăng ngày 10/10/2026). Theo lời anh trong video đăng ngày 10/10/2026, anh đã đốt 400.000 đô token Codex mà chẳng đi tới đâu, rồi đốt 20.000 đô Opus 5.5 và về đích trong hai tuần. Và một lưu ý quan trọng: anh chưa đọc một dòng code nào trong đó.

Ai theo dõi kênh một thời gian chắc đã biết anh dùng bản viết lại TypeScript sang Rust này làm "sân chơi nhỏ yêu thích" để thử các model mới và xem năng lực của model đang đi tới đâu. Anh làm vậy vì đang đi tìm những việc có vẻ bất khả thi với model. Lý do đầu tiên khiến anh khởi động project: anh có một lượng inference khổng lồ trong đợt thử nghiệm early access của GPT-5.6 Sol, và theo lời anh (video đăng ngày 10/10/2026), model đó "nghiền nát" mọi thứ anh ném vào. Vì vậy anh muốn với tới một thứ táo bạo hơn. Không phải táo bạo hơn một chút, mà là bất khả thi luôn. Viết lại toàn bộ TypeScript bằng Rust nghe không hề khả thi, nghe như một meme. Và đúng là meme thật: xa nhất anh đi được với các model của OpenAI là khoảng 84% compatibility (theo Theo, video đăng ngày 10/10/2026).

Đi được tới mức đó đã là ấn tượng, nhưng có vẻ không đi xa hơn được bao nhiêu, vì tới lúc ấy thì 16% cuối khó hơn rất nhiều. Càng tới gần đích, những phần rìa (edge) còn lại càng tệ. Đó là lý do Theo thấy càng điên rồ khi TS Rust giờ không chỉ đã ra mắt cho mọi người dùng, với một package thật trên npm (tính đến video đăng ngày 10/10/2026), mà quan trọng hơn là nhanh hơn rất nhiều. Theo số đo của Theo (video đăng ngày 10/10/2026), so với TypeScript v6, bản cuối cùng còn viết bằng chính TypeScript và JavaScript, nó nhanh hơn 12,5 lần. So với TS Go, tức TypeScript v7, bản do đội chính thức ở Microsoft làm, nó nhanh hơn khoảng hai lần.

Họ không phải những người duy nhất làm việc này. Theo kể (video đăng ngày 10/10/2026) Bun cũng vừa tung ra Bun Check, một bản viết lại TypeScript checker bằng Rust cũng nhanh hơn nhiều, và anh nói thật là nó còn nhanh hơn cả thứ anh build với TS Rust. Nhưng chuyện nào cũng có "điều kiện kèm theo".

Trong video đăng ngày 10/10/2026, anh hứa sẽ đi qua tất cả: từ cách anh build, cách anh kiểm chứng, tới những lý do bí mật khiến anh thật sự muốn thứ này tồn tại. Tin hay không thì tuỳ, những lý do đó không chỉ là lượng RAM dùng và thời gian chạy. Anh có một lý do bí mật rất thú vị, và giờ đã có demo chạy được cho nó. Theo nói màn vibe coding demo nhỏ đó thú vị hơn nhiều so với vẻ ngoài ban đầu. Anh muốn nói về tất cả: tốn bao nhiêu tiền, nó chạy thế nào, vì sao anh quan tâm tới project này đến vậy, và quan trọng nhất, điều này có ý nghĩa gì với nghề engineering từ đây về sau.

Phần Install của README trên màn hình (video đăng ngày 10/10/2026) mở đầu bằng câu "Be warned, I have no idea if this will actually work", rồi tới hai lệnh cài và chạy. README trên GitHub vẫn ghi đúng hai lệnh này (đọc ngày 25/10/2026):

npm install -D tsc-rs
npx tsc-rs -p tsconfig.json

2. TypeScript và TSC: biến .ts thành .js là chuyện dễ

Theo nói anh sẽ làm mọi cách để video không kéo dài hai tới bốn tiếng, điều khá khó vì anh có quá nhiều thứ muốn nói. Nhưng trước hết cần một bài học lịch sử ngắn để giải thích thứ này là gì và vì sao nó tồn tại.

TypeScript là một ngôn ngữ, "kiểu kiểu vậy", theo cách Theo nói trong video đăng ngày 10/10/2026. Mục đích của TypeScript là dựng một hệ thống bên trên JavaScript để ta tự tin hơn về hành vi của các app JavaScript. Thứ chính được bàn hôm nay là TSC, TypeScript Compiler. Việc của TypeScript Compiler, tất nhiên, là biến TypeScript trong editor của bạn thành JavaScript mà trình duyệt chạy được, vì trình duyệt không biết xử lý TypeScript.

Anh viết một ví dụ lên bảng vẽ: một function nhận user, khai báo name là string, rồi console.log(user.name). "Wow, mình đang viết code đấy. Đỉnh cao chưa. Lâu lắm rồi nhỉ mọi người?", anh nói, rồi phát hiện bảng vẽ còn có cả một nút chèn code. Function này cũng cần có tên, nên anh đặt là logUser:

function logUser(user: { name: string }) {
    console.log(user.name)
}

Theo Theo (video đăng ngày 10/10/2026), nếu lấy function này đem chạy trong Chrome, Node hay bất kỳ JavaScript runtime nào, nó sẽ báo lỗi ngay. Lý do là cú pháp định nghĩa type ở đây, chỗ mô tả user là một tham số kiểu object có key name là string, không phải cú pháp JavaScript hợp lệ. Bạn không thể viết vậy trong JavaScript.

Biến đoạn này thành JavaScript hợp lệ thật ra khá dễ: đi qua code và cắt bỏ hết những "chất TypeScript" (TypeScript-isms). Làm xong là chạy được. Vì vậy, theo Theo (video đăng ngày 10/10/2026), điều quan trọng đầu tiên cần hiểu: biến file TS thành file JS là dễ, gần như tầm thường. Đã có rất nhiều công cụ hay làm việc này từ lâu, và đặc biệt có một công cụ bùng nổ vài năm trước, phần nào thay đổi cách mọi người nghĩ về web dev.

3. esbuild, và phần khó thật sự: kiểm tra type

Công cụ đó là esbuild. Trong video đăng ngày 10/10/2026, Theo kể esbuild do Evan Wallace làm, người từng là CTO của Figma, vì anh ấy muốn khi sửa file trong editor thì cập nhật hiện lên UI nhanh hơn. Đưa toàn bộ code qua JavaScript chỉ để gỡ vài thứ ra cho trình duyệt chạy được là không hiệu quả. Nên esbuild được làm ra để đảm nhận nhiều bước như thế: không chỉ biến TypeScript thành JavaScript, mà cả các bước khác như gom CSS vào, tạo các asset cần thiết, rồi gộp tất cả thành một file mà trình duyệt thật sự nhận được, thay vì cả đống file nằm rải rác trong codebase.

Theo Theo (video đăng ngày 10/10/2026), tất cả những việc cần để bundle app cho trình duyệt được viết bằng Go, để hiệu quả hết mức hợp lý mà không phải "phát minh lại vũ trụ" và tự quản lý toàn bộ bộ nhớ. esbuild tuyệt vời, nhưng còn thiếu một thứ. Từ nãy ta chỉ nói chuyện biến TypeScript thành JavaScript, và đó là phần dễ.

Theo Theo (video đăng ngày 10/10/2026), phần khó thật sự là kiểm tra TypeScript: đảm bảo các type hợp lệ, được dùng và được tôn trọng đúng trong toàn bộ ứng dụng. Theo nói thẳng: việc transpile, biến TS thành JS, dễ tới mức làm ngay bằng JS cũng chẳng phải chuyện lớn. Còn kiểm tra TypeScript cho đúng thì khó hơn nhiều và cũng chậm hơn nhiều. Đó là chỗ ngốn phần lớn thời gian. Hệ quả là maintainer của nhiều codebase lớn tách riêng hai đường: đường transpile và đường type check.

Trong video đăng ngày 10/10/2026, anh nhớ lại hot reload ban đầu ở Twitch tệ thế nào. Chạy lệnh dev mất hai phút mới khởi động. Sửa một file, lưu lại, phải 30 giây tới một phút mới thấy trên trình duyệt. Anh từng rất phấn khích khi team đưa con số đó xuống dưới năm giây, bằng cách tách đường đưa code lên trình duyệt ra khỏi đường type check để xem code có đúng với định nghĩa type không. Một công cụ như esbuild giúp đi xa hơn nữa ở khoảng hot reload, từ lúc lưu tới lúc thấy trên trình duyệt, nhưng nó không cho bạn đủ thông tin để biết những thứ như type có check đúng không.

Và như ai đã xem các video cũ của anh đều biết (theo Theo, video đăng ngày 10/10/2026), type system của TypeScript phức tạp và linh hoạt đến khó tin.

4. Type system Turing-complete, và vì sao Microsoft chọn Go

Đó là một hệ thống Turing-complete (theo Theo, video đăng ngày 10/10/2026). Anh nhắc lại một chuyện cũ vui: một người bạn của anh đã port cả trò Doom vào type của TypeScript. Không phải TypeScript ngôn ngữ, mà là TypeScript type system. Một project điên rồ, và anh rất khuyên xem video đó nếu chưa xem.

Ý anh muốn nói (video đăng ngày 10/10/2026): type system của TypeScript phức tạp vì nó phải biểu diễn được mọi thứ bạn làm trong JS. Do đó viết lại checker bằng một ngôn ngữ không phải JavaScript vốn dĩ sẽ rất khổ. Tất cả những điều kỳ quặc JavaScript làm, như việc bạn có thể đổi type của biến trong lúc code chạy, cách object kế thừa đặc điểm, cách toàn bộ hệ prototype vận hành, cùng mọi sự kỳ quặc khác của JavaScript mà TypeScript mã hoá trung thành, sẽ dễ mã hoá hơn nhiều khi ngôn ngữ dùng để mã hoá cũng chính là ngôn ngữ đang được mã hoá.

Một cách nói vui hơn: giải thích tiếng Anh vận hành ra sao bằng tiếng Anh thì dễ hơn nhiều so với giải thích bằng tiếng Tây Ban Nha. Rồi hãy tưởng tượng độ phức tạp đó nhân lên cỡ 100 lần. Đó là điều khiến việc này khó: mọi sự kỳ quặc của JS phải được mã hoá trung thành trong bất kỳ thứ gì bạn chọn thay thế.

Nhưng chừng đó không đủ để cản Microsoft. Theo Theo (video đăng ngày 10/10/2026), đó là lý do Microsoft quyết định viết lại TSC. Họ muốn nó native và cực nhanh để thời gian compile và type check tốt hơn hẳn, và họ chọn Go. Theo đoán người xem có thể thấy khó hiểu, nên anh chuyển sang khung chat hỏi mọi người nghĩ lẽ ra nên chọn ngôn ngữ nào. Chat gợi ý Jai, C++, C#. C# là một gợi ý buồn cười, vì người tạo ra TypeScript cũng là người tạo ra C#.

Theo có một "hot take": Go là ngôn ngữ đúng cho việc này. Anh biết ai cũng có ý kiến riêng, nhưng để anh giải thích. Gần đây (tính tới video đăng ngày 10/10/2026) anh bị "dunk" vì mấy tweet cũ, và anh thấy chúng liên quan hơn bao giờ hết. Tháng 2 năm 2024 anh đăng: "Go is probably the right language for most Javascript build and dev tooling" (Go có lẽ là ngôn ngữ đúng cho phần lớn tooling build và dev của JavaScript). Rồi anh viết tiếp, đại ý: tweet điều này bây giờ để ba năm nữa làm bằng, khi chúng ta nhận ra mình đã sai lầm khi dồn hết vào Rust.

Anh thừa nhận nhận định này "lão hoá" không tốt, nhưng không phải vì những lý do đúng. Anh cần giải thích chuyện Go trước, vì nó gần như mâu thuẫn trực tiếp với những nhận định khác của anh về Go. Ví dụ có lần anh trêu một người khác, viết rằng: tự nhiên tôi hiểu vì sao anh nghĩ Go là một ngôn ngữ tốt.

5. Go: concurrency, cú pháp giống JS và cái giá của garbage collection

Trong video đăng ngày 10/10/2026, Theo nói mình nổi tiếng là người ghét Go. Anh chưa bao giờ thích ngôn ngữ này lắm. Anh hiểu lợi thế của nó, chỉ là nói thật thì nó khiến anh thấy mình giống một con khỉ hơn là một kỹ sư. Vậy tại sao Go lại hợp lý ở đây?

Theo Theo (video đăng ngày 10/10/2026), điểm mạnh lớn nhất của Go so với một ngôn ngữ như Rust là sự linh hoạt, vì nó không cố gắng tới mức đó để siêu an toàn về type và bộ nhớ (type system của Go, theo lời anh, là "một cái meme"). Phần concurrency có sẵn của Go rất tuyệt. Mô hình concurrency của Go có vấn đề của nó, chẳng hạn anh cho rằng channel thật ngớ ngẩn, nhưng phần lõi là goroutine có những thứ rất hay. Và concurrency là một trong những điều lớn mà team muốn có khi viết lại TypeScript, để tận dụng được nhiều core hơn trên máy bạn. Cú pháp Go cũng giống JS một cách bất ngờ, nên dễ đặt hai function, một bên mỗi ngôn ngữ, cạnh nhau và hiểu chúng đang làm gì.

Nhưng anh cho rằng (video đăng ngày 10/10/2026) mảnh lớn nhất là garbage collection. Garbage collection là một trong những điểm yếu của Go, vì nó có nghĩa là bộ nhớ không do bạn quản lý. Tới một lúc nào đó bộ nhớ phải được dọn, nghĩa là đặc tính hiệu năng của app không ổn định. Thường thì app trả lời một request khá nhanh. Nhưng nếu request đó tới đúng lúc bạn hết bộ nhớ và cần garbage collect, bạn sẽ gặp những cú tăng latency ngẫu nhiên rất khó chịu. Lợi ích là bạn có concurrency cực mạnh, đổi lại garbage collection thỉnh thoảng làm latency vọt lên.

Vì vậy, theo Theo (video đăng ngày 10/10/2026), nếu bạn có một hệ thống rất quan trọng, muốn mọi request được xử lý dưới 25 mili giây, Go có thể không phải ngôn ngữ đúng, vì thỉnh thoảng nó phải garbage collect và sẽ tạm dừng chạy code cho tới khi lượt dọn đó xong. Nói cho rõ, JavaScript và TypeScript cũng có garbage collection. Go là một ngôn ngữ thú vị vì nó vừa low-level vừa có garbage collection.

Vậy tại sao lại dùng nó cho một compiler? Như thế chẳng phải sẽ rất chậm sao? Theo trả lời (video đăng ngày 10/10/2026): không. Giả sử bạn có 100.000 request đều trả về trong 25 mili giây, rồi phải GC, và một request lại mất 300 mili giây. Nghe thì khủng khiếp, vì request đó chậm hơn mười lần so với mọi request khác. Nhưng nếu cứ một nghìn request mới có một cái chậm mười lần, thì tổng thời gian chỉ chậm hơn chưa tới 1%. Chẳng là gì cả.

Theo Theo (video đăng ngày 10/10/2026), tác động của garbage collection lên một tiến trình dài với rất nhiều việc bên trong nhỏ hơn nhiều so với khi bạn đo thời gian từng request riêng lẻ. Nên nếu bạn làm việc cần xong trong vài mili giây, một ngôn ngữ có garbage collection sẽ có những điểm yếu cần né. Còn nếu request trung bình mất hơn 100 mili giây, chẳng hạn vài giây vì bạn đang compile một app khổng lồ, thì anh chẳng quan tâm nó garbage collect một, hai, ba, mười hay một trăm lần trong request đó, vì garbage collection chiếm một phần rất nhỏ trong tổng thời gian chạy. Nó gần như không đáng kể, bị pha loãng hết.

Vậy nếu build một web service cần trả lời nhanh nhất có thể, Go không phải ngôn ngữ đúng. Nhưng nếu muốn lấy một thứ viết bằng JavaScript đang rất chậm, chạy mất cả phút, rồi cắt thời gian xuống và có thêm concurrency, thì theo Theo, Go là một trong những ngôn ngữ tốt nhất để làm việc đó (nhận định trong video đăng ngày 10/10/2026).

6. Opus port từng dòng từ bản Go sang Rust

Rồi Theo tự đặt câu hỏi thay người xem: "Nhưng làm bản Rust chắc cũng không khó lắm đâu nhỉ? Vì anh để một agent làm xong trong hai tuần mà." Và anh giới thiệu TS Rust. Viết lại toàn bộ TypeScript từ JS sang Rust sẽ không khả thi. Anh biết chắc vậy vì đã thấy các model khác anh thử, như GPT-5.6 Sol và Astra, chật vật thế nào với lần port này (theo Theo, video đăng ngày 10/10/2026). Anh nghĩ phần lớn là vì đi từ JavaScript sang Rust không hề đơn giản với một thứ phức tạp như chính TypeScript.

Đây là chỗ mọi chuyện với bản port TS Rust bắt đầu thú vị. Mở các crate ra (repo trong video đăng ngày 10/10/2026), có rất nhiều thứ đã được làm, và theo anh "đáng ngờ" là một từ công bằng cho nhiều trong số đó. Một trong số đó là gostd: thư viện chuẩn của Go được port sang Rust. Lý do là cách Opus chọn làm không phải viết lại mọi thứ từ Go sang Rust theo kiểu tự nghĩ lại, mà là đi qua bản port Go "từng dòng một" và port trung thành sang ngôn ngữ Rust.

Theo Theo (video đăng ngày 10/10/2026), kết quả là bản đó thật ra chậm hơn bản Go khá nhiều, vì phải cài lại những thứ như goroutine. Theo lục tìm xem goroutine nằm ở đâu, rồi thấy nó trong runtime.rs: goroutine được port sang Rust. Chuyện này xảy ra vì Go là điểm xuất phát tốt hơn nhiều cho một bản port sang Rust so với JavaScript. Team Microsoft đã tự tay, trung thành, đi qua từng dòng code của TypeScript, port sang Go, rồi bắt đầu tinh chỉnh để nó tốt hơn và nhanh hơn trong Go. Agent của Theo làm đúng điều đó, từ bản Go sang Rust, và chúng đã thành công.

Anh thậm chí không biết agent của mình làm vậy cho tới khi có người khác chỉ ra trên Twitter. Vừa thấy là anh bật cười: "Ồ, buồn cười thật. Thế thì giải thích được nhiều thứ." Bởi vì khi bản TS Go viết lại bằng Rust sẵn sàng cho lần chạy đầu, lúc Opus làm xong, nó chậm hơn bản Go hai tới ba lần (theo số đo của Theo, video đăng ngày 10/10/2026). Nên anh giao cho nó một lệnh /goal: mục tiêu của bạn là làm nó nhanh hơn ít nhất hai lần ở mọi mặt. Rồi anh để nó chạy hai tuần. Quan trọng hơn, anh để nó chạy trên sáu tài khoản Claude của mình.

7. Hoá đơn thật: giá API và giá subscription

Theo Theo (video đăng ngày 10/10/2026), toàn bộ phần việc TS Rust với Opus 5.5, model về cơ bản đã bỏ bản cũ và làm lại từ đầu, tương đương khoảng 24.000 đô inference nếu trả đủ giá API. Nhưng như mọi người biết, anh không trả vậy vì anh dùng subscription. Nên anh thử tính lại bằng toàn bộ log để xem bao nhiêu phần trăm mức sử dụng đã dồn cho việc này. Quy ra mức dùng subscription, tất cả công việc ở đây bằng từ 925% tới 983% weekly limit của một tài khoản, tức khoảng hai tháng rưỡi sử dụng một gói Claude Code. Tính cả việc được một lần reset miễn phí, con số này rơi vào khoảng 500 đô, hơn kém chút ít, tiền subscription (số liệu tính đến video đăng ngày 10/10/2026).

Với mức giá đó, Theo cho rằng đây là một món rất đáng tiền (nhận định trong video đăng ngày 10/10/2026). Anh biết nghe thì điên, nhưng 500 đô để có TypeScript bằng Rust, tiết kiệm bộ nhớ hơn và nhanh hơn, nhanh gấp đôi bản Go, là thứ thật sự rất hữu ích, và với anh đó là tiền tiêu đúng chỗ. Anh biết con số tiêu đề 20.000 đô hay 420.000 đô nghe như điên. Nhưng với phần trợ giá từ subscription, và việc chỉ 20.000 đô Claude là phần thật sự có tác dụng, thì mười tuần weekly limit cho kết quả này là một món hời buồn cười, theo ý anh.

Vậy nếu ai đó đang nghĩ: "Trời, team TypeScript ở Microsoft phí bao nhiêu tiền và thời gian port sang Go, lẽ ra họ cứ chờ rồi để AI làm bằng Rust"...

8. Drop-in replacement, đến cả bug cũng được port theo

...thì Theo nói: không. Anh không nghĩ AI có thể làm việc này một cách khả thi từ JavaScript và TypeScript sang thẳng Rust, nhưng nó làm được từ Go một cách tương đối dễ dàng (theo Theo, video đăng ngày 10/10/2026). Và kết quả, theo anh, gần như là một drop-in replacement 100% cho TS Go và TSC 7.

Anh biết điều đó vì một lý do khá ngớ ngẩn: các issue. Trước có năm, giờ còn bốn (tính đến video đăng ngày 10/10/2026). Anh đã rà soát các issue này, hay đúng hơn là anh và agent của anh cùng rà soát. Trong sáu issue được mở tổng cộng tới lúc đó, chỉ một issue là riêng của TS Rust. Năm issue còn lại là vấn đề có sẵn trong TSC 7, đúng phiên bản mà họ nhắm tới. Nghĩa là đó không phải lỗi của bản viết lại, mà là bug trong chính TypeScript lúc đó, được port trung thành sang bản Rust. Anh thấy rất buồn cười: không chỉ port những thứ có chủ đích, anh port luôn cả bug, vì đây thật sự là một bản thay thế tương thích hoàn toàn. Trên màn hình, tab Issues của repo hiện 4 issue đang mở và 2 đã đóng, vài issue được gắn nhãn "upstream issue".

Rồi tới hiệu năng. Vì anh bắt đầu project trước cả khi Bun Check xuất hiện, ban đầu anh đo mọi con số so với TypeScript 7. Theo số đo của Theo (video đăng ngày 10/10/2026), với các project thực tế như T3 Code, TS Rust cải thiện khoảng hai lần so với TS7 (tức TS Go), và anh nói có chỗ tới 20 lần so với TSC 6, bản TSC cuối cùng còn dựa trên JavaScript. Bảng T3 Code trong README trên màn hình ghi tsc-rs nhanh hơn tsc 6 là 8,6 lần khi không có Effect và 12,5 lần khi có Effect, và nhanh hơn tsc 7 là 2,22 lần (không Effect) và 1,89 lần (so với tsc 7 kèm @effect/tsgo).

Anh bắt đầu với các lần check T3 Code vì có làm một thứ hay ở đây. Effect TS, nếu bạn chưa biết, là một thư viện phổ biến trong TypeScript giúp xây các hệ thống concurrent đáng tin cậy dễ hơn và dễ ghép nối hơn (mô tả của Theo, video đăng ngày 10/10/2026). Effect dùng và "lạm dụng" TypeScript nặng tới mức họ gần như tự build một bản fork TypeScript riêng: một patch bạn áp vào TypeScript config và package TypeScript trong repo để đưa thêm diagnostics và tính năng của Effect vào bước type check. Theo build thẳng phần đó vào TS Rust vì team anh dựa vào nó rất nhiều cho những thứ như T3 Code.

Nên với trường hợp T3 Code của họ, theo Theo (video đăng ngày 10/10/2026), TS Rust không chỉ nhanh hơn nhiều so với TS7 kèm plugin TS Go của Effect, mà còn nhanh hơn cả Bun, anh nói "khoảng bốn lần". Bảng trên màn hình ghi 11,13 giây cho tsc-rs so với 37,60 giây cho bun check cộng lượt Effect, tức khoảng 3,4 lần. Không phải vì Bun Check chậm. Bun Check siêu nhanh, nhưng vì phải chạy thêm lượt check Effect sau nó, và khi làm cả hai thì tổng thời gian từ đầu tới cuối chậm hơn hẳn.

9. Các project khác, và lời khuyên chọn Bun Check

Nhưng đó mới chỉ là check trong T3 Code. Theo chuyển sang các project khác, "vài thứ đơn giản" như toàn bộ tRPC server, codebase của Sentry hay Excalidraw. Anh cũng check cả Effect. Theo trí nhớ của anh (video đăng ngày 10/10/2026), Bun không chạy qua được codebase của Effect, và Bun còn báo những lỗi sai trên Sentry và tRPC. Vì vậy Bun Checker, dù cực kỳ ấn tượng và nhanh hơn trong nhiều trường hợp, chưa check đủ trung thành để anh tin dùng cho những project lớn kiểu này.

Theo nghĩ Bun Check hợp với các công cụ khác của Bun: nếu bạn bắt đầu một project mới với Bun và dùng nó cho mọi thứ, Bun Check là một giải pháp tuyệt vời. Anh nói thật là anh sẽ khuyên dùng Bun Check thay vì TS Rust cho gần như mọi trường hợp, đơn giản vì anh tin nó sẽ được bảo trì lâu dài hơn (lời khuyên trong video đăng ngày 10/10/2026).

Nhưng TSC-RS, project TS Rust của anh, là một bản tái tạo trung thành hơn nhiều, và nhờ vậy nó không gặp những lỗi kỳ lạ trong các project này. Theo Theo (video đăng ngày 10/10/2026), nó chạy trung thành trong các project như tRPC, T3 Code và cả repo Effect. Anh nói mức cải thiện với phần lớn các project ở đây là "13 lần trở lên" khi đi từ TSC 6 sang TSC-RS, và thường gấp đôi so với bản Go. Biểu đồ trên màn hình ghi tsc-rs nhanh hơn tsc 6 từ 7,6 lần (Excalidraw) tới 13,2 lần (Sentry, Playwright), trung bình hình học 11,4 lần.

10. Không phải vì hiệu năng: lý do ngớ ngẩn và lý do thật (Wasm)

Rồi Theo tung ra (video đăng ngày 10/10/2026) một "spicy take" khiến mọi thứ rối hơn: anh không làm chuyện này vì hiệu năng. Anh không làm TypeScript Rust vì muốn có thứ nhanh hơn TypeScript Go. Vậy tại sao? Có một lý do ngớ ngẩn, và một lý do có thể mang tính đột phá. Anh bắt đầu với lý do ngớ ngẩn.

Lý do ngớ ngẩn, theo Theo (video đăng ngày 10/10/2026), là vì LLM không làm được. Các model từng không thể làm những bản port kiểu này, và nó đã thành một meme. Anh từng lao vào "flame war" với những người khẳng định họ có thể port TypeScript sang C++ hay ngôn ngữ khác trong một tháng, điều rõ ràng là không làm được. Có lần anh cãi nhau với một người tới mức bị người đó block. Đó là thời "những năm 2020 xa xưa", những ngày đầu của TypeScript, khi người ta còn shitpost trên Twitter trước khi AI chiếm hết mọi thứ. Anh từng cãi nhau nảy lửa về chuyện này, vì rõ ràng là bạn không thể cứ thế viết lại TypeScript bằng ngôn ngữ khác. Đó là lý do nó luôn là mục tiêu xa của anh, điều bất khả thi mà bạn không bao giờ thật sự có được, kiểu như "unobtainium" của giới web dev.

Vì thế nó là một thứ vui để ném gần như không giới hạn token vào. Anh chưa từng thử một model của Anthropic cho việc này vì chúng đốt hết hạn mức sử dụng quá nhanh. Nhưng với Opus 5.5, theo Theo (video đăng ngày 10/10/2026), hạn mức cháy rất chậm, và anh còn dư rất nhiều. Anh tự nhủ "kệ, xem chuyện gì xảy ra", và nó làm được hiệu quả hơn nhiều so với những gì anh từng đoán. Anh làm vì không nghĩ model làm được. Giờ chúng làm được rồi, anh đang cạn dần thứ để ném vào LLM. Anh không biết còn việc gì mà LLM bây giờ không làm được nhưng tương lai có thể làm được; anh thấy khó mà hình dung nổi. Anh nói mình đã hết ý tưởng engineering nào "quá sức" với model. Đây là cái "quá sức" của anh, và giờ nó đã làm xong.

Vậy lý do thật là gì (video đăng ngày 10/10/2026)? Vì sao anh muốn một phiên bản TypeScript dựa trên Rust khi đã có một bản Go siêu nhanh? Anh đã có gần như mọi thứ mình muốn từ TS Go. Có vài lý do nhỏ: anh muốn có sẵn phần Effect, và muốn nó dễ mở rộng, dễ nghịch hơn một chút. Nhưng lý do chính là một thứ nhỏ tên Wasm.

Điều này quay lại chuyện garbage collection lúc nãy (theo Theo, video đăng ngày 10/10/2026). Garbage collection là một cách tuyệt vời để gỡ gánh nặng khỏi kỹ sư, giúp họ ship phần mềm nhanh hơn mà phần mềm vẫn rất nhanh. Nhưng vì garbage collection là một quá trình phức tạp, cần phân tích bộ nhớ và làm nhiều việc quản lý bộ nhớ, nên đóng gói một app Go thành WebAssembly không hề đơn giản: bạn không thể chỉ bundle code mà lập trình viên viết, mà còn phải bundle cả bộ garbage collection.

Kết quả là, theo Theo (video đăng ngày 10/10/2026), khá khó để viết một app Go rồi bundle thành Wasm dưới 10 MB, và nó vẫn sẽ có nhiều vấn đề hiệu năng kỳ lạ vì khía cạnh garbage collection. Đó là lý do những công cụ như esbuild phải vật lộn rất lâu để Wasm chạy được. Đây cũng là một trong những thứ bị mất khi chuyển sang TypeScript Go. Trước đây, vì TypeScript rốt cuộc chỉ là JS, bạn có thể ném nó vào trình duyệt, ném vào một V8 isolate, chạy trong Node, và nó cứ thế chạy.

Với TS Go, phần nào chúng ta đã mất điều đó. Thật ra là mất khá nhiều, kể cả nhiều JavaScript API từng dùng để giao tiếp với TypeScript compiler (theo Theo, video đăng ngày 10/10/2026).

11. Trí tuệ đang rẻ đi rất nhanh

Nhưng tại sao anh lại quan tâm tới thế? Tất cả chúng ta đều đang chạy agent trên máy của mình hoặc máy của người khác, đúng không? Nếu tương lai không còn như vậy thì sao? (câu hỏi Theo đặt ra trong video đăng ngày 10/10/2026)

Trí tuệ (intelligence) thì đắt. Theo kể có những người, như một người ở Cursor và SpaceX, được cho là tiêu tới 132 triệu đô mỗi năm (con số anh nhắc trong video đăng ngày 10/10/2026). Anh nói thẳng con số này là bịa, và hứa sẽ giải thích vì sao trong một video khác. Bỏ qua chuyện những con số đó không có thật, thì tốc độ giá đi xuống là có thật.

Trước khi mở trang Artificial Analysis, một trang nền trắng, anh cảnh báo "flashbang", rồi nói mình cần port benchmark này về nhưng chưa làm (tính đến video đăng ngày 10/10/2026). Đây là biểu đồ hiệu quả chi phí theo thời gian. Nó lấy một mức điểm mà model có thể đạt, chẳng hạn DeepSeek R1 đạt trên 10 điểm trên chỉ số của họ vào tháng 1 năm 2025, rồi theo dõi giá của các model ở mức trí tuệ đó tăng hay giảm theo thời gian.

Phần điên rồ nhất nằm tít bên phải biểu đồ. Theo số liệu Theo đọc trên trang này (video đăng ngày 10/10/2026), những model rất thông minh như Opus 5, model đầu tiên lọt vào vùng 50 điểm, tốn 5,86 đô mỗi task khi họ chạy đo. Và giờ đã có những model như GPT-6.1 Sol đạt cùng mức điểm với giá 32 xu. Nghĩa là chi phí cho mức trí tuệ đó đã giảm mười lần chỉ trong khoảng bốn tháng.

Ở một mức trí tuệ cho trước, chi phí giảm nhanh tới phi lý. Theo Theo (video đăng ngày 10/10/2026), "mười lần mỗi năm" là một ước tính thận trọng. Anh lấy vùng 30 điểm: tốn 2,50 đô vào tháng 2 năm nay và xuống còn 3 xu vào tháng 12 năm nay, theo cách anh đọc biểu đồ, và anh quy ra là giảm 8 lần mỗi tháng, tính trung bình thành 1.000 lần mỗi năm. Tốc độ giá trí tuệ đi xuống thật điên rồ.

12. Cái giá bị quên: compute mà agent chạy trên đó

Nhưng theo Theo (video đăng ngày 10/10/2026), trí tuệ không phải thứ duy nhất phải trả tiền. Khi build app với AI, bạn còn phải trả tiền host, trả tiền lưu dữ liệu trong database, trả cho các hệ thống auth và nhà cung cấp bạn dùng, trả Apple để phân phối app, và đủ thứ khác. Nhưng còn một thứ nữa phải trả mà ít người nghĩ tới: compute mà agent của bạn chạy trên đó. Anh nói với "hội VPS 5 đô": giờ là lúc các bạn toả sáng, vì chúng ta thật sự cần nói chuyện.

Một điều hay mà Cursor đang làm (tính đến video đăng ngày 10/10/2026) là Cursor cloud. Theo mô tả của Theo, khi bạn mở một cloud thread trong Cursor, nó chạy trên một VM đầy đủ với 32 GB RAM (anh nói có thể là 16, nhưng khá chắc là 32), có GUI thật, processor thật, mọi thứ thật mà nó cần trên Linux, để có thể dựng app của bạn lên và test bằng một máy tính thật. Mỗi thread có máy riêng. Mở bốn thread là 128 GB RAM được giữ riêng cho bạn trong lúc đó. Và theo Theo, lúc quay video Cursor không tính tiền phần này.

Lý do: inference hiện đắt hơn VM nhiều tới mức VM gần như chỉ là số lẻ làm tròn, nên cho bạn VM miễn phí không phải chi phí lớn (nhận định của Theo, video đăng ngày 10/10/2026). Nhưng nhớ điều anh vừa nói chứ? Giá inference đang giảm, và giảm rất nhanh. Còn giá compute thì sao? Giá VM thì sao? Theo Theo, giá thuê một máy 16 hay 32 GB đang tăng đều vì AI hút hết nhu cầu RAM. Kết quả là compute để chạy agent, không phải compute chạy model mà là compute chạy code mà model đang sửa, đã chậm rãi tăng giá theo thời gian, trong khi compute cho inference lại đang rơi tự do.

Theo ước tính của Theo (video đăng ngày 10/10/2026), một bên tăng 25 tới 30% mỗi năm, bên kia giảm 10 tới 100 lần mỗi năm. Sẽ rất nhanh tới lúc inference rẻ hơn VM. Với một model rẻ như bản Flash của dòng GLM mà anh nêu tên, chạy liên tục một tiếng sẽ tốn bạn vài đô. Cái VM nó chạy trên đó có khi còn đắt hơn model và lượng inference bạn dùng trong khoảng thời gian ấy.

Và khi các model ở mức giá đó thông minh hơn, khi các model ở tầng đó rẻ hơn, điểm này sẽ tới rất nhanh. Lúc đó, compute sẽ thành ràng buộc khi build với agent. Theo Theo (video đăng ngày 10/10/2026), hiện ta đang được cho VM miễn phí, nhưng điều đó sẽ không kéo dài. Ngay cả Claude Code cũng không làm vậy nữa: Claude Code giờ cho mỗi subscriber một khoản credit để dùng cho cloud compute nếu họ dùng sản phẩm cloud của Claude.

Theo Theo (video đăng ngày 10/10/2026), có nhiều tầng lý do cho cách làm này. Compute và bộ nhớ đắt, nên họ phải lo chuyện đó. Lý do nó phải được giữ riêng (reserved) như vậy là vì cách agent của chúng ta hoạt động. Agent kỳ vọng chạy trên một máy tính thật, với terminal thật, bash thật, để chạy lệnh, chạy ripgrep, tìm trong codebase. Nó kỳ vọng có các công cụ native để sửa file, xem CPU đang dùng bao nhiêu, tìm file, di chuyển file, chạy lệnh Git, đủ mọi thứ.

Theo Theo (video đăng ngày 10/10/2026), agent kỳ vọng và được huấn luyện trên các máy Linux thật, hay Mac, hay gì đó. Chúng được huấn luyện cho những hệ thống thật nơi chúng làm được việc. Tất nhiên bạn có thể sandbox chúng ở một mức nào đó, nhưng mỗi lớp thêm vào đều tốn thêm tài nguyên. Sandbox chặt hơn không làm compute rẻ đi; nếu có thì nó còn làm compute và bộ nhớ đắt hơn.

Nghĩa là, theo Theo (video đăng ngày 10/10/2026), chúng ta cần một lớp trừu tượng tốt hơn. Lý tưởng nhất, trong một tương lai nơi agent rẻ và viết code cực rẻ vì model và inference đã rẻ đến thế, thì thứ mà chúng dùng để viết và test code không nên đắt như vậy.

13. Cloudflare và V8 isolate

May mắn là, theo Theo (video đăng ngày 10/10/2026), đây là chuyện ngành này đã khám phá từ rất, rất lâu. Một cuộc chiến cũ mà lâu rồi không ai nhắc lại, và giờ ta được quay lại với nó: "Big Orange", Cloudflare.

Anh hỏi khung chat: nhắc tới Cloudflare thì mọi người nghĩ ngay tới chữ gì? Chat trả lời: cost, cheap, free, cheap. Có vài người nói cloud và CDN, nhưng phần lớn là miễn phí, rẻ, liên quan tới chi phí. Theo Theo (video đăng ngày 10/10/2026), nhiều điều người ta gắn với Cloudflare là sự rẻ, và lý do nằm ở cách nền tảng Cloudflare vận hành.

Theo mô tả trong video đăng ngày 10/10/2026, khi anh viết code backend và host trên Cloudflare, anh không gói nó vào một Docker image để họ deploy lên server. Thật ra khi đưa code lên Cloudflare, nó không được deploy theo nghĩa đó, nó không chạy sẵn. Nó chạy khi có request tới. Request khiến Cloudflare dựng lên một worker. Worker là một tiến trình JS cô lập bên trong V8, JavaScript engine chạy Chrome và rất nhiều thứ khác. Và isolate đó không phải kernel, không phải Linux, không phải một hệ điều hành. Nó là một lớp thực thi cô lập, nơi trình duyệt hay thứ khác chạy JavaScript.

Điều này rất hữu ích trong trình duyệt, vì các tab khác nhau làm những việc khác nhau mà không đụng được vào đồ của nhau. Hoặc một tab có bốn thứ khác nhau chạy bên trong, giao tiếp được với nhau nhưng không can thiệp vào nhau. Lớp cô lập của V8 cực kỳ mạnh. Theo Theo (video đăng ngày 10/10/2026), nó không phải thứ an toàn nhất, nhưng khá an toàn. Và điều Cloudflare làm là lấy các isolate đó, làm chúng an toàn nhất có thể, để khi người dùng vào một website bạn build và deploy trên Cloudflare, nó lấy code từ storage, ném vào một isolate đang ngồi chờ sẵn, chạy, rồi huỷ.

Còn trên một nền tảng như Vercel, Heroku, Hetzner hay bất kỳ host truyền thống nào (theo Theo, video đăng ngày 10/10/2026), nếu cả bạn và anh cùng host app ở đó, thì về cơ bản mỗi người có một Linux instance riêng đang chạy với code của mình. Trên Cloudflare, code của bạn và code của anh chạy trong cùng một instance Linux, chỉ được tách ra ở tầng cao hơn là V8, thay vì bằng VM và Docker. Theo hy vọng điều này dễ hiểu; nếu không thì "hỏi agent của bạn". Anh không muốn nói mãi về chuyện này vì đã nói trong nhiều video trước.

Nhưng theo Theo (video đăng ngày 10/10/2026), mô hình này có vấn đề. Nếu chạy trong một JavaScript isolate, ta mất nhiều thứ. Ta không đọc được file từ file system, vì file system không nằm trong isolate, và nếu đọc được thì ta có thể thoát ra ngoài và phá đồ của người khác. Ta không chạy được native code, vì native code thoát khỏi isolate và cần chạy trên hệ thống thật, điều không làm được ở đây. Nghĩa là ta không chạy được nhiều ngôn ngữ khác trong Cloudflare Workers, cũng không chạy được kiểu server bền vững truyền thống. Có rất nhiều hạn chế như vậy. Theo Theo, Cloudflare đã làm nhiều giải pháp khéo cho các vấn đề này, nhưng phần code ta đang nói, JavaScript, vẫn chạy trong lớp ảo phía trên V8 thay vì ở tầng VM.

Điều đó khiến Cloudflare là một nền tảng cực kỳ hiệu quả về chi phí và bộ nhớ, và đó là lý do nó rẻ đến vậy. Theo nhận định của Theo (video đăng ngày 10/10/2026), nó thật sự rẻ để vận hành: họ không chỉ định giá thấp vì muốn thắng, mà vì nền tảng cho phép họ làm vậy mà vẫn có lời. Theo nghĩa này, Vercel không đắt vì muốn kiếm nhiều tiền hơn Cloudflare; họ có lẽ lấy biên lợi nhuận tương tự, chỉ là chi phí của chính họ cũng cao hơn.

Nhưng vì Cloudflare chỉ chạy trong lớp JavaScript này, theo Theo (video đăng ngày 10/10/2026) bạn không thể thật sự chạy một agent trong đó, vì không đọc ghi được file. Không chạy được dev server. Càng không thể chạy TypeScript Go để biến TypeScript thành JavaScript và đưa phản hồi về lỗi cho agent.

14. Demo: cả vòng dev chạy trong một isolate

"Ồ, lạ nhỉ. Hình như tôi vừa làm đúng việc đó." Theo mở demo của mình (demo trong video đăng ngày 10/10/2026). Bản đầu anh build bằng Astra có vài quyết định ngớ ngẩn làm phí nhiều bộ nhớ, nên anh chuyển sang bản do Opus làm vì nó thể hiện đúng hơn điều anh nghĩ trong đầu.

Trước khi biện minh cho "mớ hỗn loạn" sắp trình bày, anh cần đưa ra một tham chiếu cuối: một thư viện tên just-bash. Theo kể just-bash do Malte ở Vercel tạo ra và đã thành một thư viện khá nghiêm túc (theo Theo, video đăng ngày 10/10/2026). Mục đích của just-bash là cho agent một môi trường bash giả hoàn chỉnh, nằm trong bộ nhớ, viết bằng JavaScript: bạn import Bash từ just-bash rồi chạy được phần lớn các lệnh bash truyền thống, với file system giả, process giả, mọi thứ đều giả, để agent hoạt động như thể nó đang làm việc trong bash dù thật ra không phải.

Đoạn Quick Start trên màn hình (README của just-bash, video đăng ngày 10/10/2026) cài package bằng npm install just-bash rồi chạy thử như sau:

import { Bash } from "just-bash";

const bash = new Bash();
await bash.exec('echo "Hello" > greeting.txt');
const result = await bash.exec("cat greeting.txt");
console.log(result.stdout); // "Hello\n"
console.log(result.exitCode); // 0

Nhưng theo Theo (video đăng ngày 10/10/2026), để cách này dùng được cho việc build, bạn còn phải compile, type check và làm mọi thứ khác mà bạn vẫn làm trên một file system bình thường. Nếu bạn dựng nó để agent khám phá file giả và tìm nội dung, tuyệt. Nhưng bạn sẽ không build được một app thật với nó, vì cần quá nhiều thứ khác, trong đó có TypeScript Rust. Hay đúng ra là TypeScript Go hoặc TSC truyền thống, nhưng giờ với TypeScript Rust, anh nói, ta làm được những việc "rất ngớ ngẩn".

Chẳng hạn ở đây, Theo để GPT-6.1 Sol build một app đầy đủ, chạy được hoàn toàn, tất cả bên trong một V8 isolate (demo trong video đăng ngày 10/10/2026). Về mặt kỹ thuật, bản này đang chạy trong Node trên một server, nhưng nó có thể chạy ngay trong trình duyệt của bạn. Có vài giới hạn, nhưng theo anh không nhiều như bạn nghĩ. Và tất cả cứ thế chạy, làm đúng việc của nó.

Theo Theo (demo trong video đăng ngày 10/10/2026), toàn bộ mức sử dụng ở đây, từ agent, tới compute nó chạy trên đó, tới compute mà chính app chạy, tới type check, compile và mọi thứ khác, đều chạy trong isolate của anh, dùng chưa tới 260 MB RAM và đỉnh chỉ khoảng 4% CPU.

"Bạn có hiểu điều này hay tới mức nào không?", anh hỏi. Theo Theo (video đăng ngày 10/10/2026), điều này cho phép một agent build một app mà cả agent lẫn compute nó dùng, không phải compute cho inference mà là compute để chạy code và build, tất cả chỉ tốn vài xu. Làm chuyện này bằng Go thì sẽ rất tệ, vì TS Go phí rất nhiều tài nguyên đơn giản vì port nó sang JS là không khả thi, hay sang Wasm, "nhưng bạn hiểu ý rồi". WebAssembly không hợp với Go, nhưng lại cực kỳ hợp với Rust.

Để nhấn mạnh ý đó: khi anh để Astra build bản demo này, nó chọn esbuild làm bundler. Và theo số đo của Theo (demo trong video đăng ngày 10/10/2026), chỉ ngồi yên không làm gì, bản đó dùng gấp đôi RAM so với bản kia. Lý do là việc đưa vào một package viết bằng Go như esbuild vốn đã ngốn bộ nhớ, tài nguyên và dữ liệu phải nạp vào: phải nạp nhiều thứ hơn hẳn vì bundle lớn hơn nhiều.

15. Từ phần cứng tới isolate: vì sao một tab Chrome rẻ hơn một container

Trong video đăng ngày 10/10/2026, Theo thấy nhiều người trong chat bối rối không hiểu cái này chạy trên Cloudflare kiểu gì. Anh hỏi: Cloudflare, Chrome và Node có điểm gì chung? Tất cả đều dùng V8 isolate. Chúng đều dùng cùng một JavaScript engine. Khi bạn nạp một extension Chrome, nạp một file mới, hay có một tiến trình nào đó trong Wasm, tất cả là những isolate worker khác nhau (đó là thuật ngữ). Chúng giao tiếp được với nhau nếu được phép, nhưng không can thiệp được vào nhau.

Điều anh build ở đây không ấn tượng vì anh làm lại Bolt rồi dùng TS Rust. Nó ấn tượng vì anh có thể bật file system sang chế độ read-only mà nó vẫn chạy (demo trong video đăng ngày 10/10/2026). Không có gì rời khỏi RAM. Không có gì rời khỏi V8. Anh không làm gì trên hệ thống cả. Tất cả nằm trong V8. Cả vòng dev nằm trong V8.

Theo anh, không có thứ gì so sánh được (nhận định trong video đăng ngày 10/10/2026). Anh thấy người ta nhắc tới mấy công ty database này nọ cho phép chạy code trên hệ thống của họ. "Không, không, các bạn chưa hiểu rồi." Và nếu khán giả stream của anh còn chưa hiểu, anh không mấy hào hứng chờ xem người khác sẽ hiểu thế nào.

Nên anh nói nhanh về cách máy tính hoạt động (phần giải thích trong video đăng ngày 10/10/2026). Dưới cùng là phần cứng: CPU, RAM, các thứ khác. Bên trên là driver. Driver do tầng phía trên cung cấp, đó là kernel; driver là cách kernel giao tiếp với phần cứng. Trên đó là hệ điều hành. Anh cho rằng thật ra còn có file system, rồi mới tới ứng dụng.

Tiếp theo anh xem một thứ như Heroku, Hetzner hay bất kỳ cloud bình thường nào chạy ra sao (theo Theo, video đăng ngày 10/10/2026). Nếu muốn deploy một Docker image lên AWS, ta không deploy nó ở các tầng dưới, vì những tầng đó phải nằm trên phần cứng của AWS để họ đặt thêm hệ thống lên trên. Nên ở tầng ứng dụng, họ đặt một thứ như Docker, rồi chép nguyên cả chồng lên trên. Đó là cách host trên các nhà cung cấp VPS bình thường: trên file system và hệ điều hành là một ứng dụng, thường là Docker. Nó không phải lúc nào cũng chạy một kernel instance mới, thường là một "shim kernel". Theo thừa nhận anh không hiểu hết phần hypervisor của Docker, nhưng Docker có shim xuống kernel giúp phần kernel hiệu quả hơn, cho phép bỏ qua vài bước khi hợp lý. Rồi bạn dựng một hệ điều hành lên trên. Đó là lý do trên AWS, một máy AWS cung cấp có thể có một người chạy Ubuntu, một người chạy Windows Server, một người chạy Debian.

Theo Theo (video đăng ngày 10/10/2026), tất cả xảy ra ở tầng ứng dụng Docker bên trên hệ điều hành, nghĩa là mỗi thứ đều tốn RAM. Đó là lý do mỗi lần bạn bật một Docker container mới trên máy, nó ngốn cả đống tài nguyên. Chạy hệ điều hành bên trong hệ điều hành thì tốn tài nguyên.

So với JavaScript, theo Theo (video đăng ngày 10/10/2026): vẫn chồng tầng như vậy, nhưng giả sử ứng dụng là Chrome. Trong Chrome có V8, JavaScript runtime. Trong V8 có tất cả các isolate, và chúng chạy được các file và function JavaScript khác nhau cùng lúc. Cách này hiệu quả hơn nhiều, vì giờ mỗi file hay ứng dụng, nếu vừa trong một isolate, không cần shim xuống kernel, chạy một hệ điều hành và chiếm cả đống tài nguyên.

"Nói thật đi", anh hỏi, "trên máy bạn cái gì tốn tài nguyên hơn: một Docker instance Postgres mới, hay một tab Chrome mới?" Tab Chrome, dù mọi người có nghĩ Chrome chậm đến đâu, rõ ràng dùng ít tài nguyên hơn nhiều, ít một cách phi lý, buồn cười. Theo Theo (video đăng ngày 10/10/2026), lý do là hàng tỉ đô Google đã đổ vào V8. Họ muốn engine này hiệu quả hết mức để web thành một nền tảng hấp dẫn, để cuối cùng họ thôi phải làm những app Windows tệ hại. Anh nói Google đã chi một tỉ đô để Chrome đủ nhanh, để họ thôi phải làm bản Windows của Google Earth và những thứ tương tự. Rất nhiều tiền và công sức đã được đổ vào V8.

16. Isolate để chạy chứ chưa phải để build, và CPU lúc nhàn rỗi

Theo Theo (video đăng ngày 10/10/2026), điều này mang lại lợi ích cho cả hệ sinh thái theo những cách khó hình dung hết, kể cả toàn bộ Cloudflare. Cả nền tảng của Cloudflare được xây trên ý tưởng rằng ảo hoá ở tầng hệ điều hành, tức đặt một OS ở tầng ứng dụng, là ngớ ngẩn, và V8 là lớp trừu tượng tốt hơn nhiều để đặt các ứng dụng khách hàng host lên.

Cái giá, theo Theo (video đăng ngày 10/10/2026), là chúng chỉ là JavaScript. Chúng không có đầy đủ khả năng của hệ thống. Bạn không gọi được kernel vì không có kernel nào bạn được truy cập. Bạn không ghi được file vì không có file system. Nó chỉ là JavaScript. Thứ gì một tab Chrome không làm được thì một V8 isolate cũng không làm được. Hãy nhớ, mọi vấn đề ở đây là: bạn không có file system, không có quyền truy cập native code, không làm được những việc cần để build. Isolate là chỗ tốt để đặt code khi đã build xong, nhưng không phải chỗ tốt để build.

Theo Theo (video đăng ngày 10/10/2026), trên Vercel, sandbox của Vercel dùng cùng compute và cùng primitive với việc host trên Vercel. Còn trên Cloudflare, anh cho rằng sandbox của Cloudflare rất tệ, vì Cloudflare không biết cách làm mọi thứ chạy tốt với Docker, đó không phải trọng tâm của họ. Trọng tâm của họ là tầng isolate. Nên sandbox của Cloudflare chạy trên compute hoàn toàn khác, nền tảng hoàn toàn khác so với hosting worker truyền thống của Cloudflare.

Vậy điều anh làm ở đây, điều anh mở ra được, là lấy cảm hứng từ just-bash. Điều làm just-bash đặc biệt là nó "nói dối" agent sống trong tầng isolate, để chúng tưởng mình có file system và những thứ khác. Và đó là điều Theo và nhóm đã build ở đây. Nếu anh gạt công tắc cho file system của server đang chạy demo này sang read-only, để anh thật sự không sửa được file nào trên máy, chỉ làm được mọi thứ trong RAM, trong V8 isolate của Node, thì demo vẫn chạy y hệt (theo Theo, video đăng ngày 10/10/2026). Đó là điều làm demo này hay. Theo anh, hoàn toàn có thể chạy cả demo này trong một Cloudflare Worker. Thay vì cần nửa GB RAM và một mớ CPU giữ riêng, anh ném nó vào đó và nó gần như không tốn gì.

Một điều nữa đáng nghĩ là cách phân bổ CPU. Nếu bạn có một VM hai CPU và anh có một VPS hai CPU, cả hai đều đang nhàn rỗi, thì ta vẫn đang phí bốn vCPU. Có vài cách giúp phân bổ lại dễ hơn để các core ảo không bị đảm bảo cứng như vậy. Nhưng theo Theo (video đăng ngày 10/10/2026), trên Cloudflare nó chạy bằng event loop có sẵn: khi code của bạn không làm gì, nó không tốn gì ngoài một chút RAM.

Nên khi bạn đang chờ token tiếp theo từ một nhà cung cấp inference, việc đó không tốn compute của bạn vì CPU không làm gì, và CPU đó được người khác dùng. Khi dữ liệu bất ngờ tới, nó chạy task tiếp theo, vì app của bạn, app của anh và app của một người khác đều đang dùng chung một event loop, về cơ bản là chung một scheduler. Chạy mọi thứ ở đây hiệu quả hơn nhiều. Và theo Theo (video đăng ngày 10/10/2026), ngay cả một task chạy hàng giờ có lẽ cũng dành phần lớn thời gian để nhàn rỗi.

Giờ thì nó chỉ tốn tiền khi có một token tới, không tốn cho khoảng thời gian giữa các token. Nếu inference tiếp tục rẻ đi, theo nhận định của Theo (video đăng ngày 10/10/2026), kiểu build này sẽ trở nên thiết yếu, vì nó cho phép xây những trải nghiệm phát triển dùng agent (agentic developer experience) rẻ ở mọi phía: chạy agent rẻ, và cho agent compute để thực thi cũng rẻ.

Anh thấy vài người trong chat bắt đầu đoán ra và hỏi chuyện này có liên quan tới một thứ khác mà họ đoán không. Anh nói chưa tiết lộ thêm được, phải để dành cho mọi người thứ gì đó để chờ đợi, vì lần này (video đăng ngày 10/10/2026) anh chỉ muốn tập trung vào một điều: TS Rust là một trong những mảnh cuối cùng anh cần để lấy toàn bộ trải nghiệm phát triển TypeScript từ đầu tới cuối và chạy nó trong một isolate thay vì trong một VM.

17. Những prompt "rất phức tạp", và việc thật sự là dựng môi trường

Với ai tò mò muốn xem những prompt "rất phức tạp" anh dùng để build TS Rust, Theo mở một thread tên "Original Prompts Behind the Build" trong T3 Code, nơi agent liệt kê lại (demo trong video đăng ngày 10/10/2026) các prompt đầu tiên của phiên /goal chính. Prompt đầu là một task được dán vào: làm việc trong thư mục sandbox ts-rust trên máy này, đọc AGENTS.md và file type checker accountability trước. Theo anh, các file đó chứa ghi chú tự động từ lần chạy 16 tiếng trước đó, và yêu cầu vài việc: cho phép cấu hình số job Cargo, thêm scripts/state và tách file trạng thái, vân vân, rồi cập nhật AGENTS.md để nó làm được nhiều việc song song hơn.

Rồi anh gửi tiếp, nguyên văn như trên màn hình:

Do it! Great work. I trust your judgement fully, keep going and doing what you think is best to continue improving compatibility and performance. We can probably move to main soon as well

Sau đó một lần nhắc thêm:

Get whatever the best current state of the work is set as the main branch ASAP. I don't care how. I trust your judgment.

Sau đó anh chạy /effort, vì nhận ra mình đang ở sai mức effort. Theo kể (video đăng ngày 10/10/2026) nó cứ tự hạ anh xuống medium mỗi khi crash, vì hết bộ nhớ và làm sập systemd liên tục. Khi anh đã thêm vài thứ ở tầng OS để sửa chuyện này, anh phải chạy lại /effort để đặt lại mức cũ, rồi tới /goal với nội dung trên màn hình:

Complete the port. Get it as close as possible to 100% compatibility with ts-go and also improve performance. Do these efforts in parallel. multiple workflows and subagents should be running at all times to maximize parallelization. orchestrate how you need to keep them working independently all on this machine.

Anh để ý nó liên tục hết compute (theo Theo, video đăng ngày 10/10/2026). Nên anh lấy thêm các máy khác trong "đội máy" của mình, cấu hình cho truy cập SSH, rồi báo cho agent rằng giờ nó có quyền SSH vào hai VPS khác. Anh cũng để ý nó cứ dừng lại: nó đạt full compat, rồi làm một cải thiện hiệu năng nhỏ và báo "xem này, tôi đã sửa hiệu năng rồi". Nó cần một trạng thái kết thúc rõ hơn. Nên anh đặt một goal mới:

Our target is minimum 2x faster than the Go build. Continue iterating until we get there...

Và nó chạy như vậy suốt hai tuần, cho tới kết quả bây giờ (theo Theo, video đăng ngày 10/10/2026). "Như các bạn thấy, tôi viết những prompt cực kỳ phức tạp, những thứ IQ siêu siêu cao. Tôi là một mega prompter", anh nói.

Nói thật thì, theo Theo, những gì anh làm ở đây không xoay quanh prompt. Nó xoay quanh môi trường và cách thiết lập để agent làm được những việc này. Anh có những thread khác chạy song song để liên tục rà soát: tìm xem tắc ở đâu, cái gì đang mất nhiều thời gian, những kiểu lỗi nào cứ lặp đi lặp lại, rồi cập nhật môi trường để agent làm việc song song hiệu quả hơn mà không giẫm chân nhau. Sau một thời gian, Theo và nhóm build được các hệ thống cho phép việc đó chạy, và mọi thứ nhanh hơn hẳn từ lúc ấy (theo Theo, video đăng ngày 10/10/2026).

Năng lượng của anh, nói thật, giống cách anh làm việc khi là một manager: không dành thời gian dưới chiến hào viết code, mà dành thời gian đảm bảo team có mọi thứ cần để hiệu quả nhất, tìm ra chỗ đang chậm và giúp họ vượt qua để chỗ chậm đó thôi lặp lại.

18. Khi những ý tưởng điên rồ chạy được thật

Theo nói làm việc này hoá ra rất vui.

"Một hành trình thật sự", anh nói trong video đăng ngày 10/10/2026. Anh kể "AI psychosis" của mình vốn đã khá nặng, nhưng việc tất cả những ý tưởng thật sự điên rồ anh nghĩ suốt nhiều năm giờ làm được thật mới là điều đáng nói. Anh luôn muốn có một trải nghiệm phát triển full stack chạy hoàn toàn trong V8. Hồi Bolt còn là StackBlitz và họ lần đầu tung ra cả một JS runtime chạy trong Wasm, để bạn có trải nghiệm kiểu VS Code đầy đủ với app được bundle ngay trong trình duyệt, anh đã choáng ngợp. Anh muốn đi xa hơn với Cloudflare. Anh còn đi tới mức thử reverse engineer StackBlitz, giải mã phần JS binary trong Wasm của họ để hiểu họ làm thế nào, vì có quá nhiều thứ hay ở đó. Nhờ vậy anh còn kết thêm được một người bạn từ hồi ấy.

Anh luôn là một "nerd" về chuyện code chúng ta viết thật sự chạy và thực thi ra sao, các hệ thống ghép với nhau và vận hành thế nào. Đó là thứ rất vui. Và giờ anh được thử những ý tưởng điên rồ của mình. Trước đây, phần lớn những thứ này chỉ là tưởng tượng: anh chơi những trò đó trong đầu, và nếu ý tưởng nào đi đủ xa, anh có thể bàn với một người thông minh hơn, may ra truyền cảm hứng để họ build một thứ gần giống vậy trong năm năm tới.

Còn bây giờ, theo Theo (video đăng ngày 10/10/2026), khi có một ý tưởng điên rồ, anh nói với Opus và xem nó có chạy hay không. Ngay lúc này anh muốn xem cái này có thật sự chạy được trên Cloudflare không, nên anh chỉ bảo Opus "làm đi", và anh nói có lẽ nó sẽ làm được. Điên rồ tuyệt đối.

Một mặt, theo anh, ngành engineering mà chúng ta biết và yêu đã chết, rất, rất chết rồi. Những project kiểu YOLO như thế này lẽ ra không thể khả thi: lẽ ra bạn còn không vượt qua nổi bộ test, nói gì tới việc thật sự chạy được như một drop-in replacement cho TypeScript. Anh nói thẳng (video đăng ngày 10/10/2026): nếu bạn vẫn nghĩ phát triển phần mềm bằng AI không phải tương lai, không phải nơi toàn bộ ngành phần mềm rõ ràng đang hướng tới, thì bạn "đáng bị thất nghiệp" trong ba tháng tới, vì chuyện này quá điên rồ. Thật sự khó hình dung các công cụ này đã giỏi tới mức nào.

Theo nói đó là tất cả những gì anh muốn nói lần này (video đăng ngày 10/10/2026). Anh đã thức tới sáu giờ sáng để chuẩn bị các demo, và rất tự hào về những gì anh và Opus "nấu" được. Không phải vì anh nghĩ ai cũng nên dùng thứ này, mà vì anh có thể kiểm chứng ý tưởng nào chạy được hay không theo những cách khó tin nổi. Anh thật sự thấy như đang được nhìn trộm tương lai với một số thứ ở đây, và thấy điều đó rất hay. Anh không thể tưởng tượng năm sau mọi thứ sẽ ở đâu, và hy vọng mọi người hào hứng đi cùng anh trên hành trình này, vì từ đây trở đi mọi thứ sẽ chỉ hỗn loạn hơn. Và anh chào: "until next time, peace, nerds".