▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=m-B3jIMMmUE
• Original title :: Your prompts kinda suck

Theo argues that engineers are bad at prompting not because they under-engineer prompts, but because they over-engineer everything else: they keep thinking in features that have to be built into a tool, when much of that is information an agent can just produce on request. Using T3 Code examples (tool-call timing report, context-window visualizer, sub-agent selection, the npx t3 triage debug flow), he shows features that turned out to be prompts. Back inside the "engineering box", the job shifts to building primitives, data pipes and access (MCP, Web MCP, inline visualizers) so prompts can do more. He closes on the "trough of despair" that engineers feel with AI, saying the engineering on the other side is deeper and more fun than before.

Leave the engineering box

• XKCD 1425 ("check if the photo is in a national park... and of a bird") used to show that normies can't judge technical difficulty. Now engineers have the opposite problem: they don't know what they can ask an agent for, because they think in code.
• Real example: a friend wanted a T3 Code feature showing which tool calls are slowest. Theo's answer: "we already have this" - just ask the agent. A few minutes later he had an HTML report of all tool calls on the machine (one home-directory search ran 41.7 minutes).
• Earlier audits like this showed that most of Claude's failed tool calls were ripgrep invocations with Bash-only syntax breaking under Zsh.
• Context-window breakdown: asking for a visualizer showed that his proxy setup made Railway inject 70k tokens into every request for two months, unnoticed. To him this shows how little manual context management matters now.
• His own mistake: he kept adding buttons to a T3 Code "dashboard of all running threads" (rename, close, merge, regen titles), then realized it should be a meta-thread chat connected to all instances, where you just ask for what you want, a dashboard included.
• Sub-agent selection: users requested a dropdown to choose sub-agent models, but the model already picks sub-agents, so just say "spin up two Opus 5.5 delegates, summarize, then start a Grok 4.7 thread to implement".
• Run slow, high-effort requests in the background and let the result pop up. Latency barely matters if you don't need it right away.
• If you keep repeating the same prompt, move it into a skill / agent / CLAUDE.md.
• Prompting doesn't mean less work. It unlocks things that were never worth building: one-off bug visualizers, a personal music-history platform merging Tidal and Last.fm data.

Back in the box: features become markdown

• npx t3 triage runs in the terminal, so it works even when the desktop app won't start. It asks for Claude Code or Codex and pipes in a single large prompt: machine facts, plus a playbook acting as a support engineer.
• The playbook: ask the user what went wrong (with screenshots and follow-ups, since repro steps are the most valuable part), read machine facts, check for a newer playbook, clone the open-source repo, investigate, check upstream for fixes, offer outcomes, scrub secrets, and comment on existing issues rather than filing duplicates.
• What started as thousands of lines of staged flow and hooks (including routing pasted images) became ~5 lines of code and ~30 lines of markdown, and it works better. Flows with many branches and unknown failure modes suit agents better than hard-coded features.
• What's left to build? Ask the agent: "is the data available for you to debug rendering issues? If not, what should we log?"
• Ask agents to describe their own capabilities: he had Codex describe its computer-use tools in detail (app discovery, accessibility tree plus screenshots, mouse, keyboard, tabs, files, verification), then gave that to Opus in T3 Code to clone.
• Prompt about prompts, programs and systems: "why no screenshot in this PR?", "what tool would help?", "read this other thread's transcript and find what went wrong".
• Aside: he no longer understands living in terminals, since he can't read a voice-dictated paragraph there.

Primitives and pipes

• He gave his email inboxes to ChatGPT after a hand injury. He went from checking email ~10 times a day to about once, and asks agents instead. Tools like dot can watch for specific emails (e.g. an AWS bill), then investigate costs and spin up T3 Code threads via its MCP.
• He doesn't prompt instead of building. He prompts for things he never would have built, then focuses building on primitives, workflows, data pipes and access for agents.
• Next primitives for T3 Code: inline agent-made visualizers (Codex has them), so users can build their own dynamic features without new buttons.
• At least half of T3 Code feature requests are things users could just prompt for.

The trough of despair

• Glossing over code and caring less about languages and frameworks makes you feel less like an engineer. Theo calls this the trough.
• Coming out of it: agents need better systems to work in, so cleverness is worth more than ever (a debug flow that hands off to an agent, exposing an app over MCP, adding Web MCP to dashboards).
• His own work got deeper: five Rust apps this year, memory management, his own JavaScript runtime for his own cloud, connection layers between the DB and server. He doesn't review every SQL query any more, but the problems he solves are harder.
• He thinks the critics calling this brain rot are stuck in the trough after a long career climb. There has never been more to build or more reason to build it.