# Kỹ sư prompt dở vì over-engineering: hãy hỏi thay vì build

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

> Theo chỉ cách thoát khỏi tư duy kỹ sư: hỏi agent thay vì build tính năng, gói cả flow t3 triage vào một prompt, rồi build primitive cho agent.

Topics: Coding Agents, Context Engineering, Workflow, Dev Tools

Canonical: https://homus.dev/talks/your-prompts-kinda-suck

## 1. Prompt engineering là chuyện thổi phồng, nhưng kỹ sư vẫn prompt dở

Theo mở đầu bằng một câu hỏi: bạn còn nhớ cơn sốt quanh prompt engineering không? Ý tưởng rằng mình phải viết prompt thật cụ thể, thật chi li thì agent mới làm tốt, rằng nó sẽ thành cả một lĩnh vực mới sang chảnh mà ai cũng phải học và giỏi lên. Anh nói thẳng: tất cả chỉ là nhảm nhí, và anh không định giả vờ khác đi.

Vì vậy video này không nhằm nói rằng kỹ sư cần "engineer" prompt nhiều hơn. Theo muốn nói điều ngược lại. Anh nghĩ kỹ sư prompt rất dở, nhưng không phải vì họ engineer prompt chưa đủ, mà vì họ over-engineer nó. Họ không nắm lấy cơ hội mà prompt mở ra: lùi lại một bước và nghĩ lại cách máy tính có thể làm việc cho mình.

![Theo Browne nói trước micro trong phòng thu tối](https://homus.dev/photos/m-B3jIMMmUE-0003.jpg)

Theo Browne mở đầu video: kỹ sư prompt dở không phải vì thiếu kỹ thuật, mà vì quá kỹ thuật.

Anh muốn vạch một đường ranh giữa hai thứ. Prompt là gì? Engineering là gì? Khi nào nên làm cái này, khi nào nên làm cái kia? Nhưng điều cốt lõi nhất anh muốn nhấn mạnh là: phần lớn chúng ta đơn giản là chưa prompt đủ mạnh tay (not prompting hard enough).

Theo thừa nhận chính anh cũng mới ở giai đoạn đầu của chuyện này. Anh đã giúp nhiều kỹ sư quanh mình có được cú "mở khoá" đó bằng những cuộc trò chuyện thật về việc mọi người dùng AI vào việc gì hằng ngày. Và anh ngạc nhiên vì có quá nhiều người chưa từng có cú mở khoá đầu tiên trong đầu kiểu: "à, agent làm được nhiều hơn thế".

Ngay tuần trước, anh có gần như đúng cuộc trò chuyện này với một kỹ sư vừa lập công ty và vừa đi qua Y Combinator. Cuộc trò chuyện đó đổi hẳn cách người ấy nghĩ về agent của mình. Theo nhận ra anh cần dành thời gian giải thích điều này cho tất cả mọi người, để kéo các kỹ sư ra khỏi "chiếc hộp kỹ sư" (engineering box) đủ lâu mà nghĩ cho thật kỹ xem agent có thể giúp mình thế nào trong công việc hằng ngày: với thứ bạn đang build và code, với cách dùng agent trong đời sống hằng ngày, và nhiều hơn thế. Video là một hướng dẫn để prompt tốt hơn và để thoát khỏi chiếc hộp kỹ sư trong đầu.

## 2. Bước ra khỏi chiếc hộp kỹ sư: bài học từ một tranh XKCD

Theo vẽ khung cho phần chính trên một bảng trắng: tiêu đề "Engineers suck at prompting", dòng phụ "(the opposite of 'prompt engineering')", và một đường gạch đứt chia đôi hai cột "Engineering" và "Prompting".

![Bảng trắng với tiêu đề Engineers suck at prompting, hai cột Engineering và Prompting](https://homus.dev/photos/m-B3jIMMmUE-0343.jpg)

Bảng trắng của Theo: "Engineers suck at prompting", nghĩa là ngược với "prompt engineering". Hai cột Engineering và Prompting được ngăn bằng một đường gạch đứt, đúng là ranh giới anh muốn bàn trong cả video.

Để bắt đầu, anh muốn mọi người tạm sống trong một thế giới không có JavaScript hay TypeScript, nơi mình không phàn nàn chuyện app dùng Electron hay dùng chưa đủ Rust, và mấy thứ tương tự. Tạm thời hãy tập trung vào trải nghiệm của người bình thường (the normie experience) một chút.

Anh mở một trong những tranh XKCD anh thích nhất, tranh "Tasks". Người bình thường nói với kỹ sư: khi người dùng chụp ảnh, app nên kiểm tra xem họ có đang ở trong một vườn quốc gia không. Kỹ sư đáp: được, tra cứu GIS dễ thôi, cho tôi vài giờ. Theo giải thích: đúng vậy, bạn có thể dùng vị trí để biết họ đang ở đâu, dựng các bounding box cho những vườn quốc gia bạn quan tâm, rồi xem vị trí có nằm trong khoảng đó không. Đây là kiểu bài LeetCode anh đã làm đủ nhiều lần trong đời.

![Tranh XKCD Tasks: người dùng yêu cầu kiểm tra vườn quốc gia và kiểm tra ảnh có phải chim không](https://homus.dev/photos/m-B3jIMMmUE-0403.jpg)

Tranh XKCD "Tasks": tra vườn quốc gia thì "vài giờ", còn kiểm tra ảnh có phải con chim không thì "cần một nhóm nghiên cứu và năm năm". Chú thích dưới tranh: trong khoa học máy tính, khó giải thích được khác biệt giữa việc dễ và việc gần như bất khả.

Rồi người kia nói thêm: "... và kiểm tra xem ảnh có phải chụp một con chim không". Kỹ sư đáp: "tôi sẽ cần một nhóm nghiên cứu và năm năm". Theo lưu ý tranh này có từ trước thời AI: theo video đăng ngày 18/10/2026, đã có rất nhiều vision model làm việc đó một cách dễ dàng, nhưng hồi ấy nó đòi hỏi cả núi nghiên cứu. Lý do mất năm năm là vì để làm được thì phải phát minh ra AI. Có AI rồi thì dễ hơn, còn khi đó thì phải mất năm năm nghiên cứu.

Ý của anh: người bình thường vốn không giỏi đoán xem một việc kỹ thuật phức tạp tới đâu. Nhưng giờ chúng ta lại ở đầu bên kia. Kỹ sư đã quá quen với chuyện này, đến mức không biết mình có thể nhờ agent làm gì, vì lúc nào cũng nghĩ bằng code.

## 3. Cuộc trò chuyện về tool call trong T3 Code

Theo nói anh sẽ đi vào một ví dụ cực kỳ cụ thể, đúng cuộc trò chuyện anh có với một người bạn vài ngày trước. Chủ đề là tool call trong T3 Code. Anh nhấn mạnh đây hoàn toàn không phải quảng cáo cho T3 Code, thậm chí ở nhiều mặt còn ngược lại.

Gần đây anh dành nhiều thời gian dùng T3 Code và các công cụ khác để audit mọi việc agent đã làm trên các máy của mình, và anh nhận ra vài kiểu lỗi đặc biệt. Ví dụ, khi audit lịch sử, anh phát hiện phần lớn lỗi tool call của Claude là do nó gọi ripgrep với cú pháp và kiểu xuống dòng chạy được trong bash nhưng không chạy trong Z shell. Nghĩa là các máy cài Z shell của anh, gồm phần lớn các máy Linux và toàn bộ máy Mac, có tỉ lệ lỗi cao hơn với Claude, vì model viết lệnh bash theo cách không tương thích với zsh.

![Bảng trắng Tool calls in T3 Code với câu yêu cầu tính năng và câu trả lời We already have this](https://homus.dev/photos/m-B3jIMMmUE-0643.jpg)

Theo ghi lại cuộc trò chuyện lên bảng: người bạn muốn "một tính năng phân tích mọi tool call để tìm cái chậm nhất và tối ưu môi trường", còn câu trả lời là "We already have this!".

Anh kể điều đó với người bạn, và người bạn nói đại ý: "Hay thật. Mình thực ra muốn có một tính năng trong T3 Code từ lâu rồi, để nó chia nhỏ xem tool call của mình mất bao lâu, để biết tool call nào chậm nhất, nhanh nhất, lệnh nào chạy mãi không xong, rồi tối ưu môi trường thêm." Đại loại như vậy.

Theo nói nếu bạn dùng T3 Code, câu tiếp theo của anh hoặc sẽ chẳng làm bạn ngạc nhiên chút nào, hoặc sẽ làm bạn rất ngạc nhiên. Anh trả lời: "Tụi mình có cái đó rồi. Không chỉ có, mà còn có cả trong app mobile." Người bạn rất bất ngờ. Theo bảo bạn mở điện thoại, vào app T3 Code và chỉ cho bạn chỗ đó.

## 4. Tính năng không phải tính năng, chỉ là thông tin

Theo làm lại đúng thao tác đó cho người xem. Anh tạo một thread mới không gắn project nào. Vì đang quay video và muốn nhanh, anh nói sẽ chuyển sang GPT-6 Astra chế độ nhanh (trên màn hình, ô chọn mức hiển thị "Medium"); anh đùa rằng có nhiều meme về chuyện này nhưng không quan trọng lắm. Rồi anh lấy đúng câu người bạn nói, dán vào, sửa thành yêu cầu agent phân tích mọi tool call, ghi rõ "trong T3 Code" cho rõ ràng, và thêm "trên máy này" vì đó là thứ anh quan tâm; anh hoàn toàn có thể kể cho nó về các máy khác nữa.

```
Break down all my tool calls in t3 code on this machine so I can find which ones are slowest and optimize my environment
```

![T3 Code thread Find Slowest Tool Calls với prompt phân tích tool call, model GPT-6 Astra](https://homus.dev/photos/m-B3jIMMmUE-0703.jpg)

Thread "Find Slowest Tool Calls" trong T3 Code. Agent trả lời rằng nó sẽ tìm lịch sử tool cục bộ của T3 Code, kiểm tra dữ liệu thời gian được ghi lại, rồi xếp hạng tool theo tổng thời gian; dòng dưới cho thấy nó đang chạy lệnh `du`.

Anh bấm gửi. Khoảng ba phút sau, có lẽ ít hơn vì chạy chế độ nhanh, anh sẽ có một bản phân tích chi tiết mọi tool call và mọi việc anh đã làm với tất cả agent trên máy này.

Điểm anh muốn nói: rất nhiều kỹ sư vẫn nghĩ về những workflow này như những tính năng cần được build vào sản phẩm. Chúng ta quen với việc công cụ phải có tính năng thì mới lấy được thứ đó từ công cụ. Nhưng giờ mình chỉ cần hỏi. Và điều đó khác hẳn.

Theo nói rõ anh không bảo ai cũng nên tự thêm tính năng vào T3 Code, dù anh rất muốn làm cho extension và fork nội bộ chạy được, vì như vậy sẽ rất hay. Anh đang nói về những tính năng thực ra không phải tính năng. Chúng là thông tin. Và nếu lấy được thông tin đó bằng cách khác thì nó không cần là một tính năng. Thông tin chỉ cần được mở ra theo những cách bạn cần để làm những việc hay ho.

## 5. Cái dashboard Theo làm sai hướng

Rồi Theo đưa ra một ví dụ anh đã làm sai. Có một tính năng anh làm lúc có lúc không cho T3 Code: về cơ bản là một dashboard thay thế cho toàn bộ việc đang chạy. Nó hiện từng task cùng trạng thái của nó, và có một agent đi qua từng task theo cách lập trình sẵn, cho bạn biết trạng thái của nó và gợi ý nên làm gì. Agent đó có thể đổi tên thread, đóng thread, merge PR. Nó sẽ nói kiểu: "Đây là 40 thread bạn đang có. Tôi nghĩ tám cái này nên merge code rồi đóng. Hai mươi cái này nên đóng vì giờ vô dụng rồi. Phần còn lại tôi sẽ đổi tên và xếp lại nhóm. Và bạn nên gửi những prompt này cho chúng."

Anh từng thấy mình rất thông minh khi nghĩ ra tính năng đó: một dashboard để điều khiển mọi lần chạy và xem chúng rõ hơn ở một chỗ. Rồi anh cứ thêm thứ này thứ kia vào. Thêm nút mới cho đủ việc bạn có thể muốn làm, ví dụ một nút tự tạo lại toàn bộ tiêu đề, đại loại vậy.

Rồi anh nhận ra: anh có thể thêm tất cả những thứ đó cho mọi cách người ta muốn dùng nó. Hoặc anh có thể biến nó thành một khung chat. Một "meta thread" trong T3 Code, kết nối tới mọi instance T3 Code của bạn trên mọi môi trường, và cho bạn cứ thế hỏi thứ mình muốn. Muốn một dashboard đẹp? Bảo nó, nó sẽ làm cho bạn.

Hai hướng cho cùng một nhu cầu: một dashboard ngày càng nhiều nút, hay một meta thread nối tới mọi instance T3 Code để người dùng cứ thế yêu cầu thứ mình cần.

## 6. Báo cáo tool call: một lần tìm trong home directory kéo dài 41,7 phút

Lúc đó báo cáo tool call đã xong. Theo chỉ ra anh thậm chí không hề bảo agent làm thành một trang, nhưng nó tự làm thành một trang cho anh. Giờ anh có một báo cáo về mọi tool call và thời gian chúng chạy trên máy này.

![Trang báo cáo T3 Code tool timings với mục What to optimize và bộ lọc Explore the timings](https://homus.dev/photos/m-B3jIMMmUE-0905.jpg)

Trang "T3 Code tool timings" mà agent tự dựng: 60.125 bản ghi thao tác, 45.066 bản ghi có thời gian, từ 3/7 đến 4/10/2026 trên máy cục bộ. Mục "What to optimize" liệt kê năm điểm, bên dưới là bộ lọc theo khoảng thời gian, kiểu xem, nhóm, cách sắp xếp và một biểu đồ thanh theo tool.

Theo báo cáo, có một lần tìm kiếm trong home directory kéo dài 41,7 phút, một lần khác gần 10 phút, và lời khuyên là hãy tìm trong repo hoặc một thư mục đã biết. Trên trang, mục "What to optimize" còn ghi:

- **Search scope:** một lần tìm trong home directory kéo dài 41,7 phút, một lần khác 9,2 phút; nên tìm trong repo hoặc thư mục đã biết.

- **Capture startup:** một bản ghi FFmpeg ba giây bị treo mở 5,35 giờ trước khi bị huỷ, các lần thử gần đó báo lỗi setup AVFoundation; nên đặt deadline cho bước khởi động.

- **Simulator tests:** 516 lần gọi có đo giờ dùng hết 4,23 giờ, median 25,1 giây, p95 74,1 giây; các lần chạy fail tốn 66,8 phút.

- **Browser waits:** một script yêu cầu chờ 45 giây bên trong một tool chỉ cho phép 15 giây.

- **Shell startup:** 6 ms bình thường, 39 ms login, 100 ms interactive login; trang ghi đây là mục tiêu nhỏ.

Theo nói đây là thông tin hữu ích mà trước đó anh không có, chỉ vì anh chưa từng hỏi model theo cách này. Và hãy nhìn xem lấy được thông tin hữu ích như thế dễ dàng tới mức nào, chỉ bằng cách hỏi.

## 7. Visualizer cho context window và 70.000 token không ai để ý

Một thứ khác người ta hay hỏi là chia nhỏ xem context của mình đang được dùng thế nào trong T3 Code. Theo làm luôn: anh mở một thread mới, chọn Claude Opus 5.5 ở mức Extra High với context 1M (theo màn hình), và gõ:

```
Break down my current context window for this thread in T3 Code. Make a nice visualizer for it
```

Anh chắc ví dụ này sẽ chạy được vì chính anh đã dùng nó cho một video khác quay hôm trước. Và nhờ đó anh phát hiện: do cách proxy của anh được cấu hình, mỗi request anh gửi đều bị nhồi thêm 70.000 token context. T3 Code có một nút hiển thị mức dùng context, nhưng nút đó bị giấu sau một tính năng legacy, vì theo anh mình không nên phải nghĩ tới những chuyện này.

Anh nói việc anh có một khối context 70k token ở đầu mọi prompt suốt hai tháng mà không hề để ý cho thấy chuyện tự mình quản lý context giờ quan trọng ít tới mức nào (theo video đăng ngày 18/10/2026).

![Context window visualizer của T3 Code: 109.013 token đang dùng, 10,9% của cửa sổ 1M, phân rã theo loại](https://homus.dev/photos/m-B3jIMMmUE-1323.jpg)

Visualizer mà agent dựng ra: 109.013 token đang dùng, 10,9% của cửa sổ 1M, 890.987 token còn trống, 32.580 token chi phí cố định mỗi thread, 76.433 token do cuộc trò chuyện này thêm vào. Thanh màu chia ra tool schemas, danh sách skill/tool/agent, system prompt của Claude Code, chỉ dẫn của T3 Code, file CLAUDE.md và phần hội thoại; bên dưới là bảng chi tiết từng tool.

Đương nhiên dùng Opus 5.5 ở mức extra high sẽ không đưa bạn dữ liệu hay tính năng ngay lập tức. Nhưng khi bạn có tư duy "cứ chạy ở nền rồi để nó bật lên khi xong", bạn nhận ra mọi việc mất bao lâu không quan trọng lắm, miễn là bạn không trông đợi hay cần nó ngay.

## 8. Hỏi thay vì build, và những thứ trước giờ không đáng build

Điều chính Theo muốn khuyến khích: hãy nghĩ về những thứ bạn muốn, rồi tìm cách có chúng mà không phải build, bằng cách hỏi. Anh nói anh không nói vậy vì muốn mọi người lười và đốt cả đống token thay vì viết code cho hiệu quả. Thực ra là ngược lại.

Khi bạn nhận ra có những thứ trước giờ chẳng bao giờ đáng để build, nhưng lại có giá trị riêng với bạn, bạn bỗng làm nhiều những thứ đó hơn hẳn. Anh từng tạo những visualizer sâu và phức tạp chỉ để giúp mình nghĩ thông một con bug đang cố giải. Anh tự build một nền tảng quản lý lịch sử nghe nhạc của mình, vì muốn gộp dữ liệu xuất ra từ dịch vụ nghe nhạc đang dùng với dữ liệu scrobble cũ từ Last.fm cho dễ hơn. Tất cả đều có thể là tính năng build vào sản phẩm khác, hoặc sản phẩm anh tự build cho mình, nhưng anh đã học cách coi chúng chỉ là prompt.

Theo nói bạn sẽ ngạc nhiên vì có thể tìm ra và làm được bao nhiêu thứ hữu ích nếu bắt đầu hỏi thay vì build. Anh quay lại tranh XKCD (kèm cảnh báo màn hình trắng chói) và bảo: hãy nhập vai anh chàng "ngây thơ" bên trái, với câu hỏi ngây thơ "ảnh này có phải con chim không". Thay vì xin anh build một tính năng trong T3 Code, hãy thử yêu cầu agent đưa ra đúng kết quả (outcome) bạn muốn.

Cách nghĩ Theo đề xuất: thay vì xin một tính năng rồi chờ, hãy hỏi agent thẳng kết quả mình cần.

## 9. Chọn sub-agent bằng một câu prompt

Theo nói cách nghĩ này hợp nhất với những lời phàn nàn của người dùng về agent. Ví dụ, có người vừa yêu cầu thêm vào lớp orchestration mới của T3 Code một tính năng để chọn sub-agent mà model sẽ dùng. Nghe thì có vẻ hay, cho tới khi bạn nhớ ra chính model là thứ chọn sub-agent nào, và bạn chỉ việc bảo nó.

Anh nói không phải để tâng bốc T3 Code, nhưng anh chuyển sang GPT-6.1-Sol mức Medium (theo màn hình) và yêu cầu:

```
Spin up 2 Opus 5.5 delegates to explore performance wins in T3 Code, summarize their thoughts, and then start a new thread using Grok 4.7 to implement your findings
```

Anh còn chọn được chạy trên máy nào; anh chọn chiếc laptop đang dùng để mọi người xem được và để Grok chạy được. Vậy là gói Codex của anh sẽ được dùng để khởi động việc này, nó sẽ gọi hai instance Claude Code nằm gọn bên trong thread này, và khi xong sẽ mở một thread mới với kết quả.

![T3 Code đang setup worktree cho thread Spin up 2 Opus 5.5 delegates](https://homus.dev/photos/m-B3jIMMmUE-1243.jpg)

Thread mới "Spin up 2 Opus 5.5 delegates to explore performance..." đang dựng worktree: đã fetch base branch, đang check out file, sau đó mới chạy setup script và khởi động agent. Model ở ô chọn là GPT-6.1-Sol, mức Medium.

Anh hoàn toàn có thể làm thêm một dropdown nhỏ, hoặc mở rộng dropdown hiện có thành một mục "nên dùng sub-agent nào". Nhưng bạn cũng có thể chỉ cần prompt. Lát sau, hai delegate đã chạy, và có thể thấy hai nhánh khám phá phía server và phía client bằng Opus 5.5 đang tiến hành, vì anh bảo nó dùng model đó. Anh không chọn model sub-agent ở đâu cả, anh chỉ nói điều mình muốn.

Và nếu bạn thấy mình nói đi nói lại cùng một điều, đó là lúc bắt đầu chỉnh skill và các file CLAUDE.md của agent.

Đúng lúc đó, bản phân tích context window cũng xong. Thay vì phải build một tính năng hiển thị context window vào T3 Code, anh chỉ hỏi, và giờ anh có bản hiển thị. Nếu có gì muốn đổi, có câu hỏi, hay muốn làm tiếp từ đó, anh chỉ việc hỏi và nhận thay đổi. Và nếu nó đủ hữu ích, anh có thể biến nó thành một skill để dùng lại về sau.

Theo nói anh nghĩ mình đã nói gần hết phần thứ nhất: phần về prompt và về chuyện rời khỏi chiếc hộp kỹ sư.

## 10. Mang tư duy này về lại engineering: npx t3 triage

Giờ tới phần "thịt" thật sự: chuyện gì xảy ra khi mình quay lại chiếc hộp kỹ sư với cách nghĩ này. Theo nói khi mang tư duy đó về công việc engineering, về việc làm sản phẩm, nhất là các thứ trong T3 Code, nó thay đổi tận gốc cách anh nghĩ về việc thêm gì và thêm như thế nào.

Anh kể một ví dụ anh build vì có người gặp lỗi khá nặng với T3 Code trên Windows: app crash liên tục, và anh về cơ bản phải viết prompt để người đó dùng trong Claude Code trên máy họ mà debug. Việc ấy truyền cảm hứng đủ để anh làm thành một tính năng.

Anh cho rằng một trong những thứ hay nhất của T3 Code thực ra không nằm trong T3 Code, mà nằm trong T3 CLI:

```
npx t3 triage
```

Đây là một trình triage dựng sẵn để debug lỗi bạn gặp trên máy. Anh đặt nó trong terminal vì muốn nó chạy được kể cả khi app desktop không mở lên được.

Theo đoán chắc người xem đang hình dung đủ thứ: chắc anh đã "slop" ra một tính năng phức tạp điên rồ, nối tới mọi góc của T3 Code để tìm xem chuyện gì đang xảy ra ở đâu, kiểu một bác sĩ thu thập toàn bộ dữ liệu rồi đoán lỗi nằm đâu. Anh nói không phải vậy.

Anh bấm Enter. Nó hỏi có cài bản stable không, anh chọn yes vì máy này chưa cài. Nó hỏi muốn dùng Claude Code hay Codex, anh chọn Claude Code. Rồi nó đẩy (pipe) prompt thẳng vào Claude Code, gửi prompt bằng harness bạn chọn. Prompt đó có các chỉ dẫn rất cụ thể.

![Claude Code mở từ t3 triage, hỏi người dùng What went wrong with T3 Code](https://homus.dev/photos/m-B3jIMMmUE-1523.jpg)

Claude Code (Opus 5.5, context 1M, high effort) được mở từ `t3 triage`. Lệnh đầu tiên bảo nó đọc file playbook triage và làm đúng theo đó; câu đầu nó hỏi người dùng là "What went wrong with T3 Code? Tell me in your own words.", kèm gợi ý mô tả đã làm gì, chuyện gì xảy ra, bắt đầu khi nào, và dán ảnh chụp màn hình nếu có.

## 11. Cả một flow gói trong một prompt lớn

Theo mở file prompt cho mọi người xem. Phần đầu nói: một người dùng T3 Code đang gặp vấn đề với bản cài và đã mở phiên này bằng `t3 triage`. Tiếp theo là "machine facts", trỏ tới file context được ghi ra lúc chạy lệnh, chỉ là dữ liệu cơ bản về T3 Code trên máy. Rồi anh bảo model làm theo playbook bên dưới.

Playbook bảo model rằng nó là một support engineer làm việc cùng người dùng, về cơ bản là bên trong một phiên coding agent, để debug, gỡ kẹt cho người dùng, và biến những gì học được thành một GitHub issue viết tốt nếu cần. Phần đầu playbook trên màn hình:

```
# T3 Code triage playbook

You are a support engineer for T3 Code (https://github.com/pingdotgg/t3code), working
inside a coding-agent session on the machine of a user whose install is misbehaving:
crashes, auth failures, broken setups, slow launches, or anything else. Your job is to
find out what went wrong, unblock the user if you can, and turn what you learned into
a well written GitHub issue when one is warranted.

A triage context file with machine facts (version, OS, paths, server liveness) was
provided alongside this playbook. Everything machine-specific lives there, not here.

## 1. Ask what went wrong

Your first message to the user: ask them to describe what went wrong, in their own
words. Ask them to paste screenshots directly into this session if they have any.
Ask follow-up questions when the description is vague. Good repro steps are the most
valuable thing you can extract from this conversation.
```

Theo nói anh đã có thể build một flow phức tạp: chèn câu hỏi một, bạn trả lời, rồi một hook nào đó chen vào để hỏi câu tiếp theo, hoặc chuyển sang giai đoạn sau. Anh đã đang build đúng như thế. Lúc mới bắt tay, anh thấy mình đang làm một tính năng T3 triage rất cầu kỳ. Rồi anh nhận ra: model thông minh mà, nó tự làm được. Thế là anh đưa toàn bộ flow muốn người dùng đi qua vào một prompt khổng lồ duy nhất.

![File prompt.md của T3 Code triage playbook với các bước Ask what went wrong, Read the machine facts, Check for a newer playbook](https://homus.dev/photos/m-B3jIMMmUE-1603.jpg)

File `prompt.md` mở trong editor: các bước "1. Ask what went wrong", "2. Read the machine facts" (đọc file context để biết phiên bản, hệ điều hành, server có đang chạy không, đường dẫn state, log, database), và "3. Check for a newer playbook" (tải bản PLAYBOOK.md mới từ repo, nếu khác thì làm theo bản đó).

Anh đi qua từng bước:

- Đầu tiên, hỏi chuyện gì sai. Tin nhắn đầu tiên gửi người dùng phải nhờ họ mô tả lỗi bằng lời của chính họ, nhờ họ dán ảnh chụp màn hình thẳng vào nếu có, hỏi thêm khi mô tả còn mơ hồ. Repro step tốt là thứ giá trị nhất có thể rút ra từ cuộc trò chuyện.

- Rồi đọc machine facts.

- Kiểm tra xem có playbook mới hơn không. Vì dự án là open source, anh để sẵn một link công khai tới playbook, phòng khi nó được cập nhật, để model có thông tin mới nếu bạn dùng bản nightly hay gì đó.

- Lấy source code, cũng vì là open source: model có thể clone source về xem có tìm ra bug ngay trong code không.

- Điều tra. Kiểm tra upstream xem bug đã được sửa chưa, rồi đưa ra các hướng xử lý cho người dùng.

- File issue nếu thật sự có issue để file, tức là khi đó không chỉ là lỗi cấu hình trên máy họ. Phải dọn sạch mọi secret và dữ liệu khác trước khi file issue có kèm dữ liệu.

- Ưu tiên issue trùng hơn issue mới: tìm tới issue có sẵn và comment ở đó thay vì mở cái mới.

Theo nói chỉ cần vậy là người dùng debug được vấn đề của họ. Họ chạy đúng một lệnh, nó đưa họ vào Claude Code hoặc Codex, và giờ họ sửa được lỗi. Tính năng này lúc mới làm định là hàng nghìn dòng code phức tạp. Rồi anh nhận ra nó có thể chỉ là năm dòng code và 30 dòng markdown, và giờ nó chạy tốt hơn hẳn.

Anh kể mình đã tốn không biết bao nhiêu công sức để làm cho việc dán ảnh vào T3 triage chạy được, để rồi điều hướng nó cho đúng, trước khi nhận ra: cứ để Claude hoặc Codex hỏi bạn dán ảnh vào là xong, dễ hơn nhiều. Chỉ cần chạy lệnh rồi giải thích vấn đề cho agent.

Cách T3 triage được làm lại: thay một flow nhiều bước viết bằng code bằng một lệnh ngắn cộng một playbook markdown để model tự dẫn người dùng.

## 12. Flow có quá nhiều nhánh, và hỏi agent xem nó còn thiếu dữ liệu gì

Theo nói đây là một trong hai điều anh thật sự muốn đẩy mạnh để mọi người nghĩ theo hướng này. Có rất nhiều flow quá động, có quá nhiều nhánh, quá nhiều cái hố kỳ quặc người dùng có thể rơi vào, đến mức không thể làm một tính năng phức tạp hỗ trợ mọi thứ họ có thể cần.

Nếu anh biết hết mọi cách T3 Code có thể hỏng, thì anh đâu cần tính năng này, vì anh đã sửa hết rồi. Thực tế là anh không biết. T3 Code có thể và sẽ có lỗi khiến người dùng không mở được nó, không làm nó chạy như ý được. Cho những ca đó đi qua Claude Code hay Codex làm cho khả năng chúng được giải quyết khi người dùng chạm tới các góc cạnh ấy cao hơn hẳn, mà T3 Code không cần có sẵn đúng tính năng để tìm ra vấn đề cho họ.

Vậy nếu một nửa những thứ lẽ ra phải build thực ra chỉ nên là một file markdown, thì còn lại gì để build? Theo nói: "Tôi không biết. Hỏi thử xem."

Anh lấy ví dụ ngay trong cửa sổ T3 triage đó. Anh từng gặp lỗi một bản build gần đây bị nháy (flickering) khi tạo thread mới. Anh khá chắc nó đã được sửa gần đây, nhưng sửa rất vất vả vì anh nghĩ team log chưa đủ dữ liệu về cách chính app đang render. Anh đọc (bằng giọng nói) cho agent đại ý:

```
If I was to ask you to debug issues with rendering in T3 code right now, is the data available to you to see what happened in the past? If not, how would you recommend we introduce that data so that you'll have more access to more useful info in the future?
```

Rồi anh chen vào một đoạn: anh không hiểu sao người ta sống được trong terminal. Anh chỉ đọc một đoạn văn bằng giọng nói và không thể đọc lại nó cho thoải mái. Anh nói thẳng, bằng giọng rất gắt: các bạn hãy ra khỏi terminal đi, đừng tự cao nữa, các bạn sai rồi. Anh từng là người cực mê terminal, và anh không làm được nữa, thật sự không làm nổi nữa.

Vì đây là toàn bộ flow triage nên nó sẽ làm khá nhiều bước phụ, nhưng cuối cùng nó sẽ cho anh biết nó có và không có quyền truy cập vào những gì, rồi gợi ý những thứ anh có thể mở ra cho nó. Theo nói anh thường xuyên ngạc nhiên vì có quá ít kỹ sư nhận ra mình làm được điều này.

Vòng lặp Theo dùng: hỏi agent xem nó có đủ dữ liệu không, nghe nó nói thiếu gì, rồi mở thêm đúng những thứ đó.

## 13. Hỏi agent nó làm được gì: ví dụ computer use

Một ví dụ thật khác Theo làm cách đây không lâu: anh muốn biết cần gì để thêm những khả năng computer use có giá trị hơn vào T3 Code. Anh biết computer use trong app desktop ChatGPT Codex rất tốt (nhận định theo video đăng ngày 18/10/2026). Nên anh hỏi thẳng nó: hãy mô tả chi tiết những khả năng "computer use" mà bạn có quyền truy cập.

```
Describe in detail the "computer use" capabilities that you have access to
```

Mọi thông tin đó đều nằm trong context window của nó, có sẵn ở đó, và anh chỉ việc hỏi nó đưa dữ liệu ra và cho anh biết đó là gì. Sau đó anh dùng thông tin đó để tự build. Anh copy phần mô tả mọi thứ nó làm được, dán vào Opus trong T3 Code và bảo: hãy clone càng nhiều càng tốt. Và nó làm được. Theo video, phần đó vẫn đang nằm trong một PR, và team còn vài kế hoạch thú vị khác.

Anh nói: bạn có biết hay tới mức nào không, khi bạn có thể hỏi thẳng nó có quyền truy cập những gì? Và nếu thấy nó có ít quyền hơn so với ở một công cụ khác, hãy bảo nó tóm tắt sự khác biệt.

Danh sách khả năng nó đưa ra: nó khám phá được app, mở được app, đọc được giao diện, nhìn được giao diện bằng cách chụp màn hình thay vì chỉ lấy dữ liệu text có cấu trúc. Nó dùng được chuột với click, double click, right click, kéo và cuộn. Nó dùng được bàn phím, sửa được các ô nhập, dùng được tab trình duyệt, xử lý file, và thậm chí kiểm tra lại kết quả của chính mình. Nó đọc được theo hai cách: qua accessibility tree và qua ảnh chụp màn hình.

![ChatGPT trả lời về computer use: hai cách đọc giao diện là accessibility tree và screenshot](https://homus.dev/photos/m-B3jIMMmUE-2103.jpg)

Câu trả lời trong ChatGPT: cuối bảng khả năng là "Handle files" và "Verify results", rồi phần "There are two main ways I can read an interface": accessibility tree (mô tả có cấu trúc, ví dụ biết một nút tên "Save" hay một checkbox đã được chọn) và screenshot (để xem layout, ảnh, biểu đồ, control tuỳ biến rồi click hay kéo theo toạ độ). Trên màn hình, nó còn ghi trình tự bình thường là xem giao diện, thao tác, rồi xem lại trạng thái mới.

Phía trên câu trả lời, trên màn hình còn ghi tool chính là `mcp__cua_repl`, chạy JavaScript trên một API điều khiển máy tính, và rằng điều khiển app Mac native cùng một kết nối trình duyệt tương thích Chrome đang khả dụng (tại thời điểm quay, theo video đăng ngày 18/10/2026). Giờ Theo có tất cả thông tin về những gì nó làm được, và anh có được nhờ hỏi.

Và nếu bạn thấy model không làm được, hay không làm, một việc bạn muốn, bạn cũng hỏi về chuyện đó được. Theo liệt kê những câu kiểu:

- Sao bạn không thêm ảnh chụp màn hình vào PR này?

- Tool nào sẽ giúp bạn thêm ảnh chụp màn hình vào các PR sau?

- Sao bạn không tìm ra con bug này? Sao issue này vẫn còn xảy ra?

- Bạn tự chạy thử rồi tìm xem sao nó xảy ra được không?

- Bạn đọc lại nội dung thread kia rồi tìm xem chỗ nào sai được không?

## 14. Prompt về mọi thứ, và chuyện "brain rot"

Theo nói bạn có thể prompt về chính prompt của mình. Prompt về chương trình của mình. Prompt về hệ thống của mình. Prompt về câu hỏi của mình. Prompt về cả đống thứ chẳng liên quan gì tới engineering.

Anh từng prompt để gom toàn bộ file chụp MRI từ các trang web của bác sĩ. Anh đã có thể viết một chương trình đi qua mọi portal của mọi bác sĩ, thu thập và sắp xếp hết các file PDF, hoặc anh có thể nhờ một agent đi làm việc đó.

Nghe nói cách nghĩ này giờ bị gọi là "brain rot". Theo cho rằng người ta cũng từng nói y như vậy về email hồi nó mới ra. Kiểu: sao phải tới gặp bác sĩ hay gửi thư, cứ email cho họ là được. "Thế thì ngớ ngẩn, anh đâu có nhận được lời khuyên thật từ đó." Ừ, đúng, nhưng có rất nhiều việc mà gửi cái email chết tiệt đó dễ hơn hẳn. Và không phải kiểu "tôi gửi email rồi không bao giờ gặp ai nữa". Mà là "tôi gửi email cho những việc mà đằng nào tôi cũng chẳng đi gặp trực tiếp".

Anh tự hỏi: anh có dành ít thời gian gặp bạn bè ngoài đời hơn so với hồi năm tuổi, khi chưa có internet không? Có, một phần. Nhưng anh đang nói chuyện với số người nhiều gấp 10 lần, và phần lớn họ là những người anh sẽ không bao giờ được nói chuyện, vì họ không có mặt quanh anh trước thời internet và anh không có cách nào liên lạc.

Với prompt cũng vậy. Không phải anh chọn prompt thay vì build. Mà là anh chọn prompt cho những thứ trước giờ anh chẳng bao giờ thèm build.

Giống email không thay thế việc gặp nhau mà mở thêm những cuộc trò chuyện chưa từng có, prompt mở thêm những việc trước giờ không ai bỏ công build.

Và khi nhận ra điều đó mạnh tới mức nào, anh đi thêm một bước: tập trung việc build của mình vào việc tạo ra primitive và workflow, tooling, pipeline, đường dữ liệu và quyền truy cập mà agent cần, để prompt của anh làm được nhiều hơn.

## 15. Nối email vào ChatGPT và xây pipe cho agent

Tới đây là ví dụ ngớ ngẩn nhất, nhưng Theo nghĩ ai cũng cần làm, và anh biết nhiều người chưa làm: hãy nối email của bạn vào ChatGPT. Anh biết nghe thì điên rồ. Chính anh đã trì hoãn rất lâu. Và anh biết còn điên hơn khi nói nó thay đổi đời anh nhiều tới vậy, nhưng nó thật sự đã thay đổi.

Anh có năm hộp thư, bốn trong số đó phải theo dõi liên tục. Anh đã tốn rất nhiều thời gian "quấy rầy" đội ngũ Superhuman để nó chạy đúng như lẽ ra phải chạy. Theo anh, Superhuman từng là email client tốt nhất rồi cứ thế mục ruỗng dần; trang web Gmail thì tệ, và mọi app email khác còn tệ hơn (nhận định cá nhân theo video đăng ngày 18/10/2026). Anh đã suýt tự làm app email riêng suốt khoảng bốn năm, và gần đây lại suýt nữa.

Khi bị đau tay và không xử lý email dễ như trước, anh miễn cưỡng thử tính năng cho phép nối email (nhiều hộp thư cùng lúc) vào tài khoản ChatGPT. Anh đi từ chỗ mở hộp thư 10 lần một ngày xuống còn khoảng một lần một ngày. Giờ anh chỉ hỏi agent. Tốt hơn hẳn.

Với những công cụ agent anh dùng, anh còn có thể dặn nó canh một loại email nhất định. Ví dụ: để ý email từ Amazon, vì anh biết sắp có một hoá đơn AWS rất lớn. Hoặc làm hẳn kiểu điên hơn: thấy email hoá đơn AWS, anh bảo agent "cái này có vẻ lớn quá, bạn vào dashboard AWS của tôi tìm xem sao chi phí cao vậy và giúp tôi giảm xuống được không?", rồi để nó khởi động thêm một loạt agent và chương trình khác, mà trong trường hợp của anh thường là T3 Code.

Vì anh đã nối MCP của T3 Code vào Codex, anh có thể để Codex và agent kia mở thread trong T3 Code. Anh đã tạo ra các pipe để những thứ này nối được với nhau, và nối dữ liệu mà agent cần để hoạt động. Giờ anh đi được từ chỗ agent lần theo một email cho anh, tới chỗ ship thay đổi thật với các agent khác và các chương trình khác trên khắp hệ thống của mình.

Chuỗi Theo mô tả: một email hoá đơn kích hoạt agent, agent gọi Codex, Codex mở thread trong T3 Code qua MCP để tìm và sửa nguyên nhân chi phí.

## 16. Chưa bao giờ thấy mình giống một kỹ sư đến thế

Và đây là điều điên rồ nhất trong tất cả: Theo nói anh chưa bao giờ cảm thấy mình giống một kỹ sư đến vậy. Có những lúc cảm giác đó mất đi, và anh thậm chí đã bị người ta chỉ ra vài lần như vậy.

Khi bạn bắt đầu lướt qua code mà không đọc kỹ, chấp nhận rằng ngôn ngữ đang dùng hay framework được kéo vào không còn quan trọng như trước, bạn bắt đầu thấy mình bớt giống kỹ sư. Những thứ bạn dành cả đời quan tâm không còn quan trọng như trước nữa, và điều đó thật tệ. Nhưng đó chỉ là đáy của thung lũng tuyệt vọng (the trough of despair).

Vì khi bước ra khỏi đó, và nhận ra rằng để agent làm được điều mình muốn thì chúng cần những hệ thống tốt hơn để vận hành bên trong, bạn sẽ thấy những trò khéo léo "vớ vẩn" từng khiến anh mê engineering chưa bao giờ có giá trị hơn. Những thứ như:

- Nhận ra một câu hỏi, một tính năng, hoá ra chỉ cần là một prompt.

- Giải pháp khéo như thêm một debug flow chỉ việc đẩy bạn sang Claude Code hoặc Codex.

- Mở giao diện của ứng dụng qua MCP để các agent khác truy cập và điều khiển được.

- Thêm WebMCP vào một dashboard vừa build để làm được nhiều hơn với nó và truy cập nó theo những cách khác.

Theo nói engineering đang vui kinh khủng. Năm nay anh đã build khoảng năm app Rust và hiểu sâu hơn hẳn về quản lý bộ nhớ hiện đại, vì anh muốn build cho một tương lai nơi agent chạy trên phần tính toán gần như miễn phí, nhờ chạy được trong isolate.

Anh có đủ thứ ý tưởng engineering điên rồ, xa vời, trước đây không khả thi vì không đủ nhân lực để build. Và chúng cũng không hữu ích lắm, vì chưa có đủ kỹ sư viết code cho những primitive mới đó để chúng có giá trị. Giờ anh đang giải những bài toán trước đây không đủ quan trọng và tốn quá nhiều công để giải, vì bỗng nhiên bài toán quan trọng hơn và lời giải dễ với tới hơn.

![Bảng trắng I've never felt more like an engineer với đường cong cảm giác làm kỹ sư theo thời gian](https://homus.dev/photos/m-B3jIMMmUE-3143.jpg)

Bảng trắng "I've never felt more like an engineer.": một đường cong lên xuống theo thời gian, tụt sâu xuống dưới đường gạch ngang ở đoạn có AI, rồi vọt lên cao hơn mọi đỉnh trước đó. Hai mũi tên chỉ vào đỉnh cũ và vào đoạn đi lên sau đáy.

## 17. Primitive thay vì tính năng

Theo nói tất cả quy về một ý: vứt bỏ cách làm engineering suốt nhiều năm để làm ra những thứ tốt hơn bằng prompt, nếu nói thật lòng.

Anh không đếm xuể bao nhiêu lần anh lướt qua các feature request của T3 Code, các issue trên repo, hay những thứ người ta nhắn riêng để xin. Ít nhất một nửa là thứ họ có thể tự prompt, không phải để mở rộng T3 Code, mà chỉ để dùng nó. Ý tưởng rằng một tính năng có thể chỉ là chính sản phẩm, và số tính năng "có sẵn" trong T3 Code vì bạn chỉ việc hỏi agent, thật là điên rồ.

Nhưng team phải build thêm primitive để mở những khả năng đó ra. Ví dụ, khi anh xin một visualizer, nó đưa anh một trang HTML để mở ra xem, rất hay, nhưng anh không nên phải rời T3 Code để xem nó. Anh có thể mở trong trình duyệt tích hợp trong app, thứ anh đang tắt vì vài lý do lặt vặt; anh bật lên ngay: "Open integrated browser", xem ở đó được. Nhưng sẽ hay biết bao nếu agent tự làm visualizer ngay trong dòng hội thoại. Codex có cái đó; T3 Code thì chưa (theo video đăng ngày 18/10/2026).

Theo nhấn mạnh những primitive bổ sung đó không phải tính năng mới theo nghĩa thêm một nút để người dùng bấm làm gì đó. Mục đích của tool mới là để người dùng có thể tự build tính năng động của riêng họ. Đó là điều anh rất hào hứng.

Team build primitive ở tầng dưới; các "tính năng" phía trên là thứ người dùng tự tạo bằng prompt khi cần.

## 18. Đường cong cảm giác làm kỹ sư và thung lũng tuyệt vọng

Điều cuối cùng Theo muốn nói là với những người chưa cảm nhận được điều này, những người vẫn thấy mình đang mất đi thứ mình yêu và engineering mỗi ngày một kém vui. Anh nói anh thật sự hiểu, nhất là sau khi nói chuyện với nhiều người đang ở hoàn cảnh đó. Nhưng anh thật lòng nghĩ phần lớn họ đã gần tới cuối đoạn đó rồi.

Anh vẽ đường cong "mình thấy mình giống kỹ sư tới mức nào theo thời gian". Lúc mới bắt đầu, chắc bạn chẳng thấy mình giỏi. Rồi bạn bắt đầu thấy khá ổn. Rồi bạn nhận ra mình thực ra hơi ngốc. Rồi bạn dần giỏi lên, giỏi lên. Hầu hết kỹ sư đã đi qua chuyện này ở mức nào đó, nhưng giờ nó rối hơn, vì mình cứ giỏi engineering lên mãi, rồi bỗng nhiên cảm giác đó ập tới cùng AI: những việc mình đang làm không còn là giải các hệ thống phức tạp hay debug code nữa, giờ mình chỉ gửi prompt.

Nhưng theo thời gian bạn sẽ nhận ra những thứ đáng build giờ sâu và phức tạp hơn nhiều (nhận định của Theo theo video đăng ngày 18/10/2026). Theo nói anh là một product engineer, build sản phẩm người ta trả tiền qua subscription, và kiếm tiền qua quảng cáo (anh chào những người đang xem trên YouTube). Những bài toán đáng giải với anh trước đây xoay quanh việc lắp ghép các mảnh ra sao và làm giải pháp cho người dùng thế nào. Giờ anh đang build hệ điều hành của riêng mình và compiler của riêng mình.

Không phải vì trước đây anh không muốn rồi giờ bỗng muốn. Anh làm vậy vì giờ nó hợp lý hơn. Những bài toán anh giải được theo cách đó giờ quan trọng hơn, và những lời giải đó giờ khả thi hơn để build. Động lực để build đã tăng lên. Độ phức tạp của thứ bạn có thể build một mình cũng tăng lên. Lượng engineering anh làm mỗi ngày cao hơn rất, rất nhiều, và độ phức tạp của các bài toán anh dành thời gian nghĩ cũng cao hơn nhiều.

Anh còn nghĩ chi tiết từng câu SQL query trong codebase không? Không, chắc chắn không. Nhưng anh có nghĩ về cách kết nối giữa database SQL và tầng server hoạt động thế nào, và liệu có cách tối ưu thêm, tự build tầng kết nối riêng để giữ nó luôn "ấm" mà không đội chi phí lên nhiều không? Có, chắc chắn có. Anh có đang build tech stack của riêng mình mà bạn chạy được bằng `npx create-t3-app` không? Không. Anh đang build JavaScript runtime của riêng mình cho cloud của riêng mình.

Theo nói anh đang engineer vất vả hơn bao giờ hết, và não anh đang làm việc nhiều hơn bao giờ hết. Nếu bạn thấy anh lướt qua một đống code do Claude viết trong một dự án mà mọi thứ đều chạy tốt, được test rất kỹ, rồi nghĩ anh làm vậy vì não anh đã "thối", thì bạn hiểu sai từ gốc lượng công việc engineering mà giờ mình có thể làm.

Đường cong Theo vẽ: lên xuống khi mới học, leo lên một đỉnh, tụt xuống thung lũng khi AI làm mọi thứ có vẻ vô nghĩa, rồi vượt qua đỉnh cũ khi nhận ra còn bao nhiêu thứ để build.

Theo nghĩ nhiều người đang chê các developer dùng AI là "brain rot" làm vậy vì chính họ đang ở đúng đáy đó. Họ thấy tệ vì đã dành cả sự nghiệp để leo lên đỉnh cao mình từng đạt, tốn biết bao thời gian để lên tới đó. Rồi AI làm mọi thứ có cảm giác vô giá trị, vô dụng và ngớ ngẩn.

Nhưng khi đi qua được cái đáy đó, khi thung lũng tuyệt vọng đi tới điểm cuối, bỗng nhiên não bạn sẽ làm việc nhiều hơn bao giờ hết. Anh mong mọi người nắm lấy cơ hội để nghĩ lại mọi thứ, và chịu sống trong cái đáy này một chút. Ở dưới này tệ lắm, cảm giác rất khó chịu, như mọi thứ mình từng làm đều vô giá trị, vì những tính năng mình muốn thêm hoá ra chỉ là prompt, không phải tính năng. Nhưng khi chạm tới mép của nó, khi thấy AI không làm được gì, bạn sẽ nhận ra còn rất nhiều thứ phải build để tận dụng nó tối đa.

Theo nói đó là cách anh muốn mọi người nghĩ từ giờ, vì đây chính là cú mở khoá khiến anh hào hứng tới vậy. Hoặc bạn có thể quay lại nói rằng anh nghĩ vậy chỉ vì được OpenAI trả tiền. Anh đáp: được thôi, nghĩ vậy dễ hơn cho các bạn; và anh nói nửa đùa rằng anh nóng lòng chờ các bạn thất nghiệp nếu cứ nghĩ như thế. Còn với những ai thật sự yêu việc build, chưa bao giờ có nhiều thứ để build đến thế, và chưa bao giờ có nhiều lý do để build đến thế. Anh mong video truyền cảm hứng cho mọi người: hãy đi build một thứ gì đó thật hay.

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

- Tên gốc: Your prompts kinda suck
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=m-B3jIMMmUE](https://www.youtube.com/watch?v=m-B3jIMMmUE)

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

- Repo T3 Code (open source), nơi có lệnh `t3 triage` và các issue Theo nhắc tới: [github.com/pingdotgg/t3code](https://github.com/pingdotgg/t3code)

- Playbook triage của T3 Code, đúng link xuất hiện trong prompt trên màn hình (bản trên repo có thể đã được cập nhật dài hơn bản trong video): [PLAYBOOK.md](https://raw.githubusercontent.com/pingdotgg/t3code/main/.github/triage/PLAYBOOK.md)

- Tranh XKCD "Tasks" (số 1425): [xkcd.com/1425](https://xkcd.com/1425/)

Nguồn: https://homus.dev/talks/your-prompts-kinda-suck · cập nhật 2026-10-19