You're using AI agents wrong

0:00I 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

0:29companies 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 it 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 PR's a week. Huh. I know it says commits, but we squash merge. So what this actually

1:02means is the amount of PR's 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, then 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 Def Con. And somehow between my flights, my Ubers and my awful internet at the hotel at Def

1:29Con I managed to get 52 PR's landed. Huh. Okay, I may have baited 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 Potatoes 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 out-shipping you. And if that is the case, I think you'll like this video a lot cuz I don't want to keep any of this secret. I'm just going to show

1:59you 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 a very revealing video where I show how

2:13I 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 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

2:39simply 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 Browserbase. They built the best browser for agents so that they don't have to be limited to the 15 to 20% of the web that they can access over curl. They can now access everything. Whether you want to 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 in to pages, complete real actions, and get

3:09real 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 a CAPTCHA, they get stuck often. Unless you're using

3:39Browserbase, 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 Browserbase, and you can figure it out yourself at cited.link/browserbase. 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 that we're 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

4:12chatter 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

4:48triggered. This is a bug I didn't know about because I don't have manual 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 hot key for it. Step two, paste. Step three, and this one's really important in my opinion, make

5:10sure 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 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 codebases on it and a T3 Code server so I can select BB-Wan, which is

5:39my 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, CodeX, and Claude 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

6:02get 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 into 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

6:37I'm down a hand and WhisperFlow's 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 link correctly. 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

7:08composer becomes the right text for the model to add it in. I want you to do a thorough audit of both Claude 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

7:26with 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 is 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. Doesn't really matter. Just said it so I'm filming and it makes life

7:51easier. You have the context now. I want to make a fix that is both simple in implementation and not confusing to users when we 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

8:13overriding this or ignoring this part. This sentence where I said I want to make a fix that is simple in 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 Drilling 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

8:39any skill anywhere in the composer and have it link correctly. This is giving it the contours 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

9:13where 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 Claude 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 sentence is saying what I want this thread to end up at. But now

9:36I'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 cuz I know how the code base works. If you see a simple fix that we can apply to solve the problem, stop and

9:50let 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, and 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

10:21Fable. 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 cuz I don't feel like waiting. And I'll bump extra high cuz 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

10:35important 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

11:00something 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

11:27Claude 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 off, or I remove all the CLI proxy stuff from this computer to switch over to normal Codex and Claude off. I

11:58pull 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 like soda out of the fridge or something. And now I have lost all of the contacts 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

12:26likelihood 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 that 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 off, 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

12:55change. 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 have it implemented. I know apps like Codex Bar have an implementation of

13:30this, 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 the formatting of this pretty bad here, but honestly, I don't care. The models are good enough to turn slop voice-to-text

13:52into 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 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

14:24work 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 cuz this computer's 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

14:4112% 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

15:19sitting 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 in 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 cuz it's Claude 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

15:51lot 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 code I'm 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-53-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

16:21bunch 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 sub-agents to break up the work and come back to me when you have a good idea of

16:37what 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 cuz I gave this question to them 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 53-Flash, but since 53-Flash is surprisingly capable and hilariously

17:01cheap, this will cost me nothing. Obviously, if I did it with Luna instead, it would also effectively cost nothing cuz I have so much usage available, but I like 53-Flash, so why not? I'll try it with this. And just cuz, also why not, I'm going to paste the same thing. I'm going to switch over

17:16to Luna. And I'll bump it to fast on I'll do high fast. Why not? Cuz 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,

17:51usually the PR that it 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 cuz 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. come back to it later to explain why I did it, but for now,

18:20squash and merge. Now that it's 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

18:39ruins 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 cuz 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,

18:58settle, settle. Valid PR closure candidates, settle. This one I 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 a for this. Snooze. I can snooze this for in 3 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,

19:29and even then, I don't need it that often. If the model could build the context initially, you 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, I

19:49verified Claude 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 it hard codes enabled true. It ignores disable model invocation, user invocable, and skill overrides from settings. Apparently, the dollar sign is Codex syntax, and we're currently sending it to Claude untranslated. It's Good thing I had it do this audit. I just learned something about that we're

20:12doing wrong here as part of it. Apparently, the slash only explains the 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

20:31understand 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

21:05I 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

21:38I 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 Soul for exploring things on the machine and its history and challenges it's run into. I don't need fast for this cuz 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

22:09another 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, cuz 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. Our nature's right for T3. CI's green every bot find except one is fixed at the head, but it has no

22:44429 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 Claude code itself, not the open source repo for Claude code because it's closed source, but on the repo that they put their

23:09skills in the 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 people building things like this is closer to 180 seconds. Once

23:34again, 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

24:11comments 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 and 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

24:39if 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 and the risks with this PR. Hey, when I'm left with this 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

25:09is 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 Claude code expects because Claude 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 Claude code specific. Ideally, we can make Claude 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 once to make the UI a little smaller so

25:43it 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 Claude 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 compare it against Codex bar CC usage yada yada yada. Three things need to change before merge and a few follow-ups are worth tracking. And

26:11here 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, let's stash that in the JSONL 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 Claude

26:42code with T3 code, but I'm also working on Claude 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 Claude 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

27:05have here. One, the SDK response probably doesn't include 7-day Opus or Sonnet 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

27:44accordingly. I think these changes are simple enough that I trust the model to apply them correctly to the comment. And also in 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

28:04don'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

28:37merges, 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

29:07PR 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 cuz 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 it left. Note: Claude Fable

29:27Fiber is running on Theo's behalf. This is exactly what I wanted it here. Awesome. This is great. I'm much happier now. One more quick note on letting the model like 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,

30:05and 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

30:39paragraph 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, and 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

31:14those 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

31:33finished. 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

31:57memory. 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 together. For 204,

32:17use compressed native web socket 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 cuz it'll confuse me having that there when it's not the one I want to use. By three flash is doing a much better job. It spun up four sub agents to break apart the PRs and now it's

32:48doing a follow-up run with the things that it No, it's initializes out 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

33:19commands. There's also a Claude 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

33:39mode on 2.1.237. It looks like there's a real gap between what Anthropic is reporting as possible and what is actually allowed in terms of the multiple skills indicating at the start. Can you hunt through open issues on Claude 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 behavior and gap between the docs and the actual capabilities. I do love that even

34:16Anthropic models know that Anthropic's docs are utter full of lies. The main argument for open sourcing Claude code is that their docs are so and they should never make us read them because now I have two layers of obfuscation I have to fight through and integrating Claude code. I guess free, 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

34:47that matters. I'm going insane. I 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 the correct

35:15option, 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

35:37comment. 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

35:58try 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 1 2 3 4 5 6 7 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, hey, hey, hey, 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

36:25can you build in a single thread? And the answer's been a lot. I have built the whole app with 95% of the code in just this one thread with 5-6 sole on a MacBook remotely with no issues. It's been very cool. I'm like at least a hundred prompts into this probably. This one can't merge though because I haven't gotten Julius' permission so it just sits here pinned

36:46forever. 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

37:10want 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's 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

37:35test 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

37:59starting 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 it tested out in my browser for real. I have some files here that are pretty notably not images. So let's drag

38:27and 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

38:59screenshots. 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

39:16message. 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 things 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

39:42that 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 in to figuring out how to work around that fact. For mobile, I did some research and I found this project Swim. 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

40:13a 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 the fact 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 I've solved for iOS builds well enough to get some

40:47useful 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 off redirect edge cases, I was tired of merging, waiting for a nightly, checking it and then realizing it was broken. So I wanted a

41:14better 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 macOS with a label. So what this enables is I add the label preview:mac and then after some amount of time passes, a macOS preview DMG download appears in the thread that I can click on, 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

41:49built 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 off 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 Codex. I cleared all T3 code history on it. I downloaded this and made sure it

42:13worked, but I hit a problem. I couldn't download it on that machine because I wasn't signed in 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 off does a core contributor to the project. Uh which was a sane default that added, but didn't make sense for my use case. So, I made those two PRs in order to make it way

42:41easier for me to test on other machines. And it's like legitimate infrastructure. It's not super complex cuz it's 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

42:56to 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 8 minutes. So, macOS builds taking six doesn't matter cuz 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

43:19amounts. It's not the 81% it says here. This is the number of signing calls, but 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

43:51more 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

44:18I 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

44:40all 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 3 hours for us. So when a change lands, that change will be out in the nightly within 3 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,

45:21nightly 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 cuz they already had all the features cuz they were on nightly. The nightly builds are awesome because they give us a load 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

45:54testing 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

46:24that 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

46:54then, 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

47:13ready to go that still make merge scary. And our boy Igor 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 testing 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

47:47be 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

48:16difference 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

48:34effective 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 6 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 3 months now,

48:52don't I? Huh. Ah. 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, cuz I'm always looking for opportunities to improve, streamline, and be more effective in this new era of

49:17development. Let me know how y'all feel. Until next time. Peace, nerds.