My last video about ai harnesses

10,178 words · about 41 min to read

0:00 So, I was scrolling Twitter a few days ago and I saw this absolute dumbass posting about how harnesses don't matter. They were trying to compare people's preferences in harnesses to fighting about tabs versus spaces. I have the tweet open here. It's from this guy named Theo. He definitely has no idea what he's talking about. He's just a YouTuber, definitely not a dev shipping real products at all and should be ignored without question. That said, there is probably some reason he's posting this, right? If you couldn't tell, I happen to know this Theo guy pretty well, and I have a lot of thoughts on what he said here. There are few things I want to do less than another video about harnesses, but I'm going to do this one differently because I don't want this to be another video about harnesses. I want this to be my last. I know that sounds crazy. As the creator of T3 Code, I'm always out here plugging my harness, right? That's more complicated than it seems. I want to talk about harnesses one last time because I am honestly very tired of this topic. But I think by the end you will understand both properly what a harness is, but more importantly why they barely

1:01 matter nowadays. There are lots of exceptions to the rules here, but I think you'll be able to understand all of them and more. But I do have one more thing you should understand first. Today's sponsor. Today's sponsor is a little bit of a throwback. If you've been around for a while, you've almost certainly heard of this company. You might even be surprised to see me

Building extensible agents with the Eve framework

1:16 mention them again. I'll give you a hint. It involves a triangle. Versel is back, but not for me to show their cloud. I'm here to talk about Eve. This is much more similar to what they built Nex.js for, but instead of for you and I on the web, it's built for agents. It's a framework for agents. A framework built to make it as easy as possible to build good agents in a way that you and your AI can understand. Let's say I wanted to take some of the cool functionality we have in something like T3 code and expose it without relying on cloud code. I don't know, let's say over Discord. If I wanted to make a T3bot Discord, that's not going to just plug into Claude code. Fine. Thankfully, Dar and I were using Eve and were able to spin this up pretty easily. I can now in our Discord server tag T3bot and give it basic instructions like take over this PR and get it landed, full send. If you're familiar with my skills, you know what these all do. And now the bot is able to do real changes to our real code base with all the primitives it needs exposed over Eve. When you see how Eve works, it'll all make sense. You start with an instruction MD file at the root.

2:13 You define your agent with whatever model you want to use. You can define skills the same way you normally do in a skills folder. And if you need more complex tools, you can define those as well with TypeScript. If your agent needs a sandbox, you can set that up with the sandbox directory. If you want to plug it to other things, you connect channels. If you want access on Slack, Discord, and Teams, you connect them in channels. You can create other connections to things like MCP servers in the connections folder. You can define sub agents, run schedules, and more. All just by defining folders and files in a real project. This makes it trivial to use the same agent everywhere for whatever you're trying to build, even if you're just trying to troll your team by making a really silly profile picture for your bot on Discord. Build

Software abstractions shift developer focus upward

2:49 reliable agents in a way that makes sense at soy. So, before we can talk about harnesses and why I don't think people should care about them, we should talk about how developers care about things in general. The harsh reality about developers is that their jobs, at least up until recently, were all about caring about things nobody sane should ever care about. The silly example from my post is the most obvious one. Tabs versus spaces. Like realistically, the only people who should actually care here are people who have specific accessibility needs where spaces are going to make screen readers behave worse than tabs do. That's like the only reason to care about tabs versus spaces. But we do anyways because developers have dedicated their whole lives to caring about tedious That's what we do. The reality is that there are layers to the Like at the very bottom of the stack of like how much does a thing matter? There's tabs versus spaces. But as you go up the stack, you have things that matter a bit more like the patterns for defining functions and

3:53 your like fundamental algos, the frameworks you use to build, the languages you use to build those with, the architecture of your applications and how they're built and thought about, the engineers that are actually working on all of these things, the product that you're trying to build on top of all of this. And realistically speaking, the stuff at the top here, the actual product that your company sells, probably should matter a whole lot. And whether or not you use tabs or spaces should probably not matter a whole lot.

4:24 Now, you're probably looking at this a bit confused because I put the fundamental algorithms you use below frameworks and languages. That's probably going to piss off a lot of CS bros and professors that are in the audience. Sorry. You'll understand in a minute why. The thing I want to emphasize here is how what we focus on shifts over time. Back in the day, engineers cared a lot about the instruction sets that they had access to when they were building. So, this is like the different versions of assembly for the different processors you're targeting. Those things were really important back in the day, and they're still important to some people sometimes. But, we did a thing that we often do as devs. We built an abstraction. Instead of writing the instructions for each platform ourselves, we started to write in generic languages that could make the specific things for those platforms.

5:14 Then we got better languages for this like C. And eventually what happened with C wasn't that we had less assembly code or fewer programmers. It was that

1 Highlight · Developer focus shifts upward with new abstractions

5:23 programming was now easy enough that the average dev didn't have to care about what specific instructions were being run on the CPU and they could build a layer higher than they were before. The reality is that the line you draw depends on where things are at at any given time. And when C happened, the line for where you had to care was shifted slightly above the instructions that your stuff was running. When our editors got good enough to handle tabs or spaces and just switch between the two and tools like prettier got to the point where they were reliable and consistent caring about tabs versus spaces, how you break the indentation out for like the curly braces, how you format your if statements and all that.

6:04 We got to stop caring and slowly we had to stop caring about the patterns for the functions as well. both because of of course all of the good formatting tools llinters and everything existing but more importantly AI happened and with AI all of a sudden you can tab complete to generate the functions that you're typing out and eventually the fundamental algorithms you have to memorize matter less because you could name the algorithm and it would fill out the rest for you. That was how I was able to do really well in advent of code three or four years ago without really putting much effort in because I knew which algos were needed and rather than implement them I would name them and then hit tab a bunch. The point I'm trying to make is as an industry things have always shifted up like this. As new abstractions are made and new tools are created. Places that might have taken a lot of your effort before no longer

6:54 benefit you. But we're engineers. We love caring about these tedious, unnecessary things that the world around us tells us don't matter. Like, let's be real, chat. How many of y'all had parents say you're spending too much time on the computer and that won't matter as much as the real world? Let's see ones in chat. If you've ever been told by your parents that you're spending too much time on the computers and that they don't matter that much. And it didn't stop any of us, did it? Not a single one of us. We don't care when the world tells us that we're wasting our time on something that doesn't matter. If we did, we would never have learned how to code. Let's be real here. So, this is where the first problem comes in. Engineers are predisposed to caring about things that they shouldn't. The shouldn't is vague and varies depending on who you are. But like, let's be real, there's a lot of things we care about as engineers that we shouldn't. Things again like tabs versus spaces. And the models have

AI models now rival humans in system architecture

7:49 continued to get better. And with that, the frameworks have fallen. The most recent Nex.js releases got less traffic on Twitter than my random posts about T3 code. And the most attention any of the Nex.js releases have gotten this year was cuz I quote tweeted one and pointed out that there was nothing happening, like nobody noticed or cared about a new Next.js release. This whole channel was built around being Nex.js's number one defender for years. Nobody gives a anymore. We didn't even notice as this happened, but it happened. And now we're nearing the language barrier as well, where I have a bunch of stuff I wrote in Typescript.

8:31 Not only have I been able to rewrite those things in Rust, I rewrote TypeScript in Rust. Languages are an implementation detail. They're like a speck on a spec sheet now, and they can be swapped out. They can actually be replaced in a loop in not much time.

2 Highlight · AI models can now reason about complex architecture

8:45 architecture is getting more and more within the capabilities of models as well. They still don't do it even close to perfectly or even at my bar, but they understand problems in architecture. And if you go to them with a design that is good, they can find the holes that could be replaced and fixed to make it go from good to great. And when you get enough different agents with enough different information and access and testing capability together, they can find flaws in systems. I actually was just able to find a bunch of very severe flaws in Cloudflare's pipeline stuff that they seem to have been entirely unaware of because I spun up Quad when I noticed some failures that shouldn't have been happening. and it set up a bunch of alerting and monitoring and tracing in our backend systems to identify where and when failures happened, which regions they were occurring in, and write up a report that I sent to Cloudflare that they just thanked me for because they weren't aware. And they're going to go fix things because I guess Claude in some specific cases is now better at architecture than companies like Cloudflare. Do you understand how

9:45 insane that is? That the YouTuber noticed an error in his logs, asked Claude about it, and now has a report that the CTO of Cloudflare hit him up for to get more info about. If you don't think these things are changing, I am sorry. You are going to lose your job in

Harnesses provide the execution environment for LLMs

10:02 3 months. Accept where we are or die. Anyways, this is a video about harnesses. Why are we talking about this? We'll go back here, I promise. Because right now I want to rant about what harnesses are. Most of you guys have probably heard about LLMs. Let me know if you haven't, but I would hope at this point in time the idea of a language model is not too foreign to you. I'm going to ask y'all again, chat, what do LLMs do? Almost all the answers are great.

10:30 Write text. Make text. Predict the next token. Predict text. Generate text. Yep. All of these are perfectly reasonable descriptions. All an LLM can do is make text. It takes text and then it generates more text. I know that sounds crazy because we've seen AI do everything from like hack the government to reinvent all the software we use every day to destroy our economy and rebuild it. Like, how can LM do all of that if all they do is generate text?

10:59 That's where the harness comes in. Hopefully, this beautiful diagram perfectly explains what a harness is. But for those who can't tell immediately from my very poorly drawn diagram here that doesn't actually say anything, let me explain a bit. I want to explain in a weird way though. I want us to entirely ignore the right side of this for now. I want to just talk about humans and interfaces. Going to talk about a weird interface here to start. Going to talk about kitchens. You go to a restaurant.

11:28 You have some food you want. You're given the menu. You decide what food you're going to order. You order the food. The chef is told what food you want. They then stand there and stare at you and say what you expect me to cook. I can describe what I would cook, but I don't have anything here. This is just a kitchen. Where are the utensils? Where is the everything I need to cook with? You can put an incredible chef in a room and you can label the room a kitchen, but the chef can't do jack until there are things in the room that they can interface with. They need tools. It doesn't matter how smart or capable the chef is. It doesn't matter how detailed your menu is. If they don't have the tools they need in the kitchen, they can't do their jobs. Now, imagine a programmer. You're put in front of a computer and you're told to write a basic sorting algorithm and you're just staring at the monitor and you stare back at the instructor and you say, "Hey, I can't do this." And they're like, "Why?" And you're like, "There's no keyboard. You just put me in front of a monitor. There's no way for me to explain to this computer what I'm doing.

12:28 I can't put an input in and have something happen. I could stare at the monitor and talk about it, but I can't put inputs in without buttons to press. That is why we have interfaces, both hardware and software. We have keyboards and mice. We have programs with buttons that we can click. We have things that let us go from thought in our brain to taking an action to making something exist or changed or different. We need an interface to do that with for our hands to be useful beyond holding things. Even to hold things, we need things to hold. our hands are useless until there's things for them to interface with. Similarly, LMS have words. All words are good for is reading until you give the model things they can use the words for. If a human had no objects around, no people around, and they were just being filmed, the only use of their hands would be sign language. But if you give them things their hands can use and interface with and do, suddenly those hands become useful. In the same sense, all an LLM

13:29 can do with words is signal. The equivalent of us doing sign language. In order for that to become something, they need tools and systems where the words can have actions. Similar to how a keyboard lets you use your hands to type, an LM needs something to interface

3 Highlight · Harnesses act as the kitchen tools for LLMs

13:46 with as well. Humans have apps, UIs, they have keyboards and mice. They have all these different things. LMS have harnesses. For a human to cook, they need a kitchen with tools. And for an LLM to write code, it needs a harness with tools. And the way a harness works is almost misleadingly simple. The harness tells the LLM, "Hey, here is a special syntax we have that you can respond with to make me go do things. If you respond in this syntax, I will read a file for you. If you respond in this syntax, I will edit a file for you. If you respond in this syntax, I will push up to GitHub or run a command or access your memory or go cost you a bunch of money on some API. For the LM to do something, it needs a syntax it can respond in that a harness can understand, too. An LLM without a harness is like a chef in an empty kitchen. They can tell you what they would do, but they can't do anything.

14:43 And the harness is what allows the LLM to do things. So, let's play a fun game. I'm going to name some products and you guys are going to tell me where they fall here. Are they an interface or are they a harness? Let's start with an easy one. Twitch TV. Is Twitch an interface or a harness? Interface. Awesome. Nice and easy. So, a Twitch is an interface. As you can guess, so is YouTube. Let's do another easy one. The Claude Code Agent SDK. Is this an interface or a harness?

15:17 harness. Awesome. Great job, chat. If you're not familiar with the agent SDK, the point of the agent SDK is to give your LLM, well, specifically Claude, all of the things it needs in order to build, work on a computer, edit code, etc. It describes it here as an agent's an application that completes tasks by planning its own steps and calling tools that read files, run commands, or edit code. The agent SDK gives you the same tools, agent loop and context management that power claimable in Python and TypeScript. So here is where the controversial question comes. What is cloud code? Is cloud code a harness or an interface? A lot of y'all are saying both.

15:58 Handful are saying interface. I would argue quad code is an interface that bundles a harness. And the harness it bundles, at least in the desktop app, is agent SDK. So the claude app on your computer is an interface. And the interface plugs into the agent SDK, which is a harness. And if you don't believe me here, let's look at anthropics own words. If you want to embed cloud codes agent into your own Python TypeScript app and a process you own, use the Asian SDK, the library that runs the cloud code binary, yada yada yada. But then we have if you want to do interactive development or run one-off tasks from a terminal, they recommend Cloud Code the CLI because it's a terminal interface built for daily interactive use. The thing that makes this confusing is the Cloud Code binary bit, but the Cloud Code binary, that's a harness. The Asian SDK makes it easier to use that harness, but it's still just a harness. The Cloud Code CLI, that without a question is an interface.

16:55 Don't forget about this hierarchy thing because I promise we are coming back to this. It's probably the most important part of the video arguably because for this next part to make sense, I'm going to have to zoom out a little more because a lot of people are confused about T3 code specifically. This is a big part of why I'm making this video because of the volume of confusion

MCPs decouple tool integration from rigid harnesses

17:14 around what T3 code is because T3 code is not a harness. It's an interface. It does give some things to the harness. It does change how it works in some ways, but T3 code is not a harness. I will explain in a bit. First, I want to talk about tools, though, because that's a big part of what makes harnesses useful is the tools that they expose to agents. And up here, I've drawn a line separating the row with the humans and the LLMs from this row I referred to as the tool plane. This is the things that the harness exposes to the LLM. Also worth noting, I I delayed this in my article that I wrote about everything, which by the way, if you have co-workers that you're too embarrassed to send videos to, the what is a harness blog is on t3.gg GG now and I explain all of this there for the most part. So for your co-workers that may not be into me or my videos, maybe send that to them for them to read this because I have been amazed at how many devs just don't understand what a harness is. Funny enough, this all started because a Nyx Foundation member didn't know what a harness was and was trying to dunk on me

18:16 for building a harness when I'm not. Anyways, the thing I didn't rush to in this article, I actually went so out of my way in my article to delay this word until the very end. It's the word agent. An agent is a combo of a harness and an LLM. The agent is an LLM that has the ability to complete tasks that are scoped or unscoped via a harness that provides it the tools, the context, the system prompt that describes the role and all of those types of things in order to allow the LLM to do more. And it is the combo of a harness and an LLM that becomes an agent. Anyways, now that we understand that, let's talk about these tools. Most harnesses come with some tools built in, some more than others. Pi has basically no tools included. It's basically just bash.

19:02 Claude code and claude agent SDK come with a lot more. They have a spawn sub aent tool. They have read file, edit file, read skill, create artifact, bash of course, and so many other things. But you can also bring tools in from other places. Like if you install the TypeScript plugin in Cloud Code, you'll get some useful helper tools like go to definition or find reference. If you install KUA for example, which is a shared computer use control system that's open source that will be in T3 code very soon. And if all goes well, that will introduce tools like screenshot, click, and type that will allow for your agent to trigger things on your computer. Does the inclusion of tools mean that Typescript is a harness?

19:41 No, obviously not. Typescript is just a plugin for your harness that introduces additional tools that your agent can use. Same with the Kua bindings and drivers. Kua is not a harness. Kua is a set of tools that you can include in your harness that enable your agents to do more things. So, where does T3 code fit here? We don't really add new tools because we're more focused on the other side here, what I call the data plane. This is interfaces you give your agent to access things outside of the harness.

20:11 Technically speaking, you could build a lot of these things in as tools, but the point is that the the thing, so to speak, lives outside of the harness. When you add a tool to the harness, you're putting something in the kitchen. Whereas with the MCP and data plane stuff, I think of this more like a cookbook that you're leaving in the kitchen. The LLM has the option to read the cookbook and decide if it wants to do the things in it or not, or it can just leave it outright and not touch it, not care. But that's up to the LM if it's going to bother reading the book or not. It obviously can ignore the tools in the kitchen as well, but the tools are tools. They're just all around. The point of the MCP is that you're bringing in external information and interfacing with other things, so to speak. This makes a lot of sense for things like the Superbase MCP or the Postthog MCP because the point of these is to give your agent access to data that is somewhere else. Whether it is your

4 Highlight · MCPs decouple tool execution from harness binaries

21:00 Superbase product database or your analytics on Post Hog, MCP is a way for your agents to access that. So why the hell is T3 code here? Tools are very harness specific. When you create a tool, you have to do it the way the harness expects. You have to support the syntax and capabilities the harness expects. And that code that you write, it kind of lives in the harness. You're effectively shipping a binary that runs inside of the harness. It could just be TypeScript. It could just be JavaScript.

21:27 It could just be something even simpler like Python or it could be an executable, a bash script, a very thin three lines of code that hits an external API. But you're shipping the code when you ship a tool. MCPs are bindings. They're not code. Could we have taken all the things the T3 code MCP provides and make them custom tools that exist for every harness? Hypothetically, yes, we could. But by putting it in the MCP like this, we are able to have all the code be in T3 code, and we're effectively just letting the agent interface with that through a agreed upon contract where instead of the harness executing code, the harness is giving T3 code instructions to execute code instead. This allows us to build our tools and our systems in ways that are much more generic and not as much interfering with how the harnesses work by default. And this is why the T3 code MCP is so cool. Since we're not interfering with the tools built in to your harness, if you have Cloud Code installed and you're signed up for the $200 plan or the $100, even the $20, if

22:28 you have Cloud Code installed in your computer and then you install T3 Code,

22:32 Claude Code will just work in T3 Code with your sub the way that you're used to. All your skills, all your plugins, all your everything will just work. But it does add something. It adds the T3 Code MCP. So all the things you normally do with claude are there. But if you want to do something it can't normally do like spin up another thread with codeex or have a sub agent that's using anti-gravity or grock build or something like that, that's what the T3 code MCP provides. It allows your agent to search through your T3 code history and find things from other harnesses. It allows it to send messages to other threads or spin up sub aents with whatever harness you want. If we let those tools live in the harness, we're kind of stuck at that layer. If we think of this as like the LM at the bottom, then the harness, then the interface, then the thing that we're building. If we put everything in the harness, then we can't go deeper. Since we built this a different layer higher up with this MCP layer, we're able to let one harness control another harness because it's not really controlling that other harness. It is telling us in this MCP layer that we should go spawn this

23:34 other harness and then we can be the broker and pass messages between the things. This leaves us with an important question. T3 code is not a harness. Then what is T3 code? I will answer this in a second because we already have another cliffhanger. As I mentioned before with

Developers obsess over their formative tech layers

23:47 the things mattering less and less as we go up the chain, engineers tend to get really into the layer above the one that died nearest to them getting into things. Sure, we've all heard the classic comment that your music taste is highly reflective of what you were into in high school. Most humans that have favorite musicians have very similar favorite musicians at 16 and 36. Even though they've more than doubled their age, you kind of during like high school and college, the thing you're into then it sticks. Engineers are similar.

24:21 Whatever layer stopped being cool when you got into engineering, the layer just above you're going to be really into. If you want a good example of this, you're looking at one. When I got into software dev, we were moving away from the endless language wars towards a new era of framework wars. As Typescript became the industry standard, like everyone was using it, we shifted from fighting over different flavors and syntaxes of JS to the frameworks we were building our stuff with. When my YouTube started to blow up, the hot topic was Nex.js versus speltkit versus solidjs versus nux. And it feels like decades ago. That was like two years ago, not even. And I cared a lot about that because that was the layer that was getting more interesting as I was getting really into software dev. The thing that was cool when I was in college was languages, but they were kind of on the way out. And by the time I got a job, frameworks were the conversation. So that was where I was so focused. That's where I talked about

25:22 things the most. So much so that my roommate was annoyed and I started making YouTube videos just to vent about these things. But thankfully, for whatever reason, I'm pretty sure it's ADHD, I really like when these changes happen. When the focus shifts in the industry up a layer, it excites me a whole bunch because I love abstractions. I love feeling dumb. I love learning new things. So when the focus shifted away from React versus Solid and started shifting towards how we defined our infrastructure alongside our front-end frameworks, things like Next and Server components versus all the crazy RPC stuff everybody else was trying, server rendering, SSR, RSC, ISR, PPR, all these things, that was so fun for me. And then the abstraction became working with AI and agents and all those other details started to fall. I was uniquely prepared for this because I was into webdev where things shift all the time. I had transitioned from a back-end dev doing Python, Ruby, and Elixir for Twitch and AWS to a front-end TypeScript front functional programming nerd teaching all of Twitch to do more FP on the front end

26:24 to doing YouTube videos and infrastructure and all these other crazy things. And now one of the funniest moments I had uh recently, I have no other place I can put this. I'm just going to put it in this video. Why not? Thanks for watching. Also, red button underneath if you haven't hit it. Helps us out a bunch. I was chatting with Boris, the creator of Claude Code, a few days ago. We had never met before. He absolutely knew who I was. I obviously knew who he was. I told him I wanted to talk about some webdev stuff and he was very confused.

26:50 He was one of the OG React team guys and was at Meta in the early crazy days of React. He was close with a lot of the original TypeScript team as well. I knew him from his history in the web dev world. He had no idea at all that I was a webdev. He thought I was just the AI dev guy. No concept in his head that I used to be the like webdev content creator guy and that I had been working with the React core team for years at that point. Like the the number of mutual friends we had is crazy. The number of my close friends that he had interviewed and hired at Meta was hilarious and he just had no idea because that's just not the topic right now. But this also in some ways shows the thing that is crazy here, which is somebody else who was in my space with me and we both left it. Like neither of us are known for webdev stuff nowadays.

27:43 The fact that someone that important in that space, like a actual hero of mine from that era, had no idea I was in that space was very weird and jarring, but also I think showcases how quick these transitions happen. where I went from the guy who couldn't shut up about server components to the point where like I was explaining server components to my goddamn mother. Like I just I cared too much about these things and I just did a call with my mom a few days ago where I was trying to explain why Gemini is so far behind. What I'm into is what I'm into. And what I'm into right now is this. I bring this up because this has always made me get along poorly with a lot of engineers, a lot of really talented engineers even.

28:23 Because when I see the abstraction happen, I get hyped. Because all that time I've spent living in the layer I'm in, as fun and exciting as it was,

Skateboarding teaches a love for starting over

28:32 doesn't matter anymore because there's a new layer that has a high chance of wiping out the layer before, which means I get to learn again. I get to do the thing from scratch again. I learned this love in a weird place. Skateboarding. I am going to do one last weird tangent analogy. I'm sorry, but entertain me, okay? Okay, cuz when I make a video about skateboarding, nobody cares. So, if I can sneak in a 30 secondond to minute long rant about it, I'm going to do it when I have the opportunity. Okay, ones in chat. If you've ever run track and field before, even if just like once or twice in high school, have you run a around on a track? A lot of y'all have, of course, right? Okay.

29:12 Twos. If you've ever jumped over a hurdle, you know, the big stand things. things. I know a lot of y'all aren't native English speakers, but like the big like flat thing that you jump over when you're running in a track. Seen a lot of twos. So, a lot of y'all have jumped over a hurdle before. I want you to imagine in your head how that felt. Just stare at the hurdle and imagine yourself jumping over it. Just get the the image in your head. Think about which leg you jump off, which leg goes in front, how your shoulders are positioned, how your body feels as you fly over this thing. You have that in your head. Now, now that you have that in your head, swap the legs. If you were launching off the left with your right in front, mentally switch to your left leg in front and launching off right.

29:59 Vice versa if you're the opposite. Imagine in your head, how would it feel to swap the legs? One's in chat if you think that's normal. twos in chat if like it hurts your brain to even imagine using the wrong leg. Thank you guys. Lots of twos. I could go really in depth around the mentality of like which leg matters and all of this, but I'm going to tell you a fun thing. This isn't lefty or righty where like if you're a righty, you use your right leg, and if you're a lefty, you use your left leg or something like that. Righty versus lefty is like six to one split. Right leg or left leg is a 50/50 split. like it is straight up even split which leg you jump off of. Everyone's different. In skateboarding, we have the same thing.

30:42 So, in skateboarding, I'm goofy footed, which means I skate with my right foot forward. But a thing's going to happen here. I did a 180. Now, I'm skating backwards. You can see how uncomfortable my shoulders are. But I could still do a laser flip, which is one of the hardest flip tricks. I did that switch this trick as well, cuz I'm normally right foot forward. That was a switch Casper flip because I love doing goofy tricks. Not goofy as in like my stance, but silly tricks in the wrong stance. The reason it's called Goofy is rumored to be because there was a video a long time ago of Goofy from Disney and Mickey Mouse riding a surfboard with his right leg forwards. They started calling it Goofy stance. The reason I bring this up is because of a weird phenomena in skateboarding. In most sports, especially things like track, it's your goal to be as good as possible at all costs at the thing. So, if there's one leg that you're better at jumping off of, you should always use that leg. In skateboarding, you are rewarded for

31:44 learning things both ways. We call it switch. So, when you learn a trick in your regular stance, learning it in your switch stance is like a flex. It's similar to like being a basketball player and learning how to get three-pointers with both your hands for fun. But in basketball, we would just laugh at you for that. That's not worth it. But in skateboarding, that is rewarded heavily. Like it is one of the most disciplined things you can do in skating is have tricks in both stances.

32:12 People outside of skating will see that and not care. They won't understand that you just made the thing four times harder by doing it backwards. But for those of us who do care, it's the coolest thing ever. Like I can tell so quickly watching a skater doing a trick if that's their regular stance or not. It's just intuitive for me. If you've been programming for a while, you can do something similar to this. You take a programmer who has written JavaScript their whole life and you make them write an app in Go. They probably can do it.

32:42 They'll have to Google search a bunch. And most importantly, you'll know because the syntax they write is going to look a lot more like JavaScript than most Go code does. The analogy also holds for people outside of our world where if somebody built a really cool website and they told their friend and their friend's like, "That's awesome. Can you build me a thing for my Windows computer?" And you're like, "No, sorry. I only know how to build iPhone apps." That's going to be really confusing to your friend because they don't see a difference between doing the thing for an iPhone and doing the thing for a Windows computer. They just see you as a builder. In skateboarding, somebody could do a trick with their right foot forward and then do the same trick with their left foot forward. And to most people it wouldn't look any different, but to skaters it's like, "Oh my god, that is so insane." And if a programmer wrote the same app by hand in five programming languages, nobody outside of the devil world would give a but we would be like, "Oh my god, that person's a wizard." If they could rewrite the same thing in five languages, they know their I bring this up because it's not practical. As a software dev, you would make way more money becoming an industry leader at one

33:44 specific technology or thing than you would being a more general person. If you got really good at JavaScript, didn't know anything about servers, you're probably going to make 500k a year at a fang company until you decide to retire. Same the other way. Some of the most talented and more importantly, best paid devs I know seem like they've never written code before if you put them in a React codebase. But you put them in some like ancient C++ hellscape, they will fix it. They will make it

5 Highlight · Embracing the unnatural like skateboarding switch tricks

34:10 faster. They will thrive in that environment. So why did I go down the skateboarding tangent for so long? It's cuz skateboarding taught me to love stuff that makes no sense. Things that do not matter outside of my own enjoyment of them. When I learn a trick switch, I'm not doing that for anything but me. And more importantly, I'm not doing it for anything other than the feeling of doing something more difficult, of doing it despite the fact that it feels unnatural. And I grew to love this feeling of unnatural. Because no matter how good you are at a kick flip, you can do a million kick flips, if you've never tried a switch flip, you still have to learn from scratch. You actually get to a point where the more you do normal kick flips, the harder it is for you to rewire your brain to do it backwards. there's a a very rough point you get in the journey of mastering a thing where you've mastered it so much that switching to other things becomes harder and perhaps all the people who have been complaining about Theo the noobjs programmer getting so popular had a real point here by never getting too

35:11 good at one thing I never get too attached to that one thing so when a new thing happens I don't mind wiping my hands clean and moving on because to me it's just like skateboarding switch it does not matter how good my kick flips are. Doing a switch flip is still learning from scratch. It does not matter how good I am at Typescript if my agents are writing my code. It does not matter how good I am at Angular if React becomes the new framework that everyone uses. It does not matter how good my argument is for spaces versus tabs when everyone's using prettier. Most people are not good at this though. Most people, devs in particular, when they

35:46 have chosen the thing they care about, they are going to keep caring about it forever. The example of this that I have the most familiarity with by far was when Typescript blew up. I hated doing webdev. I was very much a backend dev. But when Typescript happened and then React happened and then React became a more functional programming thing, I got to come in with none of the baggage. I had spent no time getting really good and familiar with JS. So when Typescript took a lot of the things that I didn't like about JS and made them much easier and more reliable, I had no sunk cost to feel bad about. I just started using the better thing and thought it was great.

36:21 And I found myself deeply frustrated with the historical JS devs, the ones whose whole history have been like 10 years of fighting the browsers to make JavaScript a usable language. A lot of those people straight up did not make the move to TypeScript. To this day, a handful of them are still arguing that Typescript's a waste of time and mental energy. If you were a decent dev, you'd just use JavaScript to not introduce all of this terrible tooling and systems to your codebase. They don't do anything.

36:50 TypeScript is a very useful language if you think otherwise you don't understand the web. The fact that I was new to the space and I understood that made it really hard for me to have any conversation or to be real any respect for the previous people who just couldn't get over the fact that the thing they dedicated all this time to was not the right place to focus anymore. Most devs make one of these transitions in their life at most, if even. They usually stick with where they're comfortable and then never leave. The example I will use here, like

Tool loyalty traps developers in obsolete layers

37:21 I I could be wrong about this. The way you can prove me wrong here, I would bet that of everybody using Vim today, at least half of them will still be using Vim in 5 years, and most of them won't have jobs as software devs anymore. And the half that move away from Vim will be making significantly more money. That's not cuz Vim is bad. Vim is awesome. Neov is an incredible tool. It's an incredible community. It's because the people who still care that much about that type of detail are stuck. They're trapped. They're not able to leave the thing that they've like anchored themselves into. They've really like built their home in this particular layer. And a lot of the people who escaped landed in a new layer. So, if I go back here and edit this more, I change this to your editor. And then up here, I change it to the LLM. And [snorts] up here, I change it to the harness. The line has continued to move.

38:10 Obviously, we don't really care what editor people use anymore. Even when I was becoming popular, I used VS Code. I only got so much for it. Like, I got people saying you should use Vim, by the way, a decent bit, but not a lot. Now, that's like gone. I cannot remember the last time somebody said I should be using Vim. Which model you use still matters, but like we're all changing them constantly. I would argue that if you're like a hardcore loyalist for one particular model family, you're just as as the Vim guys are. Like if you refuse to use anything but a codeex model or anything but a Claude model, you're going to have a rough time.

38:39 You're probably doing well right now if you're only using Claude because the family is really good right now, but that can change at any point. In fact, by the time this video is out, it might have changed. So, a lot of people chose to dig their heels in here. Wow, you're still using VS Code in 2024. Every real dev's moved to Neovm. Wow, you're still using Cloud Code in 2026. Don't you know that Pi is more efficient? Have you not tried out Oh my PI? It makes dumb models so much smarter. You're just a slave to the labs if you think that claude code is worth using. That's where we're at right now. And I'll be real, six months ago, I would have entertained the conversation. There was a conversation worth having about harnesses. I could have part of the conversation right now.

39:20 I could do a two plus hour video about the niche differences between the harnesses. I could go on a very long rant about the show that is the codec system prompt and how it makes the models labbotomized and terrible. But I'm not going to do that because it barely matters anymore. I want to talk about effect for a sec. I know it seems insane, but le let's think about the type of person who would create effect. Is this the type of person who constantly likes to leave the thing or the layer they're in, or is it the type of person who likes to refine the layer they're in and keep polishing it indefinitely? Is this the type of person who is going to dedicate their career to making Neoim plugins or is the type of person who is going to leave Neoim as soon as something better appears in front of them? I ask this question because I got the answer wrong myself. I operated under the assumption that if you understood the nuances of the TypeScript language protocols as well as the effect team does and that you try to build your own language within the language that you're the type of person

40:21 who's never going to leave the layer therein. It couldn't have been more wrong. The tweet that actually inspired the video that we're watching is this one from Michael, the creator of Effect. Since I've started using T3 code, I no longer care which harness is used. I'd actually love to get rid of all of them. And he mentions using Clanka from one of his friends, Tim, but he doesn't care anymore is the point he's trying to make. I have felt this way for a bit, but I'd never put it so simply before.

40:48 And I've been thinking about this more because I've been getting a lot of questions from very confused people when they're using T3 code and they use claude in it and it works how they expect and then they move over to codeex and none of their skills are there and then they go into the settings in T3 code and they don't see a skills section and they spam my DM saying what the hell my skills aren't working in codeex and then I ask them did you add your skills to codeex and they say no I'm using Astra it should just work it worked fine in opus they don't even perceive the harness anymore. Like like the harness doesn't exist in the same way that like when someone uses Twitter, React Native web doesn't exist. Most people don't even know Twitter uses React Native web.

41:29 Even devs don't know that Twitter uses React Native web. T3 Code users despite being devs don't even understand that the way the model picker works is that it's not a model picker. It's a harness picker. To go back to the kitchen analogy, T3 Code isn't a kitchen. T3 Code is a food court at a mall where you pick which kitchen you go to. And if you go to Panda Express and you ask them for a burrito, you're going to be confused. That's where we're at now. But I'm also realizing like this is now my problem as well. When people stop caring about the kitchens, I now need to supply everything every kitchen could possibly supply you or people are going to be mad at me. And that's what's made my life weirdly confusing recently is the number of people who see codeex or claude code and they see this as a harness that has certain things in it like plugins or skills and they switch from cloud code to T3 code and then they add codec to T3 code and the things from claude aren't there. It's because in their mind they're swapping the thing on the right

42:31 in my little diagram. They think they're swapping out this In reality, the thing they're using is this. They're using a box that includes the LM, the harness, and the interface. And what they're swapping isn't the whole thing. They're

T3 code acts as a harness food court

42:46 just swapping the interface out with T3 code. And then they're confused why everything they do here doesn't carry through to all the other harnesses they never touched. And my hottest take here is that this is a net positive. This is going to allow for us as the creators of T3 code to make an experience that is abstracted similar to how you can just swap the string for the model or the API that you're hitting. You should be able to just swap which harness you're using so that it doesn't feel that horrible like when I know so many people who were using OpenAI models heavily and were deep in codecs that move to cloud code because Opus 55 is unbelievable and a really good value. Now they're changing the thing they're used to a whole bunch and they get really confused and annoyed. They move to T3 code and now they can swap between cloud code and codecs with a little button click. And as the models get better and smarter and the harnesses get more and more invisible in the process because here's the real spoiler guys, the harnesses and the models are getting more tied together. Previously the models had certain capabilities and the idea of tool calling trained into them and then the harness would be adjusted to work around the model. The models are now

43:47 being trained on the data from the harness. So cloud models do just behave better in cloud code usually. Open AAI models should just behave better in codeex, but the CODC system prompted ecosystem is such a show they don't. Separate rant for another time. If OpenAI succeeds at catching up, the result will be Codeex being way better for their models than Cloud Code is. Which means that we shouldn't be thinking about the harness the same way we don't think about the kitchen when we go to a restaurant. We should just go the place that has the food we want. We should just select the option that has the capability we want at the price we want. And the reason I'm complaining about all this is because the harness guys, the ones who care way too much about which harness they're using, that make fun of you for being a fool for using claude code or codec. And I'm one of them. Like I had a very big video that I thought way too much about where I described in detail why you should use cla code for your codec sub and not codeex for your codec sub. I have that all set up still. I don't use it a whole lot because the reality is that the like gap between cloud code and codeex for

44:48 using codeex models is like three to 5% maybe it washes out. I don't care if the differences are bigger than that. That is a failure in the LLM layer that will be addressed. It is not just my goal to make harnesses not matter. This isn't some weird thing I have a bias for. In fact, I don't. If harnesses mattered, I could build a really good one and win a lot of users that way. But they don't. So, I would do something way harder. Open code is much easier to build than T3 code for this reason because they don't have to make everything work with every single weird way a tool or a harness wants to behave. Do you know how complex our code is for managing all the different types of sub agents across all the harnesses? It sucks, but we have to do it because we chose the hard path.

45:28 The hard path being the one where harnesses don't matter to our users. They're just an implementation detail for us. So to everyone spamming me that I have to check out their harness because it benched so much better than claude code. Congrats on your 3% win with a lastg model or with an openweight model that wasn't trained on cloud code. Really happy for you. I'm happy that you can spend more money than my subscription to get fewer tokens and less work done. I am actually kind of happy for you because you seem happy.

45:55 Good. Cool. Awesome. Great. I'm focused

T3 code is an Agentic Development Environment

6 Highlight · Defining the Agentic Development Environment

45:58 on being productive and thinking too much about your harness is not going to make you very productive. Almost forgot. I promised an answer to this question. What is T3 code? It is kind of an interface, but it interfaces with both the human and the harness. It doesn't interface with the LLM directly, but it does connect to the harness and do things there. It does show you stuff as the user and let you do things. It also lets you control things remotely on various machines, manage your environments, update all your harnesses remotely, all these fancy things. We had a term back in the day when your text editor started to have more and more things that made your experience editing code better because like you can edit code in notepad but it's missing a lot of the things we expect whether it be syntax highlighting simple tools for running your tests and getting results inline LSP support for getting feedback from the language server those types of things. We called this an IDE an integrated development environment.

46:54 So what is T3 code? It's kind of an IDE, but this term has a very specific meaning now. It means the tool that you write code in and can run the code and do other things in as well. T3 code is not an IDE. It's an AD, an Aentic development environment. And I think this is the closest thing we have right

47:14 now to a term that actually describes the tools that we are talking about right now. And similarly to what I was saying before, I do expect this to stop being the cool hot thing. Similar to how your IDE, whether you're using Vim, Neo Vim, Emacs, VS Code, whatever else, stop being cool. I think we're already over the hump there a bit and possibly at the other side where people are going to care less and less about the thing that they are opening and using because they're just going to be prompting in Slack. But I want a good ADE. I want one really bad. I've been crashing out since December when I got a taste of what Google was cooking with anti-gravity and like there was a tiny bit of stuff in there that was good and everything else was garbage. I wanted something good and open source and customizable. So that's why I made T3 code but I did not make it because I wanted to make a harness. I never wanted to make a harness. I never do want to make a harness. I've made a lot of fake ones for benchmarking, but that's about it. I just wanted an open- source tool that was what controlled my AI work. the thing I interface with, the tool I touch to be open and customizable so I could fix it. So T3 code is an ADE

48:14 and I am suspecting ADES will stop mattering in the very near future, similar to how everything else has, but for now I care. I care a lot. We built the best one and you should consider trying it. What do you have to lose? It's free and open source. Worst case is that it sucks and you can make fun of me on Twitter for it. [sighs] I think I've said all I have to here. I wrote way too much about this topic and drew way too much about this topic, too, because I don't want to talk about harnesses anymore. And if the labs do their jobs, I won't have to talk about harnesses anymore because they'll just be part of how the systems work. If I do have to talk about harnesses again, chances are it's cuz somebody really screwed something up. So, if you see an anti-gravity video coming soon, know that it's not because Google did something good. I think that's all I have to say on this topic. I really hope I can sunset it once and for all. Let me know if this clarified things or if it just made you more confused. And please, I beg you, if you see somebody insisting that T3 code is a harness or just clearly and obviously not understanding what harnesses are, link them this video. Or if you're too embarrassed, just go link them the article. I won't make any money off that. In fact, it will cost me money. I just want people

49:16 to understand what a harness is so that I could stop dealing with this once and for all. I am so tired. And if you guys are too, I'm sorry. I've said what I have to. I'm done. And until next time, he sns.