Speaker A
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.
Theo shares how he uses AI agents and remote setups to stay productive as a CEO and part-time coder, revealing his workflow and tools.
Key Takeaways
- Effective use of AI agents and remote machines can significantly boost coding productivity even for busy CEOs.
- BrowserBase enables AI agents to access and interact with much more of the web than typical browser APIs allow.
- Multi-threaded, multi-agent workflows and remote build systems improve development speed and reliability.
- Voice-to-text and automation tools help maintain productivity when multitasking or limited physically.
- Transparency about workflow challenges and solutions can inspire and educate developers on improving their own processes.
What the video covers
- Theo discusses balancing running companies and coding, noting reduced personal coding time but increased productivity using AI agents.
- He highlights a spike in his GitHub PR merges due to new workflows that allow coding while managing other responsibilities.
- The video introduces BrowserBase, a sponsor tool that enhances AI agents' web browsing capabilities beyond typical API limits.
- Theo explains his remote coding setup using a dedicated Linux box to offload work and avoid bottlenecks on his main machine.
- He demonstrates how he triggers AI skills using commands and addresses a bug related to manual-only skill invocation.
- The video covers improvements to the T3 Code project to support multi-threaded, multi-agent workflows and remote builds.
- Theo uses voice-to-text tools like Whisper Flow to aid coding while multitasking with limited hands.
- He shares insights on managing PR prioritization, testing, and build optimization to maintain high productivity.
- The video includes real-time coding and debugging, showing transparency about his workflow and challenges.
- Theo encourages viewers to learn from his approach, adapt what fits, and share their own productivity tips.
Chapters
- 00:00Introduction: Balancing CEO duties and coding
- 02:42BrowserBase: Enhancing AI agent web access
- 05:32Remote coding setup with Linux server
- 08:26Skill invocation commands and bug discovery
- 11:12Multi-threaded workflows and T3 Code improvements
- 14:28Real-time coding with voice-to-text
- 18:24PR prioritization and build optimization
- 22:48Testing, QA, and maintaining productivity
- 29:59Conclusion and viewer engagement
Full Transcript — Download SRT & Markdown
Speaker A
Not that 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
Speaker A
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
Speaker A
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.
Speaker A
These are things that are really fun and important to me, and it's 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,
Speaker A
you see, uh 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
Speaker A
spike in mid-July where I went from 1 to 3 a week to 23, then to 37, then to 41, and then all the way up to 52. Huh.
Speaker A
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
Speaker A
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
Speaker A
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 outshipping you. And if that is the case, I think you'll like
Speaker A
this video a lot 'cause 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
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
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.
Speaker A
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.
Speaker A
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
Speaker 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
Speaker A
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
Speaker A
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
Speaker A
browsers. Whether they're hitting from an IP address that's blocked or they're trying to get around 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
Speaker A
a reason everyone from Microsoft to DeepMind is using BrowserBase and you can figure it out yourself at soy.link/browserbase.
Speaker A
So let's dive into 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
Speaker A
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
Speaker A
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
Speaker A
with the slash command. It will not work with the dollar sign command version because a 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
Speaker A
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
Speaker 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
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
these changes. That box is selected. It has all of my harnesses, codecs, and cloud 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
Speaker 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
Speaker A
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
Speaker A
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
Speaker A
multi-threaded, multi-agent thread environments. So let's kick this one off. I'm going to use voice to text here because, uh, I'm down a hand and Whisper Flow has been nice for this type of thing. So let's get going. This is an
Speaker A
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
Speaker A
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 cloud c
Speaker A
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 Claude Code's behavior as well as how we are
Speaker A
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.
Speaker A
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
Speaker 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.
Speaker A
Doesn't really matter. Just settle 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
Speaker A
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.
Speaker A
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
Speaker A
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
Speaker A
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.
Speaker A
This is giving it the contest 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
Speaker A
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
Speaker A
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
Speaker A
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 end
Speaker A
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
Speaker A
the problem lives because I know how the codebase 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
Speaker A
permission to at any given point if it finds the solution and it has four other sub aents 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.
Speaker A
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
Speaker A
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, also going to switch to full
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
touching on this a lot throughout. Another thing somebody did during the stream is they linked 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
Speaker A
of reasons. This one's also going to be a bit hard for me to test because I'm not using codeex or cloud code with the normal O anymore. I'm using these through CLI proxy. So, the usage limits aren't even exposed. So, I won't even
Speaker A
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
Speaker A
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 codeex and cloud off. I pull down the PR, I
Speaker A
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
Speaker A
grab a like soda out of the fridge or something. and now I have lost all of the conducts in my head of what work I was doing. So you need to do whatever you can to avoid those demotivating
Speaker A
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
Speaker A
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
Speaker A
feature that a lot of users are asking for. Unfortunately, I don't use normal O, 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
Speaker 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
Speaker A
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
Speaker A
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 this, for example. I want you to audit the implementation, find all of the
Speaker A
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, Whisper Flow the formatting of this pretty bad here, but
Speaker A
honestly, I don't care. The models are good enough to turn slop voice detects into the actual stuff that we want.
Speaker A
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 BB-1. I have a lot of work running on this machine. I have other separate things running in the
Speaker A
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 aents in all
Speaker A
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 cuz this computer is super powerful. Obviously 32
Speaker A
cores is a lot. I got a 16th 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
Speaker A
really solid. And this is because I'm running Linux, not Mac OS. Mac OS 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 Mac OS anymore. Generally speaking, I
Speaker A
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
Speaker A
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 Abuntu on it, and have a much better experience with lots of agents in parallel. Probably one of
Speaker A
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 to my productivity. So now we have two threads going and these are both ones that'll
Speaker A
take a while. Both because the task I gave them was expansive, but also because it's cloud code running on XI.
Speaker A
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
Speaker A
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 any given time. I just I can't know anymore. So, how do I deal with that? If
Speaker A
you guessed burning more tokens, you're starting to catch on. I'm going to swap over to GLM53 Flash because it's genuinely a really impressive model, especially at its price. I'm just using it in Codex. Doesn't really matter where you use it, but it's good at stuff like
Speaker A
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
Speaker A
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 what I should be closing, merging, etc.
Speaker A
Prioritize based on the ease of action so I have easy things to merge on top.
Speaker A
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
Speaker A
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 five free flash is surprisingly capable and hilariously cheap, this will cost me nothing. Obviously, if I did it with
Speaker A
Luna instead, it would also effectively cost nothing because I have so much usage available. But I like five free 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
Speaker A
to switch over to Luna and I'll bump it to fast on I'll do high fast. Why not?
Speaker A
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
Speaker A
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
Speaker A
your sidebar. You get this little button here that shows the PR that this thread is associated with. Usually 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
Speaker A
here, I'm going to commandclick 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
Speaker A
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.
Speaker A
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
Speaker A
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
Speaker A
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.
Speaker A
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
Speaker A
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
Speaker A
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, probably don't need it that often. If the model could build the context
Speaker A
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
Speaker A
competent path and it's simpler than expected. The audit's done. I verified Cloud Code's real behavior. Cool. This is the one for fixing the skill bug.
Speaker A
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 hardcodes enabled true. It ignores disabled model invocation, user invocable, and skill overrides from settings. Apparently, the dollar sign is
Speaker A
codec syntax, and we're currently sending it to Claude untransated. It's a good thing I had it do this audit. They just learned something about that we're doing wrong here as part of it.
Speaker A
Apparently, the slash only expansit message start at 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
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
noticed a new issue in T3 code just now coming from the remote connection to the machine that this prompt is running on.
Speaker A
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
Speaker A
middle of writing this prompt. I'd like you to investigate what's going on on 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
Speaker A
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 because again, I'm just letting these things run in the background. So,
Speaker A
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
Speaker A
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.
Speaker A
This other thread though is auditing the provider usage dashboard is completed now too. PR8327 audit subscription limit meters good bones hold before merge architecture is right for T3 CI is green every bot find except one is fixed at
Speaker A
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
Speaker A
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
Speaker A
it's closed source, but on the repo that they put their skills and let 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
Speaker A
happen a few times myself. It is really annoying and I'm happy the model found it and recognize it is 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
Speaker A
floor that people agree on in the community, people building things like this is closer to 180 seconds. Once again, I am faced with some issues.
Speaker A
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
Speaker A
research you've done. I want to leave a useful comment for the user who sorry for the contributor who put up this poll request. Help me draft a good comment to leave for this user with the core insights shared here to make it easier
Speaker A
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
Speaker A
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
Speaker A
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
Speaker 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
Speaker A
understanding of the problem and 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 SLK skills at the front are applied. That
Speaker A
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
Speaker A
indicate after the second one that that command cannot be moved to the front and applied the way that cla code expects because cloud code can only show one command at the front. Is this the right solution? Do you have other better ideas
Speaker A
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 Codeex does. I have given it my
Speaker A
additional questions and thoughts. It will give me more info. I command minus once 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
Speaker A
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.
Speaker A
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 Codex RC usage, yada yada yada. Three things need
Speaker A
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
Speaker A
that rate li that we're already scanning. Okay, this part is just wrong. So I'm going to tell it to not do that.
Speaker A
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
Speaker A
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
Speaker A
assumptions is so helpful and has prevented a ton of bugs. But I don't have the data on this machine because my O isn't going directly through cloud code or codeex. It's going through my CLI proxy. So it won't have the data it
Speaker A
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.
Speaker A
One, the SDK response probably doesn't include 7-day opus or sauna 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
Speaker A
not including it. Second, codeex's rate limits being written is useful, but those might be stale if you're also using codeex other places, too. I would really like to not have to make an API call, but I don't want to show bad data
Speaker A
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.
Speaker A
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
Speaker A
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. Tada. I don't have to worry about this anymore. In an ideal world, I would
Speaker A
be able to set something up in T3 code where after it finishes this, it auto settles because I don't care about this threat anymore. This now has all of my concerns addressed. But let's say I did want to leave this open because I wanted
Speaker A
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
Speaker A
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,
Speaker A
but the lazy option is often the best one. Instead of burning tokens on every thread, I burnt tokens on one thread. So that now I can rightclick a link to a PR and click link to thread. Now this PR is
Speaker A
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 gonna open this up quick
Speaker A
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 it left. Note Cloud Fable was responding on Theo's behalf. This is
Speaker A
exactly what I wanted to hear. Awesome. This is great. I am much happier now.
Speaker A
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
Speaker A
code project benefits from having an AI code review bot on poll 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
Speaker A
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
Speaker A
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
Speaker A
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
Speaker 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
Speaker A
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.
Speaker A
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
Speaker A
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.
Speaker A
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.
Speaker A
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,
Speaker A
I want to hop over to the PR audit that Luna on Highfast 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
Speaker A
at some point. I didn't think it had memory. I did not expect it to do that.
Speaker A
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
Speaker A
of week, I am not confident in doing that. Cloudflare, please get your together. Or 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
Speaker A
native changes. I had to rewrite the network layer in Swift. This is a bad recommendation.
Speaker A
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
Speaker A
not the one I want to use. 53 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's initialized
Speaker A
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
Speaker A
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
Speaker A
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 multiskll messages fully native skill stacking like slash a then
Speaker A
slb 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.
Speaker A
It looks like there's a real gap between what Anthropic is reporting is possible and what is actually allowed in terms of the multiple skills invocating at the start. Can you hunt through open issues on cloud code and see if others are
Speaker A
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
Speaker A
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 Anthropic models know that Anthropic's docs are utter full of lies. The main argument for open
Speaker A
sourcing cloud code is that their docs are so and they should never make us read them because now I have two layers of obuscation I have to fight through when integrating cloud code. I guess three really. There is the
Speaker A
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 obuscated and uglified so it's hard to actually dig into. Even the SDK is
Speaker A
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
Speaker A
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
Speaker A
two, I can go write a real better comment, which is the 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 cloud code team is
Speaker A
pretty cloudp. 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?
Speaker A
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.
Speaker A
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
Speaker A
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 1, two, three, four, five, six, seven threads here. Two are
Speaker A
pinned longunning ones. My Swift iOS app, which I rebuilt T3 code in Swift UI from scratch for fun, has gone way 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
Speaker A
an app can 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 56 soul on a MacBook remotely with no issues. It's
Speaker A
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's permission. So, it just sits here pinned forever. Obviously, there's a lot of things that are relatively easy to be
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
over tail scale but I can't really do much here other than like open a terminal or use the inapp 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
Speaker A
test this remotely on my computer. So, I put what was probably far too much time and token burn into adding a builtin tail scale share dev command. Let me demonstrate. I want to test these changes out quick. I'm on a remote
Speaker A
machine. Can you use the d-share dev command with tail scale 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 starting in the dev server. Oh, that was
Speaker A
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
Speaker A
that machine on a dedicated port running. So now I can open this and test it out in my browser for real. I have some files here that are pretty images.
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
it. The harness rendered the image directly in your message. So, I saw it pixels in line. The path is there, too, if I ever needed the raw bytes. Awesome.
Speaker A
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.
Speaker A
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
Speaker A
can try it and then try it and have 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
Speaker A
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
Speaker A
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
Speaker A
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 tail scale. Tail scale remote iOS
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
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 better way to test those things. So I gave myself one. I
Speaker A
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
Speaker A
enables is I add the label preview col 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
Speaker A
myself. This has made it so much easier to test changes that are desktop appsp 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
Speaker A
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
Speaker A
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 hit a problem. I couldn't download it on that machine because I
Speaker A
wasn't signing into 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
Speaker A
signed in on GitHub and off as a core contributor to the project which was a sane default it added but didn't make sense for my use case. So I made those two PRs in order to make it way easier
Speaker A
for me to test on other machines and it's like legitimate infrastructure. It's not super complex as 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
Speaker A
couple hundred lines of code for the build and another couple hundred lines to make it accessible without downloads.
Speaker A
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 Mac OS builds taking six doesn't matter because they're happening
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
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.
Speaker A
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
Speaker A
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.
Speaker A
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.
Speaker A
Nightly builds happen every three 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
Speaker A
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 breaks. Things will
Speaker A
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
Speaker A
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 shitload of useful information about what may have broken. As such, our stable releases pretty much never have
Speaker A
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
Speaker A
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
Speaker A
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
Speaker A
want you to derisk the merge button. You shouldn't even be looking at the poll 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
Speaker A
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
Speaker A
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
Speaker A
addressed fast enough. In order to derisk 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
Speaker A
make merge scary. And our boy Agore has caught on. This has been one of my philosophies since day zero, since way before I was doing content. Safety nets, not guard rails. I'm not saying don't test. We have a shitload of tests in T3
Speaker A
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 notice before it hits even a thousandth of our
Speaker A
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
Speaker A
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
Speaker A
confidence and the ability to roll back if things do go wrong. All 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
Speaker A
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 it to be was a showcase
Speaker A
of how I improve the tools I use by running into problems and also the workflows I've 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
Speaker A
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.
Speaker A
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? Huh? Ah, what a fun journey. Hopefully, you have a better idea of how I've managed to stay
Speaker A
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
Speaker A
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.
Topics:AI agentsremote codingproductivityT3 CodeBrowserBasemulti-threadingsoftware developmentvoice-to-textCEO codingautomation
