I have a confession to make. Ever since

I started focusing more on running my

company and running my YouTube channel,

I have been less good of an engineer.

Not that like my code is worse or I'm

holding the team back. Okay, I am kind

of doing that, but more I'm just not

able to spend as much time coding. I

rarely get a moment where I can sit by

my computer and I'm not behind on other

more important things that only I can do

like email or filming or working with

sponsors or all this other stuff. And I

love it. I'm not complaining. I'm very

happy with where my job, my team, my

companies, and my life are, but I did

miss coding a lot. I just like being in

the trenches, solving hard problems,

building cool stuff, and seeing the

software I use every day improve as we

make changes and just make it better.

These are things that are really fun and

important to me, and it's 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 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

spike in mid July where I went from 1 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

Defcon. And somehow between my flights,

my Ubers, and my awful internet at the

hotel at Defcon, I managed to get 52 PRs

landed. Huh. Okay, I may have bathed you

guys a bit. I finally found flows that

allow me to be as productive as I want

to coding while also having to run the

rest of my life. And while I may not be

at 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

this video a lot cuz I don't want to

keep any of this secret. I'm just going

to show you guys exactly how I work. And

if all goes well, I'm going to land some

real changes while I'm filming this

video. I've never done anything like

this and I'm admittedly kind of scared.

I'm going to be showing my ass a bunch

here. This is a a very revealing video

where I show how I work. Not all of it

will be perfect. Not all of it should be

copied, but at the absolute least, I

think you can learn some really cool

things. And the first really cool thing

I want to show you guys is today's

sponsor. If your agent doesn't have

access to the web, it's probably not a

very good agent. The knowledge in the

models is not enough to make them

effective at the things we want them to

do today, which is why they need a

browser. And if they're just using the

browsers that are available to them

through the existing APIs, they're

probably going to get stuck a lot

because over 80% of the web cannot

simply be curled or fetched over APIs.

That's 80% of the things your agent

could use to do better that it just

doesn't have access to. Unless you're

using today's sponsor, browser base.

They built the best browser for agents

so that they don't have to be limited to

the 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 endto-end browser where your agents

can click buttons, sign into pages,

complete real actions, and get real

things done, browserbase has you

covered. And it's not just useful for

getting data from other places. It's

also useful for testing your own things,

too. If you want to make sure certain

regressions stop reappearing in your app

or certain flows are guaranteed to work

24/7, you can set up an agent with

browser base to be constantly testing

them, actually going through flows

before a user ever hits a bug. And as

smart as agents are, they do often get

stuck when they're trying to use

browsers. Whether they're hitting from

an IP address that's blocked or they're

trying to get around to capta, they get

stuck often unless you're using

browserbased 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

soy.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 I've been making to T3 code

have been from my experience working

this way and trying to improve so I can

ship even more. Here is one that a

chatter mentioned while I was streaming

that seems pretty legit. If you use the

dollar sign to trigger skills, this

works great for skills that are in the

project or out of the project. But there

is a catch. If the skill can only be

invoked manually, which is a condition

you can put on a skill, it only works

with the slash command. It will not work

with the dollar sign command version

because 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

able to trigger skills that have to be

manually triggered. This is a bug I

didn't know about because I don't have

manual only on for many skills and even

those ones I don't use that much. So, I

haven't encountered this, but it's a

legit bug that I just didn't know about

that I now know about. So, let's see how

I work. Step one, new thread. I have a

hotkey for it. Step two, paste. Step

three, and this one's really important

in my opinion. Make sure it's not

running on your computer. I'm not saying

make sure it runs on someone else's

computer. I'm saying that the laptop or

whatever other machine that you're doing

other stuff on should not be held back,

bottlenecked, or required for this work

to be completed. Ideally, you have some

setup. For me, the way this works is I

have a Linux box in the other room that

is oversp 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 code bases

on it and a T3 code server. So, I can

select BB1, which is my box in the other

room to be the box that's going to run

these changes. That box is selected. It

has all of my harnesses, codecs, and

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

lot of the problems as they exist today,

but they're a good enough abstraction,

especially if your file system handles

them well, that you can just spin up a

bunch and it's mostly fine. So, let's

get this one going. Before I do this

though, I do want to call out we are at

the very surface level right now. Where

things are going to get really cool as

we go is the work I did to T3 code

itself to make both working in T3 code

easier, but also to add features and

remotely build things into T3 code

easier. So T3 Code itself I've improved

to make it easier to work this way, but

the T3 Code repo has examples on how to

set up other projects to work well in

multi-threaded multi- aent 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

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 cloud code as to

how these behaviors are triggered or

even how the skill that I'm seeing in

the composer becomes the right text for

the model to add it in. I want you to do

a thorough audit of both 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

with a good experience for our users.

There's a couple pieces of this prompt I

just spoke that I want to explain. This

one isn't necessary, but I found it

helps to let it know that a number of

users are affected. This isn't some

small side project that this is a

problem. This is a thing that is

affecting real people. It gives it

context that this is important and

should be done reliably, not just

experimentally. I was unaware of it.

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

want it to be built in a way that is not

confusing to users in my opinion. And

here is where I'm telling it

effectively, I'm okay with you

overriding this or ignoring this part.

This sentence where I said, I want to

make a fix that is simple implementation

and not confusing to users. That's a no

compromise line. I am saying very

clearly this is my expectation. I then

say in my opinion because if this thing

isn't viable, I want it to tell me as

such or if it thinks there's any reason

I shouldn't do this, it'll be honest

with me. You could also use something

like the Matt grilling skill for this,

but for a one-off issue, you shouldn't

answer 50 questions. So, in my opinion,

you should be able to use the dollar

sign to call any skill anywhere in the

composer and have it link correctly.

This is giving it the 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

the composer becomes the right text, the

model expects to add it in. This is me

saying where I am at with this

understanding. both so the model doesn't

blindly trust the issue and the things

I've told it, but also more importantly

so it'll do a better job explaining the

things I don't understand when it

responds. Now that it knows where my

knowledge is, it knows what I do and

don't have to care about when it

responds. I want you to do a thorough

audit of both 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

is saying what I want this thread to end

up at. But now I'm saying I don't want

you to do that. I want you to do a

thorough audit of these things that I'm

not sure about and I know that's where

the problem lives because I know how the

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

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.

Anyways, come back when you have a

confident solution to the problem with a

good experience for our users. I'll say

confident path to a solution so it

doesn't possibly interpret that as

meaning write the code. I think I've

made it pretty clear here that I don't

want it writing code, but fable is

fable. If you don't say something

explicitly, it will do whatever it

wants. And I'm curious what it ends up

doing. So, also going to switch to full

access because I don't feel like

waiting. And I'll bump extra high

because why not? I've given it easy

outs. And now this is running. I'm going

to show you guys what's arguably the

most important step of landing a lot of

code. Ignoring the thread until it's

done. If you spend all of your time

sitting and watching threads, waiting

for them to have an answer, you're not

being productive. It feels productive

because you see changes happening on

your machine for something you're

responsible for. But that thread's not

going to complete any faster if you keep

it open. And 99% of the time, you're not

going to see something going on in the

thread that you really want to stop. So

just go do something else. I also see

chat pointing out a real problem. And

this is a problem that pissed me off so

much that I spent weeks trying to solve

it. I start too many threads and I get

lost sometimes. I promise you we'll be

touching on this a lot throughout.

Another thing somebody did during the

stream is they linked 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 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

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 codeex

and cloud off. I pull 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 conducts in my head of what work I

was doing. So you need to do whatever

you can to avoid those demotivating

moments. One of the best things you can

do is reduce the likelihood that the bad

outcome happens. In this case, the bad

outcome is I put a lot of work in. I try

the code and it fails. One of the

easiest ways 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

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

thorough audit of the change. Find any

potential failures, obvious issues, and

things that could negatively affect

users if we were to merge it today. My

immediate areas of concern are the

frequency in which we are using these

API calls. I don't want to be spamming

the APIs in a way that would potentially

get users banned. I also want to make

sure that this data is fetched reliably

and accurately in a way that won't

confuse users if they see different

numbers in a dashboard than they see in

our product. I'm also curious how our

implementation compares to other things

that 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

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

honestly, I don't care. The models are

good enough to turn slop voice detects

into the actual stuff that we want.

Sent, I also again see concerns in chat.

Multi-agent workflows are going to be

brutal on any Mac you pick. Again, I'm

running these on BB-1. 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 aents in all

of them. on top of the other background

work I'm running here. I've had points

where on this machine I was running 40

plus agents and it wasn't breaking a

sweat. And it's not even cuz this

computer is super powerful. Obviously 32

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

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

treat my Macs as one or two tasks at a

time and I treat my Linux boxes as

effectively unlimited tasks at a time

because I've never managed to saturate

unless the tasks are running things that

are super heavy like they're running

unbounded Rust compiles that use all my

RAM and stuff like that. But you can

take any old laptop or desktop that's

sitting around, throw Abuntu 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 to my

productivity. So now we have two threads

going and these are both ones that'll

take a while. Both because the task I

gave them was expansive, but also

because it's cloud code running on XI.

So these are going to be brutal. So

let's do step three.

of how I'm landing so much. As you can

guess, a lot of these things result in a

lot of code being put up in PRs. But

keeping track of that all, okay, I'll be

frank here. It's impossible. The amount

of 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

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

what I'm about to do. I have a bunch of

PRs open in this repo and I've kind of

lost track of them. I want you to go

through all of them and help me

prioritize them. Which ones are ready to

merge? Which ones should probably be

closed? Which ones need another pass

before they're safe to merge? Use 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.

Prioritize based on the ease of action

so I have easy things to merge on top.

This prompt might seem weird because I

gave this question dump at the end. I

find these are actually very useful for

the model because it gives it a better

idea of what my goal is. What do I

actually want to learn from the work

it's about to do? This is also one of

those tasks that will take a bit even on

a fast model like 53 flash. But since

five free flash is surprisingly capable

and hilariously cheap, this will cost me

nothing. Obviously, if I did it with

Luna instead, it would also effectively

cost nothing because I have so much

usage available. But I like 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

to switch over to Luna and I'll bump it

to fast on I'll do high fast. Why not?

Because again, Luna uses basically

nothing. So now I have two threads with

different models, which is another hack

we'll talk about later, auditing my work

to see what it thinks I should be

prioritizing. Right now, while these are

running, I want to show you guys a few

more of my how I keep track of my work

tricks. One of the things I've really

liked in T3 Code recently is how we

integrate and relate a PR to a thread in

your sidebar. You get this little button

here that shows the PR that this thread

is associated with. Usually the PR that

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 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

to this thread and that means when I

merge this PR, this thread will

disappear. This seems totally fine. I

know the consequences of this PR. I will

come back to it later to explain why I

did it. But for now, squash and merge.

Now that 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 ruins your workflows,

it's totally fine. You can go turn it

off in settings. But the goal I had here

is that if you have it in your sidebar,

it's because there's more work to do. On

that note, I have things here that I

don't really need in here anymore. Most

of them were me testing things when I

was setting up for stream earlier. So,

I'm going to settle settle settle.

Validate PR closure candidates. Settle.

This one actually I know what this one

is and there are things in there I want

to deal with. So, I will leave that

open. But if I don't want to deal with

this now, I added a feature for this

snooze. I can snooze this for in 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. And even then,

probably don't need it that often. If

the model could build the context

initially, it can do it again. So now we

have three threads running, none of

which are making changes, all of which

are investigating things and helping me

make better decisions around existing

stuff. This one finished though, so

let's take a quick look. I have a

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.

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

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.

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

sit there and force myself to focus and

understand it. But remember the theme,

use tokens to reduce stress and

likelihood that you decide to go do

something else. I found myself with the

temptation to tab out and go do

something else here, but I have to fight

that and I'm going to fight it with

tokens. Watch how I do it. I really like

your description of the problems here. I

feel like I understand the issue well

now. I find your solution hard to parse

and I can't tell which parts of the

problem you're actually solving. Can you

give me a simpler, easy to digest,

explain like I'm five description of how

you plan to fix these problems? And now

I don't have to let the ADHD win. In

fact, I can guilt-free move to this

thread that just finished the work it

was doing. I also just noticed another

bug, which is that this thread didn't

mark itself as done properly. So, I'm

going to ask about that quick, too. I

noticed a new issue in T3 code just now

coming from the remote connection to the

machine that this prompt is running on.

I noticed that some threads when they

are finished and done with some work are

not correctly marking the thread as

done. I have no idea what the cause of

this could be. I also just noticed that

I disconnected from the remote in the

middle of writing this prompt. I'd like

you to investigate what's going on 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

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,

I'll send it off to go explore the

issues that I experienced right now.

This is another thing that I found helps

both with the quality of experience for

our users, but also with bumping up my

PR numbers. I have made it so

frictionless to go spin up a thread

whenever I notice an issue that I close

issues super fast and I force myself at

all times when I notice an issue like

this to go address it immediately

because otherwise it'll never happen.

This other thread though is auditing the

provider usage dashboard 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

the head but it has no 429 hygiene it

pulls the cloud endpoint faster than the

community accepted floor it fabricates

an unlimited window that the API never

reports and it ignores free local data

sources that other tools use to avoid

network calls entirely. That's a bunch

of really good insights. I like that

it's calling out the 429 risk and it

successfully found issues people have

opened on Cloud Code itself. Not the

open source repo for Cloud Code because

it's closed source, but on the repo that

they put their skills and let 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 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

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.

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 poll

request. Help me draft a good comment to

leave for this user with the core

insights shared here to make it easier

for this contributor to fix the problems

and make the PR ready to merge. I don't

want it to leave the comments yet. I

want the comments to both help me feel

more informed and if it helps me, it'll

help the contributor as well. So, I'm

going to tell it to do the same here as

well. Share your simple draft with me

here so that I can approve it before the

comment is left. Cool. This is now doing

its job and the one below has given me a

simpler explanation to what it was

describing. Simplify the problems. The

dollar menu shows skills that are broken

or turned off. And when you pick a

dollar sign skill, Claude never gets a

real instruction to run it. Claude only

forces a skill run if you use it with a

slash at the start. The fix the

translation step right before we hand

the message to Claude. And now that I'm

reading this, I have a much better

understanding of the problem 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

doesn't seem ideal. I would like for us

to make it very clear where skills are

being applied as well as what

restrictions claude code is applying to

us. The rough idea for this that I have

is if you do a slash command, we

indicate after the second one that that

command cannot be moved to the front and

applied the way that 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

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

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

on my machine for how I like comments to

be left by my agents. And it used the

skill here saying Cloud Fable 5 is

responding on behalf of Theo. Awesome.

Because the next step is going to need

that. Thanks for this. The shape is

right. Probe only on usage, page loads,

cache server side, degrade to no meters

on failure. We compared against Codex RC

usage, yada yada yada. Three things need

to change before merge and a few

follow-ups are worth tracking. And here

it says the must fixes and exactly what

those things are and why worth doing

your call whether here or in follow-ups

that you already offered. I don't love

that rate li that we're already

scanning. Okay, this part is just wrong.

So I'm going to tell it to not do that.

I have a pro tip that helps me a lot but

sadly won't help here again because my

setup is different. When I see an

assumption that I'm not sure about that

the model made, I'll ask it to audit

against my own history. Super useful

because I'm building on top of cloud

code with T3 code, but I'm also working

on cloud code with T3 code. So, it

having access to its own history on its

machine that it can check and verify its

assumptions is so helpful and has

prevented a ton of bugs. But I don't

have the data on this machine because my

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

needs to compare here. So I'm just going

to tell it what I know happens to be the

case. Some quick notes that I have here.

One, the SDK response probably doesn't

include 7-day opus or 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

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

by pulling from the cache unless we are

confidently showing what is accurate

data. I trust your judgment on this one,

but update your suggestions accordingly.

I think these changes are simple enough

that I trust the model to apply them

correctly to the comment. And also this

particular case, the contributor is in

my chat watching so he knows what my

intent is. So I'm just going to do the

lazy thing here, which is tell it after

you make these changes to your draft,

leave the comment on my behalf with the

same formatting that you have already

used. Tada. I don't have to worry about

this anymore. In an ideal world, I would

be able to set something up in T3 code

where after it finishes this, it auto

settles because I don't care about this

threat anymore. This now has all of my

concerns addressed. But let's say I did

want to leave this open because I wanted

to use it to check in on this PR later.

This is where one of my small little

hacks has been very useful for me. I

have been building T3 code to make these

workflows way easier. And I mentioned

already that I have things set up so

that when the PR merges, this auto

disappears. There's a problem though. I

didn't open this PR in this thread. So

the PR isn't linked. I could do some

crazy stuff to intelligently include it,

but the lazy option is often the best

one. Instead of burning tokens on every

thread, I 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

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

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

exactly what I wanted to hear. Awesome.

This is great. I am 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 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

over, I would see a bunch of comments,

and I would copy paste the ones I agreed

with back to the thread and say, "Fix

these." This was really inefficient and

obnoxious, so I made a skill to do it

for me instead. The babysit skill is

actually quite simple. It tells the

agent, "Hey, this PR probably has

comments from automated reviewers. I

want you to keep an eye on it. Take a

look every time automated review

comments come in and decide if they're

worth addressing. If they are, make the

changes, push them, and keep monitoring

the PR to see if the agents resolve

their comments. This one little skill is

a super simple, maybe one and a half

paragraph pile of text that creates a

loop. The loop is the agent makes the

changes, files the PR, we have all of

our automated review bots giving

feedback, 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 those AI

review bots. All of those layers could

have been more back and forth between me

and the agents doing the review and my

agent writing the code. But instead, it

all happens by itself and I'm not pulled

in until it's done. I love it. Cool.

This is no longer my problem. I can go

back to the other things. It looks like

the two PR prioritization threads

finished. Let's take a look at these.

Oh, sorry. This one wasn't the PR audit

finishing. This was the audit for the

bug that I dealt with. I don't feel like

I can give great advice fixing that

right now, but I will in a bit. For now,

I want to hop over to the PR audit that

Luna on 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

at some point. I didn't think it had

memory. I did not expect it to do that.

Here is what it made with Luna going

through all of these things. It said

that my PR raising the T3 code device

limit to five is ready to go. It is

ready, but due to issues with Cloudflare

that will hopefully be resolved by end

of week, I am not confident in doing

that. Cloudflare, please get your

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

native changes. I had to rewrite the

network layer in Swift. This is a bad

recommendation.

I do not like Luna for this type of

work. I am going to archive this because

I don't trust it enough and I just don't

even want it in my history because it'll

confuse me having that there when it's

not the one I want to use. 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

without starting the audits. Oh, did it

hit a bug? Whatever. It'll probably

figure itself out. I'll let it do its

thing. Back to the enable skills

anywhere in composer thread. I had asked

it a question trying to figure out what

is possible here. It calls out that I'm

missing a piece of the plan with the

translation layer. The front of message

rule stops applying to dollar sign

skills entirely. We relocate the

invocation on the wire. So a dollar sign

skill chip anywhere in your message runs

for real. The front only restriction

only remains true for raw slash

commands. There's also a cloud code

feature I haven't verified yet that

could make multiskll messages fully

native skill stacking like slash a then

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.

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

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

Anthropic models know that Anthropic's

docs are utter full of

lies. The main argument for open

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

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

closed source. The Python one isn't but

the JavaScript one is which is the one

that matters. I'm going insane. It

managed to find the issue for this and

Boris commented in the thread and

confirmed that it is a real bug. So now

I want your guys opinion chat. It

offered to post this comment for me. And

I have three options here. Option one, I

copy paste the comment and then leave it

in the PR directly. So it looks like

it's from me, but Fable wrote it. Option

two, I can go write a real better

comment, which is the 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

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?

I don't even need to see chat. I know

I'm right on this. You have my

permission to leave the comment. And

look at that comment has been left.

Cool.

So again, with the staying productive

thing, I know they're going to take a

bit on this one. So I'm going to snooze

this to next week. And if they haven't

solved it by next week, I'm going to

start bugging my contacts to get them to

try and fix it because this is stupid. I

really optimize for keeping my thread

list as minimal as possible. Even now, I

only have like 1, two, three, four,

five, six, seven threads here. Two are

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

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

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

like, "Oh, yeah, that makes sense. I hit

merge. Good to go." But there are a few

layers that I think are useful here from

what merge means to how I test things

before I merge to how I have exposed

this functionality so others can copy a

lot of it too. One of the most important

things you can do is make sure you have

everything in place to make it easy to

test code that you want to validate

before you merge it. This is a big

change that overhauls all of the file

upload processes in T3 code. So I want

to try it out. There is a problem here

though. This thread is on a different

machine that is remote. I am connected

over 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

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

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

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. So now I can open this and test

it out in my browser for real. I have

some files here that are pretty images.

So let's drag and drop one. What is the

file that I've attached here? How do you

have access to it? And now it is

running. And we shall see in just a

moment. Oh, look at that. It accessed

the data correctly. One of the things I

did for this upload change is whenever

you upload a file, it puts it in a user

data directory that the file path is

shared with the model. So it can use

whatever tools it wants to go read the

file. And it worked perfectly. I now

know that this code functions. I might

not have known that before. I do have

concerns that it might break

screenshots. So, let's do a screenshot

quick. Paste. How about this? What is

this file? What are the contents? It's a

PNG screenshot of the T3 code app

showing this exact conversation. Access

works differently for images. The file

was saved to the same attachments

directory, but I did not need to read

it. The harness rendered the image

directly in your message. So, I saw it

pixels in line. The path is there, too,

if I ever needed the raw bytes. Awesome.

All the concerns I had with this change

are addressed. Hypothetically, I could

just merge it. But I do have another

thread that's been auditing the changes

that thinks I should break it up more.

So, I'm letting that happen. Although,

god damn, I do really wish I could merge

this right now. How cool is that,

though, that I can just ask in the

thread for it to spin up the server so I

can try it and then try it and have way

higher confidence or lower confidence in

the right places that this code actually

behaves. There are some changes that

just cannot be tested in a browser

though. And I have accepted this and put

a lot of work into figuring out how to

work around that fact. For mobile, I did

some research and I found this project

Squim. Thank you to the people on

Twitter who told me about it. That makes

it relatively easy to access a mobile

app built on a Mac remotely where it

will build it and bundle it in a way

that you can install it through their

web app relatively trivially. It has

made it much easier for me to do a

remote build and then get a link that I

can click on my phone and install so

that I can actually test the changes

locally. Super useful. Not the best

solution. There's a couple edge cases. I

love they call it that you don't need a

VPN or tail scale. Tail scale remote iOS

builds are obnoxious but can be done.

This is much smoother but you don't get

all of the granular permissions that you

can on iOS normally. Like it restricts

share and airdrop and things because

it's not a fully signed build the same

way. So, I've now solved for web builds

because I can just access it remotely

and have solved for iOS builds well

enough to get some useful stuff out of

it. It doesn't have everything, but it's

more than enough when I'm like on the go

to test a change quick. But what about

the desktop app? I was admittedly lazy

about this one for a while where I just

didn't check desktop only changes

because honestly most of them were the

same way in web. But once we started

running into more and more issues with

weird 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

landed a pile of PRs that made this way

easier. The first one I had was a clever

fix I came up with, which was the

ability to trigger a preview build for

Mac OS with a label. So what this

enables is I add the label preview 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

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

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

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

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

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

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

couple hundred lines of code for the

build and another couple hundred lines

to make it accessible without downloads.

But I still wasn't satisfied. It was

slower than I wanted. The builds took

too long and it didn't matter before for

releases because Windows builds take 8

minutes. So Mac OS builds taking six

doesn't matter because they're happening

in parallel anyways. But now it does.

So, I did yet another thread where I

cleaned up the way that we were handling

signing to cut the build times by

meaningful amounts. It's not the 81% it

says here. This is the number of signing

calls, 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 more and more until it

never happens. All of these are

opportunities to improve your project,

improve your workflow, improve the tools

you use to build. And as you make more

of these improvements, you'll feel that

exponential growth in how much you can

ship and how much confidence you have in

what you're shipping. To go back to my

contribution rate, I was able to more

than double my throughput while on

vacation because more and more of these

changes landed and it got easier and

easier for me to verify my own work. But

I need to be real with you guys,

mistakes do absolutely still happen.

Sometimes things merge that shouldn't,

especially if we're not putting a lot of

effort into reading every line of code

anymore. Most of the bugs could not have

reasonably been caught by just reading

code. As such, it's really important to

have some form of a safety net, a way to

catch the mistakes so they don't affect

all your users or cause real problems.

We have an admittedly not perfect

solution for this with T3 Code, but due

to the unique nature of our audience,

it's proven to be pretty effective. That

solution is right here. the nightly

builds. Don't let the term mislead you.

Nightly builds happen every three hours

for us. So when a change lands, that

change will be out in the nightly within

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, nightly users

know what they're getting into. Things

will sometimes breaks. 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

shitload of useful information about

what may have broken. As such, our

stable releases pretty much never have

real regressions because they get

noticed so heavily during this nightly

testing window. There are other ways to

do this. You can do slow rollouts where

you only roll out changes to 1% of your

users and if you start seeing errors or

issues, you immediately roll back and go

figure them out. You can have a formal

QA team that does thorough testing of

everything before the code goes out. The

key things I want you to take away from

this point are, I guess, twofold. The

first is that you need a way for the

changes that break to not have to affect

a ton of users and be easy to catch and

fix. But the more important piece here

that is a little hidden underneath, I

want you to 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

yourself so that you have confidence,

too. I don't want you to have to worry

when you hit merge that if something

breaks, it's going to affect all of your

users. So, ideally, you will reduce as

much friction as possible before you

even get in the PR so that you have

relatively high confidence going in that

things will work and then after you've

built a bit more confidence that you're

hitting with no fear because if it does

break, the break will be caught and

addressed fast enough. In order to

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

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

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

users makes it so much easier to hit

merge and worry later. I think all of

these pieces are what has allowed me to

be as productive with T3 code as I have

been. From the inbox style sidebar that

I treat like a to-do list to all the

systems I have built for verifying

changes to all the unique ways I burn

tokens in order to be more confident in

my work to the ways I can ship with

confidence and the ability to roll back

if things do go wrong. All this has

enabled a part-time dev like me as well

as the full-time devs on my team to ship

way faster and way more confidently. And

I don't really care if you're using T3

code or not because the people who are

have already seen the difference and are

very happy with it. I know that a lot of

this might have come off as an

unintentional plug for T3 Code, but what

I really wanted it to be was a showcase

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

want to look back to it in six months

and see how silly some of the things I

was doing are because every time I make

one of these workflow videos, I get told

by a lot of people how helpful they are.

even a year later when they've long

since stopped being helpful. Man, I need

to do one of these every three months

now, don't I? 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

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.