Big Idea

The argument in one line.

A part-time coder can out-ship full-time engineers by treating agent orchestration itself as the skill: dedicated hardware, carefully-scoped prompts, cheap-model triage run in parallel, and release habits that make merging low-risk.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

You already use Claude Code, Codex, or a similar coding agent daily and want to run more than one or two threads at once without your machine or your patience giving out.
You maintain an open source or team project and want a concrete system for triaging pull requests, auditing risky community contributions, and de-risking what gets merged.
You want to see real prompt-engineering technique explained sentence by sentence, not as a template, but as someone justifying exactly why they phrased each line the way they did.

SKIP IF…

You're looking for a beginner explanation of what an AI coding agent is; this assumes daily use already.
You want an installable step-by-step tutorial; most of what's shown is Theo's own internal tool (T3 Code) and personal custom skills, not something you can copy directly.

TL;DR

The full version, fast.

Theo, who says running multiple companies has cut into his hands-on coding time, explains how he still lands dozens of pull requests a week on his project, T3 Code. The system: never run agents on the machine you're using, write prompts that separate hard requirements from soft preferences and explicitly ask for audits instead of code, then walk away instead of babysitting threads. He parallelizes dozens of agents on a cheap Linux box, which handles it far better than macOS, uses cheap models to triage backlog PRs, and builds small automations, like a skill that argues with review bots until they approve, to keep his thread list short. The safety net is frequent nightly builds to opt-in users, catching regressions before they reach everyone, so merging stays low-stakes even without reading every line.

Free for members

Chat with this breakdown — free.

Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.

Create a free account →

Chapters

Where the time goes.

00:00 – 02:40

01 · The confession and the PR chart

Theo admits running his company and channel has cut into hands-on coding time, then reveals T3 Code's contribution graph spiking from 1-3 PRs a week to a peak of 52 over the summer, and promises to show exactly how.

02:40 – 04:37

02 · Sponsor: Browserbase

A sponsor read for Browserbase, a browser built for AI agents: over 80% of the web can't be reached by curl or fetch alone, so agents need real browser access to search, extract, click through flows, and get past IP blocks and CAPTCHAs.

04:37 – 07:42

03 · Rule one: never run agents on your daily machine

A chat-reported bug surfaces first: the dollar-sign skill trigger works everywhere except for skills marked manual-invocation-only, which only the slash-command trigger can fire. Theo then explains his real setup: a dedicated, over-specced Linux box in another room running the T3 Code server, so his laptop is never the bottleneck, with each parallel thread working inside its own git worktree.

07:42 – 10:20

04 · How to write a prompt an agent won't over-execute

A line-by-line breakdown of the audit prompt he's about to send: state that real users are affected, separate a hard non-negotiable requirement from a softened 'in my opinion' ask, admit what he doesn't understand so the model explains rather than assumes, explicitly ask for an audit rather than a fix, and give permission to stop early once a confident path exists, before switching to full access and extra-high reasoning.

10:20 – 13:53

05 · Ignore the thread, audit the risky PR instead

Theo's core rule: watching a running thread doesn't make it finish faster, so go do something else. Applied example: a community PR adding a usage/subscription-limits dashboard that he can't easily test himself, since he runs Codex and Claude Code through a CLI proxy instead of normal auth, so he has a second agent audit the diff for real risk before he ever opens it.

13:53 – 17:35

06 · Forty agents on a Linux box

Why Theo moved dev work off macOS entirely: his Linux box sits at 5-6% CPU running dozens of parallel agent threads, and he's hit 40-plus without it breaking a sweat, while macOS reliably chokes on the same load. He calls the move to Linux one of the biggest productivity unlocks he's found, and kicks off a PR-backlog triage thread on GLM 5.3 Flash since he's lost track of which open PRs are safe to merge.

17:35 – 23:08

07 · The bug gets found, and a comment gets drafted

The skill-bug audit returns three real, separately-stacked defects; when the writeup gets too dense to parse, Theo asks for a simpler, ELI5 rewrite instead of forcing himself through it. Meanwhile the usage-dashboard PR audit finishes: good bones and green CI, but no rate-limit hygiene, a fabricated unlimited window, and a 60-second poll interval well under the community norm.

23:08 – 29:18

08 · Small hacks that keep the sidebar honest

After correcting a factual error in the drafted PR comment and posting it, Theo shows the merge-linked auto-archive and snooze system built into T3 Code, plus a right-click to retroactively link a thread to a PR. The GLM 5.3 Flash and 'Luna' PR-triage threads return their verdicts; Luna's advice on a risky native iOS PR is bad enough that Theo archives it outright and distrusts it going forward.

29:18 – 39:00

09 · The babysit skill, and testing what you can't see

A short custom skill watches a PR after it's opened, reads incoming automated review-bot comments, decides which are worth fixing, pushes the fixes, and loops until every bot approves without Theo touching it. He then exposes a WIP dev server over Tailscale to test a file-upload change from a real browser, and uses a tool called Sqim to sideload an unsigned iOS build to his phone without a VPN or a full signing pipeline.

39:00 – 49:22

10 · De-risking the merge button

A 'preview:mac' PR label triggers an automated, sign-in-free macOS preview DMG build inside the thread, and a follow-up pass trims the build's signing overhead. The real safety net is T3 Code's nightly build, shipped every 3 hours to a few thousand opt-in users out of 200,000-plus, so regressions get caught before a stable release. Theo's closing thesis: the goal isn't fewer mistakes, it's making mistakes cheap and fast to catch.

Atomic Insights

Lines worth screenshotting.

A YouTuber running multiple companies claims to land more merged pull requests per week, part-time, than most full-time engineers ship.
T3 Code's weekly PR count jumped from 1-3 to a peak of 52 over a single summer as its creator rebuilt his own agentic workflow.
Over 80% of the web cannot be reached through simple curl or fetch calls, which is why agents built only around API access get stuck constantly.
A skill marked as manually-invocable-only can be triggered by a slash command but silently fails to trigger through a natural-language dollar-sign mention.
Running agent threads on a dedicated Linux box let one person operate 40-plus parallel AI agents while the machine sat at 5-6% CPU.
macOS reliably struggles to parallelize multiple simultaneous AI agent workloads in a way Linux does not, based on side-by-side use of both.
Telling a model 'in my opinion' before a request signals it has permission to push back or say the idea isn't viable, rather than comply blindly.
Asking for 'a confident path to a solution' instead of 'a solution' keeps an investigative agent from jumping straight to writing code.
A community-contributed pull request was found, on audit, to poll an API every 60 seconds when the community-accepted floor for that endpoint is closer to 180 seconds.
A cheap, fast model can be handed an entire backlog of open pull requests and asked only to prioritize which are safe to merge, close, or need more work.
A custom 'babysit' skill can read automated code-review bot comments on an open PR, decide which are worth fixing, push the fixes, and loop until every bot approves.
A tool called Sqim lets a developer install an unsigned iOS build straight to their own phone without a VPN, Tailscale, or a full Apple signing pipeline.
A GitHub Actions label like 'preview:mac' can trigger an automated, sign-in-free macOS preview build that appears as a downloadable DMG directly inside an agent thread.
Shipping nightly builds every 3 hours to a few thousand opt-in users out of a 200,000-plus user base catches regressions before they ever reach a stable release.

Takeaway

How one part-time coder out-ships full-time teams

WHAT TO LEARN

Shipping more code with less available time is less about typing faster and more about dedicated hardware, precisely-scoped prompts, cheap-model triage, and release habits that make mistakes cheap to catch.

03Rule one: never run agents on your daily machine

Route long-running agent work to a dedicated, always-on machine instead of your laptop, so background threads never compete with the work you're actually looking at.
A skill marked manual-invocation-only can silently fail to trigger through a natural-language mention; verify how a skill is actually triggered before assuming it ran.

04How to write a prompt an agent won't over-execute

Separate a non-negotiable requirement from a soft preference in the same prompt so the model knows exactly where it's allowed to push back.
State what you don't understand about a problem explicitly; it stops the model from blindly trusting your framing and forces it to explain the real gaps.
Ask for 'a confident path to a solution' instead of 'a solution' when you want investigation, not code, since a vague ask defaults to the model just writing something.

05Ignore the thread, audit the risky PR instead

Watching a running agent thread doesn't make it finish faster; closing the tab and doing something else is the actually productive move.
When you can't easily test a change yourself, spend effort on a second agent auditing the diff for real risk before you ever set up a test environment.

06Forty agents on a Linux box

Parallel agent workloads can run dramatically better on Linux than macOS; a cheap Linux box can outperform a MacBook at running dozens of agents at once.
When a backlog has piled up, point a fast, cheap model at just prioritizing it rather than immediately trying to solve everything with your best model.

07The bug gets found, and a comment gets drafted

If an agent's explanation is too dense to parse, ask it to re-explain the fix in the simplest possible terms instead of forcing yourself through it.
A thorough audit surfaces real, stacked defects that a surface read would miss, and it can teach you something about your own system you didn't know.

08Small hacks that keep the sidebar honest

Build small automations for the friction you hit repeatedly, like auto-archiving a thread when its linked work merges, instead of manually tracking state in your head.
Distrust a model's confident-sounding recommendation the moment it's factually wrong about something you know firsthand; don't let a well-formatted answer overrule your own knowledge.

09The babysit skill, and testing what you can't see

A short, plain-language skill that tells an agent to watch a PR, read review comments, and keep fixing until they're resolved can replace a manual review-and-relay loop.
For changes you can't confidently verify by reading code, expose a real, live instance of the change and actually use it before merging.

10De-risking the merge button

Give platform-specific changes their own fast, low-friction test path instead of skipping verification because testing is inconvenient.
The goal isn't preventing every mistake before merge; it's making mistakes cheap and fast to catch after merge, so you can move fast without fear.

Glossary

Terms worth knowing.

Worktree: A git feature that checks out multiple branches of the same repository into separate folders at once, so parallel AI agents can each work in an isolated copy without colliding.
Squash merge: A way of merging a pull request that combines all of its individual commits into one commit on the main branch, which is why a raw commit count can undercount how much work actually shipped.
CLI proxy: A local relay between a coding tool and the AI provider's API that lets someone route requests through their own account setup, sometimes at the cost of losing visibility into usage limits.
429: The HTTP status code an API returns when a client has sent too many requests too quickly; the standard signal for being rate-limited.
Nightly build: A version of the software rebuilt automatically on a fixed schedule and shipped to a small group of opt-in users before it reaches everyone else.
Tailscale: A tool that creates a private network between your devices so you can securely reach a service, like a dev server, running on a remote machine as if it were local.

Resources

Things they pointed at.

03:23toolBrowserbase ↗

14:10toolClaude Fable 5

16:40toolGLM 5.3 Flash

16:50toolLuna (GPT-5.6 Luna)

10:20toolWhisperflow

40:00toolSqim

36:40toolTailscale ↗

Quotables

Lines you could clip.

01:30

“A CEO that is a part-time coder is somehow probably outshipping you.”

self-deprecating brag that reframes the whole video's premise→ TikTok hook↗ Tweet quote

11:40

“I'm going to show you guys what's arguably the most important step of landing a lot of code. Ignoring the thread until it's done.”

counterintuitive productivity claim stated plainly→ IG reel cold open↗ Tweet quote

21:40

“Use tokens to reduce stress and likelihood that you decide to go do something else.”

reframes token spend as a motivation tool, not just a cost→ newsletter pull-quote↗ Tweet quote

47:50

“Safety nets, not guardrails.”

tight, quotable engineering philosophy→ TikTok hook↗ Tweet quote

The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.

metaphor

i have a confession to make ever since i started focusing more on running my company and running my youtube channel i have been less good of an engineer not that like my code is worse or i'm holding the team back okay i am kind of doing that but more i'm just not able to spend as much time coding I rarely get a moment where I can sit by my computer and I'm not behind on other more important things that only I can do, like email or filming or working with sponsors or all this other stuff.

And I love it. I'm not complaining. I'm very happy with where my job, my team, my companies, and my life are.

But I did miss coding a lot. I just like being in the trenches, solving hard problems, building cool stuff, and seeing the software I use every day improve as we make changes and just make it better. These are things that are really fun and important to me.

And it's been really sad losing that as I've had to focus more and more on everything else. Which is why when you look at my rate of contribution to a project like T3 Code, you see, oh, I'm landing as many as 50 PRs a week? Huh.

I know it says commits, but we squash merge. So what this actually means is the amount of PRs I'm merging. And you'll notice a bit of a spike in mid -July, where I went from one to three a week, to 23, then to 37.

to 41 and then all the way up to 52 huh i guess i just wasn't that busy during this window oh wait the week of august 7th i was traveling i was at defcon and somehow between my flights my ubers and my awful internet at the hotel at defcon i managed to get 52 prs landed huh okay i may have bathed you guys a bit I finally found flows that allow me to be as productive as I want to coding while also having to run the rest of my life.

And while I may not be at Potato's level where she's landing like a thousand a month, I also have to run multiple companies, which means that a CEO that is a part -time coder is somehow probably outshipping you. And if that is the case, I think you'll like this video a lot because I don't want to keep any of this secret.

I'm just going to show you guys exactly how I work. And if all goes well, I'm going to land some real changes while I'm filming this video. I've never done anything like this.

And I'm admittedly kind of scared. I'm going to be showing my ass a bunch here. This is a very revealing video where I show how I work.

Not all of it will be perfect. Not all of it should be copied. But at the absolute least, I think you can learn some really cool things.

And the first really cool thing I want to show you guys is today's sponsor. If your agent doesn't have access to the web, it's probably not a very good agent. The knowledge in the models is not enough to make them effective at the things we want them to do today, which is why they need a browser.

And if they're just using the browsers that are available to them through the existing APIs, they're probably going to get stuck a lot because over 80 % of the web cannot simply be curled or fetched over APIs. That's 80 % of the things your agent could use to do better that it just doesn't have access to. Unless you're using today's sponsor browser base, they built the best browser for agents so that they don't have to be limited to the fifth.

15 to 20 % of the web that they can access over curl, they can now access everything. Whether you wanna do simple searches or fetch context from a given URL in a way that your agents can actually read and use, or if you want a full end to end browser where your agents can click buttons, sign into pages, complete real actions and get real things done, Browserbase has you covered.

And it's not just useful for getting data from other places. It's also useful for testing your own things too. If you want to make sure certain regressions stop reappearing in your app or certain flows are guaranteed to work 24 -7, you can set up an agent with BrowserBase to be constantly testing them, actually going through flows before a user ever hits a bug.

And as smart as agents are, they do often get stuck when they're trying to use browsers. Whether they're hitting from an IP address that's blocked or they're trying to get around to CAPTCHA, they get stuck often. Unless you're using BrowserBase because they've figured all of this out for you.

unblocking your agents as they navigate the web. There's a reason everyone from Microsoft to DeepMind is using browser -based and you can figure it out yourself at soydiv .link slash browser -based. So let's dive in to how I get so much work done recently.

Obviously, first and foremost, having good AI tools to work with is essential in getting your work this much more effective at being delivered. I will also say that a lot of the changes I've been making to T3 code have been from my experience working this way and trying to improve so I can ship even more. here is one that a chatter mentioned while i was streaming that seems pretty legit if you use the dollar sign to trigger skills this works great for skills that are in the project or out of the project but there is a catch if the skill can only be invoked manually which is a condition you can put on a skill it only works with the slash command it will not work with the dollar sign command version because the slash command version can enable a skill that isn't already on that the model can't trigger itself, but only the slash command at the front is able to trigger skills that have to be manually triggered.

This is a bug I didn't know about because I don't have manual only on for many skills and even those ones I don't use that much. So I haven't encountered this, but it's a legit bug that I just didn't know about that I now know about. So let's see how I work.

Step one, new thread. I have a hotkey for it. Step two, paste.

Step three, and this one's really important in my opinion, make sure it's not running on your computer. I'm not saying make sure it runs on someone else's computer. I'm saying that the laptop or whatever other machine that you're doing other stuff on should not be held back, bottlenecked, or required for this work to be completed.

Ideally, you have some setup. For me, the way this works is I have a Linux box in the other room that is over spec, but it doesn't even need to be. Watch my Linux video if you haven't yet.

It'll be very helpful here. And that Linux machine... has all my code bases on it, and a T3 code server, so I can select BB1, which is my box in the other room, to be the box that's going to run these changes.

That box is selected. It has all of my harnesses, codecs, and clod available to it, and I'm going to tell it what I want. Also note, I'm doing this in a work tree.

I don't think work trees are the best solution to a lot of the problems as they exist today, but they're a good enough abstraction, especially if your file system handles them well, that you can just spin up a bunch and it's mostly fine. So let's get this one going. Before I do this, though, I do want to call out we are at the very surface level right now where things are going to get really cool as we go is the work I did to T3 Code itself to make both working in T3 Code easier, but also to add features and remotely build things into T3 Code easier.

So T3 Code itself, I've improved to make it easier to work this way. But the T3 Code repo has examples on how to set up other projects to work well in multi -threaded, multi -agent thread environments. So let's kick this one off.

I'm going to use voice to text here because I'm down a hand and Whisperflow has been nice for this type of thing. So let's get going. This is an issue that's been affecting a number of users as of recent.

I was unaware of it till now. I want to make a fix that is both simple in its implementation and not confusing to users when they try to use it. In my opinion, you should be able to use the dollar sign to call any skill anywhere in the composer and have it linked correctly.

I'm not sure about the characteristics in Cloud Code as to how these behaviors are triggered or even how the skill that I'm seeing in the composer becomes the right text for the model to add it in. I want you to do a thorough audit of both Cloud Code's behavior as well as how we are implementing that behavior. If you see a simple fix that we can apply to solve the problem, stop and let me know so we can apply it ASAP.

Come back when you have a confident solution to the problem with a good experience for our users. There's a couple pieces of this prompt I just spoke that I want to explain. This one isn't necessary, but I found it helps to let it know that a number of users are affected.

This isn't some small side project that this is a problem. This is a thing that is affecting real people. It gives it context that this is important and should be done reliably, not just experimentally.

I was unaware of it. It doesn't really matter. Just set it because I'm filming and it makes life easier.

You have the context now. I want to make a fix that is both simple in implementation and not confusing to users when they try it. I've now given it my priorities.

I want this code not to be super fast, not to be super detailed. I want it to be simple. And I want it to be built in a way that is not confusing to users.

In my opinion, and here is where I'm telling it effectively, I'm okay with you overriding this or ignoring this part. This sentence where I said I want to make a fix that is simple implementation and not confusing to users, that's a no compromise line. I am saying very clearly, this is my expectation.

I then say, in my opinion, because if this thing isn't... viable, I want it to tell me as such, or if it thinks there's any reason I shouldn't do this, it'll be honest with me. You could also use something like the Matt grilling skill for this, but for a one -off issue, you shouldn't answer 50 questions.

So in my opinion, you should be able to use the dollar sign to call any skill anywhere in the composer and have it link correctly. This is giving it the condes of my expectations, but also giving it the room to push back. I'm not sure about the characteristics in Claude code as to how these behaviors are triggered, or even how the skill that I'm seeing in the composer becomes the right text the model expects to add it in.

This is me saying where I am at with this understanding, both so the model doesn't blindly trust the issue and the things I've told it, but also, more importantly, so it'll do a better job explaining the things I don't understand when it responds. Now that it knows where my knowledge is, it knows what I do and don't have to care about when it responds.

I want you to do a thorough audit of both Cloud Code's behavior and how we are implementing that behavior. This is the clear ask. I'm telling it exactly what I want it to do.

Before I said I want two things, this is my ultimate goals for the thread. This end is saying what I want this thread to end up at. But now I'm saying I don't want you to do that.

I want you to do a thorough audit of these things that I'm not sure about. And I know that's where the problem lives because I know how the code base works. if you see a simple fix that we can apply to solve the problem stop and let me know so we can apply it asap this is me giving the model permission to at any given point if it finds the solution it has four other sub agents going exploring other things it can confidently stop and just tell me what it found instead of going forever for option one of 17 to be chosen anyways come back when you have a confident solution to the problem with a good experience for our users I'll say confident path to a solution.

So it doesn't possibly interpret that as meaning write the code. I think I've made it pretty clear here that I don't want it writing code. But fable is fable.

If you don't say something explicitly, it will do whatever it wants. And I'm curious what it ends up doing. So I'm also going to switch to full access because I don't feel like waiting.

And I'll bump extra high because why not? I've given it easy outs. And now this is running.

I'm going to show you guys what's arguably the most important step of landing a lot of code. Ignoring the thread until it's done. If you spend all of your time sitting and watching threads, waiting for them to have an answer, you're not being productive.

It feels productive because you see changes happening on your machine for something you're responsible for. But that thread's not going to complete any faster if you keep it open. And 99 % of the time, you're not going to see something going on in the thread that you really want to stop.

So just go do something else. I also see chat pointing out a real problem. And this is a problem that pissed me off so much that I spent weeks trying to solve it.

I start too many threads and I get lost sometimes. I promise you we'll be touching on this a lot throughout. Another thing somebody did during the stream is they linked to this PR asking for me to merge it so I can have 51 PRs instead of 50.

I have a feeling this PR is not going to be mergeable for a bunch of reasons. This one's also going to be a bit hard for me to test because I'm not using Codex or Cloud Code with the normal auth anymore. I'm using these through CLI proxy so the usage limits aren't even exposed.

So I won't even know if this is working. And I'm going to be real here. One of the things I optimize for is preventing loss of motivation.

Let's say hypothetically, I thought there was a really good chance this PR would work, but I have to be able to test it to know. So I put a bunch of effort into either spinning up another box with normal auth, or I remove all the CLI proxy stuff from this computer to switch over to normal codecs and clot auth. I pulled down the PR, I build, I launch, I go try it, and it's broken anyways in obvious ways.

I would not be happy. That would massively impact my motivation to keep working that day. And I'm much more likely to alt -tab to Twitter or to leave to go grab a soda out of the fridge or something.

And now I have lost all of the context in my head of what work I was doing. So you need to do whatever you can to avoid those demotivating moments. One of the best things you can do is reduce the likelihood that the bad outcome happens.

In this case, the bad outcome is I put a lot of work in, I try the code, and it fails. One of the easiest ways you can prevent these failures is burning more tokens. Into my composer it goes.

I drop the link to the PR, and I'm going to tell it what I want it to do. This pull request adds a feature that a lot of users are asking for. Unfortunately, I don't use normal auth, so I can't test it myself.

Before I take the time to set up an environment to test this, I want you to do a thorough audit of the change. Find any potential failures, obvious issues, and things that could negatively affect users if we were to merge it today. My immediate areas of concern are the frequency in which we are using these API calls.

I don't want to be spamming the APIs in a way that would potentially get users banned. I also want to make sure that this data is fetched reliably and accurately in a way that won't confuse users if they see different numbers in a dashboard than they see in our product. I'm also curious how our implementation compares to other things that haven't implemented.

I know apps like CodexBar have an implementation of this, for example. I want you to audit the implementation, find all of the issues that might exist, answer these particular areas of concern, and explore other open source projects that have similar features so that we can get a good idea of how our implementation stacks up.

Okay, Whisperflow fucked the formatting of this pretty bad here, but honestly, I don't care. The models are good enough to turn slop voice to text into the actual stuff that we want. Sent.

I also, again, see concerns in chat. Multi -agent workflows are going to be brutal on any Mac you pick. Again, I'm running these on BB1.

I have a lot of work running on this machine. I have other separate things running in the background too. I'm using 5 % or less of my CPU.

A few of the threads are getting a little bit of work on them, but the majority aren't getting jack shit. And this is with multiple threads in T3 code right now with lots of sub -agents in all of them. On top of the other background work I'm running here, I've had points where on this machine, I was running 40 plus agents and it wasn't breaking a sweat.

And it's not even because this computer is super powerful. Obviously, 32 cores is a lot. I got a 16 thread machine that I paid like 600 bucks for in the other room that also has no problems at all and would be at 12 % instead of six for this workload.

It's really solid. And this is because I'm running Linux, not macOS. macOS has a ton of problems that make it really hard to reliably parallelize your work to the point where I just don't like doing it on macOS anymore.

Generally speaking, I treat my Macs as one or two tasks at a time. And I treat my Linux boxes as effectively unlimited tasks at a time. Because I've never managed to saturate unless the tasks are running things that are super heavy.

Like they're running unbounded Rust compiles that use all my RAM and stuff like that. But you can take any old laptop or desktop that's sitting around, throw Ubuntu on it, and have a much better experience with lots of agents in parallel. Probably one of the biggest hacks I have found to making myself more productive.

Just moving over to Linux for my dev work has been an exponential improvement of my productivity. So now we have two threads going, and these are both ones that'll take a while, both because the task I gave them was expansive, but also because it's cloud code running on X high. So these are going to be brutal.

So let's do step three of how I'm landing so much. As you can guess, a lot of these things result in a lot of code being put up in PRs. But keeping track of that all, okay, I'll be frank here.

It's impossible. The amount of CODEM shipping means that I don't know what PRs are open or closed of mine at any given time. I just, I can't know anymore.

So how do I deal with that? If you guessed burning more tokens, you're starting to catch on. I'm going to swap over to GLM 5 .3 Flash because it's genuinely a really impressive model, especially at its price.

I'm just using it in Codex. It doesn't really matter where you use it, but it's good at stuff like what I'm about to do. I have a bunch of PRs open in this repo and I've kind of lost track of them.

I want you to go through all of them and help me prioritize them. Which ones are ready to merge? Which ones should probably be closed?

Which ones need another pass before they're safe to merge? Use subagents to break up the work and come back to me when you have a good idea of what I should be closing, merging, etc. Prioritize based on the ease of action so I have easy things to merge on top.

This prompt might seem weird because I gave this question dump at the end. I find these are actually very useful for the model because it gives it a better idea of what my goal is. What do I actually want to learn from the work it's about to do?

This is also one of those tasks that will take a bit, even on a fast model like 5 .3 Flash. But since 5 .3 Flash is surprisingly capable and hilariously cheap, this will cost me nothing. Obviously, if I did it with Luna instead, it would also effectively cost nothing because I have so much usage available.

But I like 5 .3 Flash, so why not? I'll try it with this. and just because also why not i'm going to paste the same thing i'm going to switch over to luna and i'll bump it to fast on i'll do high fast why not because again luna uses basically nothing so now i have two threads with different models which is another hack we'll talk about later auditing my work to see what it thinks i should be prioritizing right now while these are running i want to show you guys a few more of my how i keep track of my work tricks One of the things I've really liked in T3 code recently is how we integrate and relate a PR to a thread in your sidebar.

You get this little button here that shows the PR that this thread is associated with, usually the PR that opened. And you can click it to see that PR in editor. But since I'm a little constrained on screen real estate here, I'm going to command click instead to open it up in my browser instead.

Oh, this is actually a really good PR to have here because it explains some of the things I've been doing to make my flows easier. This PR is directly linked to this thread. And that means when I merge this PR, this thread will disappear.

This seems totally fine. I know the consequences of this PR. I will come back to it later to explain why I did it.

But for now, squash and merge. Now that is merged. And now the thread is gone from the sidebar.

I built this settled flow for T3 code because I wanted to make it really clear what work needs more effort. And what work doesn't anymore. If you want to go back to the thread, you totally can.

You can unsettle. If this ruins your workflows, it's totally fine. You can go turn it off in settings.

But the goal I had here is that if you have it in your sidebar, it's because there's more work to do. On that note, I have things here that I don't really need in here anymore. Most of them were me testing things when I was setting up for stream earlier.

So I'm going to settle, settle, settle. Validate PR closure candidates. Settle.

This one, actually, I know what this one is, and there are things in there I want to deal with, so I will leave that open. But if I don't want to deal with this now, I added a feature for this. Snooze.

I can snooze this for in three hours, and now this won't come back until 9 .36 p .m. This makes it really easy to keep track of the stuff you're actually doing and get rid of things that no longer matter. Generally speaking, the only reason you should go back to an old thread is because you need the context to fix something else, and even then, I don't need it that often.

If the model could build the context initially, it can do it again. So now we have three threads running, none of which are making changes, all of which are investigating things and helping me make better decisions around existing stuff. This one finished, though, so let's take a quick look.

I have a confident path, and it's simpler than expected. The audit's done, and I verified Cloud Code's real behavior. Cool.

This is the one for fixing the skill bug. There are apparently three separate defects that are stacking up. Discovery is blind.

It only reads name and description from the front matter, and at hard codes enabled, true. It ignores disabled model invocation, user invocable, and skill overrides from settings. Apparently, the dollar sign is codec syntax, and we're currently sending it to Claude untranslated.

It's a good thing I had to do this audit. I just learned something about that we're doing wrong here as part of it. Apparently, the slash only expands at message start, and our menu offers it anywhere regardless.

I will admit, it might be my ADHD, but after the problem section, my eyes kind of are glazing over the fix. So I could just try to sit there and force myself to focus and understand it. But remember the theme, use tokens to reduce stress and likelihood that you decide to go do something else.

I found myself with the temptation to tab out and go do something else here, but I have to fight that and I'm going to fight it with tokens. Watch how I do it. I really like your description of the problems here.

I feel like I understand the issue well now. I find your solution hard to parse and I can't tell which parts of the problem you're actually solving. Can you give me a simpler, easy to digest, explain like I'm five description of how you plan to fix these problems?

And now I don't have to let the ADHD win. In fact, I can guilt -free move to this thread that just finished the work it was doing. I also just noticed another bug, which is that this thread didn't mark itself as done properly.

So I'm going to ask about that quick too. I noticed a new issue in T3 code just now coming from the remote connection to the machine that this prompt is running on. I noticed that some threads, when they are finished and done with some work, are not correctly marking the thread as done.

I have no idea what the cause of this could be. I also just noticed that I disconnected from the remote in the middle of writing this prompt. I'd like you to investigate what's going on in this machine, what might have caused the done status to not appear, and what caused the disconnect that I just noticed.

So now I have a rough prompt of what issues I'm experiencing that I wanted to explore. Generally speaking, I prefer Sol for exploring things on the machine and its history and challenges it's run into. I don't need Fast for this because, again, I'm just letting these things run in the background.

So I'll send it off to go explore the issues that I experienced right now. This is another thing that I found helps both with the quality of experience for our users, but also with bumping up my PR numbers. I have made it so frictionless to go spin up a thread whenever I notice an issue that I close issues super fast.

And I force myself at all times when I notice an issue like this to go address it immediately. Because otherwise, it'll never happen. This other thread, though, is auditing the provider usage dashboard has completed now too.

PR 8327 audit subscription limit meters. Good bones hold before merge. Argumentator is right for T3.

CI is green. Every bot finding except one is fixed at the head. But it has no 429 hygiene.

It pulls the cloud endpoint faster than the community accepted floor. It fabricates an unlimited window that the API never reports. And it ignores free local data sources that other tools use to avoid network calls entirely.

That's a bunch of really good insights. I like that it's calling out the 429 risk and it successfully found issues people have opened on Cloud Code itself, not the open source repo for Cloud Code because it's closed source, but on the repo that they put their skills and let people mark issues on. There's a bunch of people who reported issues where they can't check their usage limits, sometimes for 30 plus minutes.

I've had this happen a few times myself. It is really annoying, and I'm happy the model found it and recognized it as a real risk that exists the way we have this set up. We are apparently checking every 60 seconds, which is way too aggressive.

The settled floor that people agree on in the community of people building things like this is closer to 180 seconds. Once again, I am faced with some issues. There's a bunch of concerns here.

There's three core ones, and they're all big and very detailed, but there is just so much info here. that I don't feel like parsing. So I'm going to ask it to do something else.

This is fantastic research you've done. I want to leave a useful comment for the user who, sorry, for the contributor who put up this pull request. Help me draft a good comment to leave for this user with the core insights shared here to make it easier for this contributor to fix the problems and make the PR ready to merge.

I don't want it to leave the comments yet. I want the comments to both help me feel more informed. And if it helps me, it'll help the contributor as well.

So I'm going to tell it to do the same here as well. Share your simple draft with me here so that I can approve it before the comment is left. Cool.

This is now doing its job. And the one below has given me a simpler explanation to what it was describing. Simplify the problems.

The dollar menu shows skills that are broken or turned off. And when you pick a dollar sign skill, Claude never gets a real instruction to run it. Claude only forces a skill run if you use it with a slash at the start.

The fix the translation step right before we hand the message to Claude. And now that I'm reading this, I have a much better understanding of the problem in the risks with this PR. Hey, what I'm left with is more questions.

So I'm just going to ask them. So if my understanding is correct, only slash skills at the front are applied. That doesn't seem ideal.

I would like for us to make it very clear where skills are being applied as well as what restrictions Claude code is applying to us. The rough idea for this that I have is if you do a slash command, we indicate after the second one that that command cannot be moved to the front and applied the way that Cloud Code expects because Cloud Code can only show one command at the front.

Is this the right solution? Do you have other better ideas on how we get this UX right? I just want to make sure users aren't confused by a weird behavior that is Cloud Code specific.

Ideally, we can make Cloud Code behave nearly identical to how Codex does. I have given it my additional questions and thoughts. It will give me more info.

I command minus ones to make the UI a little smaller so it fits better on my screen. And I notice this guy is done now. Let's see the comment it left.

I also built skills on my machine for how I like comments to be left by my agents. And it used the skill here saying Cloud Fable 5 is responding on behalf of Theo. Awesome, because the next step is going to need that.

thanks for this the shape is right probe only on usage page loads cache server side degrade to no meters on failure we compared against code expire cc usage yada yada yada three things need to change before merge and a few follow -ups are worth tracking and here it says the must fixes and exactly what those things are and why worth doing your call whether here or in follow -ups that you already offered i don't love that great limit snapshot in the json l that we're already scanning okay this part is just wrong so i'm going to tell it to not do that I have a pro tip that helps me a lot, but sadly won't help here again because my setup is different.

When I see an assumption that I'm not sure about that the model made, I'll ask it to audit against my own history. Super useful because I'm building on top of cloud code with T3 code, but I'm also working on cloud code with T3 code. So it having access to its own history on its machine that it can check and verify its assumptions is so helpful and has prevented a ton of bugs.

But I don't have the data on this machine because my auth isn't going directly through Cloud Code or Codex. It's going through my CLI proxy. So it won't have the data it needs to compare here.

So I'm just going to tell it what I know happens to be the case. Some quick notes that I have here. One, the SDK response probably doesn't include 7 -day Opus or Sana anymore because those models don't have separate limits.

It does include the 7 -day Fable limit, though, and we definitely want that in ASAP. I would block this PR on not including it. Second, Codex's rate limits being written is useful, but those might be stale if you're also using Codex other places too.

I would really like to not have to make an API call, but I don't want to show bad data by pulling from the cache unless we are confidently showing what is accurate data. I trust your judgment on this one, but update your suggestions accordingly. I think these changes are simple enough that I trust the model to apply them correctly to the comment.

And also this particular case, the contributor is in my chat watching, so he knows what my intent is. So I'm just going to do the lazy thing here, which is tell it, after you make these changes to your draft, leave the comment on my behalf with the same formatting that you have already used. Ta -da!

I don't have to worry about this anymore. In an ideal world, I would be able to set something up in T3 code where after it finishes this, it auto settles because I don't care about this thread anymore.

This now has all of my concerns addressed. But let's say I did want to leave this open because I wanted to use it to check in on this PR later. This is where one of my small little hacks has been very useful for me.

I have been building T3 code to make these workflows way easier. And I mentioned already that I have things set up so that when the PR merges, this auto disappears. There's a problem though.

i didn't open this pr in this thread so the pr isn't linked i could do some crazy stuff to intelligently include it but the lazy option is often the best one instead of burning tokens on every thread i burned tokens on one thread so that now i can right click a link to a pr and click link to thread now this pr is attached to this thread which means this pr will auto settle when the pr merges so nice And the chatter just mentioned that he will have things fixed tonight or early tomorrow.

And I trust him. So I'm going to open this up quick because I want to be able to look at it. But I'm also going to snooze this until tomorrow because it doesn't matter anymore.

Awesome. And here we can see the comment that left. Note, Claude Feeble, if I was running on Theo's behalf, this is exactly what I wanted to hear.

Awesome. This is great. I am much happier now.

One more quick note on letting the model interact with GitHub on your behalf. I have found my babysitting skill to quickly become one of the most useful things I've introduced to my workflows. I think pretty much every code project benefits from having an AI code review bot on pull requests.

I genuinely really like it. That said, I found myself often in the same scenario where I would see a PR complete from a thread in any agentic tool. I would go over.

I would see a bunch of comments and I would copy paste the ones I agreed with back to the thread and say, fix these. This was really inefficient and obnoxious. So I made a skill to do it for me instead.

The babysit skill is actually quite simple. It tells the agent, hey, this PR probably has comments from automated reviewers. I want you to keep an eye on it.

Take a look every time automated review comments come in and decide if they're worth addressing. If they are, make the changes, push them. and keep monitoring the PR to see if the agents resolve their comments.

This one little skill is a super simple, maybe one and a half paragraph pile of text that creates a loop. The loop is the agent makes the changes, files the PR. We have all of our automated review bots giving feedback.

This agent will now autonomously address the feedback and keep improving the PR until none of those review bots have anything else to say. at which point it will finally go from working to done, and I click it, and it hasn't just made the one first pass on the changes. It made that first pass.

It got 12 comments. It addressed all of them. It got four more.

It addressed those. It got one more. It addressed that.

Now it's approved by those AI review bots. All of those layers could have been more back and forth between me and the agents doing the review and my agent writing the code, but instead, it all happens by itself, and I'm not pulled in until it's done. I love it.

Cool. This is no longer my problem. I can go back to the other things.

It looks like the two PR prioritization threads finished. Let's take a look at these. Oh, sorry.

This one wasn't the PR audit finishing. This was the audit for the bug that I dealt with. I don't feel like I can give great advice fixing that right now, but I will in a bit.

For now, I want to hop over to the PR audit that Luna on high fast finished. It chose to put it in an HTML plan. I think I had asked it to do that enough times before that it decided to.

Save that in memory at some point. I didn't think it had memory. I did not expect it to do that.

Here is what it made with Luna going through all of these things. It said that my PR raising the T3 code device limit to five is ready to go. It is ready, but due to issues with Cloudflare that will hopefully be resolved by end of week, I am not confident in doing that.

Cloudflare, please get your shit together. 434, use compressed native WebSocket on iOS. This is not a PR that is as simple to merge as it seems to think because this one makes a lot of native changes.

I had to rewrite the network layer in Swift. This is a bad recommendation. I do not like Luna for this type of work.

I am going to archive this because I don't trust it enough and I just don't even want it in my history because it'll confuse me having that there when it's not the one I want to use. 5 .3 Flash is doing a much better job. It spun up four sub -agents to break apart the PRs, and now it's doing a follow -up run with the things that it...

No, it initialized without starting the audits. Oh, did it hit a bug? Whatever.

It'll probably figure itself out. I'll let it do its thing. Back to the enable skills anywhere in Composer thread.

I had asked it a question trying to figure out what is possible here. It calls out that I'm missing a piece of the plan. With the translation layer, the front of message rule stops applying to dollar sign skills entirely.

We relocate the invocation on the wire, so a dollar sign skill chip anywhere in your message runs for real. The front only restriction only remains true for raw slash commands. There's also a cloud code feature I haven't verified yet that could make multi -skill messages fully native.

Skill stacking, like slash A then slash B args, loads both. The docs claim it. My earlier probe didn't test the exact form.

Let me verify it now because it decides whether we really need any warning UX at all. Verified. Stacking does not work in SDK mode on 2 .1 .237.

It looks like there is a real gap between what Anthropic is reporting as possible and what is actually allowed in terms of the multiple skills invocating at the start. Can you hunt through open issues on quad code and see if others are reporting this? It'd be really nice if we could call it out directly and try and get them to fix it instead of having to architect something crazy in our app directly.

And now I sent it off to go figure out if Anthropic has already gotten reports of this shit behavior and gap between the docs and the actual capabilities. I do love that even Anthropic models know that Anthropic's docs are fucking utter bullshit full of lies. The main argument for open sourcing cloud code is that their docs are so fucking shit and they should never make us read them.

Because now I have two layers of obfuscation I have to fight through when integrating cloud code. I guess three, really. There is the super vague things that are said publicly places like Twitter.

There is the docs, which are full of lies. And there's the source code, which is obfuscated and uglified. So it's hard to actually dig into.

Even the SDK is closed source. The Python one isn't, but the JavaScript one is, which is the one that matters. I'm going insane.

It managed to find the issue for this and Boris commented in the thread and confirmed that it is a real bug. So now I want your guys opinion chat. It offered to post this comment for me and I have three options here.

Option one, I copy paste the comment and then leave it in the PR directly. So it looks like it's from me, but Fable wrote it. Option two, I can go write a real better comment, which is the correct option to be clear.

But option three. unique to this particular scenario. Since this is an issue that I have with Claude Code, and I know that the Claude Code team is pretty Claude -pilled, I think letting the agent leave the comment, knowing that it's going to specify that this comment was left by Fable 5, I think it's funny to let Fable leave the comment.

Am I right? I don't even need to see chat. I know I'm right on this.

You have my permission to leave the comment. And look at that. Comment has been left.

Cool. So... Again, with the staying productive thing, I know they're going to take a bit on this one.

So I'm going to snooze this to next week. And if they haven't solved it by next week, I'm going to start bugging my contacts to get them to try and fix it because this is stupid. I really optimize for keeping my thread list as minimal as possible.

Even now, I only have like one, two, three, four, five, six, seven threads here. Two are pinned long running ones. My Swift iOS app, which I rebuilt T3 code in Swift UI from scratch for fun.

has gone way longer than I expected. But I also had fun testing the limits of like, how much code can you make happen? And how big of an app can you build in a single thread?

And the answer has been a lot. I have built the whole app with 95 % of the code in just this one thread with five, six soul on a MacBook remotely with no issues. It's been very fucking cool.

I'm like at least a hundred prompts into this probably. This one can't merge, though, because I haven't gotten Julius's permission. So it just sits here pinned forever.

Obviously, there's a lot of things that are relatively easy to be like, oh, yeah, that makes sense. I hit merge. Good to go.

But there are a few layers that I think are useful here from what merge means to how I test things before I merge to how I have exposed this functionality so others can copy a lot of it, too. One of the most important things you can do is make sure you have everything in place to make it easy to test code that you want to validate before you merge it.

This is a big change that overhauls all of the file upload processes in T3 code. So I want to try it out. There is a problem here, though.

This thread is on a different machine that is remote. I am connected over tailscale, but I can't really do much here other than like open a terminal or use the in -app preview browser thing, which isn't really my favorite thing. It's not going to solve my problems here.

So I needed a way to test this remotely on my computer. So I put what was probably... far too much time and token burn into adding a built -in Tailscale share dev command.

Let me demonstrate. I want to test these changes out quick. I'm on a remote machine.

Can you use the dash dash share dev command with Tailscale so that I can try it out remotely? Respond with a URL that has the pairing code in it. So it has the PR checked out.

Now it's showing the dev server. Oh, that was quick. I had to overhaul how bundling worked to make this viable at all, especially over slow networks because at my...

10 megabit per second hotel wi -fi loading the dev server took like 20 to 30 minutes so now i have this pr from that machine on a dedicated port running remotely so now i can open this and test it out in my browser for real i have some files here that are pretty notably not images so let's drag and drop one what is the file that i've attached here how do you have access to it and now it is running and we shall see in just a moment oh look at that It accessed the data correctly.

One of the things I did for this upload change is whenever you upload a file, it puts it in a user data directory that the file path is shared with the model. So it can use whatever tools it wants to go read the file. And it worked perfectly.

I now know that this code functions. I might not have known that before. I do have concerns that it might break screenshots.

So let's do a screenshot quick. Paste. How about this?

What is this file? What are the contents? It's a PNG screenshot of the T3 code app showing this exact conversation.

Access works differently for images. The file was saved to the same attachments directory, but I did not need to read it. The harness rendered the image directly in your message, so I saw its pixels in line.

The path is there too if I ever needed the raw bytes. Awesome. All the concerns I had with this change are addressed.

Hypothetically, I could just merge it, but I do have another thread that's been auditing the changes that thinks I should break it up more, so I'm letting that happen. Although, god damn, I do really wish I could merge this right now. How cool is that, though, that I can just ask in the thread for it to spin up the server so I can try it and then try it and have a way higher confidence or lower confidence in the right places that this code actually behaves.

There are some changes that just cannot be tested in a browser, though. And I have accepted this and put a lot of work into figuring out how to work around that fact. For mobile, I did some research and I found this project, Squim.

Thank you to the people on Twitter who told me about it. That makes it relatively easy to. access a mobile app built on a Mac remotely where it will build it and bundle it in a way that you can install it through their web app relatively trivially.

It has made it much easier for me to do a remote build and then get a link that I can click on my phone and install so that I can actually test the changes locally. Super useful. Not the best solution.

There's a couple edge cases. I love they call it that you don't need a VPN or tailscale. Tailscale remote iOS builds are obnoxious but can be done.

This is much smoother. but you don't get all of the granular permissions that you can on iOS normally. Like it restricts share and airdrop and things because it's not a fully signed build the same way.

So I've now solved for web builds because I can just access it remotely and have solved for iOS builds well enough to get some useful stuff out of it. It doesn't have everything, but it's more than enough when I'm like on the go to test a change quick. But what about the desktop app?

I was admittedly lazy about this one for a while where I just didn't check desktop only changes because honestly, most of them were the same way in web. But once we started running into more and more issues with weird auth redirect edge cases, I was tired of merging, waiting for a nightly, checking it, and then realizing it was broken.

So I wanted a better way to test those things. So I gave myself one. I landed a pile of PRs that made this way easier.

The first one I had was a clever fix I came up with, which was the ability to trigger a preview build for Mac OS with a label. So what this enables is I add the label preview colon Mac, and then after some amount of time passes, a Mac OS preview DMG download appears in the thread that I can click on and get the file and then go test it myself.

This has made it so much easier to test changes that are desktop app specific without having to like build the whole thing locally. I mostly built this because I have other machines that I do these tests on. I wanted to make sure that on like a vanilla MacBook, setting up auth would behave as expected.

So I had this old MacBook Air from an ex -employee that was pretty much nuked and wiped. It's become the house Mac. We use it for like running our TV downstairs and stuff.

I uninstalled everything other than cloud code and codecs. I cleared all T3 code history on it. I downloaded this and made sure it worked.

But I had a problem. I couldn't download it. on that machine because i wasn't signing to my github on that machine so i did what i always do i burned more tokens i added a feature in the t3 code repo where now those downloads that are made with that preview label do not require you to be signed in on github and authed as a core contributor to the project which was the same default that added but didn't make sense for my use case so i made those two prs in order to make it way easier for me to test on other machines it's like legitimate infrastructure It's not super complex.

This is reusing a lot of the stuff that already existed inside of the repo for doing real release builds. But this is still like a couple hundred lines of code for the build and another couple hundred lines to make it accessible without downloads. But I still wasn't satisfied.

It was slower than I wanted. The builds took too long and it didn't matter before for releases because Windows builds take eight minutes. So Mac OS builds taking six doesn't matter because they're happening in parallel anyways.

But now it does. So I did yet another thread where I cleaned up the way that we were handling signing to cut the build times by meaningful amounts. It's not the 81 % it says here.

This is the number of signing calls. The overall build time dropped by like a minute and a half, if I recall. I know these things probably seem a bit silly, but I'm trying to emphasize this pattern to you guys.

If you find where there is friction in your flows, if you pay close attention to what keeps you from merging things, what keeps you from being excited to hit that button, what risks are blocking you, what mental burdens and barriers are keeping you from checking the code, what friction is making it worse to do so you delay it more and more until it never happens.

All of these are opportunities to improve your project, improve your workflow, improve the tools you use to build. And as you make more of these improvements, you'll feel that exponential growth in how much you can ship and how much confidence you have in what you're shipping. To go back to my contribution rate, I was able to more than double my throughput while on vacation because more and more of these changes landed and it got easier and easier for me to verify my own work.

But I need to be real with you guys. Mistakes do absolutely still happen. Sometimes things merge that shouldn't, especially if we're not putting a lot of effort into reading every line of code anymore.

Most of the bugs could not have reasonably been caught by just reading code. As such, it's really important to have some form of a safety net, a way to catch the mistakes so they don't affect all your users or cause real problems. We have an admittedly not perfect solution for this with T3 code, but due to the unique nature of our audience, it's proven to be pretty effective.

That solution is right here. The nightly builds. Don't let the term mislead you.

Nightly builds happen every three hours for us. So when a change lands, that change will be out in the nightly within three hours, often less. We have a dedicated set of nightly users.

It's a few thousand of our... surprisingly big 200 ,000 plus user base. So if we do have anything go wrong in the nightly, we immediately get a ton of reports about it.

And let's be frank, nightly users know what they're getting into. Things will sometimes break. Things will sometimes get removed after they're in.

The nightly builds give users the feeling that they're staying more on top of what we're doing, which is awesome and true. I saw a lot of people who were disappointed that I had the big announcement for the new release because they already had all the features because they were on nightly. The nightly builds are awesome because they give us a shitload of useful information about what may have broken.

As such, our stable releases pretty much never have real regressions because they get noticed so heavily during this nightly testing window. There are other ways to do this. You can do slow rollouts where you only roll out changes to 1 % of your users.

And if you start seeing errors or issues, you immediately roll back and go figure them out. You can have a formal QA team that does thorough testing of everything before the code goes out. The key things I want you to take away from this point are, I guess, twofold.

The first is that you need a way for the changes that break to not have to affect a ton of users and be easy to catch and fix. But the more important piece here that is a little hidden underneath, I want you to de -risk the merge button. You shouldn't even be looking at the pull request until a bunch of agents have relatively high confidence that it's ready for you to look at.

I want you to have better ways to test the changes yourself so that you have confidence too. I don't want you to have to worry when you hit merge that if something breaks, it's going to affect all of your users. So ideally, you will reduce as much friction as possible before you even get in the PR so that you have relatively high confidence going in that things will work.

And then after you've built a bit more confidence that you're hitting with no fear, because if it does break, the break will be caught and addressed fast enough. In order to de -risk merge, you need to address both sides. You need to address what makes going to the PR in the first place feel useless.

You need to address the risks when the PR seems ready to go that still make merge scary. And our boy Agor has caught on. This has been one of my philosophies since day zero, since way before I was doing content.

Safety nets, not guardrails. I'm not saying don't test. We have a shitload of tests in T3 code and we're probably merging more tests than we are features nowadays.

But the safety nets are what make T3 code so safe. The fact that a change that breaks things will be called out and noticed before it hits even a thousandth of our users makes it so much easier to hit merge and worry later. I think all of these pieces are what has allowed me to be as productive with T3 code as I have been.

From the inbox style sidebar that I treat like a to -do list, to all the systems I have built for verifying changes, to all the unique ways I burn tokens in order to be more confident in my work. to the ways I can ship with confidence and the ability to roll back if things do go wrong. All of this has enabled a part -time dev like me, as well as the full -time devs on my team, to ship way faster and way more confidently.

And I don't really care if you're using T3 code or not, because the people who are have already seen the difference and are very happy with it. I know that a lot of this might have come off as an unintentional plug for T3 Code, but what I really wanted to be was a showcase of how I improve the tools I use by running into problems and also the workflows I have built around T3 Code in order to be as productive and effective shipping software as possible.

And I'll be frank, a lot of why I made this is I want to look back to it in six months and see how silly some of the things I was doing are, because every time I make one of these workflow videos, I get told by a lot of people how helpful they are. even a year later when they've long since stopped being helpful. Man, I need to do one of these every three months now, don't I?

What a fun journey. Hopefully you have a better idea of how I've managed to stay productive with the utter chaos that is my life and my coding setups. Maybe you learned some things here.

Maybe you hate everything I just showed you. Let me know in the comments. And if you have pro tips that are things that could benefit my workflows that I'm not trying yet, please let me know those as well because I'm always looking for opportunities to improve, streamline, and be more effective in this new era of development.

Let me know how y 'all feel. Until next time, peace nerds.

The Hook

The bait, then the rug-pull.

Theo opens by admitting the thing his contribution graph should be hiding: he barely sits down to code anymore. Then he shows the graph anyway, a summer spike from 1-3 merged PRs a week to 52, and spends the rest of the video proving the spike is real by showing exactly how he built it.

Frameworks

Named ideas worth stealing.

09:10concept

Non-negotiable vs. 'in my opinion'

State the hard requirement plainly
Soften negotiable parts with 'in my opinion'
Admit what you don't know
Ask for an audit, not a fix
Give explicit permission to stop early

A prompt structure for keeping an agent from over-executing: separate what's fixed from what's negotiable, expose your own knowledge gaps, and explicitly cap the ask to investigation rather than implementation.

Steal forany complex one-off agent prompt where you want investigation before code changes

47:50concept

Safety nets, not guardrails

Prioritize fast, cheap-to-catch failure detection, like frequent nightly releases to opt-in users, over heavy pre-merge gatekeeping, so shipping stays fast while regressions still get caught before they reach most users.

Steal forany team deciding between more manual code review versus faster release cadence plus monitoring

CTA Breakdown