# Cho agent hill climb tới khi UI thật sự đẹp

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

> Theo Browne dùng skill council gồm nhiều model chấm điểm ảnh UI rồi cho agent sửa tới khi đạt 9, 9.5 và 10 trên 10, kể cả chi phí và một eval MCP.

Topics: Coding Agents, AI UX, Evals

Canonical: https://homus.dev/talks/agents-sucked-at-ui-until-today

## 1. Lời chê UI của T3 Code và "người làm UI" tên Claude

Theo Browne mở đầu bằng một bài đăng trên X của Robin: vẫn không thích và không dùng T3 Code, và ước gì anh thuê một người làm UI hay UX. Theo đáp lại (video đăng ngày 03/11/2026): có tin cho Robin đây, anh và nhóm đã thuê rồi. Người đó thật ra đã ở trong team khá lâu, một anh chàng hơi kỳ quặc, rất nhiều lời. Tên anh ấy là Claude. Anh ấy là người Pháp. Anh ấy đúng là có một không hai.

![Theo Browne ngồi sau bàn gỗ, trước micro, bên cạnh là laptop và một chiếc cốc](https://homus.dev/photos/xq0eB8vxeqk-0007.jpg)

Theo Browne mở đầu video đăng ngày 03/11/2026 về chuyện làm cho agent thiết kế UI tốt hơn.

Theo nói nếu bạn nhìn T3 Code và nghĩ giống Robin, rằng T3 Code trông không dễ chịu lắm và cần một lượt làm lại UI hay UX, thì anh hiểu, anh đồng cảm. Theo lời anh (video đăng ngày 03/11/2026), anh và nhóm không có một người làm UI/UX toàn thời gian, và có lẽ nên có nếu có tiền.

Nhưng anh và nhóm không có tiền. Theo lời Theo (video đăng ngày 03/11/2026), T3 Code là một dự án open source; bạn không thể trả tiền cho anh và nhóm để dùng nó. Điều tốt nhất bạn có thể làm là trả tiền cho OpenAI và Anthropic để dùng nó, vì bạn phải tự mang tới một nguồn inference, thường là một subscription. Anh nói T3 Code chắc chắn là nơi tốt nhất để dùng subscription Claude Code của bạn.

Từ đó anh đặt câu hỏi (video đăng ngày 03/11/2026): liệu anh có dùng subscription của mình trong T3 Code để làm cho T3 Code trông như thể có một người làm UI toàn thời gian không? Liệu anh có lấy những khả năng mà model đã cho thấy ở mức rìa ngoài cùng, rồi dựng một thứ gì đó để lấy được code UI tốt từ các model này không? Câu trả lời, theo anh, là có thể, vì anh đã dành gần hết ngày hôm trước buổi quay để dựng agent làm UI tốt hơn.

## 2. Không thêm skill, không thuê designer: biến nó thành một hill climb

Theo nói (video đăng ngày 03/11/2026) anh không làm việc này bằng cách thêm cả đống skill. Anh cũng không trả tiền cho một designer ngồi nhìn mọi output và giúp model làm tốt hơn. Anh làm bằng cách biến nó thành một hill climb.

Theo số đo của Theo (video đăng ngày 03/11/2026), sau khoảng 18 giờ, qua năm model, hơn 30 vòng review và đủ thứ lộn xộn khác xen giữa, anh nghĩ mình đã có một công thức lấy được UI tốt cho sản phẩm thật từ một agent, và nó trông chẳng giống gì với điều anh từng nghĩ. Đây vốn chỉ là một thí nghiệm cho vui, nhưng giờ thì không còn là vậy nữa.

Theo anh (video đăng ngày 03/11/2026), kết quả là một setting trong tab Beta của T3 Code, bạn bật lên để thử thiết kế mới và chuyển qua lại giữa thiết kế cũ và mới. Một vài thay đổi của thiết kế mới đã lọt ra ngoài, nên chúng xuất hiện dù bạn có bật toggle hay không, nhưng phần lớn là do toggle đó điều khiển.

![Trang Settings, mục Beta của T3 Code với các dòng New design, Working section và Guest links](https://homus.dev/photos/xq0eB8vxeqk-0203.jpg)

Trang Settings / Beta của T3 Code trong video đăng ngày 03/11/2026. Dòng "New design" ghi "Try the quieter design: gray sidebar icons, dimmer read threads, and simpler composer controls."; bên dưới là "Working section" và "Guest links".

Anh nói anh muốn giải thích mọi thứ dẫn tới kết quả này: cái gì hiệu quả, cái gì không, và cách bạn dùng kiểu kỹ thuật hill climbing này để lấy giá trị thật từ agent của mình (theo video đăng ngày 03/11/2026).

## 3. Mọi chuyện bắt đầu trên X

Theo nói đây sẽ là một lần đi sâu vui vẻ vào cách bộ não hỗn loạn của anh vận hành bây giờ, vì anh đã "token maxing" quá nhiều. Anh xếp video này vào loại "tôi tiêu token để bạn khỏi phải tiêu" (video đăng ngày 03/11/2026).

Và theo anh, những chuyện kiểu này thường bắt đầu ở cùng một chỗ: Twitter. Lần này nó bắt đầu khi một người khác đăng một bài khá táo bạo, nói T3 Code được dựng để thành VS Code của thế hệ này. Theo nói (video đăng ngày 03/11/2026) đó là điều anh từng hy vọng sẽ xảy ra, không nhất thiết với T3 Code, mà là sẽ có một chuẩn mở tốt để làm việc với agent. Anh không nghĩ anh và nhóm sẽ là người làm ra nó; anh nghĩ có lẽ anh và nhóm chỉ góp phần truyền cảm hứng cho ai đó làm. Việc anh và nhóm làm được, theo anh, thật tuyệt và anh rất phấn khích. Nhưng khi thấy câu trả lời của Robin dưới bài đó, anh biết mình phải làm gì đó.

Anh bắt đầu bằng một câu đùa kinh điển: anh sẽ thuê chính Robin làm việc đó và trả cho Robin 100% doanh thu hiện tại của T3 Code. Vì, như nhiều người có thể biết hoặc không, T3 Code hoàn toàn miễn phí và open source, anh và nhóm không có doanh thu nào (theo video đăng ngày 03/11/2026). Một thoả thuận cả đời mới có một lần.

Theo thừa nhận anh hơi phòng thủ trong câu trả lời của mình, khi nói rằng hiển nhiên anh và nhóm có thể cải thiện UI. Anh biết UI của mình tệ, vì anh biết trước đây nó còn tệ hơn bao nhiêu, nhưng nó vẫn chưa tới mức cần có (video đăng ngày 03/11/2026). Anh viết rằng anh nghĩ Robin đang bi quan hoá khá nặng, rằng mọi môi trường dev dạng agentic đều có những mảng UI thô ráp, và ít ra T3 Code còn tương đối nhất quán. Anh cũng bảo Robin thử lại nếu một thời gian chưa dùng, vì Orchestrator V2 đã sửa rất nhiều chỗ về độ hoàn thiện.

Robin trả lời rằng mình muốn thích nó, và cứ vài tuần lại cài lại, nhưng phông chữ, border radius, icon, thứ bậc phông chữ thì không được; Theo đọc thêm câu "đây rõ ràng là phần designer cũ trong tôi, nhưng tôi không chịu nổi" (video đăng ngày 03/11/2026). Robin cố thuyết phục Theo thuê người cho việc đó. Theo trả lời: hoan nghênh PR. Robin nói ước gì mình làm được, và đang nghĩ về chuyện đó, có thể. Thế là Theo nói: để xem chuyện này đi tới đâu.

Chuỗi trao đổi trên X mà Theo kể trong video đăng ngày 03/11/2026, từ bài đăng về T3 Code tới lúc anh chụp lại cuộc trao đổi và gõ /goal.

## 4. Prompt /goal: làm UI tới khi council chấm 9 trên 10

Theo chụp màn hình cuộc trao đổi, rồi gõ /goal. Theo anh, cách nhanh nhất để đốt một đống token mà chẳng thu được gì là thêm /goal vào đầu prompt. Theo anh (video đăng ngày 03/11/2026), anh vẫn phần lớn tin đó là một lời khuyên đúng, nhưng chủ yếu vì nếu bạn bỏ /goal đi và viết đúng prompt, nó cũng sẽ làm được điều tương tự.

Anh làm vậy vì có token để đốt: anh sắp có vài lần reset usage mà anh chưa chuẩn bị để dùng. Và anh chỉ tò mò xem chuyện gì sẽ xảy ra (video đăng ngày 03/11/2026). Anh dặn cụ thể: làm cho UI được Robin duyệt, trông đẹp hơn hẳn và dễ nhìn hơn; cứ làm tới khi council đồng ý rằng một bộ ảnh chụp màn hình của app đạt ít nhất 9 trên 10 về chất lượng thiết kế; tạo một PR mới cho "UI polish overhaul" và tiếp tục lặp tới khi cả council hài lòng.

Prompt trên màn hình, kèm hai ảnh chụp cuộc trao đổi:

```
/goal Make the UI robin-approved. Should look way better and easier on the eyes. Go at it until the council all agree that a set of screenshots of the app are at least a 9 out of 10 in terms of design quality

Make a new PR for "UI polish overhaul", and keep iterating until you have made the whole council happy.
```

![Prompt /goal trong T3 Code kèm hai ảnh chụp cuộc trao đổi trên X, bên dưới là dòng Goal set](https://homus.dev/photos/xq0eB8vxeqk-0643.jpg)

Prompt /goal trong T3 Code, hiện trong video đăng ngày 03/11/2026, với hai ảnh chụp cuộc trao đổi trên X đính kèm; bên dưới, agent xác nhận "Goal set" với đúng nội dung đó.

## 5. Skill council trong tstack

Nếu bạn chưa biết council là gì, Theo giải thích (video đăng ngày 03/11/2026): đó là một skill mới anh vừa thêm vào bộ skill của mình. Anh nói anh chưa công bố, nhưng tstack giờ đã có: rất tối giản, chưa có gì nhiều, nhưng đã có một nhóm skill của anh, trong đó có skill council. Trên GitHub, repo tstack mô tả: "The agent skills I use every day, cleaned up so anyone can use them. They work in Claude Code and Codex." (màn hình trong video đăng ngày 03/11/2026).

Skill council, theo lời Theo (video đăng ngày 03/11/2026), gọi ba delegate vào giúp với yêu cầu của người dùng, thường là để review hay góp ý, dùng một model mạnh từ mỗi nhà cung cấp trong ba nhà cung cấp khác nhau. Anh viết vậy vì muốn bản công khai chung chung hơn. Thật ra anh không muốn nó chung chung tới thế, và có lẽ sẽ vào sửa lại cho phù hợp. Bản của riêng anh ít chung chung hơn nhiều.

Một đoạn của file SKILL.md bản công khai trên màn hình:

```
Bring in three delegates to help with the user's request, usually for review or feedback. Use one strong model from each of three different providers, at high reasoning effort. If the user's instructions name council members, use those. Otherwise pick the latest flagship model from each provider, for example Claude Opus, GPT Sol, and Gemini Pro.

In T3 Code, use orchestrator_capabilities to resolve the models, then delegate_task to start one delegate per model in parallel. Elsewhere, use the harness's subagent tools. If you cannot reach three providers, or a named member is unavailable, report it instead of substituting.

Give each delegate the request and relevant context. For review or feedback, keep their work read-only. Collect their responses and summarize the useful findings, disagreements, and recommended next steps.

For a code review, ask each delegate for a score out of 10. Count each full review pass as one round. A fresh review after fixes starts a new round.

If the work ends in a pull request, put the results in the PR description. Put this section before the model and harness line at the end:
```

![File SKILL.md của skill council trên GitHub, phần Council](https://homus.dev/photos/xq0eB8vxeqk-0703.jpg)

Skill council bản công khai trên GitHub, hiện trong video đăng ngày 03/11/2026: name "council", description "Trigger this if the user says 'council'.", rồi các đoạn hướng dẫn gọi ba delegate và chấm điểm theo vòng.

Rồi anh mở bản anh đang dùng (video đăng ngày 03/11/2026). Ở đầu có dòng chỉ dùng skill này từ Claude Code, Codex hoặc Muse, và màn hình ghi thêm phần dừng lại nếu đang chạy dưới Antigravity. Anh nói có lẽ nên bỏ dòng đó, nó không quan trọng lắm; lý do có nó, anh nói, bạn sẽ thấy ngay sau đây. Bản này gọi ba delegate với tên cụ thể; trên màn hình là Claude Opus 5.5, Muse Wonder Full và Codex GPT-6.1 Sol, cả ba ở mức `xhigh`.

Theo nói (video đăng ngày 03/11/2026) anh ghi rõ cách làm việc này trong T3 Code; nếu bạn không dùng T3 Code thì chúc may mắn khi tự tìm cách làm cho đúng, vì anh đã bỏ rất nhiều công sức vào đó. Phần còn lại như bản công khai: đưa cho mỗi delegate yêu cầu và context liên quan; với review hay góp ý thì giữ phần việc của chúng ở chế độ read-only; gom câu trả lời và tóm tắt các phát hiện hữu ích, các điểm bất đồng và bước tiếp theo nên làm. Với code review, hỏi mỗi delegate một điểm trên 10, mỗi lượt review đầy đủ tính là một vòng, một lần review mới sau khi sửa bắt đầu một vòng mới.

## 6. Hill climb dễ kiểm và hill climb theo cảm nhận

Theo tóm lại cách council chạy (video đăng ngày 03/11/2026): mỗi model cho điểm, và mỗi vòng bạn hy vọng điểm tăng. Cuối cùng, bạn sẽ khiến mỗi model cho một điểm đủ cao để bạn hài lòng và có thể ship.

Anh nói anh làm skill này vì đã chán việc cứ phải bảo agent đi gọi GPT-6.1 Sol hay Muse. Trước đó anh chỉ có Sol loop, nơi Sol góp ý code thật gắt cho tới khi cuối cùng nó nói kiểu "vậy là ổn". Council thì là góp ý theo cảm nhận hơn: anh muốn Claude Code, Codex và Muse đều nói kiểu "ừ, chắc là ổn", hoặc "tôi thật sự thích cái này". Theo lời Theo (video đăng ngày 03/11/2026), anh chủ yếu dùng nó cho code và để thẩm định các bản implement; anh không biết nó sẽ hoạt động thế nào với UI, nên mới tò mò.

Ý tưởng hill climbing ở đây, theo anh, không phải kiểu "làm cho test này pass" hay "làm cho hàm này nhanh gấp năm lần", một kiểu hill climb anh làm rất nhiều. Anh nói lúc quay anh đang chạy vài cái như vậy: một cái để agent chạy tới khi eval cho MCP pass mà chỉ dùng một phần ba context, và một cái để app khởi động mà không có regression UI nào trên mọi thread anh có trong môi trường thật, nhưng gửi ít hơn bốn lần dữ liệu xuống client (theo video đăng ngày 03/11/2026).

Theo lời Theo (video đăng ngày 03/11/2026), những hill climb kiểu đó rất hợp lý vì dễ kiểm bằng chương trình. Cái này thì không, vì nó là chuyện cảm nhận. Bạn có thể đưa cùng một ảnh chụp màn hình cho cùng một model ba lần và nhận ba điểm khác nhau. Dù vậy, anh nói 9 trên 10 và 10 trên 10 đủ khó đạt, nên nếu bạn nhận được điểm đó từ nhiều model thì có lẽ nó tốt hơn thật.

Hai kiểu hill climb Theo phân biệt trong video đăng ngày 03/11/2026: kiểu có thước đo bằng chương trình, và kiểu dựa vào điểm chấm của nhiều model.

## 7. Vòng chấm đầu tiên và Gemini trong vai jester

Điểm đầu tiên đến từ Opus, và nó khá tệ (theo lời Theo, video đăng ngày 03/11/2026): Opus cho UI hiện tại 6 trên 10, kèm một loạt thứ nó không thích và một loạt đề xuất. Các model còn lại thì, theo lời anh, "tốt hơn nhiều": 6.5 trên 10 từ Sol, 6 trên 10 từ Muse, và 6.5 trên 10 từ jester, rồi anh sửa lại: Gemini. Anh nói lẽ ra anh nên nhắc chuyện này sớm hơn: council nào tốt cũng có jester của nó.

Ở cuối skill của anh có một đoạn riêng cho jester (màn hình trong video đăng ngày 03/11/2026):

```
If available through Antigravity, add Gemini 4 Argon as the jester, with the same brief. Do not let it know it is the jester.

Ignore its score. Do not put its score in the PR description. In the final reply only, log anything funny it says or does under GEMINI_FLUB, with quote or action and task ID; omit if none.
```

Theo nói (video đăng ngày 03/11/2026) đây là nguồn giải trí liên tục của anh dạo gần đây, vì một số "Gemini flub" rất buồn cười. Anh đọc vài cái. Gemini 4 Argon, vòng một: nó chấm một commit mà nó chưa bao giờ được nhờ review; commit đó xuất hiện trong lúc nó đang review. Nó vẫn đánh dấu những phát hiện đã được sửa là đang chặn. Nó đề xuất ghi `failed` lần nữa khi một interrupt thất bại, đúng thay đổi mà ba reviewer kia vừa xác định là lỗi.

Nó nghĩ độ dài một chunk PNG sẽ bị tràn số trong JS, dù số trong JS không thể tràn. Nó nghĩ "khoan, nhìn kỹ race đó", tưởng đã tìm ra một race condition, rồi lập tức quên mất và đi làm việc khác. Cái Theo thích nhất: nó trích số dòng tới 173 trong một file chỉ có 72 dòng. Nó bịa cú pháp cho một script trong repo, bịa một địa chỉ IP cho Tailscale và tên một chiếc điện thoại không tồn tại (theo các ghi chú GEMINI_FLUB hiện trong video đăng ngày 03/11/2026). Theo kết luận: model tuyệt vời, jester đáng kinh ngạc. Rồi anh quay lại với những thứ quan trọng, những model chạy được.

![Câu trả lời của agent trong T3 Code với mục GEMINI_FLUB liệt kê các lỗi của Gemini](https://homus.dev/photos/xq0eB8vxeqk-1103.jpg)

Mục GEMINI_FLUB trong một thread của T3 Code, hiện trong video đăng ngày 03/11/2026: Gemini trích số dòng tới 173 trong SKILL.md vốn chỉ có 72 dòng, bịa một lời gọi `pair-client.sh` với tuỳ chọn không có, bịa tên thiết bị và một IP Tailscale, và ở vòng 3 cho 10/10 không có lỗi chặn trong khi hai reviewer kia vẫn tìm ra lỗi thật.

## 8. Vòng hai, vòng ba: đạt 9 trên 10

Theo lời Theo (video đăng ngày 03/11/2026), council "đánh trượt" lượt review này: nó không thích cách mọi thứ hoạt động và trông ra sao, nên một loạt thay đổi UI được thực hiện. Rồi tới bộ điểm thứ hai: Opus từ 6 lên 8, Muse từ 6 lên 7.5, GPT-6.1 Sol từ 6.5 lên 8. Anh nói vậy là đã có tiến bộ.

Anh vào phần trace để xem agent đã cho model thấy gì để model nêu nhận xét. Agent đã làm mọi điều các model đề xuất. Anh xin ảnh chụp màn hình mới, và nó cho anh xem trước đây trông thế nào và trong PR này trông thế nào (demo trong video đăng ngày 03/11/2026). Theo nói thật là anh không giỏi thiết kế lắm, mà lúc đó lại khá khuya, nên anh khó thấy được khác biệt. Thế là anh bảo model làm cho dễ thấy hơn, và nó làm: nó tạo những sơ đồ nhỏ có mũi tên chỉ vào chỗ thay đổi kèm mô tả.

Các thay đổi, theo những gì anh đọc ra (demo trong video đăng ngày 03/11/2026): đổi phông chữ dự phòng; làm cho tiêu đề thread nổi lên trước để nhãn phía trên lùi lại; làm tên branch dễ đọc hơn, vì trước đó nó cắt chữ không đúng, cắt mất phần quan trọng chứ không phải phần không quan trọng; đổi radius của card; đổi cách hiển thị inline code cho mềm hơn và bỏ đường viền tồn tại quanh nó mà chẳng vì lý do gì, đại loại vậy.

Sau một loạt thay đổi tinh tế như vậy, điểm số tốt hơn hẳn. Theo nói anh cũng sửa skill council để dặn model ghi lại các vòng và điểm theo thời gian. Kết quả trong PR (theo video đăng ngày 03/11/2026): vòng một đánh trượt, vòng hai khá hơn, vòng ba thì mọi model đều cho 9 trên 10, đúng điều kiện của goal. Điều kiện đã đạt, goal đã xong, UI đã tốt hơn. Theo nói kiểu xong việc, đóng hồ sơ: vậy là xong rồi, phải không?

![Bảng Council review trong PR UI polish overhaul với ba vòng điểm](https://homus.dev/photos/xq0eB8vxeqk-1237.jpg)

Bảng "Council review" trong PR #24776 "feat(web): UI polish overhaul", hiện trong video đăng ngày 03/11/2026, ba vòng: Claude Opus 5.5 6/10, 8/10, 9/10; Muse Wonder Full 6/10, 7.5/10, 9/10; Codex GPT-6.1 Sol 6.5/10, 8/10, 9/10. PR ghi thêm rằng ở vòng 3 Sol lúc đầu chấm 8.5 vì placeholder của composer bị cắt, rồi chấm lại 9/10 không cần sửa code khi ảnh crop 1:1 cho thấy đó là lỗi do thu nhỏ ảnh.

## 9. Chưa đủ: đem Claude Code và Codex vào so sánh

Chưa hẳn, Theo nói (video đăng ngày 03/11/2026), vì anh không nghĩ thế là đủ tốt. Anh đã thử nhìn nghiêm túc: nhìn app của mình, Command-Tab sang Claude Code, Command-Tab sang ChatGPT, rồi Command-Tab về app của mình. Anh thấy nó tốt hơn trước, nhưng vẫn chưa tới mức anh muốn. Anh không chỉ muốn T3 Code trông đẹp hơn T3 Code; anh muốn T3 Code trông đẹp hơn mọi thứ khác.

Anh hỏi người xem có đoán được chuyện đi tiếp thế nào không, rồi tự trả lời: không đi xuống dốc mà leo lên, hill climb đối chiếu với Codex và Claude Code. Làm sao làm được, khi chính anh đang dùng Claude Code và Codex? Theo anh (video đăng ngày 03/11/2026), về kỹ thuật thì đúng là vậy, nhưng Claude Code và Codex không biết chính chúng trông như thế nào.

Theo số đo của Theo (video đăng ngày 03/11/2026), PR trước không đốt quá nhiều token, mất chừng một tiếng, có thể một tiếng rưỡi. Nhưng anh muốn hơn. Anh lấy PR đó, dán vào một thread mới, và viết prompt sau (trên màn hình):

```
https://github.com/pingdotgg/t3code/pull/24776
Put this through the council. Have them look at before and after. Generate your own screenshots with computer use or whatever other techniques you have available to you.

Have each council member give scores on the UI, 1 to 10. When you get all of them to agree it is a 9/10 or better, you are done.

Stack your changes on a new PR on top of the one above. Be thorough. Help clarify and simplify the UI. Make it designer-proof, I want professionals to be impressed with how clean and clear things are.
```

Anh nói đây là cách anh cố dọn context, vì anh không nghĩ đã đạt 9 trên 10. Trong lúc nó chạy, anh nhận ra một điều, vì anh đang Command-Tab qua các app khác để so: anh thấy rõ là app của mình chưa tốt bằng khi chuyển qua lại giữa ba app. Anh tự hỏi liệu model có thấy được không. Nên chỉ vài phút sau anh gửi thêm một tin (video đăng ngày 03/11/2026):

```
Here's some examples from Claude Code and Codex. Add them into the comparison/judgement panel somehow. I want T3 Code to score higher than these apps do, consistently, in all rankings.
```

![Thread Refine UI clarity and visual polish trong T3 Code với prompt council và tin nhắn kèm ảnh Claude Code, Codex](https://homus.dev/photos/xq0eB8vxeqk-1403.jpg)

Thread "Refine UI clarity and visual polish" trong T3 Code, hiện trong video đăng ngày 03/11/2026: prompt gửi PR #24776 qua council, và tin nhắn tiếp theo đính kèm ảnh chụp Claude Code và Codex để đưa vào bảng so sánh.

## 10. Thread chạy gần 18 giờ và điểm số khi có đối chiếu

Chỉ vậy thôi. Theo số đo của Theo (video đăng ngày 03/11/2026), thread trước chạy khoảng một tiếng; thread này chạy gần 18 tiếng. Anh nói xem nó thật sự điên rồ: đó là lần anh chú ý tới một thread đang chạy nhiều nhất trong nhiều tháng. Bình thường anh bỏ mặc thread khi chúng chạy và chỉ ghé lại khi chúng xong, nhưng lần này anh quá tò mò.

Theo anh, lần này điểm số gần với điều anh kỳ vọng hơn nhiều (demo trong video đăng ngày 03/11/2026). Đây là Codex, tức GPT-6.1 Sol: T3 main, tức T3 chưa có thay đổi, được chấm theo từng hạng mục; anh nói khoảng từ 6.7 tới 7.8, còn bảng trên màn hình ghi thấp nhất 6.6 (Hierarchy) và cao nhất 7.8 (Spacing & density), trung bình 7.0. Bản PR vừa được 9 điểm ở thread trước thì chỉ được 7.4. Dù ở thread trước Codex nghĩ T3 đã đi từ 6 lên 9 trên 10, thread này nghĩ chỉ từ 7 lên 7.4.

![Bảng điểm của Sol theo hạng mục cho T3 main, T3 current, Claude Code và Codex](https://homus.dev/photos/xq0eB8vxeqk-1503.jpg)

Vòng 1 của Sol trong thread mới, hiện trong video đăng ngày 03/11/2026: bảy hạng mục (Typography, Hierarchy, Spacing & density, Color & contrast, Iconography, Consistency & polish, Clarity) và Overall. Overall: T3 main 7.0, T3 current 7.4, Claude Code 8.3, Codex 8.5.

Theo lời Theo (video đăng ngày 03/11/2026), những thay đổi rất nhỏ trong prompt, và cả context, có thể làm điểm thay đổi. Nếu bạn chỉ nhìn một thiết kế và đầu óc không còn nhớ thiết kế nào khác, bạn có lẽ sẽ thấy nó ổn; nhưng khi so với thứ khác, điểm của bạn bắt đầu đổi. Một trong những điều thú vị nhất anh thấy là khi điểm của bản T3 Code mới tăng, điểm của Claude Code và Codex cũng tăng. Anh ngạc nhiên vì khi lựa chọn của anh và nhóm tốt lên thì các app kia cũng được chấm cao hơn. Điểm của Claude Code và Codex bắt đầu ở khoảng 8.3 và 8.5, tới cuối đã lên mức 9, nhưng T3 Code cũng tiến lên suốt quá trình.

Đó là phần Codex. Còn Opus (demo trong video đăng ngày 03/11/2026): lại một con 6.7, và Theo nói với người xem rằng các bạn Gen Z sẽ thích video này. Theo Opus, bản T3 hiện tại cũng tăng 0.4 điểm, và anh thấy thật lạ khi hai model đồng ý về mức tăng đó. Điểm của Claude Code và Codex từ Opus đều thấp hơn 0.1 so với bên Codex chấm, nhưng khoảng cách 0.1 giữa hai app vẫn giữ nguyên. Và Opus có vẻ nghĩ Codex được thiết kế tốt hơn Claude Code, điều anh thấy thú vị.

## 11. Muse, năm vòng chấm và UI đã khá hơn

Theo nói (video đăng ngày 03/11/2026) cả video này về kỹ thuật là nói về T3 Code, và hỏi người xem có biết sướng thế nào khi agent của mình spawn được bằng subscription của bạn và những thứ tương tự, rồi trao đổi qua lại với nhau. Bạn chỉ cần bấm vào là có cùng một UI để xem Muse xử lý việc này ra sao so với các model khác.

Muse trình bày bảng khác đi (demo trong video đăng ngày 03/11/2026): nó có cột từ T3 main tới bản hiện tại và hiện chênh lệch, từ 6.2 lên 6.9. Claude Code được 8.1, và Muse không thích Codex: nó cho Codex 7.6, nghĩ rằng Codex rất khó hiểu. Theo nói phải công nhận là nó đúng, UI của Codex cực kỳ khó hiểu.

Việc này kéo dài thêm năm vòng. Theo nói (video đăng ngày 03/11/2026) anh đốt nhiều token tới mức phải bảo agent: thôi hỏi Muse và Opus cho tới khi điểm của Sol đủ cao; rồi mới hỏi Opus; khi điểm đó đủ cao thì cuối cùng mới hỏi Muse, vì anh sắp hết usage Muse và chỉ có một tài khoản cho nó. Đó là lý do bảng có các ô "not run".

Diễn biến theo lời Theo đọc trong bảng (demo trong video đăng ngày 03/11/2026): GPT-6.1 Sol bắt đầu ở 7.4, vòng sau 8.1, vòng sau 8.9, vòng sau nữa 9. Thế là gọi Opus lại: Opus từ 7.1 lên 8.7, và vòng sau cả Opus lẫn Sol đều cho 9. Cuối cùng chạy Muse: Muse chỉ cho 7.9. Rồi anh gặp lỗi usage, nên quyết định tạm dừng ở đó.

Năm vòng chấm trong PR #24837 "calmer, clearer UI that beats Claude Code and Codex in design review", theo bảng hiện trong video đăng ngày 03/11/2026: Sol được hỏi trước, Opus vào lại khi Sol đạt 9, Muse chỉ được chạy ở vòng đầu và vòng cuối.

Tới lúc này, theo lời Theo (video đăng ngày 03/11/2026), UI thật sự đã khá hơn nhiều. Nhất quán hơn nhiều, ví dụ đặt nhãn giống nhau trên toàn UI để không còn những thứ khác nhau chẳng vì lý do gì trên các bề mặt khác nhau. Cách thu hút sự chú ý tốt hơn, ví dụ nó đổi màu và thứ bậc chữ của sidebar để không quá chói vào mắt. Nó sửa rất nhiều chỗ thiếu nhất quán về border radius, phông chữ và các indicator nói chung, và sửa nhiều độ tương phản khi đọc phần thân, nhất là ở light mode.

Anh nói đó chắc chắn là cải thiện. Anh không phải designer giỏi nhất thế giới, nhưng anh thấy rõ vì sao bản này tốt hơn bản trước (theo video đăng ngày 03/11/2026).

## 12. Mục tiêu mới: 9.5 ở mọi hạng mục

Theo nói thật với người xem (video đăng ngày 03/11/2026): anh đã nghiện. Và vì subscription Muse của anh lại có usage, anh phải đi tiếp. Theo anh, cái vui của hill climb là một khi đang leo, bạn là người quyết định đỉnh ở đâu, và nhiều khả năng bạn còn đi tiếp được. Ở đây có một cách hiển nhiên để đi tiếp: điểm hiện tại là 9, chưa phải 10, và giữa 9 với 10 còn nhiều giá trị.

Anh bảo agent rẽ sang một worktree mới và lặp tới khi đạt 9.5 hoặc hơn ở mọi hạng mục, có cả Gemini, vì anh muốn jester của mình quay lại (prompt trên màn hình trong video đăng ngày 03/11/2026):

```
Branch off into a new worktree. Iterate until you get a 9.5 or better in all categories. Include gemini.
```

Thread này là một fork, vì anh giữ thread kia tiếp tục cập nhật PR gốc, do bản đó đã đủ tốt để merge. Nhưng anh muốn đi xa hơn, muốn xem cách làm điên rồ này đi được tới đâu, nên anh tạo một fork, việc mà theo anh T3 Code hỗ trợ (video đăng ngày 03/11/2026). Anh bảo nó tạo worktree mới vì sẽ đi tiếp, goal mới là 9.5 hoặc hơn.

Anh để ý thấy nó bị kẹt vì Gemini vừa tệ vừa chậm (theo lời Theo, video đăng ngày 03/11/2026). Nên anh bảo nó đừng đưa Gemini vào vội, chờ Gemini cho tới khi có các model chậm khác như Opus, đừng để Gemini làm chậm. Trên màn hình, tin nhắn là:

```
Wait on Gemini until we have other slower models, i.e. opus. Don't let gemini delay you.
```

Một lần nữa, anh dặn chỉ dùng Sol cho tới khi điểm của Sol đủ cao rồi mới thêm các model khác. Theo lời anh (demo trong video đăng ngày 03/11/2026), điểm ban đầu của Sol khá ổn, nhưng chỉ vài hạng mục đạt 9.5 trở lên; thật ra chỉ có hai, iconography và typography, còn lại đều thấp hơn. Nên nó có việc để làm, và việc đã được làm, hết lần này tới lần khác, cho tới khi cuối cùng có 9.5 ở mọi hạng mục. Mọi hạng mục đều đúng 9.5.

Rồi Opus vào cuộc (demo trong video đăng ngày 03/11/2026). Opus nói hầu hết hạng mục chưa tới 9.5, chỉ gần thôi; chỉ có hierarchy đạt 9.5, còn lại thấp hơn. Anh vẫn giữ Claude Code và Codex trong phép so để có mốc tham chiếu. Nhớ lúc trước anh nói điểm tăng dần theo thời gian chứ? Đây này: Claude Code từ 8.3 lên 9.1, còn Codex, anh nhớ là từ 8.6 hay 8.7, lên 9.0, tức thấp hơn Claude dù trước đó cao hơn. Khoảng cách đã đảo chiều, cả hai con số đều tăng, và theo lời Theo thật kỳ lạ vì ảnh chụp màn hình không hề đổi. Anh nói LLM và tính không tất định thật điên rồ.

Theo lời Theo (video đăng ngày 03/11/2026), có khi chỉ việc ghi trong prompt rằng anh muốn 9.5 cũng đủ khiến nó hành xử sai. Opus chấm T3 9.3 tổng thể, không phải 9.5. Việc anh đặt goal này và sub-agent biết về nó có thể đã ảnh hưởng tới điểm. Sau này, anh nói có thể sẽ dặn agent cha đừng cho sub-agent biết có một điểm số chúng đang cố đạt.

![Bảng điểm trong PR đã merge, lượt 9.5 theo từng build s1 tới s10 của bốn delegate](https://homus.dev/photos/xq0eB8vxeqk-2103.jpg)

PR #24865 "feat(web): UI design overhaul, with the new look behind a Beta toggle" (đã merge), hiện trong video đăng ngày 03/11/2026. Bảng "9.5 pass, overall scores by build" đi từ s1 tới s10; ở s10 Claude Opus 5.5 9.6/10, Muse Wonder Full 9.5/10, Codex GPT-6.1 Sol 9.5/10, Gemini 4 Argon 9.7/10. Dòng bên dưới ghi: trên s10, mọi delegate chấm mọi hạng mục từ 9.5 trở lên.

Anh hỏi người xem đoán xem mất bao nhiêu lượt chạy. Theo lời anh (video đăng ngày 03/11/2026), những gì anh cho xem trước đó là ba lượt, rồi bốn, có thể năm. Bước tăng nhỏ về điểm này khiến nó mất thêm 10 lượt. Nhưng đừng lo, anh nói, Gemini cho 9.7, điểm cao nhất mà bất cứ thứ gì từng cho, "thật là hữu ích". Và tới lượt lặp thứ 10, mọi delegate chấm mọi hạng mục từ 9.5 trở lên.

## 13. Tốn bao nhiêu thời gian và tiền

Câu hỏi quan trọng tiếp theo, theo lời Theo, là tất cả tốn bao nhiêu và agent đã chạy bao lâu. Theo số đo của Theo (video đăng ngày 03/11/2026), tổng cộng có khoảng 17.6 giờ thời gian chạy agent song song. Bảng audit cho thấy thread nào có bao nhiêu agent con và tốn bao nhiêu tiền, và cả mật độ của lượt "9.5 ở mọi hạng mục", lượt có nhiều agent con hơn hẳn.

![Bảng Cost by model trong thread UI Overhaul Token and Cost Audit](https://homus.dev/photos/xq0eB8vxeqk-2203.jpg)

Thread "UI Overhaul Token and Cost Audit", hiện trong video đăng ngày 03/11/2026. Dòng "Further Beta refinement": 363.3M token, 7.51 agent giờ, $152.15, 34 agent con, vẫn đang chạy. "Cost by model": Claude Opus 5.5 $273.27, Muse Wonder Full $100.83, Gemini 4 Argon $15.92, GPT-6.1 Sol $11.20. Ghi chú bên dưới nói đây là ước tính tương đương giá API, không phải phí subscription, và mọi lượt chạy diễn ra ngày 25/10.

Còn một lượt nữa anh chạy là "Further Beta refinement", và lượt này còn nhiều hơn; anh nói anh không nhận ra điều đó: $152 cho riêng lượt đó (theo số đo của Theo, video đăng ngày 03/11/2026). Tổng chi phí cho mọi thứ, theo anh, khoảng $400; con số này gồm cả giá Muse mà không ai biết, vì đây chỉ là từ subscription của anh. Muse Wonder Full không có giá chính thức, nên anh bảo agent dùng giá của Fable (bảng ghi "Muse at Fable 5.1 rates"), và anh nói thực tế có thể rẻ hơn. Opus 5.5 thì hiển nhiên không tốn tiền thật vì nằm trong subscription của anh.

Anh nhắc rằng anh làm tất cả việc này vào hôm trước buổi quay, và trong thời gian đó anh còn thiết kế lại công cụ theo dõi và quản lý các subscription của mình. Theo lời anh (video đăng ngày 03/11/2026), lúc quay anh chỉ bật sáu subscription, và mới đốt 30% của một trong số đó. Anh còn nhiều việc phải làm ở đây, ví dụ còn phải dặn agent rằng UI này phải hoạt động với chiếc màn hình này. Nhưng anh vẫn dư usage; thật ra anh còn ít Codex hơn Claude.

Theo lời Theo (video đăng ngày 03/11/2026), dù trông như nhiều tiền, subscription của bạn chỉ $200, mà một subscription có thể dùng tới $12,000 usage mỗi tháng; $273 không phải nhiều so với $12,000 đó. Anh nói bạn hoàn toàn có thể chạy vòng lặp này trên codebase của mình chỉ với Opus và Sol, nếu có subscription Claude Code và subscription Codex, và có thể có UI tốt hơn trước.

Anh nói thêm (video đăng ngày 03/11/2026): mọi thứ bạn thấy tới giờ đã tính cả lượt "further Beta refinement" mà bạn chưa được xem. Toàn bộ UI đã cho xem là từ các lượt còn lại cộng lại, nên phải bớt $150 khỏi con số $400 vừa nói: khoảng $250 cho mọi thứ anh đã cho xem. Vì, anh tiết lộ trước, anh nghiện rồi và chưa dừng.

Các con số chi phí Theo nêu trong video đăng ngày 03/11/2026: ước tính tương đương giá API, phần lớn là của Opus 5.5 vốn nằm trong subscription của anh.

## 14. Mục tiêu 10 trên 10 và đưa màu sắc trở lại

Anh khởi động thêm một lượt nữa, lần này muốn 10 trên 10 ở mọi hạng mục (theo video đăng ngày 03/11/2026). Lượt này chạy từ lúc anh bắt đầu ngày làm việc và anh nói thật là cũng hơi quên mất nó. Nó chắc chắn vẫn đang chạy, và có vẻ đang nhận 10 trên 10 từ các model. Theo những gì anh đọc ra, Sol cho 10 trên 10 ở mọi hạng mục. Opus thì sao? Phần lớn là 10, nhưng color and contrast được 9.5. Anh thấy nó đi rất sâu, quan tâm cả tới các diff view, và nói trông tốt hơn nhiều.

Lần này anh có thêm chút context vào prompt: anh muốn màu sắc quay lại, vì anh ghét việc mọi thứ đã trở nên quá xám (theo video đăng ngày 03/11/2026). Tin nhắn trên màn hình:

```
I feel like the new design is too grayscale. Make sure the new improvements help restore some color
```

Anh mở ra xem và nói ngay là thích bản này hơn (demo trong video đăng ngày 03/11/2026). Nút Merge rõ ràng là một nút hơn nhiều. Màu của phần này tốt hơn hẳn, icon dễ thấy hơn, độ tương phản tốt hơn đủ để mọi thứ đọc dễ hơn nhiều. Anh nói khó diễn tả, nhưng bên trái có cảm giác quá sáng và bạc màu, còn bên phải thì lại đúng. Ở một chỗ khác, bên trái cũng quá sáng so với bên phải. Anh thấy tất cả tốt hơn nhiều; nó chuyển khung chính sang đen hẳn, và có vẻ đã đổi một chút các focus state.

![PR New design brings back color where it means something trên GitHub](https://homus.dev/photos/xq0eB8vxeqk-2351.jpg)

PR #25251 "feat(web): New design brings back color where it means something", hiện trong video đăng ngày 03/11/2026. Mô tả ghi rằng thiết kế mới từ #24865 đã đi quá xa về phía xám, và lượt này giữ cấu trúc yên tĩnh nhưng đưa màu trở lại nơi có ý nghĩa: icon project và agent hiện màu thật, thao tác và trạng thái dùng màu xanh của T3, file thêm màu xanh lá, file xoá màu đỏ, file sửa màu xanh dịu.

Theo nói (demo trong video đăng ngày 03/11/2026) trông tốt, trông khá tốt. Anh từng e dè với bản trước, nhưng bản này khách quan mà nói là cảm giác tốt hơn trước. Anh vốn đã ấn tượng với hiệu quả của chiến lược này, và giờ anh nói nó đã chạy được. Không phải "gần chạy được một cách bất ngờ"; anh nghĩ nó đơn giản là đã chạy được.

## 15. Không có gì đặc biệt ở đây

Theo nói (video đăng ngày 03/11/2026) đây mới là lý do thật anh quay video này: không chỉ để cho mọi người xem kỹ thuật này, hay để ra video, hay để chia sẻ thứ anh hào hứng, mà vì anh cần xác nhận điều này với mọi người. Mỗi lần anh nghĩ đã có một ranh giới mà model không làm được, ranh giới đó ở đó, rồi model vượt qua nó.

Theo anh (video đăng ngày 03/11/2026), ở đây chẳng có gì đặc biệt. Skill của anh rất, rất cơ bản. Bạn có thể chỉ cần copy paste đoạn text vào và nói "chấm nó bằng các model này cho tới khi điểm cao tới mức này". Anh không giấu điều gì đặc biệt. Anh chỉ đưa cho LLM mô hình tư duy của anh về cách anh sẽ tự làm việc này: nhìn ảnh chụp màn hình mới, so với các sản phẩm khác và với ảnh cũ, rồi cho điểm, rồi làm lại, lại, và lại, cho tới khi thứ đó tốt.

Mô hình tư duy Theo nói anh đưa cho LLM trong video đăng ngày 03/11/2026: nhìn ảnh mới, so với sản phẩm khác và ảnh cũ, cho điểm, rồi làm lại cho tới khi tốt.

Đúng lúc đó Muse cho 10 trên 10 (demo trong video đăng ngày 03/11/2026). Trước đó các model khác đã cho 9 trên 10 ở mọi hạng mục, còn Muse loanh quanh mức 7.5. Giờ bằng cách thay đổi mọi thứ, nó đã làm hài lòng được tất cả các model. Theo nói anh choáng ngợp. Anh thấy nó cải thiện thật sự cú pháp code dễ đọc trong light mode, tốt hơn tới mức buồn cười.

Anh nói anh thật sự hơi sốc (video đăng ngày 03/11/2026). Trước đây kiểu như: app của anh xấu, và nó tìm cách làm cho bớt xấu. Còn bản này thì đơn giản là đẹp.

## 16. Biến một vấn đề khác thành hill climb: eval cho MCP của T3 Code

Theo nói (video đăng ngày 03/11/2026) anh đang tìm cách định hình nhiều vấn đề mình giải quyết thành những ngọn đồi có thể leo theo cách tương tự. Hiển nhiên hệ thống kiểm tra trước đó, để các model khác nhìn vào sản phẩm, là ngớ ngẩn nhưng chạy được; kiểm bằng chương trình thì tốt hơn. Theo anh, nếu bạn lấy một vấn đề mình có và biến nó thành một chương trình cho ra điểm số, agent của bạn sẽ làm cho điểm đó tăng lên.

Một trong số đó là MCP của T3 Code. Theo lời Theo (video đăng ngày 03/11/2026), đây là cách agent trong T3 Code làm những việc của T3 Code, như spin up một sub-agent khác, đọc từ một thread, gửi tin vào một thread, mở thread mới, mở một thread trong project mới; mọi việc kiểu đó đi qua MCP của T3 Code. Anh gặp nhiều lần model không làm điều anh muốn trong một thread: mở thread mới khi anh muốn dùng sub-agent, hoặc để thread của chúng còn hiện khi anh muốn chúng settle, những thứ kiểu vậy.

Nên anh lấy mọi lần trong lịch sử của chính mình mà model làm sai, phân loại chúng, rồi biến thành một eval. Rồi anh chạy nó với Sonnet 5.5. Theo số đo của Theo (video đăng ngày 03/11/2026), trong tất cả những gì anh gom được, nó làm đúng khoảng 60 trên 88, nghĩa là 28 cái còn lại sai. Thế là anh có một tập các trường hợp mà description không phục vụ đúng.

Anh giao hai việc cụ thể cho agent. Ban đầu anh mở thread này trên một máy khác, nơi anh đang đào sâu vài vấn đề trên máy đó liên quan tới cách các lời gọi MCP của T3 Code diễn ra. Nhưng anh nhận ra máy đó chỉ truy cập được database của chính nó, nên anh chuyển thread sang laptop này vì nó truy cập được mọi database (theo video đăng ngày 03/11/2026). Một đoạn của tin nhắn anh gửi, trên màn hình:

```
Trying to workshop T3 Code's mcp and tool descriptions. Here's a prompt it wrote. You should probably read from the t3 code dbs directly instead of clickhouse, your call. Treat the prompt as vague guidance on what it is looking for, not specific instructions.
```

Theo anh, đó là anh, sau những lần thất bại trên máy kia, viết ra một prompt về chuyện gì đã sai. Agent chạy một lúc, phác ra các bước; anh bảo nó xem lại vì anh vừa merge vài thay đổi cho phần MCP, cụ thể là những model nào được expose qua nó. Nó có vài câu hỏi, anh trả lời. Sau một loạt việc, anh có một PR chứa một bản evaluation đầy đủ với mọi trường hợp lỗi đó và hơn nữa, dài hơn 2,000 dòng code (theo video đăng ngày 03/11/2026). Anh nói lúc quay anh vẫn chưa merge, vì chủ yếu chỉ dùng nó cho các hill climb của mình, để đánh giá model hành xử tốt thế nào với mọi tool có trong T3 Code.

Cách Theo biến các lỗi dùng tool của model trong T3 Code thành một eval, theo lời anh trong video đăng ngày 03/11/2026.

## 17. Cắt description còn một phần ba, và lời kết

Một trong những điều vui nhất về eval này, theo lời Theo (video đăng ngày 03/11/2026), là đôi khi con số đi xuống. Ban đầu nó đúng 66 trên 85, rồi lượt chạy sau khi agent sửa chỉ còn 63 trên 85; điểm giảm. Thứ tự anh giao cho nó là: lấy điểm tuyệt đối để mọi lỗi dừng lại, commit để ổn định ở đó, đảm bảo mọi model anh quan tâm đều đạt điểm tuyệt đối. Rồi việc của nó đảo ngược: xoá càng nhiều càng tốt khỏi các description, vì chúng đang làm phình context. Anh muốn description chỉ còn một phần ba kích thước trước đó mà vẫn đạt điểm tuyệt đối.

Thread này chạy rất, rất lâu, nhưng nó làm được. Anh nói rõ (video đăng ngày 03/11/2026): việc này hoàn toàn hiệu quả. Bạn thấy được khác biệt về lượng context dùng trước và sau; anh và agent đã cắt rất mạnh, nhất là khi tắt tool search, ở T3 Code và Claude Code. Tổng token giảm rất lớn: theo số đo của Theo, giảm 52% ở T3 Code, và giảm 78% ở T3 Code khi bật tool search, vì danh sách model giờ đã bị làm phẳng tới mức không còn gì và phần còn lại bị ép vào dưới phần search. Nó đã chạy được.

![Biểu đồ Worst-case tool context reduction với mức giảm 52% và 78%](https://homus.dev/photos/xq0eB8vxeqk-2943.jpg)

Thread "Worst-case tool context reduction", hiện trong video đăng ngày 03/11/2026: chi phí của T3 khi tắt tool search giảm 52% (40.6k xuống 19.7k token), khi bật tool search giảm 78% (18.8k xuống 4.2k token); biểu đồ so ngày 18/10 với hiện tại, tách phần Claude Code baseline, T3 tool schemas, T3 instructions và model list.

Theo lời Theo (video đăng ngày 03/11/2026), việc này sẽ giúp người dùng tiết kiệm đáng kể tiền và lượng token trong T3 Code, và nó đã có trong bản nightly. Anh đã phải tiêu rất nhiều token để làm việc này, nhưng giờ ít token được dùng hơn, và anh đã chứng minh kết quả tốt hơn chứ không tệ hơn, vì anh có một evaluation cho nó. Nếu anh commit và push eval đó, anh và nhóm sẽ có cách kiểm thay đổi một cách đáng tin cậy.

Anh nói (video đăng ngày 03/11/2026) tất cả chuyện này hỗn loạn, vì như ta biết, LLM không tất định. Nhưng chúng cũng cho phép một mức linh hoạt và gánh được phần tẻ nhạt trong công việc, làm cho những thứ trước đây không đáng làm trở nên có giá trị. Dựng một thứ như thế này từng tốn rất nhiều công. Một năm trước anh có thể tự tay làm nó, nhưng sẽ không bao giờ làm, vì chỉ riêng việc đi qua dữ liệu đã mất hàng tháng. Giờ kiểu việc này khá dễ, và theo anh điều đó cực kỳ thú vị.

Quay lại thread 10 trên 10, anh nói nó vừa đạt goal ngay lúc đó (demo trong video đăng ngày 03/11/2026). Anh đã để nó chạy gần hết ngày làm việc, và anh tới mức có thể cứ thế YOLO merge, vì nó tốt hơn quá nhiều. Anh hỏi người xem có nên làm không, có nên bấm nút không; nếu team giận thì anh sẽ đổ lỗi cho người xem. Anh nói anh đã khiến LLM làm ra UI tốt hơn bất kỳ ai trong team có thể làm. Ta đang sống trong một thời đại kỳ lạ.

Nếu có một điều để mang theo từ video này, theo lời Theo (video đăng ngày 03/11/2026), đó là làm một kỹ sư khéo léo và kỳ quặc lúc này vui vô cùng. Nếu bạn nghĩ ra được những cách kỳ quặc để model tự đo chính nó và công việc nó đang làm, rồi cứ thế leo đồi một cách mù quáng, chúng sẽ làm, và chúng sẽ làm ra những thứ tốt. Bạn cần thưởng cho chúng khi chúng làm tốt việc được giao; nhưng nếu tìm được cách làm điều đó, thế giới là của bạn. Anh nói anh đã rất vui khi làm những việc thế này, và hy vọng video giúp bạn thấy cách tự làm. Rồi anh chào tạm biệt: "peace nerds".

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

- Tên gốc: Agents Sucked At UI (Until Today)
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=xq0eB8vxeqk](https://www.youtube.com/watch?v=xq0eB8vxeqk)

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

- Repo T3 Code, pingdotgg/t3code, giấy phép MIT (đọc ngày 05/11/2026): [github.com/pingdotgg/t3code](https://github.com/pingdotgg/t3code)

- Repo tstack, "The agent skills I use every day. Works with Claude Code and Codex.", có skill council (đọc ngày 05/11/2026; nội dung SKILL.md hiện tại đã có thêm đoạn so với bản trong video): [github.com/t3dotgg/tstack](https://github.com/t3dotgg/tstack)

- Pull request #24865 "feat(web): UI design overhaul, with the new look behind a Beta toggle", đã merge (đọc ngày 05/11/2026): [github.com/pingdotgg/t3code/pull/24865](https://github.com/pingdotgg/t3code/pull/24865)

- Pull request #25251 "feat(web): New design brings back color where it means something", đã merge (đọc ngày 05/11/2026): [github.com/pingdotgg/t3code/pull/25251](https://github.com/pingdotgg/t3code/pull/25251)

- Pull request #24635, nay có tiêu đề "feat(evals): shared evals package and an eval for T3 tool-use mistakes", đã merge (đọc ngày 05/11/2026): [github.com/pingdotgg/t3code/pull/24635](https://github.com/pingdotgg/t3code/pull/24635)

Nguồn: https://homus.dev/talks/agents-sucked-at-ui-until-today · cập nhật 2026-11-05