Boris has some really good advice

[00:00:00]Engineering's changed a lot over the last few years, and I can understand why many people feel almost betrayed by this. Back in the day, I had so much fun customizing my setups in VS Code and Atom and even Sublime Text where I got started. And when I started my channel with the T3 stack, that blew up, too. I had so much fun with this type of work, trying to get my environment and my setup and the way I built exactly right.

[00:00:22]And I could fully understand why people who cared about these things kind of feel left behind. That was such a fun part of the job and it's gone now. Well, kind of. If you're not familiar with Boris, he's one of the two original creators of Claude Code. It was an experiment he started at Anthropic that went way further than expected. And as a result, he's gotten really vibe code pill. Obviously, he's a big fan of using Claude to do most if not all of his work. And he's also had some uh dumb quotes to put it lightly about how all of engineering work will be replaced. We won't need engineers anymore. Those types of things. But he made a post today that is different. This post is much more focused on us, the engineers who love this enough to watch videos about it in their spare time, to get their stuff working how they wanted to build the exact tools to solve their exact problems the way they like. That type of person should be excited now.

[00:01:10]And I think he did a great job justifying the why here. This video has two core audiences I want to address.

[00:01:17]The first is passionate developers who miss the thing they love. the people who put all their time into getting great at coding, great at building their environments, great at setting up the world the way they want it when they work. But the second audience is arguably more important. It's the people who already got over this line and want to help their friends do it. So, what I'm saying is this video is kind of for me. I have a lot of friends who haven't quite had this all click yet. But just cuz everything's changed doesn't mean it isn't fun still. In fact, I've felt more clever and had more fun than I ever have as a developer in my entire career.

[00:01:46]because a lot of those skills that I built back in the day are more valuable now than they ever have been. One more valuable thing before we get started though, today's sponsor. Tell me if you've been there before. You do a bunch of changes with your agents. You get a PR up and ready to go and then you sit and you wait for CI to run. Then it hits a random error that you didn't hit on your machine. So you go in the logs, you find the error, you copy paste it to your agent, you say fix it, and then it pushes it back up and then you're sitting waiting again. Wouldn't it be great if that CI was way faster? Or if even better, your agent could trigger it directly, get the logs, and fix things yourself. If that existed, it must be really complex to set up. It certainly couldn't be done in one line, and it would probably also be way more expensive than using something like GitHub actions, right? Oh, I spoiled it again, didn't I? Yeah, Blacksmith fixes all of these issues. Their CLI makes it trivial for your agents to run the CI directly, and more importantly, it ends up being way faster and cheaper. At my company, we run all of our CI on Blacksmith, and it has been so much nicer. Not just because it's faster and cheaper, but also because the monitoring is way better. Finding things that go wrong, debugging them, seeing how much usage and utilization we're actually doing, what jobs are causing that utilization, what errors are transient, which things are failing more often than others. All the things you need to care about when you're building real services are so much easier with Blacksmith.

[00:03:01]We've run almost 3,000 jobs on Blacksmith in the last 7 days, and I would expect this number to keep going up. More importantly, our failure rates are going down because we have good analytics on what's going on. Your agents deserve better and faster CI.

[00:03:12]Give it to them today at swordv.link/blacksmith.

[00:03:15]So, I'm going to have a lot to say myself here, but I want to get started with Boris's post because it catches a lot of the same core points I want to make, and I really like how he put it.

[00:03:24]Something I've been thinking about. In the past, the best engineers I knew spent a lot of time automating their work in various ways. Better Vim or Emacs automations, writing lint rules to catch repeat code issues, building up a suite of endto-end tests so they don't need to smoke test the app manually.

[00:03:39]These kinds of things were the highest leverage activities an engineer could do because it multiplied their own output which in turn meant they could build more things. These types of clever solutions and workarounds are so so cool to me. One I talk about a lot from when I was at Twitch was the test that caught failures before almost anything else. We had this endto-end test that would go to a random channel on Twitch, which by the way I'm currently live streaming on as I do for all my videos. The way it worked is two bots would go to this channel on Twitch. One would send a message in Twitch chat and the other would receive the message and make sure it actually appears and renders properly. It was a super simple test that just required spinning up two instances of Playright that had a browser underneath that already had the cookies for these accounts signed in. One sent the message, the other made sure it was still there. And that test was so simple and so clever and it caught so many failures before anything else did. And I always loved that type of clever problem solving, finding ways to take the most complex systems and assure their success in the simplest possible ways. And I think that mindset is what's so valuable right now. And it's why certain people are enjoying all of this way more than others. Back to what Boris was saying here. He thinks many of these automations have become even more important now. It's true for a number of reasons. First off, the infer and developer experience automations speed you up. And if you're running an army of agents, each one of those agents will be sped up as well. More automation means more output per unit of time. Yes, absolutely agree here. A lot of the things I cared about about like spinning up your experience or quickly provisioning a preview environment were things I cared a lot about, but I would get a meaningful amount of push back when I would push these things back in the day. I remember how much I loved preview environments with tools like Versel and how people would push back on me saying, "Tho you care too much.

[00:05:29]Nobody actually needs these preview environments. They're all building it on their device anyways. Now that you're not, now that your code is being built by agents anywhere else in the world, it could be in the cloud. It could be in a background tab on your computer. It could be in a work tree. It could be on another computer on your network. Having things like a good preview environment experience is super valuable. And also having ways for your agents to test those previews, find bugs, and then post videos of the results is super useful as well. But this also is an opportunity to get clever with your problem solving.

[00:05:56]For example, I noticed my agents couldn't add video files to pull requests because they didn't have a way to add them to the PR. On the GitHub UI, when you drag and drop the video onto the PR, it will upload it temporarily in a way that's visible in the PR, but you can't do that with the CLI or any of the tools that update PRs programmatically.

[00:06:14]So, I end up building my own custom file upload skill with my own service I put up on Cloudflare called files.teslop.org with a key that I put on all of my different machines on my fleet. And now these machines are able to upload a file and then post the line inside of the PR.

[00:06:30]It's so nice. And I'm going to be honest, the amount of fun I have building these one-off things is way higher than I expected. The magic of putting together a few pieces, figuring out what works, writing this up as a skill, and then testing it inside of your agent and seeing it able to use these tools. It's similarly rewarding to setting up a environment for your team and watching them use the things and have them work really well, but the feedback loop is much tighter and when things break, it's a less big deal. It's so fun and so rewarding. Ryan just joined chat. If you're not familiar, he's the creator of SolidJS and historically he wasn't that into doing things like configuring your environment really deeply and caring about how your editor works. But suddenly with AI, he feels more pulled towards these types of like automations and refinement work.

[00:07:16]The way you put it here, I actually really like. He's excited by AI because it finally feels worthwhile to build this stuff. He's never cared about automations because he doesn't like managing more things, worrying about more moving pieces and breaking stuff.

[00:07:27]But now, let's go. Yeah, it's great. And even cooler, most teams are more willing to let you spend time on this stuff now.

[00:07:34]Previously, if you spent 3 days working on your Vim config, your team would be very upset with you and your boss might be concerned. Now, that's not the case.

[00:07:42]Now, there's more buying to do these types of experiments. And I've had so much fun with it. In fact, I've had to encourage my team to spend more time doing things like this because they're so used to it not being worthwhile. Even though they enjoy it and are drawn to it, they've had to like tone that down in their head. Now they don't have to anymore, and that's really exciting.

[00:08:01]Or's next point is one of my favorites.

[00:08:04]Moving things to code improves efficiency. Your agents could fix an issue every time it sees the issue happen, but that uses tokens and it might miss cases. If Claude instead writes a lint rule, a CI step or a routine, that class of issue can be fully automated forever. This is really what people are talking about when they talk all about loops. It's about automating entire types of busy work rather than solving them one-off. This isn't a new idea at all. Engineers have been doing this for a long time. Yeah, this is one of the things I love the most about building with AI. There are certain things that would be useful if we had them, but just weren't worth the extra effort. things like having a custom lint rule that requires like 400 lines of code to check very specific weird things. If those things were easy to see visually, we would probably just do that in code review. That would just stay manual labor indefinitely. Now that doing the code part is easier than ever, as well as doing all of the tests to verify that code change. Suddenly, a lot of this type of work, like building custom automations and actions for each individual project, makes a ton of sense. I literally was just talking about how I built a micros service on Cloudflare so that my agents could upload things to it via a markdown file.

[00:09:10]This type of thing just didn't make sense when you had to write the code by hand unless you did the thing that it solved a lot and most problems just aren't encountered enough for people to care. Now that the agents are hitting them way way more, all of a sudden this makes a ton more sense. And here's where we get to the coolest part of all this, which is how it affects your team. Third and most importantly, automation makes it possible for others to contribute to the codebase more easily. Increasingly, what I am seeing is engineers are contributing to code bases on day one because claude can navigate the codebase for them and that non-engineers are able to contribute to a codebase as effectively as the engineers can. This is a bit of a reach. We'll come back to this idea of non-engineers contributing in just a sec. What gets in the way of both of these is domain knowledge that lives in people's heads rather than in automation. the stuff you used to have to learn when ramping up. What's changed thanks to agents is that the domain knowledge can be encoded as infrastructure and is no longer limited to what is expressable in lint rules and types and tests. They now capture nearly all domain knowledge encoded as code comments and skills and claude MD rules and memories. If I put up a PR for an iOS codebase I don't know and a code reviewer rejects it because I didn't use the right framework or something like that or if a designer builds a new feature and it gets rejected because it doesn't follow the right architectural patterns. These are failures of automation. I think he goes a little further with this than I would like especially with where things are right now. But the idea here is very very good that it is our role as the engineers who have the experience that know what a good codebase is and what a bad codebase is. That we have to set up the systems to make it more likely that when people come in that the codebase continues to be good and high quality. And those guards can look very different. They can be custom lint rules we write. They can be structures that we build and architectures we make, but they can also just be markdown files. And that's so cool. This idea that it's our job to not just steer our own agents as we build, but to create systems where other people's agents get steered correctly as well. One of the rules I've always had with the teams I run is what I call the dumb questions rule. When I bring on a new employee or teammate, I would almost always require them to ask at least one dumb question every day or their day is not done yet because those dumb questions help unblock them, which is great and all, but what's much more powerful with this is it gives you an intuition for what is and isn't working for people who are discovering your codebase and working in it for the first time. You only get to be a beginner in a codebase once. So having that insight is super useful as I try to make the codebase more approachable to make new devs more effective in it and to prevent certain classes of regressions going forward. I've been doing this my whole career and it's one of the things that's always allowed my teams to work more effectively and ship crazy things way faster than others do, especially when I moved over to doing startups. I've always found it so rewarding to build your codebase in a way that others can contribute and understand. This is why I made the T3 stack in the first place. I wanted it to be as easy as possible to know when things were working and clear as possible to know why things weren't.

[00:12:14]And yes, to an extent, if you get all of this right, non-engineers will be able to contribute in an effective manner, but not as effectively because I don't think non-engineers should have to understand how all of this stuff is defined. And as I've said many a time, do not let your agents write your quad MD or agents MD file. That is where it's worth putting the extra effort in.

[00:12:37]That's how you'll understand what leads to different behaviors in your agent.

[00:12:41]And you should watch what your agents do and then adjust those files and adjust your tooling and adjust the setup you have in order to steer the model in the way you want it to go. I'm actually planning a big overhaul for all of this inside of T3 Code very soon because I've been a little annoyed at some of the behaviors that it has, especially when you're developing against T3 code directly. And I think that that work will be a good example of this in the not too distant future. But again, the goal here should be to set things up not so that the agents magically intuit it everything they should ever know. Rather to get them feedback when they're doing things wrong, both for the agent and for your potential teammates that are contributing as well. You can even use these steering files to help suggest the model push back on certain things. Like if you notice that people keep coming in and asking for a specific feature that should not be in your project, you can add to your agent MD. If they ask for this, stop and tell them no and it will.

[00:13:36]It's almost magical in a way and it's fun to get clever with it, too. When you realize there are ways to chain these things and use them together that make the outputs more consistent and reliable and meet your specific expectations, it's it's really fun. It honestly feels similar to how building the T3 stack did when I realized all these pieces could be combined in such a fun and powerful way where if I had Prisma on the back end turning my database into actual typed functions and then I have TRPC which exposes those functions over a simple RPC layer to my client and now I have endto-end type safety in the hook in the component that is rendering the UI all the way to the database that's storing that data. That feeling was so cool when it all started to work and watching the community form around it was unbelievable. That was the type of thing that happened to me once every few years at best before. Now I get things like that almost every day and it's so so cool. I like how Boris wrapped this up as well. It really emphasizes these important points. Every team should be writing the claude MDs, review MDs, skills and docs that enable agents to productively work in their codebase with zero additional context from the prompter. This sounds crazy and at the same time it's a natural extension of the stuff engineers have always done.

[00:14:50]Automate and code domain knowledge as infra. As the models get smarter and as harnesses mature, this task becomes easier. In the meantime, it is on every team to look for ways to convert their domain knowledge to infra so that Claude can write code better so that code review catches issues more automatically so the next person working on your codebase can contribute more easily. I will say I have a very convenient cheat sheet for this part which is that my preferences are all public information because I'm popular. So if I put in my agent MD or claude MD build this the way Theoa would like it built, it can usually figure things out. And if it can't, I just say Matt PCO instead and it does. Seriously though, it's really fun to figure out how this all works.

[00:15:29]And I've even seen some very talented developers, cough cough, Ben cough cough, who started getting psychosis just from seeing how much they could influence and steer the model with the agent MD doing crazy things like dumping context from his favorite books to get the model to feel more the way he likes things to feel and to talk the ways that he likes to read. And silly things like that can meaningfully impact the behavior of the models. It's crazy how much little changes in these files can impact the experience that you and other developers have. And to be extra clear about this, I am not saying you should go rush out and install every skill and every plugin from every thing and try to force the team to do the same thing. I'm saying that you should use these tools the way they come preconfigured. And then when you find problems, build solutions to prevent them going forward.

[00:16:18]Don't just install a bunch of stuff before you get started. You shouldn't touch any of these files until you've sent the first couple prompts and you see what goes wrong. And as Boris said, you should send these prompts with as little context as possible to see if that's little enough for the model to understand. And if not, what context should be encoded inside of these files?

[00:16:38]If your CloudMD or agents MD are just lists of where things are in the codebase, that's not a good guide. Those files should steer the model towards success, not towards specific lines of code. I would argue that everything I've said so far is not controversial and hopefully we can all agree on it. This next piece might be reaching a bit. So take it with a grain of salt, but hear me out as well. These skills are how you become a senior in quotes developer. If you want to level up your effectiveness on your team and have more impact on the projects you work on, these skills are some of the best ways to do it. Going from a great individual contributor to somebody who really pushes the whole business or team forward requires that your work not just elevate you or the product. It should elevate the team and how they contribute as well. And the more you learn about these techniques which you can learn solo just building your own projects with lots of agents by the way or you can learn them at a company as you try to make changes to make it easier for others to contribute and make it more likely your contributions land in fewer prompts.

[00:17:39]These skills are super valuable and if you can build them, they will help you level up your career massively. Even if the company you're at right now doesn't appreciate it, the next one has a much higher chance of it. And as the industry continues shifting in this direction, I believe the skill of making environments where code can be landed most effectively is a much bigger skill than actually landing the code yourself. But my hottest take about that is that it's not a new thing. This was always the best way to level up. The path to staff engineer was never one of just landing more code. It's one of building these structures and systems. And now you can do it solo in a way you never could before. When I would build solo projects, I didn't know how it felt to contribute to them cuz I knew how they worked. I had all the context and everything in my head. Now with agents, even my solo projects are way beyond my own comprehension. So I have to focus on building these systems so that my own agents and my own ADHD don't get lost in the process. and that has allowed me to continue leveling up here. And if you want to keep growing in your career, you want to go to senior, principal, staff, wherever you're hoping to be, I think these skills will be some of the most important in order to get there. Hoping this video was helpful. Send it to some co-workers if they've been struggling with this move. I know that the change in the industry has been scary for most of us, but it's honestly been so fun once I started to embrace it a bit more.

[00:18:57]And hopefully maybe, just maybe, this video will get a couple more people over that line. Because once you've made it over, the world becomes so much fun. And I've been enjoying building more than I've ever enjoyed in my career. Let me know how y'all feel. And until next time, he sns.