▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=q1D90-uGvBg
• Original title :: You're using AI agents wrong

Theo, who by his own account barely has time to code any more, went from 1-3 merged PRs a week to 52 — the peak week being one he spent travelling to DefCon on hotel wifi. This video is a live walkthrough of the workflow that made that possible: agents running on a remote Linux box, an inbox-shaped thread list, tokens spent liberally to keep his own attention from wandering, and a large amount of infrastructure built purely to remove friction from the merge button.

Run the agents somewhere else

Step one of every task is a new thread; step two is making sure the work is not running on the machine he is using for everything else. His setup is an over-specced Linux box in the next room holding all his repos plus a T3 Code server, selected as the execution target for each thread, with all harnesses (Claude Code, Codex) available on it. Work happens in worktrees — not the ideal abstraction, but good enough to spin up many cheaply.

The reason is throughput under parallelism. With multiple threads each running several sub-agents, plus other background work, the 32-core Linux box sits at 5% CPU; he has run 40+ agents on it without strain, and a $600 16-thread machine would sit at 12% for the same load. macOS, by contrast, he treats as a one-or-two-tasks-at-a-time machine because it parallelises badly. Moving dev work to Linux is, in his words, one of the biggest productivity hacks he has found — take any old laptop, install Ubuntu, and the multi-agent experience improves dramatically.

Anatomy of a prompt

He dictates prompts with Whisper Flow and doesn't clean up the formatting — models are good enough at turning "slop voice-to-text" into intent. What he is deliberate about is structure. Walking through his prompt for a skill invocation bug:

• Say that real users are affected. Not strictly necessary, but it tells the model this is production work, not an experiment.
• State priorities as a no-compromise line. "A fix that is simple in its implementation and not confusing to users" is his hard requirement.
• Then hedge with "in my opinion". This gives the model explicit room to push back or tell him the approach isn't viable.
• Say where your own understanding ends. Declaring what he doesn't know about Claude Code's behaviour stops the model blindly trusting his framing and makes it explain the right things back.
• Give one clear ask. A thorough audit of both Claude Code's behaviour and their implementation of it.
• Give the model an early exit. "If you see a simple fix, stop and let me know" so it doesn't chase option one of seventeen while four sub-agents explore.
• End with the desired end state, worded as "a confident path to a solution" so it doesn't interpret it as permission to write code.

He also likes ending prompts with a dump of his open questions and areas of concern: it tells the model what he actually wants to learn from the work.

Then ignore the thread

The step he calls arguably the most important: once a thread is running, stop watching it. Watching feels productive because things are changing on your machine, but the thread won't finish faster and 99% of the time nothing appears that you'd want to interrupt. Go do something else.

Thread hygiene is what makes this survivable. In T3 Code he built a "settle" flow: a thread lives in the sidebar only while it still needs work, and a thread linked to a PR auto-settles when the PR merges (you can also right-click a PR link and attach it to a thread manually, which is the lazy alternative to inferring the link). Threads he isn't ready to drop get snoozed for hours or until next week. He keeps the list down to a handful, and his rule is that the only reason to reopen an old thread is to reuse its context — and even then, if the model could build that context once, it can build it again.

Burn tokens to protect your own motivation

The recurring theme, stated repeatedly: one of the things he optimises for is preventing loss of motivation. The failure mode he fears is investing setup effort in testing a PR, finding it obviously broken, and losing the day's momentum and mental context to Twitter or the fridge.

The mitigation is always the same — spend more tokens. Concrete instances from the stream:

• Rather than reconfiguring his auth to test a community PR adding usage meters, he had a model audit it first: API call frequency, ban risk from polling, data accuracy versus the provider dashboard, and comparison against other open-source tools with the same feature. The audit found they were polling every 60 seconds against a community-accepted floor of ~180, that it fabricated an "unlimited" window the API never reports, and it surfaced real user reports of usage endpoints failing for 30+ minutes.
• When a thorough audit's problem section was clear but the fix section made his eyes glaze over, he did not force himself to concentrate. He asked for an explain-like-I'm-five version of the plan — spending tokens instead of letting the ADHD win and tabbing away.
• Same move for the long list of concerns on the usage PR: instead of parsing it himself, he had the model draft a review comment for the contributor, on the grounds that what helps him understand will help the contributor too. He reviews the draft, corrects the assumptions he knows are wrong, and then lets the agent post it under his name (his comment skill makes clear the model is writing on his behalf).
• He has lost track of which of his own PRs are open. So he pointed a cheap fast model at the repo — go through all of them, use sub-agents, tell me what to merge, close, or re-review, sorted by ease of action. He ran the same prompt on two different models to compare; one produced a genuinely useful prioritised plan, the other recommended merging a PR whose native networking changes he knows aren't safe, so he archived that thread so it wouldn't confuse him later.

A related trick he rates highly: when a model states an assumption he can't verify, ask it to check the assumption against its own history on that machine. It has prevented a lot of bugs — though it doesn't work in his current setup, where auth goes through a CLI proxy so the local usage data isn't there.

The babysit skill

His favourite recent addition is a skill of about a paragraph and a half. It tells the agent: this PR will get comments from automated reviewers, watch it, decide which comments are worth addressing, make and push the changes, and keep monitoring until the bots have nothing left to say.

That closes a loop he used to close by hand — reading review-bot comments, copy-pasting the ones he agreed with back into the thread. On the PR he showed, the agent had already absorbed 12 comments, then 4, then 1, and come out approved, without pulling him in until it was done.

Make it possible to actually test the change

The other half of the throughput story is infrastructure built so that he can verify work from wherever he is:

• Web: a built-in "share dev" command that exposes a running dev server over Tailscale and hands back a URL with a pairing code. He asks for it in the thread, opens it in his own browser, and tests the change for real — which is how he confirmed a file-upload overhaul both worked and didn't break screenshot pasting. Making this viable required overhauling bundling, because on 10 Mbit hotel wifi the dev server took 20-30 minutes to load.
• iOS: a third-party service that builds a Mac-hosted app remotely and installs it on his phone from a link. Not perfect — unsigned builds restrict share and AirDrop — but enough for a quick check on the go.
• Desktop: a preview:mac PR label that triggers a macOS preview DMG in the thread. He built it to test auth flows on a clean machine, then had to add a second feature so those downloads don't require GitHub sign-in, then a third pass cleaning up code signing to cut build time.

His point in enumerating these small pieces: watch for what keeps you from hitting merge — what mental burden, what risk, what friction makes you delay checking the code until it never happens — because each of those is an opportunity, and the improvements compound.

Safety nets, not guard rails

He is blunt that mistakes still happen, that things merge that shouldn't, and that most of those bugs could not have been caught by reading the diff anyway. So the answer is a net rather than a gate. T3 Code ships "nightly" builds every three hours to a few thousand of its 200k+ users, who know what they signed up for and report breakage immediately — which is why stable releases rarely carry real regressions. Slow percentage rollouts with fast rollback, or a formal QA team, serve the same purpose.

The takeaway he wants is twofold: a broken change should never be able to reach many users, and — the part hiding underneath — de-risk the merge button from both sides. You shouldn't be looking at a PR until agents are fairly confident it's ready, you should have a way to test it yourself for confidence, and you should know that if it breaks anyway it'll be caught before it matters. He notes they merge more tests than features these days, so this isn't an argument against testing; it's an argument that nets, not guard rails, are what make merging fearless.

Closing

He frames the whole thing less as a T3 Code advertisement than as a demonstration of the loop: hit friction, fix the tool, ship more. And he admits part of the motive is wanting to look back in six months and see how silly some of it was — every workflow video he makes keeps getting called helpful long after it stopped being accurate, so he figures he needs to redo one every three months.