0:00Speaker A:You might have noticed that I haven't been posting videos as much recently. Part of that's because I had a lot of fun going to open Sauce, and that definitely threw off my schedule for recording. But the bigger part is just that I've been coding way, way more. Way more.
0:11Speaker A:I've landed dozens of PRs in just the last three days and many more. If you're willing to go back a week or two. I have been coding more than I ever have, and more importantly, I've been landing more code than I ever have. A lot of my productivity wins recently can be credited to T3 code.
0:26Speaker A:We've made a ton of improvements that make it way easier to work on lots of things for real applications parallel but I've also spent a lot more time in my editor. The last two days I've spent more time in VS code than I probably have in the last year actually writing and reading code. As long as you consider Markdown files code. I know this sounds insane, but I actually sat down and spent maybe six hours just editing Markdown and then the next day spent another six to 10 hours testing those changes and making small adjustments afterwards.
0:58Speaker A:And I want to share how much this has benefited me. I am genuinely annoyed at how much these small changes have improved my development experience, and I have a feeling they will help you out too. I want to cover everything that I've been doing here, from how I actually make these changes and test them to how I keep these things synced across the many different machines I do dev work on, because there's like five of them now, to how I actually write these things and audit the histories I have with my agents to make sure I'm doing them right. So.
1:26Speaker A:But I got one more really helpful thing I want to show you first. Today's sponsor. There's a lot of parts to your app that used to be really easy to build before AI that got even easier thanks to agents going and doing all the work for you. And if I'm being honest, Auth is definitely one of those things.
1:39Speaker A:So what's the role of an Auth platform like work os if agents can just build Auth for you? There must be a reason why companies like OpenAI, Anthropic, Cursor, Perplexity, Vercel, Replit, Bolt and everyone else in this list are betting on what workos built, right? Well, yeah, of course. But it's probably not what you think.
1:55Speaker A:It's not because setting up Auth is so hard. It's because your Auth needs to do More than it ever did before. Auth is how you know what users are accessing your things. Auth is how you set up an enterprise to use your service.
2:06Speaker A:Auth is how agents can do things on behalf of their users. You could try to set up all of these pieces yourself, but if you're planning on diying it and you want to sell to real businesses, you should probably go look at the admin portal on work os because you're going to have to go set up okta, SAML, Duo, ADP, ADFs and all of these other things that I know you don't want to set up. You're watching this channel, you like writing real code. Don't deal with this.
2:29Speaker A:Just use work os. And when it comes to agents, Work OS is helping pioneer a new standard to allow for your agents to off on a service, which is huge. They're partnering with a ton of companies like cloudflare, Firecrawl, Resend, Monday Kernel and more in order to get this standard ready. And it already is.
2:45Speaker A:So if you have a small app with a handful of users, no businesses and no agents using it, you're fine rolling your own. But if you want to build something serious, look no further than soydev Link workos. So as I mentioned before, I've been coding a lot more and I actually decided to sit down and take the time to streamline certain things that I was doing. Since T3 code makes it so easy to work across multiple machines, I have four that I work on T3 code itself on in T3 code you can literally just click and choose what box is going to run that down.
3:12Speaker A:Diff. Super convenient to have lots of machines that you could run different work on depending on the needs of the work you're doing. Managing everything that exists on all of these machines and making sure skills are available on the right ones and not available on different ones. Not trivial.
3:26Speaker A:And I caught myself starting to make a custom system to manage all of that and I got pretty far into it and it was buggy and annoying and had lots of annoying edge cases so I stopped. This directory we're looking at here is my fleet repo and my fleet repo is just a bunch of markdown files and fork of Vibe proxy because I'm making a lot of changes to the CLI proxy API for my specific needs and in my agents and Claude MD I describe what this project is and what I want agents to do in it. So when I do make changes to the skills I have, like I have my core agents in cloudmd and I have the Skills directory that has a folder for cloud only skills, a folder for my command center skills which is just this one machine, the leader machine that controls everything else, and a universal folder for the skills that I want all of my machines to have. I also have a little bit of metadata that I include here that makes it easier for my agents when I'm running them in this project to know which skills should appear on which machines.
4:24Speaker A:So let's start from the top. This was my AgentsMD and Claude MD file that I have had on all of my computers for approximately two years now, give or take. Maybe a bit less. And I hadn't touched it because I just didn't think it mattered that much.
4:38Speaker A:I also have a video I did before about deleting your Claude MD and AgentsMD. That was for Project Claude and AgentsMD files. And you're definitely writing those wrong. I will show you what I mean in a bit.
4:47Speaker A:Just we'll get there. Trust me. This was my old file. I had global defaults.
4:51Speaker A:First off, I called that repo specific agentmd instructions override these. User instructions override both typescript. I had one instruction. Avoid any unless there is no reasonably typed alternative or the user explicitly asks for it.
5:02Speaker A:Because I was tired of agents just writing any everywhere, especially GPT4 1 and Sonnet 4 to 4 too. Really bad about all that. And then I had some instructions here for commands. I was really tired of agents spinning up dev servers and breaking my environment.
5:16Speaker A:So I told them to stop. I said prefer targeted verification first like type check and lint and focus tests. Run full builds, yada yada. Package manager preferences.
5:25Speaker A:I said prefer BUN than PNPM tech preferences. Just the things I want to use. Code styles. Okay, I did make one change here recently.
5:32Speaker A:I added this yagni bit which did actually meaningfully help. I don't know where this came from. Another agent might have added this and then the computer inventory. This was definitely added by Sol when I was working on the fleet at some point.
5:43Speaker A:But this was not a great agentsmd and I just kind of lived with it for a long ass time. Here is my new global Agents md. This is probably the least important of the files, but we'll go through the rest. I'm Theo.
5:57Speaker A:You're my agent. We'll be working together a lot, so I thought it'd be worth introducing myself. Known for my YouTube channel and work on T3 products like T3GG, T3 chat, T3 code, uploading, ping, et cetera. I love to build.
6:06Speaker A:I focus on building complex things as simple as possible. I love to find ways to reduce complexity when solving problems. This is a small piece, but I found this helps a lot. Just because my preferences were not often met by agents, especially with certain overeager models like 5, 6 Sol and Opus 5.
6:24Speaker A:I noticed that my agents were a bit too proactive and we're a little quick to start writing a lot of code when they didn't necessarily need that much code. This two sentence addition here helped a ton with that. In particular, I specify that I want to share some of my preferences here so we can be more aligned as we work together. You might be questioning why I'm writing this way.
6:46Speaker A:A lot of it is because the models are good at tone matching. If you talk a certain way to the model, the model is more likely to talk that way back, which is to something I very much wanted. You'll see more specific examples of this in the not too distant future. I do have bullet point lists where they make sense like in my general coding preferences, so keep things simple.
7:05Speaker A:Type safety is useful. Don't be scared to propose bold ideas that can meaningfully benefit our work. Be careful with destructive actions that are not explicitly requested. Tests are good, endless smoke tests, regression tests for feature deletions, et cetera.
7:17Speaker A:Much less good. Tests should be focused, not slop. Comments are a great way to clarify functions and how code is used. Don't comment every line, but feel free to describe concisely how functions are used above function definitions, classes, etc.
7:28Speaker A:And keep comments up to date when making changes. Important to keep things in sync. Coding preferences for TypeScript I have separate pieces here. This is mostly because this is my agent's MD.
7:37Speaker A:A lot of this is just to tune 5,6 SOL to not suck as much at TypeScript. Specifically I said if your typescript code looks like a Python dev wrote it, it's bad TypeScript code. Avoid one liners that are just casting wrappers. Write TypeScript in ways that Matt Pocock and Theo would be proud of.
7:50Speaker A:A very brief if there's no tack for these things in the repo, this is the stuff I generally like. And when building more complex web and React native apps, I'd like to pull in Zustang React query tans like Start Clerk or better Auth if self hosting and Archetype or Zod if Perf isn't an issue. You get the idea. Questions are read only.
8:05Speaker A:This is another nice change because I got annoyed at 5.5 and 5.6 being a little too quick to start Making changes when I ask about stuff in the project. This helped a ton there Match ceremony to the task. Do not spawn subagents or multi agent panel for work or a single agent finishes in one pass. Delegation is for breath or adversarial review, not for ordinary tasks.
8:24Speaker A:Several agents do work in parallel state file ownership upfront so they don't collide. This again was noticing a lot of sub agents editing the same files and having problems. This one line helped quite a bit. Visual and design work do not edit real components first standing contrasts Prefer dark mode with white texts this is me trying to get rid of the grays last radius this is me trying to make sure it doesn't destroy my production environments and then my pull request section.
8:49Speaker A:This is a little aggressive here, but I have a separate pull request skill that has been very very helpful. I'm going to get this question a lot so I'm going to jump at it up front here. Sorry if you answered already, but where can I find the agent's MD file? I want to copy some of the instructions.
9:03Speaker A:You can't I very intentionally not publish this file, not because I'm evil and I want you to have to carefully watch the video and copy every single word by hand. The real reason is the value of this isn't the exact things I instructed. It is the way I thought of it. It is the reasons I added the things I added and the path I took there.
9:24Speaker A:I'm still going over the files and we'll do this for a bit, but I will describe how I came to these conclusions and why I added these things right after. I really want you guys to take the opportunity to learn from my process here, not to copy paste the specific things in my global files. Copying all these files would be like copying someone's generic code template, then using it for every single thing you touch, but also all of the things that you've worked on before as well. These files influence how all of your agents work across everything you do.
9:56Speaker A:You should control this file, you should edit this file, you should think about its contents and adjust it over time based on your needs and your problems. Anyways, let's look at my skills a bit. I noticed myself saying the same couple things to my agents over and over and they would often behave differently and they would often behave in ways that I didn't love. In particular, when I asked my agents to babysit a PR or to file a pr, the quality I would get out was mixed.
10:24Speaker A:So I started originally with the babysit PR skill which has been Very helpful because a lot of my projects have a lot of AI code reviewers on them thanks to the incredible channel sponsors we have around that. Some projects like T3 Code have three or four of them on the project and the point of the babysit skill is to have my agent monitor the print, doing things like rebasing and pulling in main when it should so that the PR stays fresh. Things like reading those review comments and addressing them when they come in. Most importantly looping until the PR is green and everyone's approved.
10:55Speaker A:As I told my agents to babysit more, I noticed certain failure patterns that frustrated me. Little things like the agent commenting through my account but not indicating it was an agent to big things like the PR getting three times larger than it should have been because it would address every single comment like it was mission critical, even for things that didn't matter as much. So the point of this was to fix those things. All the repos we work in have various AI review bots.
11:19Speaker A:They're helpful even if they're not always right. If your harness offers tools to monitor a pr, use them so you can respond when comments arrive. Otherwise, pull the PR for new comments and checks only. Act on checks and comments newer than the latest push.
11:29Speaker A:Verify every bot finding against the source before changing code. Fix real findings and CI failures, distinguish repository failures from infrastructure flakes, and reply with a written reason. When dismissing false positives, I'll specify to keep an eye on changes to main and rebase when needed. If an overlapping PR makes this one obsolete, stop monitoring, report to the user and ask before closing unless closure was explicitly authorized.
11:49Speaker A:If a review bot leaves feedback you believe is not worth addressing, reply and resolve the comment format. Comments left on Theo's behalf as such Markdown model slug responding on behalf of Theo actual reply this has been super helpful. Screenshots and videos help as well. I have a custom file upload skill that I built for my agents that allows them to upload arbitrary files to R2 with a public URL they can use to embed things in PRs because I noticed them doing NAS nasty shit to try and get a video in a pr.
12:14Speaker A:This solved that. This is probably the most important line in here though. Do not let review feedback expand the PR beyond the user's original goal. Address real shortcomings, but avoid scope creep.
12:24Speaker A:This skill's been great. One of the most important details is kind of hidden now let me do that so you can see it better. The Description this is a thing that most people get wrong and agents get even more wrong. Your description should not describe necessarily what the skill does because the description is always inserted even if the skill's not being used.
12:45Speaker A:The point of the description is to let the model know when it should pull in the skill. So you should treat the description less like an elaborate explanation of all the things the skill does. Hell, I've seen skills where the description gives you everything that you need and you don't even need to use the skill because the description has all the details. The description should have the magic keywords to tell the model when to pull the thing in.
13:08Speaker A:So here I could probably delete this monitor a pull request through review in CI entirely and have it just be use when the user asks to monitor, watch, or babysit a pr. The point of this skill is to be pulled in and give the model the context when it needs these things. I know it's unintuitive because it's called the description, but you really should think of the description of a skill as the trigger keywords rather than as an actual description. As such, you can guess how my File PR skill is Formatted file A concise pull request use when the user asks to file, open or create a pr.
13:42Speaker A:Originally I had the File PR and babysit PR skills as one skill, but I noticed once I added the keywords that it was good enough at triggering that I didn't really need that anymore, so I made them separate. Also, I often want one and not the other, so having them separate was really nice. So now I have the File PR skill that triggers whenever a user requests filing, opening, or creating PRs. This skill has been a night and day difference to my quality of life.
14:06Speaker A:Not because my agents couldn't file PRs before they could, but my agents would often file PRs in ways that I fucking hated. And now I don't hate it as much. Here's an example of a PR that was filed by one of my agents before I made these changes. The title is Fix Server Parse CLI version in Update Preflight Summary Verified Pinned runtimes against the CLI's actual T3 version output, make the self updating process runner fake, emit the same format and keep wrong version coverage realistic.
14:35Speaker A:Can any of you guys say in plain language what the point of this PR was? I know I can't. I happen to remember what I did here. The problem was that I was getting errors in the little log in T3 code that showed when there was drift between the version on your machine and the version on the remote machine.
14:52Speaker A:And this is the PR that was made to fix that. A lot of my PR descriptions looked like this and the titles aren't helpful either, and that was annoying me. So I gave direct concrete examples to my agent here before filing, Check whether a PR for this branch already exists. Review the diff locally against Origin main to make sure its contents match the goal.
15:09Speaker A:PR titles usually become commit messages, so follow the repository's title conventions. Look at recently merged PRs and git histories for example prefer a concise human readable title that explains why the changes matter. Bad example here. Perf server negotiate per message deflate on the websocket Good example Perf server cut websocket frame size by 70% with gzipping this was a real example that I did because I had a really awful title I hated from one of my agents and gave it this example.
15:37Speaker A:Agents are really good at bad and good examples. So if you notice your agent's doing something poorly that you have to go adjust. Put one or two of those inside of a skill or your globals and and now the agent knows what bad and good is to you and you've seeded its weights with the things that matter to you. Another important chunk that I have here.
15:56Speaker A:This is probably the one that's changed my life the most. As silly as it is. Open the description with a simple explanation of the problem based on the user's original prompt, then briefly explain the solution. Do not lead with an implementation inventory.
16:08Speaker A:So I gave a bad example here. Removed implicit workspace carryover from every new thread entry point. New threads inherit only the project from context branch worktree, yada yada. Just nonsense.
16:19Speaker A:No one's going to read this. Good example. My new work tree default was ignored when starting new threads on existing work trees. Super unintuitive now.
16:27Speaker A:Your preferences always apply so much better. I also specifically told it to stop opening draft PRs because Codex loves opening draft PRs that don't get reviews. They told it to open a real PR rather than a draft. So review bots run if the user also has to babysit it.
16:40Speaker A:Continue with the babysit PR skill. I probably don't even need this anymore because it pulls the skills incorrectly and you can see the difference if we scroll up a bit and click any of my new PRs. Here's a simple example. Fix for release Skip scripts during Vercel installs, the hosted web deployment runs its filtered Vercel install command twice.
16:58Speaker A:Both installs invoke the root prepare lifecycle so the persistent build cache accumulated effect ts go backups until it hit the hundred file limit in blocked releases, so now we're running with ignore scripts. That's a lot clearer. I also have at the bottom here in my example description. Maybe I don't have it here, but I have it in my global.
17:16Speaker A:I think I have it in my global. I do. I should add it here as well. Add a blurb to the end of the PR description about what model and harness is making the changes.
17:24Speaker A:This has been really helpful for keeping track of what I'm using for different work. Sadly, Codex often doesn't know what model it's using. I've been yelling at the Codex team for a bit about this. Claude always knows and most other harnesses know as well.
17:36Speaker A:Codex does not include the model slug inside of the system prompt, which is dumb of them. So sometimes It'll say that 5.4 filed it when it didn't, which is annoying. But yeah, small thing helps a lot to like get this information in my PRs. I've been really happy with this change, much more so than I expected.
17:52Speaker A:Another simple example. I had a bug in stashed prompts where they were being stashed per harness, which didn't make sense because if I stashed a prompt for Codex I want to go throw it in Claude. It annoyed me. I told it that, told it needs fixing and it described it accordingly.
18:05Speaker A:Stashing a prompt, switching providers and restoring it didn't work. The stash was bucketed per provider instance, so after a switch the badge disappeared and the stash looked lost. Restoring also dragged the stash model selection back, defeating the point of moving a prompt to a different provider. This is a great description of why I cared enough to do this thing.
18:22Speaker A:Super nice. Everything so far has been focused on my global skills and my global agents and Claude MD files. But there's a lot more to this than that. I want to show how I tuned the files that we have in T3 code itself for people contributing to T3 code.
18:38Speaker A:This isn't for T3 code users, it's for T3 code contributors. It's much more specific to the code base, which means it would be helpful to figure out how I discover these things in the first place. This was not a great example because I actually explicitly told the agent to not make the PR but instead generate the one click link so I could make the pr. And then I opened it and went and tidied all of these things up.
18:58Speaker A:Yeah, from here down as AI slop I did include that. This is the real thread I use to do a lot of the changes that I'm talking about here. To be clear, when you look at the generated agentsmd and Claude md, don't assume I used those because I didn't. I was using them largely as a reference point to get things tuned how I wanted.
19:15Speaker A:I opened with a relatively wordy prompt on what my goals were here that I want to rethink the AgentsMD in CloudMD for T3 code. I want them to better match the tone of my global agents in CloudMD. I also want to better represent the project and how agents should work. Random additional things I want to touch on.
19:29Speaker A:These are things I knew had been happening a lot that were annoying me and also I wanted to pull in my glossary from my lakebed agentsmd because I found that that has been super super helpful for how I communicate with the agent. I also said to match the tone from that file. Write up two separate drafts for an alternative claw MD based on what I shared here and it wrote them and I didn't like them much. There were parts there that were good but it wasn't great.
19:50Speaker A:But I asked it to do something that ended up being significantly more helpful. Can you look through my history with models like Fable, Opus and GPT5.6 Sol in Claude code and codecs on this machine to see what the most common mistakes are? Want to make sure we optimize to steer away from those? I want you to break down the most common failure modes and how often each model hits them.
20:12Speaker A:This was fun because not only did it catch specific failures that I cared about, it also categorized them by how often they happened. With each model and harness I noticed Opus 5 was aggressively killing the wrong process, often killing the T3 code instance that it was running in and it now is confirmed with real numbers. Even though I only used it for two days, it had done significantly more attempts to kill processes than Fable had in all the time I used it. Here you can see all the times user data were touched.
20:40Speaker A:Thankfully it was almost all read only inspection but we should still audit it further. PR hygiene we noticed SOL see again 40% of the time it filed PRs it was filing drafts. Other models were much less likely to file a draft. A lot of repo wide check failures where it was running things that didn't need to.
20:56Speaker A:Taking way more resource and build time on my machine. Good call out that it had here and it also tracked the bash error rates for the different agents that were working here as well. I will say that I did all of this with Opus because I was out of Fable at the time and it didn't do quite as good of a job auditing as both Fable and five six did. I did have all of them do audits looking for various failures and try to collect as many of them as possible so that I could use that as a reference point.
21:24Speaker A:As I mentioned, I had a lot of agents do this audit with me and find all the weird failures that happened across all of my real runs on my real machines. I forgot which model made this one, but I really really liked it. This was measuring corrections per 100 user messages per model, so I would often tell Fable it implemented things wrong. But that's also because I use Fable to do the hardest stuff and I often give Fable less context going in.
21:51Speaker A:I also apparently tell Opus 5 that its results look wrong way more often. It looks like sol's really good here, but remember I don't use GPT models for UI stuff, so if I say it looks wrong I'm probably just gonna move off of SOL for process. I actually had more problems with Fable than other models for like leaving branches stale, not fixing CI stuff like that. Opus 4.8 would misread what I was asking for very often.
22:16Speaker A:Tool misuse Opus was the worst by far. Opus 5 was misusing shit all the time and breaking my environment overbuild. Opus 5 and Opus 4:8 were the most aggressive with Apparently Fable is slightly worse than SOL overall, but it's a universal problem. Stopping early was also a universal problem.
22:32Speaker A:Noverify was pretty universal. Regression was rare but expensive when it happened, and only SOL was doing unasked edits that I had to tell it like hey, don't edit that, undo that. And then it proposed a bunch of changes to my global files that it thought made sense and I sat and read through this and this one and this one and even this one. The point of doing all of this is that I wanted to get a better feel for all of the things that went right and wrong in my history.
23:01Speaker A:Some of this is just vibing it out in gut feel based on my own uses and my own work in these projects. But it's also a lot easier to go through your history with an agent, or dozens of them in this case, than it is to read through all of that yourself and really think about it. And getting stats on what the failure cases are and getting your agents to give you the feedback on what happened is super helpful. And if you notice certain threads that just didn't go how you want, you should work with the agent to fix that.
23:31Speaker A:You should Ask it why did you make this decision? What gave you indication that this was the right direction? It might be something that's outdated in your CLAUDE MD or agents md. It might be something that it read incorrectly early and then followed along once it was in context that didn't actually make sense.
23:47Speaker A:Think about these failure modes, notice them when they happen, and ask the agent questions. Another really common one is if you ask for what you think will be a simple change and the agent takes 30 minutes or more when you thought it would take five. Ask the agent why it took longer. What did it spend its time on?
24:03Speaker A:Ask it to categorize all of the tool calls it made into different groups and try to determine which ones were and weren't helpful so that you can make adjustments to help the model make better decisions in the future. And I guess with that there's no better time than now to dive into our AgentsMD file. Another very important thing is that your AgentMD should be incredibly different from your README MD. The point of a README is context on the project and what it is that is useful for humans and agents that are trying to decide if they want to pull in this code.
24:34Speaker A:The point of the agent and CLAUDE MD files is to tell the agent how to change things in the code base and what it should know before it makes those changes. So yes, there are parts of this that should be descriptions of the project, but the majority of what's going on here really should be focused on how your agents will work in the project. While there is a lot of overlap between developers contributing to a project and agents doing those contributions, this file really should not be written for devs. It should be written for agents to help the agent interact with the dev better.
25:04Speaker A:And with that said, one of the most important details you can get right in these is a glossary. I like writing these not just so the agent understands me, because it's usually pretty good at that. It can infer what I mean when I talk about a thing that I want it to do. The glossary can help it understand what I'm saying a little bit, but the glossary is much more helpful for the agent to describe things to me the way I want it to.
25:28Speaker A:And a lot of these base terms are really simple. Most of them are terms that it probably already knew. But when you give it this type of really simple language to describe things with, it becomes much easier to talk to the agent because it knows how you're thinking and how you and your team are working. So our glossary is really Simple.
25:46Speaker A:Here, the first word defined in the glossary is you, which means the agent reading this file and changing T3 code. We, us and maintainers mean Theo, Julius and the people building T3 code. These are who you're talking to now. User means the person using T3 code to direct coding agents.
26:03Speaker A:An agent means the coding agent. A user runs inside of T3 code. Depending on context, this may also include you. Provider means the agent runtime or harness that T3 Code talks to, such as Codex, Claude, Cursor or Opencode.
26:17Speaker A:Client means the web, desktop and mobile UIS environment means one running T3 server and the machine file system provider credentials and state that it owns A project is an environment, local workspace record rooted at a directory. You get the idea. These are all very simple terms. I think this is easier from the top though, so let's do that.
26:34Speaker A:T3 Code is a minimal GUI for coding agents. A node, WebSocket, server wraps provider CLIS like codecs, Claude Code, Cursor, Grok and OpenCode. And it serves web, desktop and mobile clients. You can think of T3 code as an open source.
26:45Speaker A:Bring your own subscription alternative to apps like Claude, Desktop, codecs, App, Cursor, Glass and Conductor. This is useful context because now the agent has to spend less time figuring out what it is or what to look at when it's trying to model UI and ux. Now it has very specific direct instructions. Now it knows what to think about when it's trying to get things right.
27:05Speaker A:And then an important piece. What makes T3 code special? Again, you might think, oh, that's something that should go in the readme. Yeah, to an extent.
27:12Speaker A:But the more important part of putting this here is to give the model an idea of what it should never compromise on. If it's making changes and those changes hurt any of these things, it shouldn't make those changes. It also helps contextualize how it's working and where it's working. So it knows things like, since I say we're open at the core, that means it's an open source project, act accordingly.
27:32Speaker A:Or things like, we have over 100,000 users who love T3 code. That means that despite being alpha, we have to be careful to not break things. I even say here that it's important we maintain the things that our users love as we continue to iterate on the product. Here's a brief list of the things we can never compromise on.
27:47Speaker A:Open at the core. D3 Goat is truly open. We share our roadmap. We share how we think about things.
27:51Speaker A:And of course we share all of our code. A large number of our users run forks. We work in the open and we should strive to stay that way. Two Is performance without compromise Lots of apps have gotten bogged down with bad tech decisions in slop.
28:01Speaker A:We have not and we're proud of the performance of T3 code. We regularly audit for performance regressions often caused by sending too much data over websockets, CSS animations causing GPU spikes, lists being hard to render, and more. Make sure all changes are considerate of performance impact. 3.
28:15Speaker A:Remote Ready the architecture of T3 CODE's WebSocket layer with NPXT3 enables a lot of awesome remote features. These have become core to the product whether users are connecting directly over their local network using tailscale or leaning in fully with T3 Connect, which is our tunnel solution. Also in this repo we need to make sure new features are properly supported. And then I have the multi surface callout because because T3 code has its three core web desktop and mobile web is kind of two services.
28:41Speaker A:We have the public facing app T3 codes as well as the locally hosting web app through MPX T3 command. Both need to be supported by all new features where reasonable desktop's the main surface most users install. First it's a full electron app that bundles the server runner as well. The desktop app can also be used as the host server, allowing remote connections from both app T3 codes or the mobile app.
28:59Speaker A:Then there's Mobile which is a react native app for both iOS and Android. There mobile app allows for connecting to any T3 code server to control work remotely. Still an early access test flight, but it's pretty close to shipping globally. This I need to go remove now because we launched the app.
29:12Speaker A:This is all of the context that I want the model to have going in about what T3 code is so that it can make better decisions and not spend its first four tool calls googling and reading through files to figure out what the fuck we're doing. I then do my favorite a note from Theo. I like ambitious ideas, simple systems and software that feels obvious. Do not preserve complexity just because it already exists.
29:31Speaker A:Do not introduce machinery because it looks architecturally impressive. Understand the real constraint, then fight for the smallest model that makes the correct behavior unsurprising channel both measure twice, cut once and yagni. These are just phrases in the dev world that are associated with smaller concise changes and not adding things that are unneeded. Fight scope, creep.
29:52Speaker A:Try to honor the dev's intent in both a minimal and realistic fashion. The rest of this document is meant to help you navigate the code base and make changes effectively. Think of these instructions less as hard rules, more as good defaults. This is another important thing because I've noticed sometimes I'll put things in here that a user doesn't want and then they get really annoyed if the agent's MD and the user disagree.
30:12Speaker A:So I always put something like this in in order to make sure the person prompting can get around the stuff I put here. If it doesn't make sense, I even specify that developer preferences should be able to override anything here. Of note, most T3 code contributions will come from T3 code itself, often controlled remotely. This means you should be careful about accessing data, killing dev servers and other things that may damage the T3 code instance that the contributor is using.
30:36Speaker A:This is because I got really annoyed at Opus killing my running jobs. It was so fucking annoying that it inspired me to do this whole rewrite. So I guess Opus has contributed a lot. If you haven't caught up on the podcast, Opus5 went from my favorite model to one that pisses me off a ton really fast.
30:51Speaker A:I don't use it if I can avoid it at this point. Yeah, this was because Opus was pissing me off. And then we have the glossary and then I have the three ways to hurt yourself. This came pretty much directly from Sol auditing my logs and finding these particular failure modes.
31:04Speaker A:That happened a lot. I have a few more pro tips coming up for real world work, as well as two skills that have changed my life that I've never shared before and I'm really excited to show you guys all of that. But this video is getting long so I hope you can forgive one more quick sponsor break. If you're a developer and you watch my videos or you've talked to me in person, then you probably already know how much I love today's sponsor.
31:24Speaker A:It's Convex and I don't normally ask them to pay me because I show them for free. Their stuff is so good that we built all of T3 chat on top of it after my own self rolled solution just wasn't cutting it. And I'm so thankful I did because Convex solves so many annoying problems. They want me to show their new cloud code plugin.
31:39Speaker A:And I get it, it makes the model better at Convex, but it doesn't really need it because the models already are all so good at convex. It turns out having one folder in your code base that represents all of the Things that your backend, database, et cetera, all need makes it really easy for agents to write code against it. This is why I love Convex. It's just code, and it's just typescript code too, which makes it really safe.
31:59Speaker A:And if you're worried about scale, don't be. Jamie and James are two of the most talented engineers I've ever met. They helped Dropbox Scale. I've never met somebody who can tell you all the flaws of S3 scalability quite like these two can.
32:10Speaker A:The real reason to use Convex is all of the annoying problems it solves. From keeping data Synced to preview PRs, to access controls, to just all of these things that normally take a lot of work for you and your agents. Convex just makes it easy build apps in a way that you and your agents Will love @Soydev. Link convex.
32:26Speaker A:Sorry about that. I hope you understand writing markdown is expensive and writing it all by hand is time consuming. A bit of this was whisper flowed, but the majority of this was hand coded and written. So yeah, this next piece is another one of those huge lifesaver ones because I was running into a lot of problems where I would make a change in T3 code and it would only apply to one of the surfaces.
32:46Speaker A:For example, it would only be changed on the desktop app and not the website or mobile. I wanted to stop doing that and also to make sure the docs kept up to date as well. So I said as much. Hit every surface the most common defect in this repo is a change that works on the path you tested and is missing everywhere else.
33:03Speaker A:Before calling frontend work done, walk this list and say which entries apply. Make sure all the entry points are addressed. Things like settings, page command, palette and key bindings. So if you add a feature in the chat view it should be accessible in those places you have clients because we need to make sure things work in all the different clients, the web version, the desktop version as well as the mobile apps.
33:22Speaker A:Shared logic lives in the shared package, client runtime section and then the providers. Each of our providers have their own adapters. Provider shape features need a decision per adapter even if the decision is not supported here. Very helpful, especially when we add features for Codex and Claude.
33:38Speaker A:Now you have to decide, okay, not cursor, grok or open code because their implementations aren't quite quite as far along. Or maybe you do decide to sneak in grok because their SDK has made a lot of progress. Super helpful. We also have this contracts package which describes everything that crosses the wire over the websocket server or the new HTTP backed like Cold Store.
33:56Speaker A:A lot of the time changes will be made in the app that aren't properly reflected in the contracts package. This one line has fully fixed that. This was another really big one. Reverse states I had a lot of instances where I added things like settle and snooze but the logic to unsettle or unsnooze was not provided.
34:13Speaker A:This helped a ton with that. Same with the connection modes telling it the ways it can connect. Make sure that they all work as expected and then the docs this callout ended up making me go even further and I believe I still have a PR open for this. I do.
34:28Speaker A:I made a PR that I have to update and get merged soon where I properly split user and maintainer docs so they're two entirely separate entry points Because I've had a lot of problems with models writing a bunch of the internal details of how something works in the user facing docs. I had this a lot with Lakebed and I still have it a bit with T3 code and I found that a really clear split plus a little bit of tuning in your agent's MD to steer the model in the right direction helps a ton with this also gave some context on dev servers because I noticed the model often trying to call bun even though the whole project is vite plus now and it's called out everywhere. Models are also really bad at vite without a little bit of help because they'll try to type out vite and it doesn't work. They have to use VP and they'll also use VP dev instead of VP run dev which is really annoying.
35:11Speaker A:I called out Evan Yu for this decision already where VP dev does its own thing and VP run dev does what you actually want even though PNPM dev and bundev do the obvious thing. VP dev is special and that pissed me off a lot at the time because it annoyed me to have to remember to type the right thing. Then my agent started making the same mistake and now I'm even more pissed. So this is a line that exists because our friend Evan Yu could not get over his bullshit.
35:37Speaker A:It is what it is. He's wrong. It is hurting real users. Now I have to add this line and burn millions of tokens over the next few years because one person thought this was a good idea.
35:47Speaker A:Yeah, color pieces in here that were helpful is I gave instructions for using custom T3 code home directories so that if you spin up a dev server it doesn't break your running server as well as the ability to share a dev server over tailnet and tailscale, which has been awesome for doing a lot of remote dev work. I also noticed it was often sharing the wrong URL without the pairing token that I needed, so I told it to do that and I also noticed that it was stopping the wrong processes and often forgetting to stop the one that it should. So I told it to make sure it saves the PID when it spins up the dev instance so it could kill it. I gave explicit instructions for test data which have been very helpful as well, as well as some instructions for verifying I got annoyed at it spinning up computer use when it didn't need to, so I specified here upon request user visible front end changes should get one integrated pass in a real client and we have skills for this TestT3 app and test T3 mobile that Julius wrote for spinning up and testing those things with computer use.
36:38Speaker A:Then a bit more pull request instructions so the people filing pull requests will get better stuff when they do it from their agent. Because a lot of we have like 500 PRs I want everything I can to make them easier to read. This has been very helpful already with that the where code lives probably isn't that necessary anymore, but it's so little. Whatever, it's fine.
36:56Speaker A:A little taste section about where we want things to live Complexity belongs to the adapter boundary. Orchestration stays pure UI stays dumb Inferred types over annotations. Any is the enemy. Yep.
37:06Speaker A:Comments describe how a thing is used and move with when the code moves to be used mostly to describe functions, not to annotate every line of behavior. Our users drive agents all day and notice dropped frames, lying spinners and stale labels. No continuously repainted animations. They peg the gpu.
37:20Speaker A:If a real here fights the task in front of you, say so loudly and get a human sign off before breaking it. One last one is I noticed that the dev servers were being spun up and worked on with way too much security for something that only affects your local network and tail net. So I yelled at it for that and said security is important but should not be over indexed on especially for dev mode and maintainer only features. Another one of those additions that seems small but has actually been life changing for a lot of this work.
37:46Speaker A:The harsh reality is that you don't notice complexity that isn't necessary until it crosses a certain threshold. So the problem I had is that stuff was getting unnecessarily complex. I only noticed when it was too far. But then I took all of the things that caused that.
37:58Speaker A:I put them here and now everything is less complex, which has been awesome. It's been so nice to have everything I do just be more like what I want. And my prompts have gotten way smaller as a result. Here's a real example.
38:15Speaker A:I have to add the iOS and Android apps for T3 code to the marketing site. We are working on a marketing site overhaul, but I want these asap so we're going to get them right now. I asked it to make these changes. It decided that it wanted to give me a mock for all the different options using one of those two skills.
38:31Speaker A:I'll show you in a minute. And it created these mocks. A's marketing hero with the also on your phone callout B. Marketing final call to action C Download page D Marketing footer I hate most of these.
38:45Speaker A:It wants C +D A together. Do C D A file and babysit. That is my whole prompt. That prompt will do everything I want the way I want it to the C. D plus A it knows because that's the context it gave me.
39:01Speaker A:Using my HTML skill and file in PR tells it use these skills to figure out the rest that I want. Here's one I did yesterday that I forgot to make a PR for where I'm trying to fix the remote upgrade path to just have better UI file and PR and now that will be filed and I'll probably go merge it after I'm done recording. So I just noticed a bug literally now where I had a slept thread that woke because I snoozed it and it unsnoozed but I wanted to settle it and the settle button wasn't working on a thread that had just woken up. So I described the bug.
39:33Speaker A:I had a woke thread that I wanted to settle and I was unable to. The settle button that appeared on hover would not work right click settle did diagnose and fix file and babysit. That is everything I need and I will have a PR that is probably ready to merge in the next 15 or so minutes. That's pretty fucking cool.
39:49Speaker A:I know it's silly but this has been really nice but I promised you guys more. Promised you guys skills I hadn't shown. So I'm gonna do that now. The first ones I wanna show here are my command center skills.
40:01Speaker A:These are the ones that are specific to just this machine. Because I bring new computers into my network that I want to use for different things all the time. I do need to get in the habit of sunsetting a bunch of them, but I'm not there yet. But when I get a new Linux box set up or I just reimage a machine, I don't have to put a bunch of work in or set up nix or some shit.
40:21Speaker A:I just want to get that machine online asap. So I ended up configuring a bunch of things for my machine, getting my laptop how I wanted, and then telling an agent to look at all of my config, look at my bash history, look at all the things I set up and write them all down. And then once I did that, I told it to go set up another machine with all of the things I liked. And it got a lot of it, but it missed some things and it did some things it didn't need to.
40:44Speaker A:So I told it all of those. I told it to adjust those instructions to better fit the needs that I had. And it did. It created a whole provision, a box skill that is all of the things that I want to have on these new machines that I could set up over ssh.
41:00Speaker A:I even got it to make me this nice little HTML page that it updates every time it makes changes to the fleet that detail all the machines, their specs, what they do, what exists on them, et cetera. Different connection methods, the different specs, the baseline for what I want on each box, tmux, certain shell stuff, the ability to control TMUX over SSH with a mouse. And as you've probably seen in previous videos, that's exactly what I have set up. I have this machine.
41:29Speaker A:This is the one that does most of my dev work. It's my framework desktop with 32 threads and 64 gigs of RAM. This machine gets abused and it is where I do all my dev work now. And it runs a T3 code process that everything is controlled through.
41:43Speaker A:All of my machines are color coded and also have matching colors inside of my actual like cmux. So it's easy to see each machine in SSH when I need to. But honestly, since the recent T3 code changes, I have been doing a lot less. I'm just using everything through T3 code and not bothering with the SSH.
42:00Speaker A:You get the point though. I set all of this up so that I can more easily manage and configure my machines. And I have a skill that is only on this computer, but this is in a repo that has all the skills that all the other computers get. So let's look at the universal ones.
42:12Speaker A:I promised you guys I would show some skills I have never shown before. I already mentioned the file upload 1. This needs a lot of tuning in the description because a lot of this one I will admit is slop. The whole service I built is also slop.
42:26Speaker A:I actually bought tslop.org in order to have a place on cloudflare that these files will go and this is my file upload skill for uploading any local file m dash a screenshot, screen recording, log, document markdown, file config, build artifact or archive to the user's public file hostileslop.org and return a public URL rewriting all of this when user asks to upload a file or one is needed for a pr. PR descriptions use this skill. Cool. Much better description.
42:59Speaker A:I also have a requires section I added here in my metadata because I don't want the skill on machines where I don't have a global file host token because that is how this skill gets authenticated. If it is unset tell the user instead of guessing and I have the simple bash command that it will run in order to post the file to My service needs the token. As long as it has the token it can upload. So you use only the file's base name for file name such as login flow mp4.
43:20Speaker A:The server sluggifies it and adds a random suffix so names do not need to be unique. Treat the response body yada yada yada and then basic instructions on how to use the URL in GitHub as well as instructions that it can encode a gif for a preview when it makes sense to. And I even give the ffmpeg command for that, which probably wasn't necessary. This skill is fucking awesome.
43:40Speaker A:You have any idea how cool it is to have agents that can upload files? So if you're on your phone on the T3 code mobile app and your agent builds some new feature and you want to see it, you can tell it upload the file and respond with the URL and then it does. And then you can click the URL and watch the actual video it recorded on a real computer of it doing the thing. You can tell it to file a PR and it can include that URL in the embedded video in the actual pr.
44:04Speaker A:It makes the back and forth so much easier. And this is the theme I really want to make sure you guys get out of this. I'm not just trying to make the model more technically competent. The role of all of this is not to make the model better at writing code.
44:18Speaker A:There are little pieces here that are helpful with that. But the main point of all of this, the main reason I put all this time in, is to make the model better at communicating with me. I want to read the outputs, but when the outputs are piles of slop with no useful context, it sucks. All of these skills, all of these capabilities, all of this time I spent is giving the model what it needs to communicate with me and other maintainers and contributors better.
44:45Speaker A:And the file upload skill is not super useful for the agent, but it's really useful for me when I want the agent to show me something. And that was all the preamble for the skill that I rely on the most, the one that has fundamentally changed my life and sadly requires me to shout out anthropic because Thorek is the guy who HTML pilled me. This is my HTML planning skill. It's no longer HTML plans.
45:07Speaker A:I use it a lot for things that aren't plans. It's now HTML communication. When the user asks for an HTML write up of work not as part of the code base. Use this skill to create and always upload it to post plan.
45:20Speaker A:This is also useful for reading postplan.dev URL because I noticed the agent would try to browser used go to post plan when it could just curl it. So when should this be used? Use this skill for any request to produce a readable HTML artifact for a human. Whether it's called a plan, a spec, a write up findings or summary or report comparison set of UI mocks.
45:38Speaker A:The word plan is often absent. You can tell I wrote this by hand because of the typos here. What the requests share is a document to read outside the terminal and a link to open it. Horrible copy.
45:48Speaker A:I'll touch this up later. Also use it whenever a user supplies a post plane URL. A lot of this was slop. I tidied up incorrectly.
45:54Speaker A:Honestly. Probably going to delete almost all of this. The rest is what matters. Reading a post plan URL.
45:59Speaker A:I want the model to stop opening this in the browser directly. So now I say when a user supplies a post plain dev URL, fetch the uploaded HTML immediately with the shell. Do not use web search or browsers to retrieve it. You know what I'm going to do?
46:13Speaker A:I'm going to show you guys how I actually make changes here because I'm seeing opportunities to improve real prompt. I just wrote that might be helpful for you guys to see how I work with agents. This is in my Fleet repo where I manage all of this content. I want to make a few more small changes.
46:27Speaker A:I've made more since my last prompt, so re Familiarize yourself before editing the HTML communication skill is a bit overloaded. I want to break it in two similar to the file PR and babysitPR skills because I worked with this instance in this thread for that in the past. The descriptions for both should be really simple, focused on when to trigger and not what it is. One should be post plan read for reading content from post plan URLs.
46:48Speaker A:The other should be HTML communication for communicating to the user via HTML. When to use section should not exist in the post plan skill, only the HTML communication one. It should also be more minimal. Make your changes, don't commit or push to any machines yet.
47:03Speaker A:I'll tell you when this is just because I'm using SOL and I want to make sure it doesn't overdo so I tell it where to stop. When you give the model a stop point, life gets much better. Remember earlier when I said to go fix the feature with settle, diagnose and fix file and babysit? Apparently it was a straightforward CSS bug fix.
47:20Speaker A:Yeah, that was a pointer events none that was breaking or that should have existed that didn't on the woke label that was causing it to break the button that I had. I don't love this comment but fuck it yolo let's merge it. Cool. And now that's gone Man.
47:37Speaker A:I love the new T3 code workflow so much. While I was doing that, this finished and now we have the changes and my new skills so we can read these quickly. Use this go when the user wants a plan spec write up finding summary report, comparison or set of UI mocks presented as readable HTML. Do not use it for HTML, it shifts part of the product.
47:54Speaker A:Yep. Create one self contained HTML file capped at 512k. Write it like a spec, not a landing page. Sure there's like basic formatting things that I left in there.
48:04Speaker A:UI mocks, label them A, B and C for easy selection. Lay them out for direct comparison. Keep one file across iterations so its post plane URL stays stable. So I have post plan which is another microservice I set up that lets you upload a file with one command and as long as the path doesn't change, the file uploads the same way and will update with versions.
48:24Speaker A:And I also say never open a browser. Claim the documents hosted before upload succeeds. Do not verify in browser unless the user asks. I was so tired of opus randomly doing that.
48:31Speaker A:This looks much better. Let's go confirm the new skill that we got here, post, plan read, which shouldn't really need anything special there. Whatever. Fetch the upload HTML with the shell.
48:41Speaker A:Do not use web search or a browser. Remove trailing slash then append slash raw Unless the URL already ends in raw, it shouldn't actually need that. It should be the same content now. But sure both will work.
48:50Speaker A:Commit and push apply changes to the fleet. In the real world, I probably would have tidied this up slightly more or went and confirmed that the RAW isn't necessary anymore. Just to make these even simpler, less context is best as long as it has the context it needs. But these are all relatively simple and hopefully this is helpful.
49:12Speaker A:Use when the user asks to communicate through an HTML document. That's so much better. I want to add one more slight change here. Or if they mention HTML with no additional context, cool.
49:23Speaker A:I want to be able to just say HTML at the end of a prompt. And now I have that cool there. Just by adding to the end of the description. If they mention HTML with no additional context, that means use this skill, which is what I wanted.
49:34Speaker A:Sorry. Made one tiny change to description. Continue. And now those updates will sync across my whole machine in not very much time.
49:43Speaker A:This shit's so cool. Like, how cool is it that I am writing markdown? I'm writing effectively copy in order to change the behavior of the people, the agents across all of the machines on my network. And now this just works.
49:59Speaker A:It's so cool. It's so cool. I could just tell my agent to go sync all of this shit and it figures it out. Just because I have SSH access over tailscale set up.
50:07Speaker A:Igor pointed out that Steve Jobs would be so fucking memorized by this. Steve Jobs would go so hard with vibe coding, he would have fired all of his engineers and like turned Mac OS into complete slop. You might have noticed one thing I didn't do at any point in this video. I never told you to go to this repo and copy and install all of my skills.
50:25Speaker A:That's because I don't think that's a good idea. Similar to how I don't think you should just go install all of the JavaScript packages somebody uses. You shouldn't just go install all of the skills someone uses. This is a thing that you should build up based on your needs and your experience communicating with your agents on your projects.
50:42Speaker A:And this is a great opportunity to level up your own understanding of things as well. In order to make good skills in Agent MD and Claude MD files, you to understand how your agents work and where they fail, and hopefully this has helped you see where I find these things and you get some lessons you can apply in your own work as well. Don't blindly copy all the stuff I did here. Take the opportunity to learn and better understand how your agents work in your stuff, and I have a feeling the tips here will actually end up being really helpful.
51:08Speaker A:This video is already longer than Codex's system prompts. I'm going to wrap it up now. I hope this was helpful. And until next time, Peace nerds.
