How I code with AI changed a lot transcript

About 5 months ago, I made a video about how I build with AI. A lot of you guys really liked it. Just seeing into a workflow of somebody who's trying a little too hard to push the limits of these tools and build awesome things. And since then, I've kind of entirely changed my workflow. Back in that video, I was heavily using cursor in plan mode with Opus models and going really in-depth on how I would use plans as the core piece to generate the outputs.

That's not really how I'm building at all anymore. From the IDEs that I work in to the models that I use to the workflows that I've built for myself to get the most value out of these agentic tools, everything's kind of changed. And I really want to go in-depth on it. Because to be frank, going back to this old video now just hurts me a little bit because I wouldn't make most of the recommendations I made there today.

So, what am I doing now? That's a really good question, and I can't wait to answer it after I tell you guys a bit about today's sponsor. I don't know about you guys, but I'm shipping more apps than ever. Little things for my team, big things I put in front of people, and more. But I keep hitting the same friction points when I do that. Building this stuff's easy, but authenticating users and charging them money tends to be really hard.

I could just use today's sponsor, Clerk, but that would get kind of expensive. If I have 30 different projects and I'm paying 20 bucks a month for all of them, that's way too much, right? Nope, because I successfully bullied them into doing unlimited apps on the paid plan and on the free plan. I still can't believe I won on this one cuz I was pushing them for a while about this because I always was the guy that wanted a bunch of different apps, and I hated that Clerk was becoming my biggest expense.

Now, it's basically free. I pay the 20 bucks per month. I already have like 40 projects on my Clerk for $20 a month, and I couldn't be happier with it. Especially now that I'm using their billing product. Yes, they built a Stripe alternative in. Don't worry, it's still using Stripe. They just have the best Stripe implementation I've ever seen. And believe me, I've tried a lot of them, and I've invested in a bunch, too.

The cost comes out to exactly the same as if you use Stripe yourself, but it's a hundred times easier to set up. All the billing data is set up on users, they have access to it through the user component that you already should be using, and setting up a pricing table couldn't be easier. You just call the pricing table component. Waste less time on billing and auth and spend more time making good software at suzerain.link/clerk.

There's a lot to break down here from the models I pick to the harnesses I use to what UIs I'm working within IDEs, apps, etc. The way I style my prompts, the way I use or don't use plans, how I manage things remotely which is a really fun angle I want to dive into as well. And most importantly, I would argue how I actually think about the pull requests that I am making when I build with AI. I want to give a bit of context on where my experience is coming from here because the way I've been building and the things I've been building has been very different recently.

I took on a pretty bold, pretty stupid project called Lakebed. It's a new full-stack framework, a new runtime, a new backend, a new database, a new cloud, a new lot of things to try and make it easier to build quick apps with agents. The point is to be a shitty prod for shitty apps, but this means I had to do a lot of different things. Thankfully, I was mostly working on it myself though, which balances out some of the chaos I put myself through when making it, but it gave me a lot to reflect on in terms of how I want to build with agents now, and I've shifted a lot of my perspectives through the experiences I've had here.

When working on Lakebed, I tried a lot of different tools. I used Cursor a little bit, I used the Codex app a lot, I used T3 code, I tried using Claude code a good bit as well. I even played with open code and some of the cool new like open source models throughout. It was a very eye-opening experience to see how those different models could work in a code base like this, but also, more importantly, how they handled different prompt styles, different harnesses, and different agent.md and claude.md files in particular.

But, I want to answer this first question around models. What models am I using now? Obviously, saying anything about this is going to make the video incredibly dated. In fact, by the time this video is published, it's possible that a new state of the art is out. But at this point in time, I really struggle to use anything other than GPT-5.5. I will explain more on why I'm enjoying 5.5 so much now, especially compared to how little I enjoyed it in the past.

I have pretty much entirely stopped using Claude models. I'll occasionally pull one in to like make a quick landing page for me, but for the most part, I'm just using 5.5. I do think Composer 2.5 is really cool, but I have effectively unlimited inference on 5.5 cuz I'm on the $200 a month plan, and I still am under that weird 10x thing they did for people who attended the 5.5 event. So, I, despite my best attempts, cannot get these numbers down.

They just did a reset that they probably didn't even need to do, but the worst I could get is about 6% down on my weekly usage when building a full cloud from scratch. So, yeah. I think the limits are very generous on that plan. They are 10x more generous for me cuz I'm on that weird thing cuz of the event. I don't know how drastically that will change when the 10x is gone, but like the worst I was able to do damage-wise would have been the equivalent of 60% with the normal limits.

So, I don't think it's a big deal. That said, the cheaper plans are much easier to hit limits on, especially if you use some of the cool new features in the harness. Harnesses are a much more interesting conversation in various ways. If you're not familiar with what a harness is, you should definitely watch my video on how Claude code works. It is an in-depth overview of what it takes to allow an AI to use your computer to edit code and actually do things for the work you're trying to do.

To be very, very simple with it, the harness is the set of tools and the actual application, runtime, whatever, that allows an agent to do things on your computer to edit code and whatnot. Most harnesses come as some form of CLI, whether that is the harness in Claude code or the harness in something like Codex, but some aren't necessarily focused on that. They are more like an SDK. The Cursor harness, for example, is more in that direction.

They do have a CLI for it, but yeah, there are a lot of really cool harnesses nowadays, especially in the experimental space. Things like pie are really really cool and I do need to do a better deep dive on it and I haven't yet. That said, as part of me using 55 more, I have found myself pretty much always defaulting to the Codex harness. There are a lot of things that Codex has been doing really well lately. One of the biggest ones is that they've kept the CLI boring.

They're not loading it up with all sorts of crazy stuff. The CLI has just kind of stayed a simple minimal boring CLI, but they have been building really cool things into the Codex app and a lot of those do carry over to the CLI as well, which means they carry over to other things using the harness like you know, my favorite way to actually build up these things, T3 code. A lot of you all seem to be confused about what T3 code is.

T3 code is not a harness. It is not able to be paid for and it is not most importantly T3 chat. T3 chat is a different thing. T3 chat is an app for chatting with AI agents similar to chat GPT. T3 code is an app for managing your other AI harnesses similar to something like conductor or kind of cursor, but really it's more similar to the Codex app. I'm very proud of what we have built with T3 code and by we I mostly mean Julius.

He's done the vast vast majority of the work. I have put a lot of time into the Codex app though. I was using it for most of the building of like that cuz I wanted to just do another deep dive on the competition, see what its strengths are, see what its weaknesses are and get a rough idea of where things are at. As I mentioned before, the Codex app is really good and if you're just using the GPT models and you're happy with Codex, totally fine to stick with it.

If you've never tried one of these styles of agentic IDEs where you have multiple projects open at the same time, you have threads that are easy to swap between on said projects, this style of building is really, really nice. When Anthropic added a view like this in its original release, I started to see the potential value in this way of building. Since then, I've quadrupled down. This is how I build. I only really open up editors to edit environment variables now.

So, if I do actually use Cursor, which I'll be real, I don't use it on my computer very much, I usually use it in their new Cursor Glass UI, which is from my experience, but very broken and laggy. Apparently, it's getting better. I still have not had a good experience with it. The Codex app is very, very good and is probably the best bet for most people right now. Obviously, I'm biased and I find T3 Code to be much more pleasant, much more stable, much more reliable, especially with remote stuff.

But, realistically, Codex is what most people are going to experience. It's a great experience. I will also say if your only experience with an app like this is the Claude Code desktop app, then you've not experienced an app like this because the Claude Code desktop app is like a third-class citizen at Anthropic. No one there really uses it. No one there is really trying to make it great. It's been stapled into the Claude desktop app in a way that isn't very pleasant.

The Codex app is how most people at OpenAI interface with Codex. In fact, I've heard many more people who aren't even technical using it as an alternative to ChatGPT itself. The Codex desktop app is the best way to use Codex. If you've only used it through the CLI, you've not really used Codex. So, I'm using T3 Code. I would absolutely support people for choosing Codex instead. There's lots of other cool options to consider like Conductor.

My main gripes with Conductor are that I had a really rough time trying to give them feedback. I was surprised how quickly my team got ghosted cuz we really wanted Conductor to be good. It's also closed source, which means if you don't like anything about it, you're kind of stuck. Whereas, T3 Code is entirely open source. You can do whatever you want to. In fact, a huge portion of our users are running forks of T3 Code.

It is also worth noting that if you're primarily using a a Code subscription, we are about to get heavily limited because they marketed a [ __ ] change where they started giving you credits when you're a subscriber. The credits are what we would use instead of your actual subscription limits, which is absolute [ __ ] If you use Claude Code via the Claude Code CLI or the Claude Code desktop app, you can get up to $5,000 of usage for 200 bucks a month.

But if you use it in something like Conductor or T3 Code, or if you SSH into a computer and call Claude-P instead of just the Claude CLI directly, then you only get $200 of usage. And if you go over that, it costs you money directly. It is a [ __ ] change. I can't believe they actually did it. I have a whole dedicated video on that. But again, we can't do anything. It sucks that we can't do anything. We will probably have a crappy terminal UI that will open when you use Claude Code in T3 Code because there isn't really another option for us.

Blame Anthropic. We can't do anything. We do support everything else you might want to use though. We support Cursor and Open Code. You can enable them in settings. They just use the existing CLIs through ACP. It's nice. It's really cool having a tool like this that supports everything in one consistent cohesive UI. Especially once you get into the remote stuff. I know I'm skipping some steps here, but I really want to emphasize this when we're talking about the ops cuz I think it's one of the most important things.

I know what a lot of y'all are thinking. Why don't you just SSH into a computer instead? Cuz like the problem we're trying to solve with remote control is what happens when I shut my laptop and an agent is running. I want to open and see the result. I don't want it to get stopped. I don't want to have the meme where I have the laptop half open as I walk around. I just want to be able to run the thing, close my laptop, or go offline, or code from an Uber, and then have it updated reliably.

I really thought Codex would have this figured out. And to their credit, the mobile integration is largely there. The fact that there's this little button you can click to set up your phone through the ChatGPT app to control Codex on your computer remotely is actually really really cool. As I hinted at before, I like the coder machines that aren't this laptop, but I still like to control it from this laptop. And on this local network, I have my Mac mini and I try to control it from the codex up here with codex running on there.

This is an actual Mac mini running on my network that I can connect to remotely over like the Mac screen share stuff. I have codex on here open and ready to go. I also have T3 code open on here ready to go. I spent the last week trying to do everything through codex. God damn did I hit a lot of issues. The mobile integration is mostly fine, but I'm just going to quickly go over some of the insultingly bad problems I had trying to control it remotely through the desktop app.

The first one, and this was like an absolute stopper for me, occasionally the model picker would disappear and when that happened, even though I was connected, I was unable to do anything on the remote machine. So, I had to connect back over to it via the screen share, close and reopen the codex app, come back here, close and reopen the codex app, and maybe it would work. Like, maybe. Usually not, but sometimes it would.

When it does work, it still has all sorts of fun issues. When you actually just like send a prompt, it usually responds fast, but you see how slow that was to pop up like the history? It's really bad. And where it gets even rougher is if you have to open up the terminal for any reason. I'm going to type 1 through 9 just by sliding my hand down the keyboard starting now. Oh, it actually did it kind of fast that time. It's still like super sticky keys.

Like, I am typing as I speak. When I was trying this yesterday, there was up to a 30-second to 2-minute delay. I cannot stand God, it's sticky keys so bad even when you type correctly. It's unusably bad. And then when you try to paste an image, it's like 50/50 if it works at all. I have not been happy with the remote experience outside of mobile on codex. I tried it because I wanted to try the mobile stuff. Was pretty impressed with that.

Assumed the desktop app would work well, and it just didn't. Then my team reminded me that Julius went really hard on the remote stuff for T3 Code. So, I decided to try that instead. And I'm actually trying this a few different ways. I'm trying the baked-in to the app remote version, but I'm also trying the remote hosted version that was very easy to set up. I hop over to Helium, you'll see here, I have my T3 Code instance over my local network fully functioning.

I can hop here. I can go to an existing thing. I can open the terminal. It types full speed, no issues, cuz it's effectively actually SSHing over. It has been significantly easier to build. Image pastes work perfectly, and I actually love having it in the browser, because now this is a different thing from my local instance. I don't have to like remember which ones on which machine and deal with all of that. It's been very, very nice.

One of the coolest examples I've seen of somebody pushing the limits of the T3 Code remote stuff is Jack here. He doesn't have a computer. He does most of his work from an Android tablet. So, what he did in order to get T3 Code working on his tablet is he actually spun it up as a T3 Code server in Replit. This gives him the ability to use the T3 Code web app hosted on Replit to build projects remotely on Replit, which I think is really, really cool.

Point being, T3 Code remote hosting is great, especially if you combine it with something like Tailscale, which allows you to connect to devices on other networks very trivially without having to expose it to the whole web. It's been very nice to work with. I have been blown away with how stable it is. I've used this for the majority of the changes I've been making to Lakebed for the last day and a half, and I'm also using it to spin up new projects remotely, too, which has been very surprisingly solid.

The one catch here is mobile. We do have mobile web, and it works better than I would have expected. Julius is cooking a React Native app now. We should hopefully have that pretty soon, fingers crossed. And if you do want to test this out yourself, you can just go to settings in T3 Code, hop over to connections, and relatively easily set up Tailscale or network access remotely or on your existing network. Very easily.

You can even do custom SSH connections, even though in Codex they're a bit rough. We actually have a UI to store password when you set it up yourself in T3 Code. As I mentioned before, Julius went really hard on this stuff because he really likes these remote flows, and the result is that it is one of the best experiences I've ever had doing remote coding with AI by far. No longer am I stuck using tools like Termius to SSH into some shitty Linux box and try to make a terminal UI work on my phone.

I still can't believe people are doing that. I will crash out briefly on the SSH terminal people for a second cuz I need you guys to understand how much you're suffering when you do that. First off, you have to deal with tmux or zellij or GNU screen or something. So, if you disconnect, you don't kill the work that you're doing. Second off, you now have to have a bunch of weird key bindings or some other abstraction to switch between different threads you're working on.

God forbid you want to go do something in a work tree. Good luck, have fun with that. You're going to be writing a lot of handwritten Git commands to spin up that work tree. And then what happens when you want to paste an image? I would estimate that a third to half of my prompts have an image in them, whether I'm just quickly grabbing an error screenshot and pasting it, or if I have some UI that I want to throw over to the agent to tell Hey, can you make it look like this other thing?" I use images a lot in my prompts.

The fact that they kind of almost work in traditional CLIs and then don't work at all over SSH is insulting. I've been fighting this fight for a while. I, as a person who spent the vast majority of their computer time in terminals throughout their life, I really, really don't like doing agent coding in terminals anymore. I'll still do it occasionally for like quick demos or like editing things on my computer. Like if I'm trying to config some directory or like fix my dot files, stuff like that, I absolutely will still use Codex CLI.

But But, I am trying to do real work in a real code base, I want the app every single time. I still can't believe the pasting images over SSH thing is as absurd as it is. And while it's cool people are like building raycast workflows in order to upload an image easily to send it as a URL over for the agent. Like, it's cool. You shouldn't have to do that. The amount of workarounds I've seen people make just to be able to use Cloud Code over SSH is hilarious and painful and no.

I I I will not support that mental illness. Please try a good desktop app for agentic coding before assuming the terminals are the only solution because you tried the Code X desktop app 6 months ago and it was [ __ ] It's still [ __ ] I understand if that's the only experience you've had that you think CLIs are better. They're not. A good desktop app for coding will [ __ ] all over a CLI any day. As I mentioned before, working remotely is really, really nice, especially if you're like me and you find yourself randomly having to like leave your office to go to some event to some coffee shop meeting, or you just like want to check in on your work as you're pacing around the office.

I really like being able to do work remotely and I find myself spinning up more and more of my work remotely. When I know I'm going to be sitting at my desk for a while, like when I'm streaming or when I'm working with my team, I will still often run things in T3 Code locally, but almost all the time otherwise, I am connecting to that remote Mac and doing things through that. But, now I need to talk about how I actually do the work in these tools cuz thus far we've just been focusing on the tooling side.

And in order to understand why I like 55 so much and why I like remote coding so much, I think my actual ways of working with the models are worth understanding more. Context management really is the name of the game for getting these things right. An underrated trick that I found really useful is giving the agent the ability to explore other code bases that might be relevant. In this case, I was trying to set up auth for the user-facing apps people would deploy and generate with Lakebed.

So, I needed it to have a good off solution. I wanted to see if my implementation for my off service I built before called Shoe would be a good fit. So, rather than like describing it or throwing it at the docs, I just cloned down the repo and told the model, "Take advantage of the off implementation I have in Shoe." with a link to the path on this computer with that implementation so it could use that as a reference point.

This type of context manipulation results in much more reliable outputs from the models and it's been one of the biggest improvements I have personally experienced. Even just telling the model like go clone this repo and throw it in some scratch directory in order to figure things out. There's one other super reliable thing I want you to know about though. Our sponsor. Agents can write surprisingly good software as long as the problems they're solving are simple.

There's certain things that just aren't though. You know, like DNS, the thing that sucks for everybody. It'd be really nice if DNS was simpler. Oh, DNSimple is on the screen, isn't it? I I love these guys. I've been so blown away with every interaction I've had with them, all of the cool things they do. The fact that they made a good SDK for managing your DNS is incredible. If you're trying to build services where users can like register domains or subdomains or manage masks and set up forwarding and do all these types of things, good luck doing that programmatically because the APIs that exist for it suck unless you're using DNSimple.

Like how cool is it that I can call client.register or check domain to see if a domain's available and then buy it all from just writing TypeScript. This is so useful that I wish I could do it through a CLI. Oh, oh, is the CLI on the screen now? Yeah, this one was so cool I did a call with the guy who made it because I was blown away and I wanted to give him some feedback to make it better for agents because having an agent able to run a CLI to debug DNS issues is like a thing that I would have killed for years ago and now that I have it is like, "Oh, yeah, obviously." The CLI's no joke.

This is a full-time project for one of the engineers there and he went hard on it. Everything you would do through the STK is available, and it's all also exposed with the help commands so that your agent can see how to use it. You're too busy to be debugging DNS, let your agents do it for you at soydev.link/dnsimple. Here is the original thread where I started Span, aka Lakebed, my new cloud framework everything project that I'm very proud of.

You might notice this is quite a blob of text. The reason for this is that I used voice-to-text. I found that using WhisperFlow or other voice-to-text tools makes me write much better prompts. And this one was meant to be a very much thought dump. Like I wanted to plan out with the model. Especially for these types of large changes, I do like planning. And I want to be clear about something. I do not mean plan mode. I like to work with the model and not be scared of letting it write code or make changes or test things.

And plan mode is a little too restrictive. And there are problems here. Like I've had times where I wanted to talk to the model about a thing and it just went and did the thing. 5-5 is really guilty of this. But again, I prefer working this way, where I'm not necessarily in the plan mindset and then in the edit mindset. It's more of a natural back and forth. So here I started with a very important thing, my end goal.

And I find that this is the thing most developers miss. You guys love focusing on the details and I understand why. That's been what mattered our whole career. Especially when you're advising more junior engineers, it is important to be detailed about how the thing should work, not just what the thing is. I found myself moving over to this more higher level, like here is what I want that to do, not how I want you to implement it.

And I started with roughly that. This directory is for a new project I want to start called Span. The goal is admittedly complex. I want to rethink how clouds work from first principles. I want to build a new full-stack TypeScript framework that has all the pieces you need to build full applications including simple minimal reliable off layer database synchronization, file storage, and more. The goal is to make everything you need available via the code instead of having to go through other layers of platforms.

If a user has to open a dashboard, we have failed because I want this to work for agents in all different ways that they would need to initialize projects. The formatting got all screwed up cuz I was voice to texting and I wasn't even paying attention. I thought this was going to be a throw away, but the fact that I did this as a throw away and it went so well shows how powerful these tools have gotten. To open, I said I want first for it to roast the plan and give me all my thoughts and feedback before we proceed.

Do whatever research you need, yada yada. Says, "I love the ambition, but the roast is simple. This is not one project. It's a runtime database sync engine object store deployment control plane local emulator security model migration system observability stack and agent interface wearing one trench coat. The idea is viable only if Span starts with a brutally small thesis." It tried to insist that things like Convex, Instant, and Jazz meant it wasn't necessary.

Also, Cloudflare being as good as Cloudflare is, yada yada. I had to slowly convince it. The important thing here, and I know this is hard for people, you have to read what it says. I know people tend to gloss over the text the model puts out and instead read the code it puts out or maybe they'll even read the plan it puts out, but rarely. I find that devs have this instinct where they care more about the code output and not enough about what it said, and that's entirely backwards.

You have to read what it says. And if you don't like how it's saying things or it says too much, steer it the way you want it to talk instead. Tell it to be more brief and concise. Tell it that it wrote way too much [ __ ] Tell it to format things in the ways you want to read, but you need to get the model talking to you in a way you'll actually read what it says. Mark is a victim of this, and I was planning on yelling at him about this when he was here and I forgot.

I will do it later. You got to read the text, especially when you're doing big sweeping changes. And accordingly, you have to respond to the model based on what it said. So, I went through here and typed by hand the different sections and my thoughts on what it had to say saying here are the things that I agree with, here's the parts I don't agree with trying to get the context of this thread to be more in the direction I want this project in.

You got to kind of treat it like you're convincing somebody of your way of wanting to do things. I put the work in to convince the model to do the thing I want. I see a lot of questions in chat already like what skill command or framework are you using to get the grilling, what skills do you have set up, have I tried the superpowers plugin, all this [ __ ] No. You're all coping. You don't need all of that [ __ ] I have almost zero skills installed.

Just talk to the [ __ ] model. They're smart enough now. I don't even have the super small and useful grill me skill from Matt set up because I just have it as a binding in whisper flow. Grill me skill. I just hold down my whisper flow key, I say grill me skill, and it just pastes the exact markdown into the input. So, I can just do that and it will do the same thing. Super easy. Even then, I can just tell it to and it usually does it.

You guys care too much. I don't bother with skills usually. After I gave my feedback, the model agreed more. This context makes the idea much sharper. I buy it more now. The category isn't new cloud, it's an agent native app substrate for tiny full stack apps. Yes, I got it now. And this is why you talk to the model and you read what it says. You need to make sure you and the agent and the context are on the same page.

And this is the biggest thing I want you to take from this video. The most important thing when you're building with AI is that the AI understands what you want and how you build. You can do that by writing a 5,000 line agent MD that's global on your computer with all of the things you like and do and such. You could also become a famous influencer and tell the model I'm Theo. Build the way I like to build." Which works sometimes.

But the easiest thing to do is to just read the outputs and steer the model in the direction you want to go in. And if you notice it making the same mistakes over and over again, go into the agents.md and try to give the model your psychosis. That's what I've done and I think that's one of the strongest things I did that made it possible for me to make this project so quickly. You'll notice that in this lakebed agents.md there are no file paths.

There are no technical decisions or enforcements. There's a couple small general rules at the bottom that I might even delete cuz I haven't found it to be super useful. The point of the agents.md, at least how I use it now, is to make the model more steered towards what I'm trying to do. I wrote this one almost like a letter from me to the agent to tell it how we're thinking, what we're building, and why we're doing this.

So that it's less likely to have bad assumptions or ask weird questions or work outside of the technical constraints that I want it to work within. This document has helped so much. I noticed almost immediately after writing this, by hand by the way, my agents did not write this file. I wrote this file. After I wrote that, I found that I didn't really have to do much to get the agent to build how I wanted it to. Once it had the context of how I was thinking about this, it started behaving way, way better.

The craziest thing that I did throughout this project, and I know this is going to be hard for a lot of you, when the agent pushed back, I listened. When it said certain things were not necessarily the right idea or were too hard to justify, I listened. And I deleted those. And one more hack that I found really nice is one that comes from our friends over at Anthropic, having the model write an HTML file for the plan.

It's so much nicer to read. I found this much easier to like read and go through the whole plan and get feedback, and answer all the remaining questions. It was so nice. That said, the first HTML page it made was horrible. It looked awful. So, I had to like yell at the model a whole bunch about that. Also, apparently in the Codex app, the questions tool just didn't work in the remote mode cuz at this point I was controlling this from my phone cuz I was busy, and it couldn't ask me questions.

It might be that mode, it might be the not using play mode. I don't know what it was, but it was insisting it couldn't ask me questions. So, I had to like go through and answer all of them directly. And then I was like, "The UI for the pages is awful. I got it to clean it up. After a while, it like still was full of useless crap. I gave it as much as feedback." There's also another trick that I found really useful. Get a screenshot tool that lets you actually do [ __ ] Like being able to point an arrow at a thing and say, "This sucks." It makes it so much easier to steer the model to make the right changes with things.

I press control C, the thing goes away, it's on my clipboard. I use Shutter. It's great. There's lots of other options that are good, too. Get a good screenshot tool. It makes life so much easier. Once I got the HTML in a good state, I found that every plan I did from that point was really nice-looking because it would just look at the existing one and be like, "Oh, [ __ ] I'm going to copy this formatting." And this is like one of the coolest things is once you get the agent to behave how you want, if there is enough proof of that behavior in your code base, whether that is HTML plans, whether that is your agents MD steering it certain ways, whether it's the code itself, once you get the model to behave how you want it to, everything else almost stops mattering.

And that's one of the coolest things to discover as I've been using 55. Like in its default state, copying the prompts I used to use with the big bloated useless agents MD, 55 sucks. When you take the time to condense and steer it the way you want it to work, it becomes the coolest way to work I've ever built with. And here's where we're going to get into the other things about how I built. You might have noticed I have a lot of threads here.

These are just the ones I did in the Codex app. I have another few dozen in T3 code, all for the same project that I did in 5 days. I probably started over 100 threads on this one project in 5 days. And I know what you're thinking already. Oh, so you have all of those running in separate work trees and you're hopping between 15 of them. Cool. Everyone says they do that now, but there's no way you're productive. Nope.

Almost every single one of these threads was run by itself on main alone. I found that I am just genuinely way less interested in these more parallel workflows lately, because it's just too much context to keep track of. And when you spin up a smart enough model, especially if you're taking advantage of fast mode, which I've surprisingly been using a lot, it's not worth the price increase. But if you're not getting close to hitting your limits on the Codex plan, it's very nice to use.

The fact that fast mode is included on your plan, it just increases how fast you go through your limits on Codex. When it costs actual money on Claude code is hilarious to me. But yeah, I've been using fast mode on my Codex subscription. I've never come even close to hitting my limits. It's been very nice. So much so that I don't even find myself leaving extra high as much. If I'm just doing UI stuff or I want it to respond faster, I'll hop over to low.

But I've gotten good enough at keeping extra high on task that I found it fine. You'll notice a lot of these threads are literally just one prompt. This one was very simple. What would it look like to let users bring environment variables for server-side code? Ideally, they'd be able to update a .env.lakebed.server file and run NPX lakebed deploy to push those environment variables into the cloud for their deployment.

A minute and 54 seconds later, it wrote a whole model for how this should work that I thought was great. And it really seemed to understand what I wanted here. The important design choice section shows the name of the file. It said that this should be the source of truth with replace semantics. If we add something and deploy, it gets created and updated. If we edit something locally, the deploy will rotate it. And if If delete something from it, then lakebed deploy will delete it.

Exactly what I wanted. I didn't have to get more specific, I didn't have to write a long-ass prompt. I wrote two sentences, and then it specked out exactly what I wanted. To which I responded, "Love it. Build it." 10 minutes later, the whole thing is working exactly how I wanted. No additional changes needed to be made. I just pushed it to GitHub, and I was done. It was great. And then I started my next thread, which was, "I want to be able to manually bump rate limits for a given user." This is cuz one of my friends who was trying it out was loving it and wanted a higher rate limit.

So, I just told it, "Add this feature." And I gave it a little more detail here. "I want a new users table in the admin dashboard, cuz I want to be able to control this myself, with the ability for me, specifically me, to set custom overrides for someone's limits." Another important thing, and I had this in my agent MD. I didn't talk about it before. A glossary of terms and language to help the model understand what you're saying can be very, very helpful.

I found that with this project, it was difficult because there is me, the person working on this thing. There's also me as a user of the thing. There's the agent building Lakebed, and then there's the agent using Lakebed to build apps for you, the user of Lakebed. So, I gave it these specific terms, where you is the agent that is actually going to make changes. Me, we, and us are the humans that are building Lakebed itself.

Developers refers to our users, people who are going to build things on top of Lakebed. And then agents, which is the thing the developers are using to build with this. Again, the point here is to make it easier for the model to know what I'm referring to as I discuss these things. It's another one of the themes you'll notice. Generally speaking, you should try to keep things simple. And if it doesn't work, that doesn't mean make it more complex.

It means fix the things that prevent it from being simple. If talking with the model in plain language was preventing it from getting what you're saying, you shouldn't get way more over specific in all of your prompts. You should make slight changes to your agent MD and to your cloud MD so that you can keep your prompt simple. And you'll notice almost all of my prompts here are two sentences or less. I know this one was three sentences in a list of things, but it did exactly what I wanted the first try.

And you'll notice this looks almost identical to how the home page looks now. Nice and simple. And as I said before, none of these threads were running parallel. I would do a task, I would complete the task, and then I would make a new thread and start the next task. And I would just do that over and over again. As Mortgage said in chat, make the difficult change easy, then make the change easily. Yep. Why new threads?

I always make new threads because I don't want old context getting in the way. I treat every thread as a pile of information that is steering the model. And if I'm doing something different, like this thread, I was working on environment variables. And then this thread, I'm working on user limits. These are different concerns, and having the same thread with different concerns within it just biases the model towards things that aren't necessarily correct.

Remember, the way these models work is a bunch of parameterization. All of these sets of characters that are in your history, that are in the model, your history changes what points to what in the model. So the more stuff in your history, the more customized the model is to an extent. Every additional word in your chat history is changing how the model behaves. I don't want to deal with that. And to those saying, wait, does that mean the model has to explore the code base every time?

Yeah, it does. It doesn't [ __ ] matter. It does a great job. It still completes all of these things in seconds. And I find that in real code bases, there is so much stuff going on that the history of your previous change is just going to confuse the next one. Also, chat pointing out, they noticed that I'm not mentioning files specifically or applying skills for it to work on. Correct. I'm not doing anything more specific.

I trust the model to find the right file. I am more likely to recommend the wrong file than the model is half the time. If it turns out the file that I said isn't necessarily the right one for the change, the model's going to get confused and try to make it work in that file. If I have a good dev on the team, I'm not telling them what file to edit. I'm telling them what to do and they'll figure out what to change. And I would find half the time when I look at the diff for the changes it made that I am surprised what files it ended up changing.

Again, don't add details unless it needs the details. Try to be more sparse with your requests and prompts. Figure out what it doesn't understand and then figure out how to fix that without making your [ __ ] too complex. Yeah, I'm just looking through all my threads here. Almost all of them are actually just two sentences. This was a voice to text, which is why it's a bit longer and I needed a little more context what I wanted there.

Yeah, for the most part all of these are very simple. Here's an example of me sharing a log screenshot instead of actually copy pasting logs as it's so much easier to do. One more pro tip. When you have ideas that are a bit complex or the model struggles to understand it, don't over explain. Just give examples. The more simple an example you give that contains the problem you're trying to solve, the better job the model will do at solving it.

So, this example I was trying to discuss custom domain flows for Lakebed, which coming soon. I have a lot of layers to fix here to get it right. I gave the example of I have a project on Lakebed and gave it an actual URL to an actual Lakebed project I had deployed. I have a domain on Vercel, t3.gg. I've configured a CNAME for Lakebed demo t3.gg where the value is this. What's the best path to make this work? Handling SSL and whatnot.

This is to tell it like specifically what my question is, like what my where my problem is located, and then the goal as well. The goal is to be as easy as possible for our users without massively ballooning costs. It's silly, but I think this is a great example of a prompt for something complex. I said what I wanted. I gave it a very clear concise example so it would understand exactly what I wanted to do, and then I steered it towards the parts that I wanted the most help with, and gave it specific goals in order to keep it within my constraints.

Gave me a bunch of info. It did not give me enough info about costs though, so I asked it very specifically, "Give me a breakdown of all of the costs I would incur by going with your proposal." And then it did exactly that. I didn't like the proposal, so I got more specific with an exact flow I would want the user to go through. This example, I say the user would run this command, "npx lakebed domains add demo1.t3.gg", then the CLI would output to add the domain set the following records, and you go set these records.

And I specify I would go and assign those values, wait for lakebed to pick up the change, issue SSL, and good to go. Ask more questions for more clarification. But I really just used this thread to figure out the how to do this. What I would normally do at the end if I was ready to go with this is I would ask it to write down a simple plan based on what we discussed that I could have as the markdown or the HTML plan that I would read, confirm, and then hand off to a new thread to go actually build it.

Once you actually get the model to start doing the work, one of the most important things is to give it the tools it needs to verify that the work was done. This could be CLI commands it can run, this could be a test suite it writes, this could be computer use where it actually goes to the page to see if it's correct or not. This is one of the things I have found to be the best about using Codex. Their plugins, and specifically the computer use stuff that they have built, is really, really good.

Codex's computer use, will let Codex control apps on your computer. It'll let it control a full browser with an extension, and it can even do it with the computer's locked now, which is really, really cool. I've been blown away with how useful this is. My issue is that I don't like it working on my computer, cuz I want to use my computer when the agents are running. So again, this is where the remote stuff got really nice.

I've also noticed that once you set these things up in the Codex app, that you can use them through the Codex CLI, which means you can use them through D3 code. So, I set up all the computer use stuff in the Codex app, and then I went back to using D3 code remotely, and now my D3 code can verify changes by deploying an app on Lakebed, and then going to Lakebed to see if it actually deployed or not, and make sure it behaves as expected.

It's so powerful, and I found that it makes the likelihood that by the time the agent pings me that it's done, that it actually did it correctly, is way higher. Throughout this whole project, I would say of the like 50 plus threads I've done, maybe four or five of them didn't do what I wanted first try. The rest all behaved exactly how I expected them to, and it worked very well. And also to be very clear, I'm not using the new like goal skill feature thing inside of Codex.

It seems really cool. It didn't work in the app for me when I tried it, and I don't use the CLI a whole lot, and certainly not for these long running things. And most of the stuff I'm doing, even the stuff that seems really difficult, ends up being done under 10 minutes, especially on fast mode. Here I overhauled the runtime for anonymous deployments, and it took 7 minutes. Code Rabbit found issues, so I screenshotted the issues in the Code Rabbit PR, told it to fix them.

And it did. And then there was conflicts on main, so I told it, "There's conflicts with latest main. Please address them and push up your changes when done." And then it did. And then I merged it, and then it was good. If your takeaway so far is that this is surprisingly simple, you have the right takeaway. It's very simple. The simpler your flow, the better. Do things the stupid easy way, and if it doesn't work, figure out how to make it work.

I want to talk a bit about my PR flow now, cuz I think this is important. When I start work, I usually start it with a rough idea of how complex the change will be in my head. It varies a lot depending on what I'm doing, and sometimes a task ends up being a lot more complex than I expected it to be. If I'm unsure of the complexity of the task, I'll usually start by asking the model for its thoughts and we'll have that back and forth.

When I have a good gut feel of how big the change is, at that point I'll often decide if it's worth doing on the branch I'm currently on and in the work tree I'm currently on or if I should go make a new work tree to finish up this task. Sometimes, once I'm halfway through the planning process, I realize this is going to be a lot more work than expected, so I just copy the initial prompt, I go spin up a new thread in a work tree, I paste that prompt with a couple additional steering comments to make sure it doesn't go down the bad path I was going down earlier.

This has worked very well for me. That said, in this project that I've done hundreds of commits on, again, it's a solo project, so it is different in that sense. I have not actually found myself reaching to make PR's that often and I even closed two of the ones that I made cuz I didn't find myself needing it. What I made big enough changes that I really wanted to sit with and get second opinions on, things that are security related, things that change the hosting layer, thinking through what changes need extra eyes, not just like a human looking at it, but other agents or code review tools looking at it.

Like, uh building the intuition for what changes would benefit from that is really important. And sometimes you'll put up the PR and something like Code Rabbit, Macroscope, Graptile, whatever you're using will catch a bunch of issues and then you tell the agent to fix them and it does and then it catches more. At that point, I'll just tell the agent to run in a loop until it resolves all of the issues, usually using something like the CLI for Code Rabbit, which has been very helpful for this type of thing.

I had two or so of these where there were just so many pieces of feedback that I didn't want to keep copy-pasting back and forth or telling the agent go check the PR again over and over and instead just told it run the CLI until you don't get any feedback and that worked great. That ended up working specifically for a lot of the ownership stuff that I was trying to get right with this project. That said, in real projects with lots of developers, you're going to start running into problems with PR bloat.

Especially, and this is one of the coolest but also the most painful things in a tool like T3 code, we made it a bit too easy to make a PR. You can spin up a new thread, make changes, and then click one button to commit them, branch them, PR them. Super nice when you're using PRs as an artifact for review. Not so nice when you're accidentally spamming your project with a bunch of PRs that'll never merge. I do love the one-click.

I file a lot more PRs when I have that feature. Getting a good workflow in Codex for turning your changes into a PR was annoying. So, yeah, this was very very helpful. But sometimes those PRs will just sit around and you don't know if they're worth merging or not anymore or even looking at. I've had that happen a few times even solo on this. And again, bring in the agent. I noticed one of my branches kind of got stale and had a lot of conflicts.

So, I brought this branch up in a new thread. I asked, "How up-to-date is the Theo/admin overhaul branch? Compare against the latest main. If these changes are still worth merging, fix the conflicts and push up the finished branch." It had inspected it. So, the work tree is clean and currently on a local helper branch. Branch is significantly behind and has 49 commits not in this, while the admin overhaul has two commits on the main.

Diff's concentrated reading the changes. And at the end here, it said, "After inspecting both sides, the branch's useful works already been on main. Main already has the admin user detail route, this route, user detail UI, and smoke coverage for the admin user shell API. Board of the merge and did not push because pushing a fixed branch would just add noise for changes that are already represented in newer forms on main.

Recommendation, close and delete." Awesome. Generally, it is important to try and keep PRs from getting too stale because it gets really bad really fast. Take it from us with 414 open PRs on t3code right now. It gets bad. I think I covered everything I have to here. I know this video was a bit chaotic, but I kind of just wanted to show you the chaos. What does it actually look like with real projects I'm working on. That's why I showed you the actual threads that I was using to build real projects that I'm deploying now.

I've never been happier with my flow, which means it's probably all about to change again and I'll be sure to do another updated video if these things shift over time, but for now just try to keep it simple. I find most developers are trying too hard to engineer their workflows. And I get that. I love engineering my stuff, too. But generally speaking, keeping it simpler makes things much better and the fact that I have made my set of tools here and my way of thinking about things here so simple has made me way, way more productive as a result.

And while I do dearly love t3code and what it enables for me, especially around the remote stuff, the codex app is fine. Just like stop using sidebars in your IDEs, guys. Stop using CLIs. Stop using these things that make it too hard to just start a new thread or start working on a new change. If you're looking at the code more than you're looking at the conversation about the code, you're already behind. It's time for us all to let go a little bit and try to build the way the AI is strongest, which is with a good conversation that builds the right context for the model to go do the right thing.

I know it's a bit different and I really hope it was helpful for y'all. Let me know how you guys feel and until next time, peace, nerds.