AI Multi-Threaded Development Workflow: The Secret Behind 50+ PRs in a Vacation Week

As the founder of T3.gg, a well-known developer and YouTube creator, Theo (t3.gg) openly admits he's no longer a full-time engineer — running the company, making videos, and managing sponsorships take up most of his time. Yet look at his contribution curve on the T3 Code project: from one to three PRs per week in mid-July, spiking to 23, then 37, then 41, and ultimately breaking 52 PRs in a single week. What makes this even more remarkable is that during the 52-PR week, he was attending DEF CON — getting it done on planes, in Ubers, and over hotel WiFi.

How did he pull this off? The answer isn't that he got better at coding — it's that he found a workflow for running AI Agents in parallel across multiple threads. This article breaks down Theo's methodology systematically. Its core philosophy can be distilled into one line: spend tokens to reduce mental overhead.

Core Principle: Code Doesn't Run on Your Local Machine

The first step in Theo's workflow is to open a new thread, paste the task, and — make sure it doesn't run on your own computer.

He emphasizes that your everyday laptop or workstation should never become the bottleneck for AI development tasks. To that end, he set up a Linux desktop in the next room (codename BB1), loaded it with all his codebases and a T3 Code server, and mounted harnesses for multiple models including Codex and Claude. All development threads are dispatched to that machine.

Here's a counterintuitive but critically important point: why Linux instead of Mac? Theo points out that macOS has numerous issues with reliable parallelization and struggles to run multiple Agents stably. On Linux, he's run over 40 Agents simultaneously without the machine breaking a sweat — even on a secondhand 16-thread machine he bought for $600, CPU usage sits around 12%. He calls this "one of the biggest hacks for making myself more productive."

Prompt Strategy: Give Instructions and an Escape Hatch

When demonstrating a fix for a skill-trigger bug, Theo showed the carefully designed structure of his prompts. Every sentence has a deliberate purpose.

Establish Priority and Non-Negotiables

He tells the model "this issue is affecting a large number of real users," giving the task a sense of importance and reliability expectations. Then he draws a hard line: "I want a fix that's simple to implement and won't confuse users" — this is a non-negotiable boundary.

Give the Model Room to Push Back

The key move is using phrasing like "in my opinion" to explicitly tell the model: if this approach doesn't work, you can push back or ignore that part. He also honestly discloses the limits of his own knowledge: "I'm not sure how Claude Code triggers these behaviors internally." This serves two purposes: it prevents the model from blindly trusting the issue description, and it lets the model better explain the parts he doesn't understand in its response.

Allow the Model to Stop Anytime

The cleverest line is: "If you find a simple fix, please stop and tell me so we can apply it immediately." This grants permission to multiple sub-Agents exploring in parallel — once one finds the answer, it can confidently interrupt and report back rather than grinding through all 17 approaches to completion.

The Critical Step: Ignore the Thread Until It's Done

Theo believes the most important step to landing large volumes of code is completely ignoring the task while it runs.

Watching a thread waiting for results creates the illusion of productivity, because you see code you're responsible for constantly changing. But staring at it won't make it run faster, and 99% of the time you won't spot anything that requires an immediate stop. So go do something else.

He admits the codebase has grown to the point where "I genuinely don't know which PRs are open or closed at any given moment." The solution, again, is to burn tokens — he uses a cheap but capable model like GLM 5.3 Flash or Luna, spinning up a dedicated thread to audit all PRs: which ones can be merged, which should be closed, which need another pass, sorted by ease of action so he can prioritize the simple merges first. He even runs the same audit task with two different models simultaneously, cross-validating the results.

Using Tokens to Fight Motivation Loss

This is the most personal and insightful part of Theo's workflow. He explicitly states that one of his core optimization goals is preventing motivation loss.

He gives an example: suppose a PR looks like it might work, but testing it requires painfully setting up an environment. You go through all that effort, run the test, and the code is obviously broken. That "put in a ton of effort and failed" moment crushes your momentum for the day — you're tempted to flip over to Twitter or grab a soda from the fridge, and all the context in your head vanishes.

The countermeasure is, again, burning tokens: let the Agent do a thorough audit before you test anything yourself. He has the model review the PR, identify all potential failure points and obvious issues, and even research similar implementations in other open-source projects (like CodexBar) for comparison. This dramatically reduces the probability of an "invested effort, got nothing" failure.

He also has a trick for fighting ADHD: when the model's fix explanation is too long and he can't focus on it, he doesn't force himself to concentrate. He just tells the model: "I really like how you described the problem, but the solution is hard to follow — can you give me an explanation simple enough for a five-year-old?" — buying back his own attention with tokens.

Agents Auto-Managing GitHub: The Babysit Skill

Theo introduced one of his most useful custom skills — the babysit skill. It's essentially a paragraph and a half of text, yet it creates an automated loop.

The skill tells the Agent: this PR will likely receive comments from automated review bots — keep watching it, and every time a new comment arrives, decide whether it's worth addressing; if so, make changes, push, and keep monitoring, until all review bots have nothing more to say, at which point change the status from "in progress" to "done."

In a live demo, this Agent independently completed the first round of fixes, handled 12 comments, then received 4 more and handled those, then 1 more — ultimately receiving approval from all AI review bots with zero intervention from Theo. He also built a "comment style skill" that has the Agent post comments under the signature "Claude Fable 5 on behalf of Theo" — transparent and efficient.

Lowering the Testing Bar: Remote Testing Solutions

Pre-merge validation is an area where Theo has invested enormous effort. He's built separate testing pipelines for web, iOS, and desktop:

• Web: He added a --share-dev command to T3 Code that, combined with Tailscale, generates a URL with a pairing code — letting him test a PR running on the remote machine directly in his local browser. He also refactored the bundling logic, because loading the dev server over 10Mbps hotel WiFi originally took 20–30 minutes.
• iOS: Using a community-recommended project called Squim, remote builds generate a link you can tap on your phone to install directly — no VPN or complex Tailscale configuration required.
• Desktop: He implemented logic so that adding a preview:mac label to a PR automatically triggers a macOS preview DMG build, which appears in the thread for download. He even reworked the authentication logic so these preview downloads don't require a GitHub login, making it easy to test fresh user auth flows on a clean old MacBook Air.

Core Philosophy: Safety Nets, Not Guardrails

Even so, Theo admits mistakes still happen — especially when the team is no longer reading code line by line. But most bugs couldn't be caught by reading code anyway. His final line of defense is therefore safety nets, not guardrails.

T3 Code has around 200,000 users, and several thousand "nightly build" users serve as the critical safety net. The nightly build actually runs every 3 hours, so the moment a change breaks something, this group of risk-aware early adopters floods in with reports. As a result, the stable version of T3 Code almost never sees real regression bugs — issues are found and fixed before they touch even one in ten thousand users.

Theo frames all of this as "de-risking the merge button":

1. Before opening a PR, have a fleet of Agents reach reasonably high confidence — you shouldn't even open the PR before that point;
2. After opening a PR, use convenient testing tools to build your own confidence;
3. After merging, use safety nets to ensure that even if something goes wrong, it gets caught and fixed quickly.

Turning Friction Into Improvement Opportunities

What's perhaps most worth borrowing from Theo's workflow isn't any specific technique, but the meta-methodology he keeps coming back to: notice every point of friction in your workflow that makes you hesitant to hit the merge button — whether it's mental overhead, testing hassle, or fear of risk — and treat every one of those friction points as an opportunity to improve the project, the workflow, or the tooling.

"When you make more and more of these improvements, you'll feel an exponential growth in both your delivery capacity and your delivery confidence." It's the accumulation of these small optimizations that allowed a "part-time programmer" juggling multiple roles to double his output during a vacation week.