# Harness là gì, và vì sao Theo cho rằng nó chẳng còn quan trọng mấy

[Theo Browne](https://homus.dev/speakers/theo-browne) · [Theo - t3․gg](https://homus.dev/orgs/theo-t3-gg)

> Theo giải thích harness là gì qua sơ đồ người, interface, harness, LLM, tool plane và data plane, và vì sao T3 Code là một ADE chứ không phải harness.

Topics: Agents, Coding Agents, Dev Tools

Canonical: https://homus.dev/talks/my-last-video-about-ai-harnesses

## 1. Một bài đăng của "gã Theo" nào đó, và video cuối về harness

Theo mở đầu (video đăng ngày 30/10/2026): anh kể vài ngày trước, khi đang lướt Twitter, anh thấy một "tên ngốc hoàn toàn" đăng bài rằng harness không quan trọng. Người đó đem chuyện mọi người thích harness này hay harness kia ra so với cuộc cãi nhau tabs hay spaces. Anh mở bài đăng đó ngay trên màn hình: nó đến từ một gã tên là Theo. Theo nói gã này chắc chắn chẳng biết mình đang nói gì, chỉ là một YouTuber, chắc chắn không phải một dev đang ship sản phẩm thật, và nên bị bỏ qua không cần bàn. Dù vậy, anh nói, chắc phải có lý do nào đó khiến gã này đăng bài như thế, đúng không?

![Theo Browne ngồi trước micro trong phòng thu tối, bên cạnh laptop và cốc nước](https://homus.dev/photos/ebILGCoN4UU-0003.jpg)

Theo Browne mở đầu video: đây là lần anh muốn nói về harness lần cuối (theo video đăng ngày 30/10/2026).

![Bài đăng trên X của Theo - t3.gg: Caring a lot about harnesses rn feels similar to caring about tabs vs spaces](https://homus.dev/photos/ebILGCoN4UU-0011.jpg)

Bài đăng của Theo trên X ngày 22/10/2026: "Caring a lot about harnesses rn feels similar to caring about tabs vs spaces", nghĩa đen là quan tâm nhiều tới harness lúc này cũng giống như quan tâm tới tabs hay spaces. Bên dưới, anh tự trả lời "Kind of self-own'd here huh" (theo video đăng ngày 30/10/2026).

Rồi anh nói thẳng: nếu người xem chưa nhận ra thì anh tình cờ biết gã Theo này khá rõ, và anh có rất nhiều suy nghĩ về điều gã nói ở đây. Có rất ít thứ anh muốn làm ít hơn việc làm thêm một video nữa về harness. Nhưng lần này anh sẽ làm khác đi, vì anh không muốn đây lại là "một video nữa về harness". Anh muốn đây là video cuối cùng (theo video đăng ngày 30/10/2026).

Anh biết điều đó nghe thật điên rồ khi đến từ người tạo ra T3 Code. Anh lúc nào cũng quảng bá cho "harness của anh", đúng không? Theo nói chuyện đó phức tạp hơn vẻ ngoài. Anh muốn nói về harness một lần cuối vì thật lòng anh đã rất mệt với chủ đề này. Nhưng anh nghĩ tới cuối video, người xem sẽ hiểu đúng harness là gì, và quan trọng hơn, vì sao ngày nay harness chẳng còn quan trọng mấy (theo Theo, video đăng ngày 30/10/2026). Có rất nhiều ngoại lệ cho các quy tắc ở đây, nhưng anh nghĩ người xem sẽ hiểu được tất cả những ngoại lệ đó, và còn hơn thế nữa.

## 2. Dev quan tâm tới những gì, và đường ranh cứ dịch dần lên

Trước khi nói về harness và vì sao anh không nghĩ mọi người nên quan tâm tới chúng, Theo muốn nói về cách dev quan tâm tới mọi thứ nói chung. Sự thật phũ phàng về dev, theo anh, là công việc của họ, ít nhất là cho tới gần đây (theo video đăng ngày 30/10/2026), xoay quanh việc quan tâm tới những thứ mà không người tỉnh táo nào nên quan tâm.

Ví dụ ngớ ngẩn trong bài đăng của anh là ví dụ rõ nhất: tabs hay spaces. Theo Theo, thực tế thì những người thật sự nên quan tâm ở đây là người có nhu cầu accessibility cụ thể, khi spaces làm screen reader chạy tệ hơn tabs. Đó kiểu như là lý do duy nhất để quan tâm tới tabs hay spaces. Nhưng dev vẫn quan tâm, vì dev đã dành cả đời để quan tâm tới những thứ lặt vặt vớ vẩn. Anh nói: đó là việc chúng ta làm (theo video đăng ngày 30/10/2026).

Sự thật là những thứ vớ vẩn đó có nhiều tầng. Ở tận đáy của chồng "một thứ quan trọng tới đâu" là tabs hay spaces. Càng đi lên, càng gặp những thứ quan trọng hơn một chút: các pattern để định nghĩa function và các thuật toán nền tảng, các framework dùng để build, các ngôn ngữ dùng để viết những thứ đó, architecture của ứng dụng (cách nó được build và được nghĩ ra), các kỹ sư thật sự làm mọi thứ đó, và sản phẩm mà bạn đang cố build trên tất cả những thứ này (theo video đăng ngày 30/10/2026).

Chồng các tầng mà Theo vẽ ra (theo video đăng ngày 30/10/2026): càng lên cao càng đáng quan tâm, sản phẩm ở đỉnh, tabs hay spaces ở đáy.

Thực tế mà nói, theo Theo (video đăng ngày 30/10/2026), những thứ ở đỉnh, tức sản phẩm mà công ty bạn bán, có lẽ nên quan trọng rất nhiều. Còn việc bạn dùng tabs hay spaces thì có lẽ không nên quan trọng mấy. Anh đoán người xem đang hơi bối rối vì anh đặt các thuật toán nền tảng xuống dưới framework và ngôn ngữ. Điều đó chắc sẽ làm nhiều "CS bro" và giáo sư trong khán giả nổi cáu. Anh xin lỗi, và nói một lát nữa họ sẽ hiểu vì sao.

Điều anh muốn nhấn mạnh ở đây là thứ chúng ta tập trung vào thay đổi theo thời gian. Ngày xưa, kỹ sư quan tâm rất nhiều tới instruction set mà họ có trong tay khi build, tức các phiên bản assembly khác nhau cho các bộ xử lý khác nhau mà họ nhắm tới. Những thứ đó ngày xưa rất quan trọng, và đôi khi vẫn quan trọng với một số người. Nhưng dev đã làm một việc mà dev hay làm: build một abstraction. Thay vì tự viết instruction cho từng nền tảng, dev bắt đầu viết bằng các ngôn ngữ chung có thể tạo ra những thứ riêng cho từng nền tảng. Rồi có những ngôn ngữ tốt hơn cho việc này, như C (theo video đăng ngày 30/10/2026).

Theo nói cuối cùng thì điều xảy ra với C không phải là có ít code assembly hơn hay ít lập trình viên hơn. Mà là lập trình đã đủ dễ để một dev bình thường không phải quan tâm CPU đang chạy instruction cụ thể nào, và có thể build ở một tầng cao hơn trước. Thực tế là đường ranh bạn vẽ tuỳ vào việc mọi thứ đang ở đâu vào từng thời điểm. Khi C ra đời, đường ranh "chỗ bạn phải quan tâm" dịch lên một chút, nằm ngay trên các instruction mà code của bạn chạy (theo video đăng ngày 30/10/2026).

Khi editor đủ tốt để xử lý tabs hay spaces và đổi qua lại giữa hai thứ, và các tool như Prettier đã tới mức đáng tin và nhất quán, thì việc quan tâm tới tabs hay spaces, cách tách thụt lề cho dấu ngoặc nhọn, cách format câu lệnh if và mọi thứ kiểu đó, dev đã được thôi quan tâm. Và dần dần dev cũng phải thôi quan tâm tới các pattern để viết function, một phần vì tất nhiên đã có mọi công cụ format, linter tốt. Nhưng quan trọng hơn, AI đã xuất hiện. Với AI, bỗng nhiên bạn có thể bấm tab để tự hoàn thành và sinh ra function bạn đang gõ. Và rồi các thuật toán nền tảng mà bạn phải thuộc lòng cũng bớt quan trọng, vì bạn có thể gọi tên thuật toán và nó sẽ điền phần còn lại cho bạn (theo video đăng ngày 30/10/2026).

## 3. Advent of Code, chuyện bố mẹ, và framework đã đổ

Theo kể đó là cách anh làm bài rất tốt ở Advent of Code ba hay bốn năm trước mà không tốn mấy công sức: anh biết cần những thuật toán nào, và thay vì tự cài đặt chúng, anh gọi tên chúng rồi bấm tab liên tục (theo video đăng ngày 30/10/2026).

Điều anh muốn nói là, với tư cách một ngành, mọi thứ luôn dịch lên như thế. Khi abstraction mới được tạo ra và tool mới xuất hiện, những chỗ trước đây có thể tốn rất nhiều công sức của bạn không còn đem lại lợi ích cho bạn nữa. Nhưng chúng ta là kỹ sư. Chúng ta thích quan tâm tới những thứ lặt vặt, những thứ cần thiết mà thế giới xung quanh bảo là không quan trọng (theo video đăng ngày 30/10/2026).

![Bảng vẽ Harness rant với danh sách Product, Engineers, Architecture, Languages, Frameworks, một đường kẻ ngang, rồi Fundamental algos, Patterns for defining functions, Tabs vs spaces, Instructions](https://homus.dev/photos/ebILGCoN4UU-0743.jpg)

Bảng vẽ "Harness rant": đường kẻ ngang nằm giữa Frameworks và Fundamental algos. Các tầng dưới đường kẻ (Instructions, Tabs vs spaces, Patterns for defining functions, Fundamental algos) là những thứ mà theo Theo dev đã thôi phải quan tâm (theo video đăng ngày 30/10/2026).

Anh hỏi chat: thật lòng mà nói, bao nhiêu người trong các bạn từng bị bố mẹ nói rằng bạn dành quá nhiều thời gian trên máy tính, và chuyện đó sẽ không quan trọng bằng thế giới thật? Anh bảo ai từng bị nói vậy thì gõ 1 vào chat. Và chuyện đó có cản được ai trong chúng ta không? Không một ai. Chúng ta không quan tâm khi thế giới bảo rằng mình đang phí thời gian vào thứ không quan trọng. Nếu có quan tâm, chúng ta đã chẳng bao giờ học được cách code.

Thật lòng mà nói, đây là chỗ vấn đề đầu tiên xuất hiện: theo Theo (video đăng ngày 30/10/2026), kỹ sư có thiên hướng quan tâm tới những thứ mà họ không nên quan tâm. Chữ "không nên" thì mơ hồ và tuỳ vào bạn là ai, nhưng thật lòng mà nói, có rất nhiều thứ kỹ sư quan tâm mà lẽ ra không nên, lại là những thứ như tabs hay spaces.

Và các model vẫn tiếp tục tốt lên. Cùng với đó, các framework đã đổ. Theo kể (video đăng ngày 30/10/2026) rằng các bản Next.js gần đây có ít lượt chú ý trên Twitter hơn mấy bài đăng nhảm nhí ngẫu nhiên của anh về T3 Code. Lần mà một bản Next.js được chú ý nhiều nhất trong năm nay là vì anh quote tweet một bản phát hành và chỉ ra rằng chẳng có gì xảy ra cả, chẳng ai để ý hay quan tâm tới một bản Next.js mới. Anh nói mình từng là người bênh vực Next.js số một trong nhiều năm, vậy mà giờ không ai thèm quan tâm nữa. Chúng ta thậm chí không nhận ra khi chuyện này xảy ra, nhưng nó đã xảy ra.

Và giờ chúng ta đang tới gần "rào cản ngôn ngữ". Anh có nhiều thứ đã viết bằng TypeScript. Không chỉ viết lại được những thứ đó bằng Rust, anh còn viết lại chính TypeScript bằng Rust. Theo Theo (video đăng ngày 30/10/2026), ngôn ngữ giờ là chi tiết cài đặt. Chúng giống một dòng thông số trên bảng spec, có thể thay ra được, và thật sự có thể được thay thế trong một vòng lặp chạy không mất nhiều thời gian.

## 4. Architecture, báo cáo gửi Cloudflare, và LLM chỉ sinh ra chữ

Architecture cũng ngày càng nằm trong khả năng của model (theo Theo, video đăng ngày 30/10/2026). Model làm việc này vẫn còn xa mới hoàn hảo, thậm chí chưa đạt mức anh đòi hỏi. Nhưng model hiểu các vấn đề về architecture. Nếu bạn đem tới một thiết kế tốt, model có thể tìm ra những lỗ hổng cần thay và sửa để đưa nó từ tốt lên rất tốt. Và khi gom đủ nhiều agent khác nhau, với đủ thông tin, quyền truy cập và khả năng test khác nhau, chúng có thể tìm ra lỗi trong hệ thống.

Theo kể (video đăng ngày 30/10/2026) anh vừa tìm ra một loạt lỗi rất nghiêm trọng trong phần pipeline của Cloudflare mà Cloudflare có vẻ hoàn toàn không biết. Anh để ý thấy vài lỗi không lẽ ra phải xảy ra, nên đã bật Claude lên. Claude dựng một loạt alerting, monitoring và tracing trong các hệ thống backend của anh để xác định lỗi xảy ra ở đâu và khi nào, ở những region nào, rồi viết một báo cáo. Anh gửi báo cáo đó cho Cloudflare, và Cloudflare chỉ cảm ơn anh, vì họ không biết và sẽ đi sửa.

Câu chuyện Theo kể (video đăng ngày 30/10/2026): từ vài lỗi lạ trong log, Claude dựng hệ thống theo dõi, chỉ ra lỗi xảy ra ở đâu, khi nào, ở region nào, rồi viết báo cáo mà anh gửi cho Cloudflare.

Theo nói có lẽ trong một số trường hợp cụ thể, Claude giờ giỏi architecture hơn cả những công ty như Cloudflare (theo anh, video đăng ngày 30/10/2026). Anh hỏi: bạn có hiểu chuyện đó điên rồ tới mức nào không? Một YouTuber để ý thấy một lỗi trong log của mình, hỏi Claude về nó, và giờ có một báo cáo mà CTO của Cloudflare nhắn cho anh để xin thêm thông tin. Anh nói nếu bạn không nghĩ mọi thứ đang thay đổi, thì anh rất tiếc, bạn sẽ mất việc trong ba tháng nữa. Chấp nhận chỗ chúng ta đang đứng, hoặc chết (dự đoán của Theo trong video đăng ngày 30/10/2026).

Dù sao thì đây là video về harness. Sao lại nói chuyện này? Anh hứa sẽ quay lại đây, vì ngay lúc này anh muốn "rant" về harness là gì.

Theo đoán phần lớn người xem đã nghe về LLM, và mong rằng tới thời điểm này ý niệm về language model không quá xa lạ. Anh hỏi lại chat: LLM làm gì? Gần như mọi câu trả lời đều tốt: viết chữ, tạo chữ, đoán token tiếp theo, đoán chữ, sinh chữ. Đúng vậy, tất cả đều là những mô tả hoàn toàn hợp lý (theo video đăng ngày 30/10/2026).

Theo Theo (video đăng ngày 30/10/2026), tất cả những gì một LLM làm được là tạo ra chữ. Nó nhận chữ vào rồi sinh ra thêm chữ. Anh biết điều đó nghe thật điên rồ, vì chúng ta đã thấy AI làm đủ thứ, từ hack chính phủ, tới tái tạo mọi phần mềm ta dùng hằng ngày, tới phá huỷ nền kinh tế rồi dựng lại nó.

## 5. Người, interface, harness, LLM: căn bếp không có dụng cụ

Làm sao LLM làm được tất cả những thứ đó nếu tất cả những gì nó làm là sinh ra chữ? Theo nói đó là chỗ harness bước vào. Anh mở bảng vẽ "wtf is a harness" và nói mong rằng sơ đồ "đẹp đẽ" này giải thích hoàn hảo harness là gì (theo video đăng ngày 30/10/2026).

![Sơ đồ vẽ tay: Human, mũi tên tới Interface, tới Harness, tới LLM là một con robot, có mũi tên chiều ngược lại](https://homus.dev/photos/ebILGCoN4UU-1102.jpg)

Human gửi tới Interface, Interface gửi tới Harness, Harness nói chuyện với LLM (hình robot), và các mũi tên quay ngược lại (theo video đăng ngày 30/10/2026).

Nhưng với những ai chưa thấy ngay từ "sơ đồ vẽ rất tệ chẳng nói lên điều gì" này, anh sẽ giải thích một chút, theo một cách hơi lạ. Anh muốn tạm thời bỏ qua hoàn toàn nửa bên phải của sơ đồ, và chỉ nói về con người và interface. Và anh bắt đầu bằng một kiểu interface lạ: căn bếp.

Bạn tới một nhà hàng, bạn có món muốn ăn. Bạn được đưa thực đơn. Bạn chọn món, bạn gọi món. Đầu bếp được báo bạn muốn món gì. Rồi đầu bếp đứng đó nhìn chằm chằm vào bạn và nói: sao, anh muốn tôi nấu à? Tôi có thể mô tả tôi sẽ nấu gì, nhưng ở đây tôi chẳng có gì cả. Đây chỉ là một căn bếp. Dụng cụ đâu? Mọi thứ tôi cần để nấu đâu?

Bạn có thể đặt một đầu bếp xuất sắc vào một căn phòng và dán nhãn căn phòng là "bếp", nhưng đầu bếp chẳng làm được gì cho tới khi trong phòng có những thứ để họ tương tác. Họ cần dụng cụ. Đầu bếp giỏi hay có năng lực tới đâu cũng không quan trọng. Thực đơn chi tiết tới đâu cũng không quan trọng. Nếu trong bếp không có dụng cụ họ cần, họ không làm được việc của mình (theo video đăng ngày 30/10/2026).

Giờ hãy tưởng tượng một lập trình viên. Bạn được đặt trước một chiếc máy tính và được bảo viết một thuật toán sắp xếp cơ bản. Bạn cứ nhìn màn hình, rồi nhìn lại người hướng dẫn và nói: này, tôi không làm được. Người đó hỏi: sao vậy? Bạn trả lời: không có bàn phím. Anh chỉ đặt tôi trước một cái màn hình. Không có cách nào để tôi giải thích cho chiếc máy tính này điều tôi đang làm. Tôi không thể đưa input vào để có gì đó xảy ra. Tôi có thể nhìn màn hình và nói về nó, nhưng không thể đưa input vào khi không có nút để bấm.

Theo nói đó là lý do chúng ta có interface, cả phần cứng lẫn phần mềm. Chúng ta có bàn phím và chuột. Chúng ta có chương trình với các nút để bấm. Chúng ta có những thứ cho phép đi từ một suy nghĩ trong đầu tới một hành động, để làm một thứ gì đó xuất hiện, thay đổi hay khác đi. Chúng ta cần một interface để làm điều đó, để đôi tay có ích hơn việc cầm nắm, mà ngay cả cầm nắm cũng cần có thứ để cầm. Đôi tay vô dụng cho tới khi có thứ để chúng tương tác (theo video đăng ngày 30/10/2026).

Tương tự, LLM có chữ. Theo Theo (video đăng ngày 30/10/2026), chữ chỉ dùng được để đọc cho tới khi bạn cho model những thứ mà nó có thể dùng chữ để tác động. Nếu một người không có đồ vật nào xung quanh, không có ai xung quanh, và chỉ đang bị quay phim, thì công dụng duy nhất của đôi tay là ngôn ngữ ký hiệu. Nhưng nếu bạn đưa cho họ những thứ đôi tay có thể dùng, tương tác và làm, bỗng nhiên đôi tay trở nên hữu ích. Cũng vậy, tất cả những gì một LLM làm được với chữ là ra tín hiệu, tương đương với việc ta dùng ngôn ngữ ký hiệu. Để chữ thành một cái gì đó, LLM cần tool và hệ thống nơi chữ có thể biến thành hành động.

Giống như bàn phím cho phép bạn dùng tay để gõ, một LLM cũng cần thứ gì đó để tương tác. Con người có app, UI, bàn phím, chuột, đủ thứ khác nhau. LLM có harness. Để một người nấu ăn, họ cần một căn bếp có dụng cụ. Và để một LLM viết code, nó cần một harness có tool (theo video đăng ngày 30/10/2026).

Theo nói cách harness hoạt động đơn giản tới mức dễ gây hiểu lầm. Harness nói với LLM: này, đây là một cú pháp đặc biệt mà bạn có thể dùng để trả lời, để bảo tôi đi làm việc. Nếu bạn trả lời theo cú pháp này, tôi sẽ đọc một file cho bạn. Nếu bạn trả lời theo cú pháp này, tôi sẽ sửa một file cho bạn. Nếu bạn trả lời theo cú pháp này, tôi sẽ push lên GitHub, hoặc chạy một lệnh, hoặc truy cập memory của bạn, hoặc đi tiêu của bạn một đống tiền trên một API nào đó. Để LLM làm được gì đó, nó cần một cú pháp để trả lời mà harness cũng hiểu được (theo video đăng ngày 30/10/2026).

Cách harness hoạt động theo lời Theo (video đăng ngày 30/10/2026): harness cho LLM một cú pháp đặc biệt; LLM trả lời theo cú pháp đó thì harness đi làm việc thật.

Theo Theo (video đăng ngày 30/10/2026), một LLM không có harness giống như một đầu bếp trong căn bếp trống. Họ có thể nói cho bạn họ sẽ làm gì, nhưng không làm được gì. Và harness là thứ cho phép LLM làm việc.

Rồi anh rủ chat chơi một trò: anh sẽ đọc tên vài sản phẩm, và chat sẽ nói chúng nằm ở đâu, là interface hay harness. Bắt đầu bằng câu dễ: Twitch TV là interface hay harness? Chat trả lời: interface. Tuyệt, dễ thôi. Vậy Twitch là một interface, và như bạn đoán được, YouTube cũng vậy. Thêm một câu dễ nữa: Claude Code Agent SDK là interface hay harness? Chat trả lời: harness. Anh khen chat làm tốt (theo video đăng ngày 30/10/2026).

## 6. Agent SDK, Claude Code và T3 Code: cái nào là harness?

Nếu bạn chưa quen với Agent SDK, Theo giải thích rằng mục đích của Agent SDK là cho LLM của bạn, cụ thể là Claude, mọi thứ nó cần để build, làm việc trên máy tính, sửa code và vân vân (theo Theo, video đăng ngày 30/10/2026). Anh đọc phần mô tả trong trang docs: một agent là một ứng dụng hoàn thành một tác vụ bằng cách tự lên kế hoạch các bước và gọi các tool đọc file, chạy lệnh hoặc sửa code. Agent SDK cho bạn cùng các tool, agent loop và cách quản lý context đang chạy Claude Code, lập trình được bằng Python và TypeScript (trang docs đọc trong video đăng ngày 30/10/2026).

Và giờ tới câu hỏi gây tranh cãi: Claude Code là gì? Claude Code là harness hay interface? Theo đọc chat: rất nhiều người nói "cả hai", một số nói "interface" (theo video đăng ngày 30/10/2026).

Theo lập luận rằng Claude Code là một interface có đóng gói kèm một harness. Và harness được đóng gói đó, ít nhất trong bản app desktop, là Agent SDK. Vậy app Claude trên máy tính của bạn là một interface, và interface đó cắm vào Agent SDK, vốn là một harness (theo Theo, video đăng ngày 30/10/2026). Anh nói nếu bạn không tin anh thì hãy xem chính lời của Anthropic.

![Trang Claude Code Docs, mục Compare the Agent SDK to other Claude tools với bảng You want to, Use, What you get](https://homus.dev/photos/ebILGCoN4UU-1623.jpg)

Trang Claude Code Docs mà Theo mở (theo video đăng ngày 30/10/2026), bảng "Compare the Agent SDK to other Claude tools": Agent SDK là "A library that runs the Claude Code binary", Claude Code CLI là "The terminal interface, built for daily interactive use", thêm Client SDK và Managed Agents.

Theo đọc bảng so sánh trên trang docs: nếu bạn muốn nhúng agent của Claude Code vào ứng dụng Python hoặc TypeScript của riêng bạn, trong một process bạn quản lý, thì dùng Agent SDK. Đó là một library chạy binary của Claude Code, "yada, yada, yada". Còn nếu bạn muốn phát triển tương tác hoặc chạy các tác vụ một lần từ terminal, Anthropic khuyên dùng Claude Code CLI, vì nó là một interface terminal được build để dùng tương tác hằng ngày (trang docs đọc trong video đăng ngày 30/10/2026).

Theo nói chỗ gây rối ở đây là cụm "binary của Claude Code". Nhưng binary của Claude Code là một harness. Agent SDK giúp dùng harness đó dễ hơn, nhưng nó vẫn chỉ là một harness. Còn Claude Code CLI thì không nghi ngờ gì là một interface (theo Theo, video đăng ngày 30/10/2026).

Anh dặn người xem đừng quên chuyện phân cấp này, vì anh hứa sẽ quay lại nó, và có lẽ đây là phần quan trọng nhất của video. Để phần tiếp theo có nghĩa, anh phải lùi ra xa thêm một chút, vì có rất nhiều người bối rối về T3 Code. Đó là một lý do lớn khiến anh làm video này: lượng người nhầm lẫn T3 Code là gì. Theo Theo (video đăng ngày 30/10/2026), T3 Code không phải harness, nó là một interface. Nó có cung cấp một số thứ cho harness, và có thay đổi cách harness hoạt động ở vài chỗ. Nhưng T3 Code không phải harness. Anh sẽ giải thích sau.

## 7. Tool plane, và chữ "agent"

Trước hết, Theo muốn nói về tool, vì theo anh (video đăng ngày 30/10/2026) phần lớn thứ làm harness hữu ích là các tool mà harness đưa cho agent. Trên bảng vẽ, anh kẻ một đường ngăn hàng có con người và LLM với một hàng phía trên mà anh gọi là "tool plane". Đây là những thứ harness đưa cho LLM.

![Sơ đồ Tool plane phía trên: TypeScript plugin với goToDefinition, findReference; cột Harness với bash, spawn_subagent, read_file, edit_file, read_skill, create_artifact; Computer use (i.e. CUA) với screenshot, click, type](https://homus.dev/photos/ebILGCoN4UU-1723.jpg)

Tool plane trên bảng vẽ: cột Harness (ghi Claude Agent SDK, Codex CLI, Pi) chứa bash, spawn_subagent, read_file, edit_file, read_skill, create_artifact; bên trái là TypeScript plugin (goToDefinition, findReference), bên phải là Computer use (i.e. CUA) với screenshot, click, type. Ô Interface ghi T3 Code, Codex App, TUIs, GUIs (theo video đăng ngày 30/10/2026).

Theo cũng lưu ý rằng anh đã cố tình lùi việc này lại trong bài viết anh viết về toàn bộ chủ đề. Bài "What is a harness" của anh đã có trên blog t3.gg (theo video đăng ngày 30/10/2026), và anh giải thích phần lớn những điều này ở đó. Anh nói mình rất ngạc nhiên khi thấy có bao nhiêu dev không hiểu harness là gì. Buồn cười là mọi chuyện bắt đầu khi một thành viên của một foundation không biết harness là gì mà vẫn cố "dunk" anh vì đã build một harness, trong khi anh không hề build harness.

Thứ anh không vội nói tới trong bài viết, thậm chí anh đã cố tình lùi từ này tới tận cuối bài, là chữ "agent". Theo Theo (video đăng ngày 30/10/2026), một agent là sự kết hợp giữa một harness và một LLM. Agent là một LLM có khả năng hoàn thành các tác vụ, có phạm vi hoặc không có phạm vi, thông qua một harness cung cấp cho nó tool, context, system prompt mô tả vai trò, và mọi thứ kiểu đó, để LLM làm được nhiều hơn. Chính sự kết hợp giữa harness và LLM mới tạo thành một agent.

![Sơ đồ với khung Agent bao quanh Harness và LLM, Interface nằm ngoài khung](https://homus.dev/photos/ebILGCoN4UU-1843.jpg)

Theo vẽ khung "Agent" bao quanh Harness (Claude Agent SDK, Codex CLI, Pi) và LLM; Interface (T3 Code, Codex App, TUIs, GUIs) nằm ngoài khung (theo video đăng ngày 30/10/2026).

## 8. Tool đến từ đâu, và data plane: cuốn sách nấu ăn để trong bếp

Giờ đã hiểu điều đó, Theo nói về các tool. Theo anh (video đăng ngày 30/10/2026), phần lớn harness đi kèm một số tool có sẵn, harness này nhiều hơn harness kia. Pi gần như không có tool nào đi kèm, về cơ bản chỉ có Bash. Claude Code và Claude Agent SDK đi kèm nhiều hơn: có tool spawn sub-agent, có read file, edit file, read skill, create artifact, tất nhiên có bash, và rất nhiều thứ khác.

Nhưng bạn cũng có thể đem tool vào từ những chỗ khác. Ví dụ, theo Theo (video đăng ngày 30/10/2026), nếu cài plugin TypeScript trong Claude Code, bạn sẽ có vài tool trợ giúp hữu ích như go to definition hay find reference. Nếu cài CUA, một hệ thống điều khiển máy tính (computer use) dùng chung, mã nguồn mở, mà anh nói sẽ sớm có trong T3 Code nếu mọi việc suôn sẻ, thì nó sẽ thêm các tool như screenshot, click và type, cho phép agent kích hoạt các thao tác trên máy tính của bạn.

Vậy việc thêm tool có làm TypeScript thành một harness không? Theo nói rõ ràng là không. TypeScript chỉ là một plugin cho harness của bạn, thêm các tool bổ sung mà agent có thể dùng. Các binding và driver của CUA cũng vậy. CUA không phải harness. CUA là một bộ tool mà bạn có thể đưa vào harness để agent làm được nhiều việc hơn (theo video đăng ngày 30/10/2026).

Vậy T3 Code nằm ở đâu? Theo nói anh và nhóm T3 Code không thật sự thêm tool mới, vì anh và nhóm tập trung vào phía bên kia, thứ anh gọi là "data plane". Đây là các interface bạn đưa cho agent để truy cập những thứ nằm ngoài harness. Về mặt kỹ thuật, bạn có thể build nhiều thứ trong số này thành tool, nhưng điểm mấu chốt là thứ đó, có thể nói như vậy, sống ở bên ngoài harness (theo video đăng ngày 30/10/2026).

![Sơ đồ Data plane: T3 Code MCP trỏ vào cột Harness có memory, CLAUDE.md, AGENTS.md; Supabase MCP và PostHog MCP trỏ vào từ bên phải](https://homus.dev/photos/ebILGCoN4UU-2023.jpg)

Data plane trên bảng vẽ của Theo (video đăng ngày 30/10/2026): cột Harness phía dưới có memory, CLAUDE.md, AGENTS.md; T3 Code MCP trỏ vào từ bên trái, Supabase MCP và PostHog MCP trỏ vào từ bên phải.

Theo dùng lại hình ảnh căn bếp: khi bạn thêm một tool vào harness, bạn đang đặt một thứ vào trong bếp. Còn với MCP và những thứ ở data plane, anh nghĩ về nó giống một cuốn sách nấu ăn bạn để lại trong bếp. LLM có quyền chọn đọc cuốn sách đó và quyết định có làm theo hay không, hoặc bỏ mặc nó hẳn, không động tới, không quan tâm. Việc có buồn đọc cuốn sách hay không là tuỳ LLM. Tất nhiên LLM cũng có thể bỏ qua dụng cụ trong bếp, nhưng dụng cụ là dụng cụ, chúng nằm sẵn quanh đó (theo video đăng ngày 30/10/2026).

Theo Theo (video đăng ngày 30/10/2026), mục đích của MCP là đem thông tin từ bên ngoài vào và, có thể nói như vậy, tương tác với những thứ khác. Điều này rất hợp lý với những thứ như Supabase MCP hay PostHog MCP, vì mục đích của chúng là cho agent truy cập dữ liệu nằm ở chỗ khác, dù đó là database sản phẩm trên Supabase hay số liệu analytics trên PostHog. MCP là một cách để agent truy cập những thứ đó.

## 9. Tool là code, MCP là binding: vì sao T3 Code nằm ở data plane

Vậy vì sao T3 Code lại nằm ở đây? Theo Theo (video đăng ngày 30/10/2026), tool gắn rất chặt với từng harness. Khi tạo một tool, bạn phải làm theo cách harness mong đợi. Bạn phải hỗ trợ cú pháp và các khả năng mà harness mong đợi. Và code bạn viết về cơ bản sống bên trong harness. Bạn đang thực chất ship một binary chạy bên trong harness. Nó có thể chỉ là TypeScript, chỉ là JavaScript, hay một thứ còn đơn giản hơn như Python. Hoặc nó có thể là một file thực thi, một bash script, ba dòng code rất mỏng gọi một API bên ngoài. Nhưng khi ship một tool là bạn đang ship code.

Còn MCP là binding, không phải code. Liệu anh và nhóm có thể lấy mọi thứ mà T3 Code MCP cung cấp rồi biến chúng thành custom tool có mặt trong mọi harness không? Về giả thuyết thì có. Nhưng bằng cách đặt nó vào MCP như thế này, anh và nhóm giữ được toàn bộ code nằm trong T3 Code, và thực chất chỉ để agent tương tác với nó qua một hợp đồng đã thống nhất. Thay vì harness tự chạy code, harness đưa chỉ dẫn cho T3 Code để T3 Code chạy code (theo video đăng ngày 30/10/2026).

Theo nói (video đăng ngày 30/10/2026) điều này cho phép anh và nhóm build tool và hệ thống theo cách chung chung hơn nhiều, và ít can thiệp vào cách harness hoạt động mặc định. Và đó là lý do anh thấy T3 Code MCP rất hay. Vì anh và nhóm không can thiệp vào các tool có sẵn trong harness của bạn, nếu bạn đã cài Claude Code và đăng ký gói 200 đô, hay 100 đô, thậm chí 20 đô (các mức gói Theo nhắc tới trong video đăng ngày 30/10/2026), rồi cài thêm T3 Code, thì Claude Code sẽ chạy được trong T3 Code với gói đăng ký của bạn theo đúng cách bạn quen. Mọi skill, mọi plugin, mọi thứ của bạn đều chạy được.

Nhưng T3 Code có thêm một thứ: T3 Code MCP. Theo Theo (video đăng ngày 30/10/2026), mọi thứ bạn vẫn làm với Claude đều còn đó. Nhưng nếu bạn muốn làm thứ nó bình thường không làm được, như mở thêm một thread với Codex, hay có một sub-agent dùng Antigravity hoặc Grok Build hay thứ gì đó tương tự, thì đó là thứ T3 Code MCP cung cấp. Nó cho phép agent tìm trong lịch sử T3 Code của bạn và tìm ra những thứ từ các harness khác. Nó cho phép agent gửi tin nhắn tới các thread khác, hoặc mở sub-agent với bất kỳ harness nào bạn muốn.

Nếu để các tool đó sống trong harness, anh và nhóm sẽ bị kẹt ở tầng đó. Nếu nghĩ theo kiểu LLM ở dưới cùng, rồi tới harness, rồi tới interface, rồi tới thứ chúng ta đang build, thì nếu đặt mọi thứ vào harness, ta không thể đi sâu hơn. Vì anh và nhóm đã build cái này ở một tầng khác, cao hơn, với tầng MCP này, nên có thể để một harness điều khiển một harness khác. Thật ra nó không điều khiển harness kia. Nó báo cho T3 Code qua tầng MCP rằng cần đi mở harness kia, rồi T3 Code làm người môi giới, chuyển tin nhắn qua lại giữa các bên (theo Theo, video đăng ngày 30/10/2026).

Thứ tự các tầng Theo mô tả (video đăng ngày 30/10/2026): LLM ở dưới, rồi harness, interface, và thứ đang build. T3 Code MCP nằm ở tầng cao hơn harness, nên một harness có thể nhờ T3 Code mở một harness khác và chuyển tin nhắn qua lại.

Điều này để lại một câu hỏi quan trọng: nếu T3 Code không phải harness thì T3 Code là gì? Theo nói sẽ trả lời câu đó sau một chút, vì đã có một "cliffhanger" khác đang chờ.

## 10. Dev mê tầng ngay trên tầng vừa chết

Như Theo nói lúc trước, các thứ ngày càng ít quan trọng khi đi lên chuỗi tầng, và theo anh (video đăng ngày 30/10/2026), kỹ sư thường mê tầng nằm ngay trên tầng vừa chết, ở gần thời điểm họ bước vào nghề.

Ai cũng từng nghe câu nói kinh điển rằng gu âm nhạc của bạn phản ánh rất rõ những gì bạn thích hồi trung học. Phần lớn những người có nhạc sĩ yêu thích có các nhạc sĩ yêu thích rất giống nhau ở tuổi 16 và tuổi 36. Dù tuổi đã tăng hơn gấp đôi, thứ bạn mê trong thời trung học và đại học vẫn cứ bám lấy bạn. Theo nói kỹ sư cũng vậy: tầng nào hết "ngầu" vào lúc bạn bước vào nghề, thì bạn sẽ rất mê tầng ngay phía trên nó (theo video đăng ngày 30/10/2026).

Anh nói nếu muốn một ví dụ tốt thì bạn đang nhìn thấy một ví dụ. Khi anh bước vào nghề phát triển phần mềm, ngành đang rời khỏi những cuộc chiến ngôn ngữ bất tận để sang một kỷ nguyên mới của cuộc chiến framework. Khi TypeScript trở thành tiêu chuẩn của ngành, khi ai cũng dùng nó, cuộc tranh cãi chuyển từ các "hương vị" và cú pháp khác nhau của JS sang các framework mà ta dùng để build. Khi YouTube của anh bắt đầu bùng nổ, chủ đề nóng là Next.js đấu SvelteKit đấu Solid.js đấu Nuxt (theo video đăng ngày 30/10/2026).

Anh nói chuyện đó có cảm giác như từ vài thập kỷ trước, trong khi thật ra mới khoảng hai năm, thậm chí chưa tới (theo video đăng ngày 30/10/2026). Và anh quan tâm rất nhiều tới chuyện đó vì đó là tầng đang trở nên thú vị hơn đúng lúc anh thật sự mê phát triển phần mềm. Thứ "ngầu" hồi anh học đại học là ngôn ngữ, nhưng ngôn ngữ khi đó đang dần lỗi thời. Tới lúc anh đi làm, framework là chủ đề của mọi cuộc trò chuyện. Nên đó là chỗ anh tập trung, chỗ anh nói nhiều nhất, nhiều tới mức bạn cùng phòng của anh bực mình, và anh bắt đầu làm video YouTube chỉ để xả về những chuyện đó.

Các tầng mà Theo kể mình đã đi qua (theo video đăng ngày 30/10/2026): từ cuộc chiến ngôn ngữ, sang cuộc chiến framework, sang cách định nghĩa hạ tầng cùng framework front-end, rồi tới làm việc với AI và agent.

Nhưng may là, vì một lý do nào đó (anh khá chắc là ADHD), anh rất thích khi những thay đổi này xảy ra. Khi trọng tâm của ngành dịch lên một tầng, anh rất phấn khích, vì anh mê abstraction. Anh thích cảm giác thấy mình ngốc. Anh thích học những thứ mới. Nên khi trọng tâm dịch khỏi React đấu Solid, nó bắt đầu chuyển sang cách ta định nghĩa hạ tầng đi cùng framework front-end: những thứ như Next và server components, đối lại với đủ thứ RPC điên rồ mà những người khác đang thử, server rendering, SSR, RSC, ISR, PPR, tất cả những thứ đó. Anh nói giai đoạn đó với anh rất vui (theo video đăng ngày 30/10/2026).

## 11. Từ backend tới AI, và cuộc trò chuyện với Boris

Rồi abstraction trở thành làm việc với AI và agent, và mọi chi tiết khác bắt đầu rơi rụng. Theo nói anh đã được chuẩn bị đặc biệt tốt cho chuyện này vì anh làm web dev, nơi mọi thứ thay đổi liên tục. Anh đã chuyển từ một dev backend viết Python, Ruby và Elixir cho Twitch và AWS, sang một "mọt" lập trình hàm TypeScript ở front-end, dạy cả Twitch làm nhiều lập trình hàm hơn ở front-end, rồi sang làm video YouTube, làm hạ tầng và đủ thứ điên rồ khác (theo video đăng ngày 30/10/2026).

Và anh kể một chuyện mà anh thấy là một trong những chuyện buồn cười nhất anh gặp gần đây (tính đến video đăng ngày 30/10/2026). Anh nói không có chỗ nào khác để kể nên sẽ kể luôn trong video này, sao lại không. Theo kể (video đăng ngày 30/10/2026) vài ngày trước anh có nói chuyện với Boris, người tạo ra Claude Code. Hai người chưa từng gặp nhau. Boris hoàn toàn biết anh là ai, và tất nhiên anh biết Boris là ai. Anh nói mình muốn bàn vài chuyện về web dev, và Boris rất bối rối.

Theo kể Boris là một trong những người "OG" của đội React và đã ở Meta trong những ngày đầu điên rồ của React. Boris cũng thân với nhiều người trong đội TypeScript ban đầu. Theo biết Boris từ quá khứ của Boris trong giới web dev. Còn Boris thì hoàn toàn không biết Theo là một web dev. Boris nghĩ Theo chỉ là "anh chàng làm AI", không hề có khái niệm rằng Theo từng là người làm nội dung về web dev, và rằng tới lúc đó anh đã làm việc với đội React core nhiều năm. Hai người có rất nhiều bạn chung. Số bạn thân của Theo từng được Boris phỏng vấn và tuyển vào Meta nhiều tới mức buồn cười. Vậy mà Boris không hề biết, vì đó không phải chủ đề lúc này (theo video đăng ngày 30/10/2026).

Theo nói chuyện này cũng phần nào cho thấy điều điên rồ ở đây: một người khác từng ở cùng giới với anh, và cả hai đều đã rời khỏi giới đó. Cả hai giờ đều không được biết tới vì chuyện web dev nữa (theo Theo, video đăng ngày 30/10/2026). Việc một người quan trọng như vậy trong giới đó, một người hùng thật sự của anh thời đó, không biết anh từng ở trong giới đó là điều rất lạ và gây sốc. Nhưng anh nghĩ nó cũng cho thấy các cuộc chuyển dịch này diễn ra nhanh tới mức nào: anh đã đi từ người không thể ngừng nói về server components tới mức, như anh nói, phải giải thích server components cho chính mẹ mình. Anh đã quan tâm quá nhiều tới những thứ đó. Và vài ngày trước, trong một cuộc gọi với mẹ, anh lại đang cố giải thích vì sao Gemini tụt lại xa như vậy (nhận định của Theo trong video đăng ngày 30/10/2026).

Anh nói: thứ anh mê là thứ anh mê, và thứ anh đang mê lúc này (video đăng ngày 30/10/2026) là chuyện này. Anh nhắc tới điều đó vì nó luôn khiến anh khó hoà hợp với nhiều kỹ sư, kể cả nhiều kỹ sư thật sự tài năng. Vì khi thấy abstraction xảy ra, anh phấn khích, bởi toàn bộ thời gian anh sống trong tầng hiện tại, dù vui và hào hứng tới đâu, cũng không còn quan trọng, vì có một tầng mới với khả năng cao sẽ xoá sạch tầng trước. Điều đó có nghĩa là anh được học lại. Anh được làm lại mọi thứ từ đầu.

Anh nói mình học được niềm yêu thích này ở một chỗ lạ: skateboarding. Anh xin phép kể một lần lạc đề kỳ quặc cuối cùng bằng một phép so sánh, và xin người xem chiều anh. Vì khi anh làm video về skateboarding thì chẳng ai quan tâm, nên nếu lén chèn được một đoạn rant từ 30 giây tới một phút về nó, anh sẽ làm khi có cơ hội (theo video đăng ngày 30/10/2026).

Anh hỏi chat: gõ 1 nếu bạn từng chạy điền kinh, dù chỉ một hai lần hồi trung học, từng chạy vòng quanh đường chạy. Tất nhiên nhiều người đã từng. Rồi gõ 2 nếu bạn từng nhảy qua rào, "cái thứ dựng đứng to to", anh nói biết nhiều người xem không nói tiếng Anh bản ngữ, nên giải thích là cái thứ to và phẳng mà bạn nhảy qua khi chạy trên đường đua. Anh thấy rất nhiều người gõ 2, vậy là nhiều người từng nhảy qua rào.

## 12. Lạc đề về skateboarding: nhảy rào và đổi chân

Theo bảo người xem hình dung trong đầu cảm giác đó. Cứ nhìn vào cái rào và tưởng tượng mình nhảy qua nó. Hình dung thật rõ: bạn bật bằng chân nào, chân nào đưa ra trước, vai đặt thế nào, cơ thể cảm thấy ra sao khi bay qua cái rào. Giờ bạn đã có hình ảnh đó trong đầu. Giờ thì đổi chân. Nếu bạn bật bằng chân trái với chân phải đưa trước, hãy đổi trong đầu sang chân trái đưa trước và bật bằng chân phải, và ngược lại nếu bạn làm theo kiểu kia. Hãy tưởng tượng việc đổi chân sẽ có cảm giác thế nào.

Anh hỏi chat: gõ 1 nếu thấy chuyện đó bình thường, gõ 2 nếu chỉ tưởng tượng dùng nhầm chân thôi đã thấy nhức đầu. Anh cảm ơn chat, và thấy rất nhiều số 2. Anh nói có thể đi rất sâu vào tâm lý chuyện chân nào quan trọng và mọi thứ kiểu đó, nhưng anh sẽ kể một điều thú vị: chuyện này không giống thuận tay trái hay tay phải, kiểu người thuận tay phải thì dùng chân phải, người thuận tay trái dùng chân trái. Theo lời anh (video đăng ngày 30/10/2026), thuận tay phải so với tay trái là tỷ lệ khoảng 6 trên 1, còn chân phải hay chân trái là chia đôi 50/50, chia đều hoàn toàn chuyện bạn bật bằng chân nào. Mỗi người mỗi khác.

Hai tỷ lệ Theo nêu khi nói về nhảy rào (theo lời anh, video đăng ngày 30/10/2026): thuận tay phải so với tay trái khoảng 6 trên 1, nhưng chân bật thì chia đều.

Trong skateboarding cũng có chuyện y như vậy. Theo nói anh đứng kiểu "goofy", tức anh trượt với chân phải ở trước. Rồi anh cho xem vài đoạn clip anh trượt: một chuyện sắp xảy ra ở đây, anh xoay 180 độ, giờ anh đang trượt ngược, và người xem có thể thấy vai anh khó chịu thế nào, nhưng anh vẫn làm được một cú laser flip, một trong những cú flip khó nhất. Anh cũng làm cú này theo kiểu switch, vì bình thường anh để chân phải ở trước, đó là một cú switch Casper flip. Anh nói mình thích làm những trick "goofy", không phải goofy theo nghĩa thế đứng của anh, mà là những trick ngớ ngẩn ở thế đứng ngược (theo video đăng ngày 30/10/2026).

Lý do nó được gọi là goofy, theo lời đồn mà Theo kể, là vì từ lâu có một đoạn phim Goofy của Disney cùng chuột Mickey lướt ván với chân phải đặt trước, nên người ta bắt đầu gọi đó là thế goofy (theo video đăng ngày 30/10/2026).

Anh kể chuyện này vì một hiện tượng lạ trong skateboarding. Trong phần lớn các môn thể thao, nhất là những môn như điền kinh, mục tiêu của bạn là giỏi nhất có thể bằng mọi giá. Nên nếu có một chân bạn bật tốt hơn, bạn nên luôn dùng chân đó. Còn trong skateboarding, bạn được thưởng vì học trick theo cả hai chiều, gọi là "switch". Khi bạn học một trick ở thế đứng thường, việc học nó ở thế switch là một kiểu khoe tay nghề. Anh so nó với một cầu thủ bóng rổ học ném ba điểm bằng cả hai tay cho vui, nhưng trong bóng rổ người ta sẽ cười bạn vì chuyện đó không đáng. Còn trong skateboarding, việc đó được đánh giá rất cao, là một trong những thứ đòi hỏi kỷ luật nhất trong skateboarding: có trick ở cả hai thế đứng (theo video đăng ngày 30/10/2026).

## 13. Switch, chuyên sâu một thứ, và TypeScript

Người ngoài giới skateboarding sẽ thấy điều đó và không quan tâm. Họ sẽ không hiểu bạn vừa làm việc đó khó hơn bốn lần bằng cách làm ngược. Nhưng với những người có quan tâm, đó là thứ ngầu nhất trên đời. Theo nói anh có thể nhận ra rất nhanh khi xem một người trượt làm trick xem đó có phải thế đứng thường của họ hay không, với anh đó là trực giác (theo video đăng ngày 30/10/2026).

Nếu bạn đã lập trình một thời gian, bạn cũng làm được điều tương tự. Lấy một lập trình viên viết JavaScript cả đời, bắt họ viết một app bằng Go, có lẽ họ làm được. Họ sẽ phải Google nhiều, và quan trọng nhất, bạn sẽ biết ngay, vì cú pháp họ viết trông giống JavaScript hơn nhiều so với phần lớn code Go. Phép so sánh này cũng đúng với người ngoài thế giới lập trình: nếu ai đó build một website rất hay rồi kể cho bạn, và bạn của họ bảo "hay quá, build cho tôi một thứ chạy trên máy Windows được không", và họ trả lời "không, xin lỗi, tôi chỉ biết build app iPhone", người bạn đó sẽ rất bối rối. Vì họ không thấy khác biệt giữa làm cho iPhone và làm cho máy Windows. Họ chỉ thấy bạn là người build (theo video đăng ngày 30/10/2026).

Trong skateboarding, một người có thể làm một trick với chân phải trước rồi làm cùng trick đó với chân trái trước, và với phần lớn mọi người nó trông chẳng khác gì. Nhưng với người trượt ván, đó là điều điên rồ không tưởng. Và nếu một lập trình viên tự tay viết cùng một app bằng năm ngôn ngữ, chẳng ai ngoài giới dev quan tâm. Nhưng dev sẽ nói: trời ơi, người đó là phù thuỷ. Nếu viết lại cùng một thứ bằng năm ngôn ngữ được thì họ thật sự hiểu nghề (theo video đăng ngày 30/10/2026).

Anh nhắc chuyện này vì nó không thực tế. Theo Theo (video đăng ngày 30/10/2026), với tư cách một software dev, bạn sẽ kiếm được nhiều tiền hơn nhiều khi trở thành người dẫn đầu ngành ở một công nghệ hay một thứ cụ thể, so với khi là một người tổng quát hơn. Nếu bạn rất giỏi JavaScript mà không biết gì về server, có lẽ bạn sẽ kiếm 500 nghìn đô một năm ở một công ty FANG cho tới khi quyết định nghỉ hưu (ví dụ của Theo trong video đăng ngày 30/10/2026). Chiều ngược lại cũng vậy. Một số dev tài năng nhất, và quan trọng hơn là được trả lương cao nhất mà anh biết, trông như chưa từng viết code bao giờ nếu bạn đặt họ vào một codebase React. Nhưng đặt họ vào một mớ C++ cổ lỗ như địa ngục, họ sẽ sửa được, làm nó nhanh hơn, và phát triển mạnh trong môi trường đó.

Vậy vì sao anh đi lạc đề về skateboarding lâu như vậy? Vì skateboarding dạy anh yêu những thứ chẳng có lý, những thứ không quan trọng ngoài niềm vui của chính anh. Khi anh học một trick theo kiểu switch, anh không làm vì gì khác ngoài chính mình. Và quan trọng hơn, anh làm chỉ vì cảm giác làm một việc khó hơn, làm nó dù nó thấy không tự nhiên. Anh dần yêu cảm giác "không tự nhiên" đó. Vì dù bạn giỏi kickflip tới đâu, bạn có thể làm cả triệu cú kickflip, nhưng nếu chưa bao giờ thử switch flip, bạn vẫn phải học từ đầu. Thật ra bạn còn tới một điểm mà càng làm kickflip thường, càng khó "đi lại dây" cho bộ não để làm ngược lại. Có một điểm rất khó khăn trên hành trình làm chủ một thứ, khi bạn đã thành thạo nó tới mức chuyển sang thứ khác trở nên khó hơn (theo video đăng ngày 30/10/2026).

Và có lẽ tất cả những người từng phàn nàn về "Theo, gã lập trình viên JS gà mờ" mà lại nổi tiếng, đã có lý ở đây. Vì không bao giờ quá giỏi một thứ, anh không bao giờ quá gắn bó với thứ đó. Nên khi có thứ mới xuất hiện, anh không ngại phủi tay và đi tiếp. Vì với anh, nó giống trượt ván switch: kickflip của anh giỏi tới đâu cũng không quan trọng, làm switch flip vẫn là học từ đầu (theo video đăng ngày 30/10/2026).

Theo Theo (video đăng ngày 30/10/2026), việc anh giỏi TypeScript tới đâu cũng không quan trọng nếu agent đang viết code cho anh. Anh giỏi Angular tới đâu cũng không quan trọng nếu React trở thành framework mới mà ai cũng dùng. Lập luận của anh về spaces hay tabs hay tới đâu cũng không quan trọng khi ai cũng dùng Prettier. Nhưng anh nói phần lớn mọi người không giỏi chuyện này. Phần lớn mọi người, đặc biệt là dev, khi đã chọn thứ mình quan tâm, sẽ quan tâm tới nó mãi mãi.

Ví dụ mà anh quen thuộc nhất là khi TypeScript bùng nổ. Anh từng ghét làm web dev, anh là một dev backend chính hiệu. Nhưng khi TypeScript xuất hiện, rồi React xuất hiện, rồi React trở nên thiên về lập trình hàm hơn, anh được bước vào mà không mang theo hành lý cũ nào. Anh chưa từng dành thời gian để thật giỏi và quen với JS. Nên khi TypeScript lấy nhiều thứ anh không thích ở JS và làm chúng dễ hơn, đáng tin hơn nhiều, anh không có chi phí chìm nào để tiếc. Anh chỉ việc bắt đầu dùng thứ tốt hơn và thấy nó tuyệt vời (theo video đăng ngày 30/10/2026).

Và anh thấy mình rất bực với những dev JS lâu năm, những người có cả lịch sử khoảng 10 năm chiến đấu với trình duyệt để biến JavaScript thành một ngôn ngữ dùng được. Theo kể (video đăng ngày 30/10/2026) nhiều người trong số đó thẳng thừng không chuyển sang TypeScript. Tới hôm nay, một nhóm nhỏ trong số đó vẫn cho rằng TypeScript là phí thời gian và năng lượng: nếu là dev tử tế, bạn chỉ cần dùng JavaScript để khỏi đưa đống tooling và hệ thống tệ hại này vào codebase, chúng chẳng làm gì cả. Theo Theo, TypeScript là một ngôn ngữ rất hữu ích, và nếu bạn nghĩ khác thì bạn không hiểu web.

## 14. Vim, model, harness: đường ranh lại dịch lên

Việc anh mới vào giới mà đã hiểu điều đó khiến anh rất khó trò chuyện, hay thật lòng mà nói là khó tôn trọng, những người đi trước không thể vượt qua chuyện thứ họ đã dồn bao thời gian vào không còn là chỗ đáng tập trung nữa. Theo Theo (video đăng ngày 30/10/2026), phần lớn dev chỉ trải qua tối đa một lần chuyển dịch kiểu này trong đời, nếu có. Họ thường ở lại chỗ họ thấy thoải mái và không bao giờ rời đi.

Anh đưa ra một ví dụ, và nói mình có thể sai, đây là cách chứng minh anh sai: anh cược rằng trong tất cả những người đang dùng Vim hôm nay, ít nhất một nửa vẫn sẽ dùng Vim sau năm năm nữa, và phần lớn trong số đó sẽ không còn làm software dev. Còn nửa rời Vim sẽ kiếm được nhiều tiền hơn đáng kể (dự đoán của Theo trong video đăng ngày 30/10/2026).

Anh nói đó không phải vì Vim tệ. Vim tuyệt vời. NeoVim là một công cụ xuất sắc, một cộng đồng xuất sắc. Mà là vì những người vẫn còn quan tâm tới kiểu chi tiết đó nhiều tới vậy đang bị kẹt. Họ bị mắc bẫy. Họ không thể rời thứ mà họ đã neo mình vào. Họ thật sự đã dựng nhà ở tầng đó. Còn nhiều người đã thoát ra thì hạ cánh ở một tầng mới (theo video đăng ngày 30/10/2026).

Theo quay lại sơ đồ các tầng và sửa thêm: anh đổi một dòng thành "Editor", phía trên đổi thành "LLM", và phía trên nữa đổi thành "Harness". Đường ranh đã tiếp tục dịch lên. Theo Theo (video đăng ngày 30/10/2026), rõ ràng chúng ta không còn thật sự quan tâm người khác dùng editor gì. Ngay cả hồi anh đang nổi lên, anh dùng VS Code và chỉ bị chê một chút, có người bảo anh nên dùng Vim, kha khá nhưng không nhiều. Giờ thì chuyện đó biến mất. Anh không nhớ lần cuối có người bảo anh nên dùng Vim là khi nào.

![Danh sách các tầng: Harness ở trên đường kẻ ngang có mũi tên chỉ vào, dưới đường kẻ là LLM, Editor, Architecture, Languages, Frameworks, Fundamental algos, Patterns for defining functions, Tabs vs spaces, Instructions](https://homus.dev/photos/ebILGCoN4UU-3903.jpg)

Chồng tầng sau khi Theo sửa (theo video đăng ngày 30/10/2026): đường kẻ giờ nằm ngay dưới Harness, còn LLM, Editor, Architecture, Languages, Frameworks và các tầng cũ nằm dưới đường kẻ.

Theo Theo (video đăng ngày 30/10/2026), dùng model nào thì vẫn còn quan trọng, nhưng ai cũng đổi model liên tục. Anh cho rằng nếu bạn là một người trung thành cứng nhắc với một họ model, bạn cũng "toang" y như mấy người dùng Vim. Nếu bạn từ chối dùng bất cứ thứ gì ngoài model Codex, hay bất cứ thứ gì ngoài model Claude, bạn sẽ gặp khó. Có lẽ lúc này bạn vẫn ổn nếu chỉ dùng Claude, vì họ model này đang rất tốt tính đến video đăng ngày 30/10/2026, nhưng điều đó có thể thay đổi bất cứ lúc nào, và anh nói có khi tới lúc video ra mắt thì nó đã đổi rồi.

Rất nhiều người đã chọn cắm chân ở tầng này. Theo dựng lại những câu kiểu: "Trời, năm 2024 rồi mà anh vẫn dùng VS Code à? Dev thực thụ chuyển hết sang NeoVim rồi." Và giờ: "Trời, năm 2026 rồi mà anh vẫn dùng Claude Code à? Anh không biết Pi hiệu quả hơn sao? Anh chưa thử Oh My Pi à? Nó làm model ngu thông minh hơn hẳn. Anh chỉ là nô lệ của các lab nếu nghĩ Claude Code đáng dùng." Theo nói đó là chỗ chúng ta đang đứng lúc này (theo video đăng ngày 30/10/2026).

## 15. Effect, câu của Michael Arnaldi, và skill biến mất khi đổi sang Codex

Theo nói thật lòng, sáu tháng trước anh đã sẵn sàng tham gia cuộc trò chuyện đó. Khi đó có một cuộc trò chuyện đáng có về harness. Lúc này anh vẫn có thể nói một phần của nó. Anh có thể làm một video hơn hai tiếng về những khác biệt nhỏ giữa các harness. Anh có thể rant rất dài về "mớ hỗn độn" là system prompt của Codex và việc nó làm các model bị "cắt não" và tệ hại thế nào (nhận định của Theo trong video đăng ngày 30/10/2026). Nhưng anh sẽ không làm vậy, vì theo anh chuyện đó chẳng còn quan trọng mấy nữa.

Rồi anh muốn nói về Effect một chút (theo video đăng ngày 30/10/2026). Anh biết nghe có vẻ điên rồ, nhưng hãy nghĩ về kiểu người sẽ tạo ra Effect. Đó có phải kiểu người thích liên tục rời khỏi thứ hay tầng mình đang ở? Hay kiểu người thích tinh chỉnh tầng mình đang ở và đánh bóng nó mãi không ngừng? Đó là kiểu người sẽ dành cả sự nghiệp để làm plugin cho NeoVim, hay kiểu người sẽ rời NeoVim ngay khi có thứ tốt hơn xuất hiện trước mặt?

Anh hỏi vậy vì chính anh đã trả lời sai. Anh từng mặc định rằng nếu bạn hiểu các sắc thái của các protocol trong ngôn ngữ TypeScript tới mức như đội Effect, và cố build ngôn ngữ của riêng mình bên trong ngôn ngữ đó, thì bạn là kiểu người sẽ không bao giờ rời tầng mình đang ở. Anh không thể sai hơn được nữa (theo video đăng ngày 30/10/2026).

Bài đăng thật sự đã truyền cảm hứng cho video này là của Michael Arnaldi, người tạo ra Effect. Trên X, ngày 14/10/2026, Michael viết rằng từ khi bắt đầu dùng T3 Code, anh ấy không còn quan tâm harness nào đang được dùng, thậm chí rất muốn bỏ hết tất cả và chỉ dùng "clanka" của một người bạn. Theo nói điều Michael muốn nói là anh ấy không còn quan tâm nữa. Theo nói mình đã có cảm giác này một thời gian, nhưng chưa bao giờ diễn đạt nó đơn giản như vậy (theo video đăng ngày 30/10/2026).

Và anh đã nghĩ về chuyện này nhiều hơn vì anh nhận được rất nhiều câu hỏi từ những người rất bối rối khi dùng T3 Code. Theo kể (video đăng ngày 30/10/2026): họ dùng Claude trong T3 Code và nó chạy đúng như họ mong đợi. Rồi họ chuyển sang Codex và không thấy skill nào của mình. Rồi họ vào phần settings trong T3 Code và không thấy mục skills. Rồi họ spam tin nhắn riêng của anh: "Theo, cái quái gì vậy? Skill của tôi không chạy trong Codex." Anh hỏi lại: bạn đã thêm skill vào Codex chưa? Họ trả lời: không, lẽ ra nó phải tự chạy chứ, với Opus thì chạy ổn mà.

Theo nói những người này thậm chí không còn nhận ra harness nữa. Harness không tồn tại với họ, giống như khi ai đó dùng Twitter thì React Native Web không tồn tại. Phần lớn mọi người thậm chí không biết Twitter dùng React Native Web, ngay cả dev cũng không biết (theo Theo, video đăng ngày 30/10/2026). Người dùng T3 Code, dù là dev, không hiểu rằng cái model picker thật ra không phải model picker, mà là một harness picker.

Quay lại phép so sánh căn bếp: theo Theo (video đăng ngày 30/10/2026), T3 Code không phải một căn bếp. T3 Code là một khu ẩm thực trong trung tâm thương mại, nơi bạn chọn đi vào bếp nào. Và nếu bạn vào Panda Express mà gọi một cái burrito, bạn sẽ bối rối. Đó là chỗ chúng ta đang đứng lúc này.

Phép so sánh của Theo (video đăng ngày 30/10/2026): T3 Code là khu ẩm thực nơi bạn chọn bếp; skill thêm vào bếp Claude Code không tự có trong bếp Codex.

Nhưng anh cũng nhận ra giờ đây đó cũng là vấn đề của anh (theo video đăng ngày 30/10/2026). Khi mọi người thôi quan tâm tới các căn bếp, anh giờ phải cung cấp mọi thứ mà mọi căn bếp có thể cung cấp, nếu không mọi người sẽ giận anh.

## 16. Cái hộp người dùng đang đổi, và harness gắn chặt với model

Theo nói đó là thứ làm cuộc sống anh gần đây (tính đến video đăng ngày 30/10/2026) rối một cách kỳ lạ: số người nhìn Codex hay Claude Code như một harness có những thứ nhất định bên trong, như plugin hay skill. Họ chuyển từ Claude Code sang T3 Code, rồi thêm Codex vào T3 Code, và những thứ của Claude không có ở đó. Lý do, theo Theo, là trong đầu họ, họ đang đổi thứ nằm bên phải trong sơ đồ nhỏ của anh. Họ nghĩ họ đang đổi cái này. Trên thực tế, thứ họ đang dùng là một cái hộp gồm LLM, harness và interface. Và thứ họ đổi không phải cả cái hộp.

![Sơ đồ với khung lớn bao quanh Interface, Harness và LLM; trên Interface ghi Youtube.com, Twitch.tv; trên Harness ghi Agent SDK](https://homus.dev/photos/ebILGCoN4UU-4243.jpg)

Theo vẽ khung lớn bao quanh Interface, Harness và LLM (theo video đăng ngày 30/10/2026): người dùng thật ra đang dùng cả cái hộp đó. Phía trên Interface vẫn ghi Youtube.com, Twitch.tv, phía trên Harness ghi Agent SDK từ trò chơi đoán lúc trước.

Họ chỉ đổi phần interface sang T3 Code. Rồi họ bối rối vì sao mọi thứ họ làm ở đây không đi theo sang các harness khác mà họ chưa từng đụng tới. Và nhận định "nóng" nhất của anh ở đây là chuyện này là một điều tích cực (theo Theo, video đăng ngày 30/10/2026). Nó sẽ cho phép anh và nhóm, những người tạo ra T3 Code, làm ra một trải nghiệm được trừu tượng hoá, giống như cách bạn chỉ việc đổi chuỗi tên model hay đổi API bạn đang gọi. Bạn nên có thể chỉ việc đổi harness đang dùng mà không thấy quá tệ.

Theo kể (video đăng ngày 30/10/2026) anh biết rất nhiều người từng dùng model OpenAI rất nhiều và đã gắn sâu với Codex, rồi chuyển sang Claude Code vì Opus 5.5 "không thể tin nổi" và rất đáng tiền. Giờ họ phải đổi rất nhiều thứ họ đã quen, và họ rất bối rối, khó chịu. Họ chuyển sang T3 Code, và giờ họ có thể đổi qua lại giữa Claude Code và Codex chỉ bằng một cú bấm nút. Và khi model tốt hơn, thông minh hơn, harness sẽ ngày càng vô hình trong quá trình đó.

Vì đây mới là "spoiler" thật sự, theo Theo (video đăng ngày 30/10/2026): harness và model đang ngày càng gắn chặt với nhau. Trước đây, model có những khả năng nhất định và có khái niệm tool calling được huấn luyện vào, rồi harness được điều chỉnh để làm việc quanh model. Giờ thì model đang được huấn luyện trên dữ liệu từ harness. Nên model Claude thường thật sự chạy tốt hơn trong Claude Code. Model OpenAI lẽ ra cũng phải chạy tốt hơn trong Codex, nhưng system prompt và hệ sinh thái của Codex là một mớ hỗn độn nên chúng không chạy tốt hơn (nhận định của Theo trong video đăng ngày 30/10/2026).

Nếu OpenAI đuổi kịp thành công, kết quả sẽ là Codex tốt hơn hẳn Claude Code cho các model của OpenAI. Điều đó có nghĩa là, theo Theo (video đăng ngày 30/10/2026), chúng ta không nên nghĩ về harness, cũng như ta không nghĩ về căn bếp khi tới một nhà hàng. Ta chỉ nên tới chỗ có món ăn mình muốn. Ta chỉ nên chọn lựa chọn có khả năng mình muốn, ở mức giá mình muốn.

Và lý do anh phàn nàn về tất cả những chuyện này là vì "dân harness", những người quan tâm quá nhiều tới việc mình dùng harness nào, những người chế giễu bạn là kẻ ngốc vì dùng Claude Code hay Codex. Theo nói chính anh cũng là một người như vậy. Anh từng nghĩ rất kỹ, quá kỹ, và giải thích chi tiết vì sao nên dùng Claude Code cho gói Codex của bạn chứ không dùng Codex cho gói Codex. Anh vẫn còn setup đó. Nhưng anh không dùng nó nhiều, vì thực tế là khoảng cách giữa Claude Code và Codex khi dùng model Codex là khoảng 3 tới 5 phần trăm, có lẽ vậy, và nó bị san phẳng (theo đánh giá của Theo trong video đăng ngày 30/10/2026). Anh không quan tâm. Nếu khác biệt lớn hơn thế, đó là một thất bại ở tầng LLM và sẽ được xử lý.

## 17. Con đường khó, và T3 Code là gì: IDE hay ADE

Theo nói làm cho harness không còn quan trọng không chỉ là mục tiêu của riêng anh, và đây không phải một thiên kiến kỳ quặc nào đó của anh. Thật ra anh không có thiên kiến đó. Nếu harness quan trọng, anh có thể build một harness thật tốt và giành được nhiều người dùng theo cách đó. Nhưng theo anh (video đăng ngày 30/10/2026), harness không quan trọng, nên anh làm một việc khó hơn nhiều. Anh nói OpenCode dễ build hơn T3 Code nhiều vì lý do này, vì OpenCode không phải làm mọi thứ chạy được với từng cách hành xử kỳ quặc của mọi tool hay mọi harness.

Anh hỏi: bạn có biết code của anh và nhóm để quản lý mọi loại sub-agent khác nhau trên mọi harness phức tạp tới mức nào không? Nó rất khổ, nhưng anh và nhóm phải làm vì đã chọn con đường khó. Con đường khó đó là con đường mà harness không quan trọng với người dùng T3 Code, mà chỉ là chi tiết cài đặt đối với anh và nhóm (theo Theo, video đăng ngày 30/10/2026).

Nên gửi tới mọi người đang spam anh rằng anh phải thử harness của họ vì nó benchmark tốt hơn Claude Code nhiều: Theo chúc mừng chiến thắng 3% của họ với một model đời trước, hoặc với một model open weight không được huấn luyện trên Claude Code. Anh nói anh thật sự mừng cho họ. Anh mừng là họ có thể tiêu nhiều tiền hơn gói đăng ký của anh để có ít token hơn và làm được ít việc hơn. Anh nói thật ra anh có phần mừng cho họ, vì họ có vẻ vui. Tốt, hay, tuyệt. Còn anh tập trung vào việc làm việc hiệu quả, và theo anh (video đăng ngày 30/10/2026), nghĩ quá nhiều về harness sẽ không làm bạn hiệu quả hơn mấy.

Theo nói suýt nữa anh quên mất đã hứa trả lời câu hỏi này: T3 Code là gì? Theo Theo (video đăng ngày 30/10/2026), nó phần nào là một interface, nhưng nó giao tiếp với cả con người lẫn harness. Nó không giao tiếp trực tiếp với LLM, nhưng có kết nối tới harness và làm việc ở đó. Nó có hiển thị thứ cho bạn với tư cách người dùng và cho phép bạn làm việc. Nó cũng cho phép điều khiển từ xa trên nhiều máy, quản lý môi trường, cập nhật mọi harness của bạn từ xa, và đủ thứ hay ho khác.

Ngày xưa có một thuật ngữ cho lúc trình soạn thảo văn bản bắt đầu có ngày càng nhiều thứ giúp việc sửa code tốt hơn. Vì bạn có thể sửa code trong Notepad, nhưng nó thiếu nhiều thứ ta mong đợi, dù là syntax highlighting, các công cụ đơn giản để chạy test và xem kết quả, hay hỗ trợ LSP inline để nhận phản hồi từ language server, những thứ kiểu đó. Thứ đó được gọi là IDE, integrated development environment (theo video đăng ngày 30/10/2026).

![Bảng vẽ ghi What is T3 Code?, bên dưới là IDE, Integrated Development Environment](https://homus.dev/photos/ebILGCoN4UU-4703.jpg)

Theo viết "IDE, Integrated Development Environment" dưới câu hỏi "What is T3 Code?" trên bảng vẽ, trước khi đưa ra thuật ngữ anh dùng cho T3 Code (theo video đăng ngày 30/10/2026).

Vậy T3 Code là gì? Theo nói nó phần nào giống một IDE, nhưng thuật ngữ này giờ có một nghĩa rất cụ thể: công cụ bạn viết code trong đó, chạy code trong đó và làm nhiều thứ khác trong đó. Theo Theo (video đăng ngày 30/10/2026), T3 Code không phải IDE. Nó là một ADE, an agentic development environment. Và anh nghĩ đây là thứ gần nhất mà chúng ta có lúc này để làm thuật ngữ mô tả đúng các công cụ đang được bàn tới.

## 18. ADE, Antigravity, và lời kết

Và giống những gì anh nói lúc trước, Theo nói anh cũng dự đoán ADE sẽ thôi là thứ "hot", giống như IDE của bạn, dù là Vim, NeoVim, Emacs, VS Code hay thứ gì khác, đã thôi "ngầu". Theo Theo (video đăng ngày 30/10/2026), có lẽ chúng ta đã qua cái dốc đó một chút, thậm chí có thể đã sang bên kia, nơi người ta sẽ ngày càng ít quan tâm tới thứ mình mở lên và dùng, vì họ sẽ chỉ prompt trong Slack.

![Toàn cảnh bảng vẽ: Tool plane ghi Code that runs in the harness, hàng Human, Interface, Harness, LLM ở giữa, Data plane ghi Code that runs somewhere else](https://homus.dev/photos/ebILGCoN4UU-4843.jpg)

Toàn cảnh bảng vẽ "wtf is a harness" ở cuối video (theo video đăng ngày 30/10/2026): Tool plane ghi "Code that runs in the harness", Data plane ghi "Code that runs 'somewhere else'", ở giữa là Human, Interface, Harness và LLM.

Nhưng anh muốn một ADE tốt. Anh muốn nó rất nhiều. Theo kể (video đăng ngày 30/10/2026) anh đã "phát điên" từ tháng 12, khi được nếm thử thứ Google đang nấu với Antigravity. Có một chút xíu trong đó tốt, còn mọi thứ khác là rác. Anh muốn một thứ tốt, mã nguồn mở và tuỳ biến được. Đó là lý do anh làm T3 Code. Nhưng anh không làm nó vì muốn làm một harness. Anh chưa bao giờ muốn làm một harness, và sẽ không bao giờ muốn. Anh đã làm nhiều harness "giả" để benchmark, nhưng chỉ vậy thôi.

Anh chỉ muốn một công cụ mã nguồn mở điều khiển công việc AI của anh. Thứ anh tương tác, công cụ anh chạm vào, phải mở và tuỳ biến được để anh tự sửa được. Nên theo Theo (video đăng ngày 30/10/2026), T3 Code là một ADE, và anh đoán ADE sẽ thôi quan trọng trong tương lai rất gần, giống mọi thứ khác. Nhưng lúc này, anh quan tâm. Anh quan tâm rất nhiều.

Theo nói anh nghĩ mình đã nói hết những gì cần nói. Anh đã viết quá nhiều về chủ đề này, và đã vẽ quá nhiều về chủ đề này, vì anh không muốn nói về harness nữa. Và nếu các lab làm tốt việc của mình, anh sẽ không phải nói về harness nữa, vì harness sẽ chỉ là một phần trong cách các hệ thống vận hành (theo Theo, video đăng ngày 30/10/2026). Nếu anh lại phải nói về harness, khả năng cao là vì ai đó đã làm hỏng việc gì đó rất nặng.

Anh nói đó là tất cả những gì anh muốn nói về chủ đề này, và anh thật sự mong có thể khép nó lại một lần cho xong. Anh nói mình rất mệt, và nếu người xem cũng mệt thì anh xin lỗi. Anh đã nói những gì cần nói. Anh xong rồi. Anh chào: "until next time, peace nerds."

## Nguồn và liên kết

- Tên gốc: My last video about ai harnesses
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=ebILGCoN4UU](https://www.youtube.com/watch?v=ebILGCoN4UU)

- Kênh YouTube Theo - t3․gg (Theo Browne): [youtube.com/channel/UCbRP3c757lWg9M-U7TyEkXA](https://www.youtube.com/channel/UCbRP3c757lWg9M-U7TyEkXA)

- Bài viết "What is a "harness"?" của Theo trên blog [t3.gg](https://t3.gg), đăng ngày 22/10/2026 (đọc ngày 03/11/2026): [t3.gg/blog/post/what-is-a-harness](https://t3.gg/blog/post/what-is-a-harness)

- Claude Code Docs, trang Agent SDK overview với bảng so sánh Agent SDK, Claude Code CLI, Client SDK và Managed Agents mà Theo mở trong video (đọc ngày 03/11/2026): [code.claude.com/docs/en/agent-sdk/overview](https://code.claude.com/docs/en/agent-sdk/overview)

- T3 Code, trang chính (đọc ngày 03/11/2026): [t3.codes](https://t3.codes) · repo: [github.com/pingdotgg/t3code](https://github.com/pingdotgg/t3code)

- CUA, bộ công cụ computer use mã nguồn mở mà Theo nhắc tới (đọc ngày 03/11/2026): [github.com/trycua/cua](https://github.com/trycua/cua)

- Effect, thư viện TypeScript do Michael Arnaldi tạo ra (đọc ngày 03/11/2026): [effect.website](https://effect.website)

Nguồn: https://homus.dev/talks/my-last-video-about-ai-harnesses · cập nhật 2026-11-03