Theo says your prompts kinda suck. The fix is on your side of the keyboard.

Theo Browne says engineers overengineer their prompts. The gist of his new video, the examples worth knowing, and what it asks of the person.

A man in glasses and a dark jacket types on a laptop at a wooden desk, an open notebook and pen beside it, in a bright office with a brick wall and shelves behind him.
Photo: Vitaly Gariev / Unsplash

Theo Browne posted Your prompts kinda suck on 18 October. It runs 32 minutes, and it is one of his more practical videos. Here is the gist, the examples worth knowing, and what we think it asks of the person at the keyboard. The video mostly talks about the agent side of that.

Theo Browne, t3.gg, 18 October 2026. 32 minutes. Watch on YouTube

The gist

Theo opens with a twist on “prompt engineering”. He thinks engineers are bad at prompting, but not because they don’t engineer their prompts enough:

“I think it’s ’cause they’re overengineering it, and they’re not taking the opportunity that prompting offers us to take a step back and rethink how the computer can work for us.” (0:20)

His argument is that developers still treat what they want as a feature someone has to build: a dashboard, a dropdown, a diagnostic tool. Often it is really a question, and the agent can just answer it. In his words, these are “features that aren’t actually features, they’re information” (7:40). Once you stop building those, your engineering moves down a level, to the data, access and pipelines that let a prompt do more.

The examples worth knowing

The tool-call report (5:46). A friend who had just started a company through Y Combinator asked Theo to add a feature to T3 Code that would show which tool calls were slow. Theo opened a new thread instead and typed: “break down all my tool calls so I can find which ones are slowest and optimize my environment”. In under three minutes the agent went through about 66,000 operations from July to October and built an HTML report. The worst one was a search across the whole home folder that had run for 41.7 minutes. An earlier audit like this had found that Claude was writing ripgrep commands that worked in bash and failed in zsh, which was the shell on most of his machines.

The dashboard he didn’t need (7:54). Theo had been designing a dashboard for T3 Code’s background tasks, adding one button after another: rename threads, close idle ones, merge pull requests. Then he saw it could be a single chat thread connected to all his T3 Code instances, where you just ask for what you want.

The triage tool (14:11). A Windows user’s app kept crashing on startup. Theo started planning a diagnostic tool and a way to route screenshots into the terminal, and it was heading for thousands of lines. What shipped as npx t3 triage is five lines of code that collect facts about the machine and hand a 30-line Markdown playbook to Claude Code or Codex. The playbook tells the agent to ask what went wrong, read the machine facts, get the source, investigate, check for existing issues, redact private details, and file a clean bug report.

“This feature when I first started working on it was going to be thousands of lines of complex code, and then I realized it could be five lines of code and then 30 lines of markdown, and now it works way better.” (17:31)

The 70,000 tokens (9:51). Asking an agent to chart what was filling its context window turned up a misconfigured proxy on Railway. For two months it had been adding about 70,000 tokens to the front of every request, and he hadn’t noticed.

He also covers dropping a sub-agent dropdown because you can just tell the model which agents to use, gathering MRI files from several doctors’ portals, and going from checking email ten times a day to about once, after a hand injury pushed him to connect his inboxes to ChatGPT.

Built, or asked for. Source: Theo Browne, “Your prompts kinda suck”, t3.gg, 18 October 2026.
What was wantedThe feature you would buildWhat Theo did
See which tool calls are slowA timing dashboard in T3 CodeOne prompt, and a report in under three minutes
Manage background tasksA dashboard with a button for every actionOne chat thread connected to every T3 Code instance
Diagnose crashes on users’ machinesThousands of lines of branching diagnosticsFive lines of code and a 30-line Markdown playbook
Pick models for sub-agentsA dropdown in settingsTell the model which agents to start
Collect MRI files from doctors’ portalsA scraper for each portalAsk an agent to log in and gather the PDFs

What it asks of the human

Theo’s advice is mostly about where to put your engineering. We are building Sense to work on the person rather than the AI, so here is what we took from the video about judgment.

1. Catch the urge to build

Theo uses the xkcd comic “Tasks” (3:53). Checking whether a photo was taken in a national park takes a few hours. Checking whether it shows a bird needs “a research team and five years.” Non-developers used to get this wrong one way. Theo’s point is that developers now get it wrong the other way: “we don’t know what we can ask the agent for because we’re always thinking in code.”

What he is showing is not a prompting trick. It is the moment before the prompt, when you ask whether the thing needs to exist at all. Theo missed that moment himself with the dashboard, and he builds these tools for a living. That is what makes the video honest.

Try it: list the last three things you built, or had an agent build, to look at information: a dashboard, a report, a script. Could you have asked for the answer instead?

2. Throwing away what you started is a judgment call

In both the triage tool and the dashboard, Theo had already started the big version. Stopping work you have invested in is one of the harder calls in any job. With agents it gets harder, because the work keeps arriving faster than your doubts about it.

Try it: think of the last thing you abandoned. How long did it keep going after you first had doubts? What made you stop?

3. A dumber prompt needs a sharper person

“Break down all my tool calls so I can find which ones are slowest” is a short prompt. It is short because Theo knew exactly what he wanted to find out, and when the report came back he could tell which line mattered. The work didn’t disappear. It moved to two things only you can do: knowing the outcome you want, and judging whether the answer is right.

The report an agent hands back is a claim about your machine, not a fact about it. We wrote about that in A passing check is a claim, not evidence.

Try it: before your next short prompt, write down in one sentence the outcome you want and what would make you believe the answer. If you can’t, the prompt isn’t dumb, it’s vague.

4. Nobody checks what looks fine

Theo takes the 70,000 tokens as proof that managing your context by hand matters less now: “I had a 70k token context thing at the front of all my prompts for the last two months and didn’t even notice” (10:13). That may be true. We read the same story another way too. Something was wrong in every request for two months, and nothing felt wrong. It only showed up when he asked to see it.

What showed up once Theo asked. A misconfigured proxy added 70,000 tokens of extra context in front of every request for two months. The slowest tool call was one search across the whole home folder, at 41.7 minutes. Claude’s search commands, written for bash, had a higher error rate on zsh, the shell on most of his machines. The tool-call report took under three minutes and covered about 66,000 operations from July to October.
Nothing felt wrong until an agent was asked to look.

We think the same goes for how each of us works with AI. Most of us carry a story about our own work: I’m careful, I always check, I’m better at this than I was in spring. Like the proxy, that story goes unchecked until someone looks at the record. That is the question Sense is built around: is the person getting better, and how would they know?

Try it: pick one thing you believe about how you work with AI, such as “I always read what the agent changed”. Go through your last ten sessions and count.

5. Name the trough

Near the end, Theo draws a curve of how it feels to be an engineer over time (28:18): years of climbing, a peak of mastery, then a steep fall when AI arrives and the things you were proud of start to matter less. He calls it the trough of despair, and says he has been in it. His way out was to aim his skill at harder problems: compilers, runtimes, infrastructure. “I’m engineering harder than I’ve ever engineered, and my brain is working harder than it’s ever worked” (30:14).

A curve of how it feels to be an engineer over time, redrawn from Theo Browne’s sketch. It rises to a peak labelled mastery, falls steeply when AI arrives into the trough of despair, then climbs past the old peak toward primitives, pipelines, compilers and runtimes. Under it, Theo’s quote: I’m engineering harder than I’ve ever engineered, and my brain is working harder than it’s ever worked.
Theo Browne’s curve, redrawn by us. From the video at 28:18.

That is the most human part of the video, and it goes beyond code. Writers, designers and strategists are feeling the same drop. The question it leaves is not whether your old skill still matters. It is where your best thinking is going now, and whether you would notice if it stopped going anywhere.

Try it: at the end of this week, write down the hardest thing you thought through yourself, not the hardest thing the agent did. If it is hard to name, that is worth knowing.

Watch it if

  • You build tools for other developers or for your own team. The tool-call report and the triage tool are worth the time on their own.
  • You have a setup full of long prompts and rules files, and you want an argument for cutting back.
  • You are somewhere in that trough. Start at 24:58.

The sponsor segment runs from 1:46 to 3:36.

Your prompts kinda suck, Theo Browne, t3.gg, 18 October 2026. The comic is xkcd 1425, “Tasks” by Randall Munroe.

All writing