Modern Creator
Why Modern Creator?
Theo - t3․gg · YouTube

Claude Code's creator has some really good advice

Theo reacts line-by-line to Boris Cherny's post arguing that automation — CLAUDE.md rules, lint checks, CI — matters more than ever in the agent era, not less.

Posted
yesterday
Duration
Format
Reaction
sincere
Views
70.9K
2.2K likes
Big Idea

The argument in one line.

Claude Code co-creator Boris Cherny argues that the highest-leverage engineering skill hasn't been replaced by AI agents — it's been amplified, because automation that once sped up one developer now speeds up an entire fleet of agents at once.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…
  • You're a developer who misses tinkering with dotfiles, lint rules, and CI setups and wonder whether that instinct still matters in an agent-first workflow.
  • You lead or mentor engineers and want a framework for deciding what belongs in CLAUDE.md or AGENTS.md versus what to just tell an agent each time.
  • You're building solo with AI agents and want to understand why documentation discipline matters even when no teammate will ever read the file.
SKIP IF…
  • You're looking for a step-by-step Claude Code prompting tutorial — this is commentary on a philosophy post, not a how-to guide.
  • You have no interest in team process or engineering management — the video is squarely about leverage and contribution, not model prompting technique.
TL;DR

The full version, fast.

Reacting to a post by Claude Code co-creator Boris Cherny, Theo argues that AI agents didn't kill the value of automating your own work — they multiplied it. A lint rule, CI check, or CLAUDE.md rule that once saved one engineer time now speeds up an entire fleet of agents at once, and lets non-experts and new hires contribute on day one because domain knowledge lives in infrastructure instead of someone's head. The actionable core: never let an agent write your CLAUDE.md or AGENTS.md yourself, test steering files by sending the shortest possible prompt first and encoding only what breaks, and treat a rejected PR for style or architecture as a failure of your team's automation, not the contributor. The skill of building environments where code lands cleanly — always the mark of a senior or staff engineer — now matters even on solo projects, since agent-built codebases can exceed what any one person holds in their head.

Free for members

Chat with this breakdown — free.

Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.

Create a free account →
Chapters

Where the time goes.

00:00 – 00:47

01 · Why this hits different

Theo admits the old joy of tinkering with editors, dotfiles, and lint rules feels gone — then introduces Boris Cherny's post as a rebuttal to that feeling.

00:47 – 02:10

02 · Two audiences for this video

Theo frames the video for passionate devs who miss this work, and for people already 'over the line' who want to help friends get there.

02:10 – 03:15

03 · Sponsor: Blacksmith CI

Mid-roll sponsor read for Blacksmith, a faster/cheaper CI runner Theo's company uses for agent-triggered CI.

03:15 – 05:00

04 · Reason 1: automation now speeds up an army of agents

Reading Boris's first point: infra/DevX automation that once sped up one engineer now speeds up every agent running in parallel. Preview environments, once dismissed as unnecessary, are now essential.

05:00 – 08:03

05 · Reason 2: move fixes into code, not into the agent's memory

Boris's second point — a lint rule or CI step automates a whole class of bug away instead of re-fixing it each time. Theo tells the story of building his own Cloudflare file-upload microservice (files.tslop.org) just so his agents could attach proof videos to PRs.

08:04 – 10:38

06 · Reason 3: automation lets others contribute

Boris's third point: domain knowledge that used to live in people's heads can now be encoded as CLAUDE.md rules, comments, and skills, so engineers unfamiliar with a codebase — and non-engineers — can contribute effectively from day one.

10:39 – 13:04

07 · The 'dumb questions' rule, and don't let agents write your CLAUDE.md

Theo's own rule for new hires (ask one dumb question daily) as a diagnostic for missing automation, plus his hard line: never let an agent author your CLAUDE.md or AGENTS.md yourself.

13:04 – 16:26

08 · Testing steering files, and the t3-stack feeling

How to iterate on steering files (shortest prompt first, then patch what breaks), why a CLAUDE.md of file locations isn't a real guide, and the rush of chaining these rules together — which Theo compares to the feeling of building the original t3 stack.

16:26 – 19:12

09 · "This is how you become a senior dev now"

Theo's closing argument: the skill of building environments where code lands cleanly was always the mark of a senior/staff engineer, and it now applies even to solo projects that have grown beyond one person's comprehension.

Atomic Insights

Lines worth screenshotting.

  • Claude Code co-creator Boris Cherny argues automation matters more, not less, in the agent era, because it multiplies an entire fleet of agents instead of just one engineer.
  • If an agent fixes the same bug every time it sees it, that's wasted tokens — turning the fix into a lint rule or CI check automates that whole class of issue away forever.
  • A PR rejected for not following the right framework or architecture pattern is a failure of your team's automation, not a failure of the person who submitted it.
  • Domain knowledge that used to live only in senior engineers' heads can now be encoded as CLAUDE.md rules, code comments, and skills, letting a codebase-naive engineer or a non-engineer contribute on day one.
  • Never let an agent write your CLAUDE.md or AGENTS.md file — it's the one file worth the extra manual effort, because it steers every future prompt anyone sends.
  • Test steering files by sending the shortest possible prompt first and watching what breaks — don't pre-install every skill and plugin before you've felt the actual gap.
  • A CLAUDE.md that's just a list of file locations isn't a good guide; the file should steer the model toward good decisions, not point at where things live.
  • The 'dumb questions' rule — requiring a new teammate to ask at least one dumb question daily — surfaces exactly where a codebase's automation and docs are missing.
  • Once agents write most of the code, even a solo project can exceed what one person holds in their own head, which makes steering documentation a personal necessity, not just a team courtesy.
  • The career skill that used to define staff and principal engineers — building systems where others can land code effectively — now matters more than shipping code fast yourself, and you can practice it solo.
Takeaway

Why automation got more valuable, not less, in the agent era

WHAT TO LEARN

The lint rules, CI checks, and documentation habits that used to define a great engineer aren't obsolete — they're the exact skill that decides whether an army of agents multiplies your output or just multiplies your mess.

04Reason 1: automation now speeds up an army of agents
  • Automation that used to speed up just you now speeds up every agent in your fleet, so infra and DevX work multiplies instead of adding.
  • Preview environments, once dismissed as unnecessary, are now essential because agent-built code can originate anywhere — the cloud, a background tab, or another machine entirely.
05Reason 2: move fixes into code, not into the agent's memory
  • If an agent has to fix the same class of bug every time it appears, that's wasted tokens; writing it as a lint rule, CI check, or routine automates that class of issue away for good.
  • Custom one-off tooling that never justified the build time by hand — like a file-upload microservice just so an agent could attach a video to a PR — now pays for itself because agents hit the problem constantly.
06Reason 3: automation lets others contribute
  • Domain knowledge that used to live only in senior engineers' heads can now be encoded as CLAUDE.md rules, code comments, and skills, so agents and new hires can navigate a codebase they've never seen.
  • A PR getting rejected for not following the right framework or architecture pattern is a failure of your team's automation, not a failure of the person who submitted it.
07The 'dumb questions' rule, and don't let agents write your CLAUDE.md
  • Require every new teammate to ask at least one 'dumb question' a day — their confusion is free data about exactly where your codebase's automation and docs fall short.
  • Never let an agent write your CLAUDE.md or AGENTS.md — it's the one file worth the extra manual effort, since it steers every future prompt anyone sends.
  • Steering files can do more than describe the codebase — you can instruct the model to push back and refuse specific requests, and it will.
08Testing steering files, and the t3-stack feeling
  • Don't pre-install every skill and plugin before you start — send the shortest possible prompt first, watch what goes wrong, and only then encode the missing context into your steering files.
  • A CLAUDE.md that's just a list of file locations isn't a good guide; the file should steer the model toward good decisions, not just point at where things live.
09"This is how you become a senior dev now"
  • The skill of building environments where code lands cleanly has always mattered more than shipping code fast — it used to show up only on teams, and now it matters even on solo projects.
  • Once agents write most of your code, a solo project can exceed your own comprehension, which makes steering documentation a personal necessity, not just a team courtesy.
Glossary

Terms worth knowing.

CLAUDE.md
A markdown file at the root of a codebase that gives Claude Code standing instructions and context for how to work in that project.
AGENTS.md
A generic, tool-agnostic version of the same idea — a file of standing instructions any AI coding agent reads before working in a repo.
Lint rule
An automated check that flags code style or quality problems before it's merged, without a human having to review for that issue manually.
CI (Continuous Integration)
An automated pipeline that builds and tests code every time it's pushed, catching failures before a human has to.
tRPC
A tool that lets frontend code call backend functions directly with full type safety, without hand-writing a separate API layer.
Prisma
A tool that turns a database schema into typed functions your application code can call directly, instead of writing raw queries by hand.
t3 stack
Theo's own popular opinionated starter template for web apps, combining Next.js, tRPC, and Prisma to give end-to-end type safety out of the box.
Playwright
A browser automation tool used to write end-to-end tests that click through a real, running web page like a user would.
Resources

Things they pointed at.

02:17toolBlacksmith ↗
06:09toolfiles.tslop.org (Theo's custom Cloudflare file-upload service) ↗
00:00linkBoris Cherny's X post (@bcherny)
12:16productt3.gg / t3 stack
Quotables

Lines you could clip.

12:28
“Do not let your agents write your CLAUDE.md or AGENTS.md file. That is where it's worth putting the extra effort in.”
sharp, standalone rule with an obvious contrarian edge→ IG reel cold open↗ Tweet quote
17:51
“I would argue... the skill of making environments where code can be landed most effectively is a much bigger skill than actually landing the code yourself.”
reframes what 'senior engineer' means in one line→ TikTok hook↗ Tweet quote
18:13
“Now with agents, even my solo projects are way beyond my own comprehension.”
surprising, personal admission that lands the whole video's thesis→ newsletter pull-quote↗ Tweet quote
03:48
“One I talk about a lot from when I was at Twitch was the test that caught failures before almost anything else.”
sets up a concrete, curiosity-driving story→ TikTok hook↗ Tweet quote
The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.

analogystory
00:00Engineering'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 Versus Code and Atom and even Sublime Text where I got started. And when I started my channel with the t three stack, that blew up too.
00:15I had so much fun with this type of work, trying to get my environment and my setup and the way I built exactly right. And I could fully understand why people who cared about these things kinda feel left behind. That was such a fun part of the job, and it's gone now.
00:30Well, 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 pilled.
00:41Obviously, he's a big fan of using Claude to do most, if not all, of his work. And he's also had some 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.
00:52But 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, and I think he did a great job justifying the why here.
01:13This video has two core audiences I want to address. 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 setting up the world the way they want it when they work. But the second audience is arguably more important.
01:29It's the people who already got over this line and wanna help their friends do it. So what I'm saying is this video is kinda for me. I have a lot of friends who haven't quite had this all click yet, but just because everything's changed doesn't mean it isn't fun still.
01:41In fact, I've felt more clever and had more fun than I ever have as a developer in my entire career, 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.
01:55You 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, then you're sitting waiting again.
02:10Wouldn'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?
02:26Oh, I spoiled it again, didn't I? Yeah. Blacksmith fixes all of these issues.
02:30Their 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.
02:46Finding 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.
03:01We've run almost 3,000 jobs on Blacksmith in the last seven 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.
03:12Give it to them today at soidiv.link/blacksmith. So I'm gonna have a lot to say myself here, but I wanna get started with Boris' post because it catches a lot of the same core points I wanna make, and I really like how he put it. Something I've been thinking about.
03:25In 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 end to end tests so they don't need to smoke test the app manually. 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.
03:48These 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 end to 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.
04:06But 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 Playwright that had a browser underneath that already had the cookies for these accounts signed in.
04:25One 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.
04:44And 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.
04:55It's true for a number of reasons. First off, the Infer and Developer Experience automations speed you up.
05:01And 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.
05:10A 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 pushback when I would push these things back in the day. I remember how much I loved preview environments with tools like Vercel, and how people would push back on me saying, Theo, you care too much.
05:29Nobody 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.
05:47And 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. 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.
06:02On 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 a PR, but you can't do that with the CLI or any of the tools that update PRs programmatically. So I ended building my own custom file upload skill with my own service I put up on Cloudflare called files.tslop.org with a key that I put on all of my different machines on my fleet.
06:25And now these machines are able to upload a file and then post the line inside of the PR. It's so nice. And I'm gonna be honest, the amount of fun I have building these one off things is way higher than I expected.
06:38The 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 an environment for your team and watching them use the things and have them work really well.
06:54But 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.
07:02If 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 automations and refinement work. The way you put it here, actually really like.
07:18He'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, but now, let's go. Yeah, it's great.
07:30And even cooler, most teams are more willing to let you spend time on this stuff now. Previously, if you spent three days working on your VimConfig, your team would be very upset with you and your boss might be concerned.
07:40Now that's not the case. Now there's more buy in to do these types of experiments, and I've had so much fun with it. In fact, if I 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.
07:58Now they don't have to anymore. And that's really exciting. Boris' next point is one of my favorites.
08:04Moving 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.
08:18This 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.
08:26Engineers have been doing this for a long time. Yeah. This is one of the things I love the most about building with AI.
08:32There 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 Coder View.
08:48That 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.
09:04I literally was just talking about how I built a microservice on Cloudflare so that my agents could upload things to it via a markdown file. 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.
09:21Now 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.
09:32Third, and most importantly, automation makes it possible for others to contribute to the code base more easily. Increasingly, what I am seeing is engineers are contributing to code bases on day one because Claude can navigate the code base for them, and that non engineers are able to contribute to a code base as effectively as the engineers can.
09:49This 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.
10:02What's changed thanks to agents is that the domain knowledge can be encoded as infrastructure and is no longer limited to what is expressible in Lint rules and types and tests. Capture nearly all domain knowledge, encoded as code comments and skills and ClotMD rules and memories.
10:17If I put up a PR for an iOS codebase I don't know and Decoder Viewer 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.
10:39That 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 code base 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.
11:03And 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's not done yet because those dumb questions help unblock them, is great and all.
11:30But 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.
11:50I'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 code base in a way that others can contribute and understand.
12:06This is why I made the t three 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. 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.
12:23Because 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.
12:34That is where it's worth putting the extra effort in. That's how you'll understand what leads to different behaviors in your agent. 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.
12:50I'm actually planning a big overhaul for all of this inside of t three code very soon because I've been a little annoyed at some of the behaviors that it has, especially when you're developing against t three 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 everything they should ever know, rather to get them feedback when they're doing things wrong, both for the agent and for your potential teammate that are contributing as well.
13:19You 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.
13:36It'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 t three 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 end to 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.
14:16That 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 be once every few years at best before. Now I get things like that almost every day, and it's so, so cool.
14:31I 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 code base with zero additional context from the prompter.
14:45This sounds crazy, and at the same time, it's a natural extension of the stuff engineers have always done, 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 code base can contribute more easily.
15:09I will say I have a very convenient cheat for this part, which is that my preferences are all public information because I'm popular. So if I put in my agent m d or claud m d, build this the way Thea would like it built, it can usually figure things out. And if it can't, just say Matt Pocock instead, and it does.
15:25Seriously though, it's really fun to figure out how this all works. 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 AgentMD, 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.
15:49And 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 everything and try to force the team to do the same thing.
16:10I'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.
16:18Don'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.
16:38If your ClotMD or AgentsMD are just lists of where things are in the code base, that's not a good guide. Those files should steer the model towards success, not towards specific lines of code.
16:49I 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.
17:03If 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.
17:24And 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. These skills are super valuable, and if you can build them, they will help you level up your career massively.
17:44Even 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.
18:00But my huddest 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.
18:10It'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 because I knew how they worked.
18:21I 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.
18:34And that has allowed me to continue leveling up here. And if you want to keep growing in your career, you wanna 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.
18:48Send it to some coworkers 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. And hopefully, maybe, just maybe, this video will get a couple more people over that line.
19:02Because 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, peace nerd.
The Hook

The bait, then the rug-pull.

Theo opens by admitting what a lot of longtime developers feel: the joy of tinkering with your editor, your lint rules, your CI has quietly disappeared. Then he pivots to a post from Claude Code co-creator Boris Cherny arguing the opposite — that instinct isn't dead, it just got a lot more leverage.

Frameworks

Named ideas worth stealing.

03:15list

Boris Cherny's three reasons automation matters more now

  1. Infra/DevX automation speeds up every agent in your fleet, not just you
  2. Moving a fix into code (lint rule, CI step, routine) automates a whole class of issue away, saving tokens and avoiding missed cases
  3. Automation lets others — engineers new to the codebase and non-engineers — contribute as effectively as the original team

The three-part argument, read verbatim from Boris Cherny's X post, for why automating your own work is a bigger lever now than before agents existed.

Steal forjustifying time spent on internal tooling, CI, and CLAUDE.md/AGENTS.md work to a skeptical team or manager
11:41concept

The dumb questions rule

Theo requires every new hire to ask at least one 'dumb question' a day. It's not just onboarding kindness — the questions map exactly where the codebase's documentation and automation are missing, which is now the same map you'd use to write a better CLAUDE.md.

Steal foronboarding new engineers, or diagnosing what's missing from your project's AGENTS.md
CTA Breakdown

How they asked for the click.

VERBAL ASK
02:17link
“soydev.link/blacksmith”

Woven into a rhetorical setup about slow CI ('wouldn't it be great if...') before naming the sponsor — a soft-sell pattern rather than a hard interrupt.

MENTIONED ON CAMERA
02:17toolBlacksmith ↗
06:09toolfiles.tslop.org (Theo's custom Cloudflare file-upload service) ↗
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
OTHER LINKSAlso linked in the description.
Storyboard

Visual structure at a glance.

open
hookopen00:00
sponsor
ctasponsor02:17
reading the post
valuereading the post03:15
custom skill story
valuecustom skill story06:09
domain knowledge as infra
valuedomain knowledge as infra08:04
don't let agents write CLAUDE.md
valuedon't let agents write CLAUDE.md12:28
senior dev take
valuesenior dev take17:29
Frame Gallery

Visual moments.

open00:01Frame at 00:21 from Claude Code's creator has some really good advice00:21Frame at 00:31 from Claude Code's creator has some really good advice00:31Frame at 00:50 from Claude Code's creator has some really good advice00:50Frame at 01:04 from Claude Code's creator has some really good advice01:04Frame at 01:13 from Claude Code's creator has some really good advice01:13
open00:01Frame at 00:21 from Claude Code's creator has some really good advice00:21Frame at 00:31 from Claude Code's creator has some really good advice00:31Frame at 00:50 from Claude Code's creator has some really good advice00:50Frame at 01:04 from Claude Code's creator has some really good advice01:04Frame at 01:13 from Claude Code's creator has some really good advice01:13Frame at 01:33 from Claude Code's creator has some really good advice01:33Frame at 01:48 from Claude Code's creator has some really good advice01:48Frame at 02:02 from Claude Code's creator has some really good advice02:02sponsor02:17Frame at 02:37 from Claude Code's creator has some really good advice02:37Frame at 02:45 from Claude Code's creator has some really good advice02:45Frame at 03:00 from Claude Code's creator has some really good advice03:00Frame at 03:14 from Claude Code's creator has some really good advice03:14reading the post03:28Frame at 03:43 from Claude Code's creator has some really good advice03:43Frame at 04:04 from Claude Code's creator has some really good advice04:04Frame at 04:06 from Claude Code's creator has some really good advice04:06Frame at 04:26 from Claude Code's creator has some really good advice04:26Frame at 04:40 from Claude Code's creator has some really good advice04:40Frame at 04:55 from Claude Code's creator has some really good advice04:55Frame at 05:09 from Claude Code's creator has some really good advice05:09Frame at 05:24 from Claude Code's creator has some really good advice05:24Frame at 05:38 from Claude Code's creator has some really good advice05:38Frame at 05:53 from Claude Code's creator has some really good advice05:53Frame at 06:07 from Claude Code's creator has some really good advice06:07Frame at 06:21 from Claude Code's creator has some really good advice06:21custom skill story06:36Frame at 06:50 from Claude Code's creator has some really good advice06:50Frame at 07:04 from Claude Code's creator has some really good advice07:04Frame at 07:19 from Claude Code's creator has some really good advice07:19Frame at 07:33 from Claude Code's creator has some really good advice07:33Frame at 07:48 from Claude Code's creator has some really good advice07:48domain knowledge as infra08:01Frame at 08:16 from Claude Code's creator has some really good advice08:16Frame at 08:31 from Claude Code's creator has some really good advice08:31Frame at 08:45 from Claude Code's creator has some really good advice08:45Frame at 09:04 from Claude Code's creator has some really good advice09:04Frame at 09:14 from Claude Code's creator has some really good advice09:14Frame at 09:27 from Claude Code's creator has some really good advice09:27Frame at 09:43 from Claude Code's creator has some really good advice09:43Frame at 09:57 from Claude Code's creator has some really good advice09:57Frame at 10:12 from Claude Code's creator has some really good advice10:12Frame at 10:26 from Claude Code's creator has some really good advice10:26Frame at 10:38 from Claude Code's creator has some really good advice10:38don't let agents write CLAUDE.md10:55Frame at 11:09 from Claude Code's creator has some really good advice11:09Frame at 11:24 from Claude Code's creator has some really good advice11:24Frame at 11:38 from Claude Code's creator has some really good advice11:38Frame at 11:52 from Claude Code's creator has some really good advice11:52Frame at 12:07 from Claude Code's creator has some really good advice12:07Frame at 12:21 from Claude Code's creator has some really good advice12:21Frame at 12:36 from Claude Code's creator has some really good advice12:36Frame at 12:50 from Claude Code's creator has some really good advice12:50Frame at 13:04 from Claude Code's creator has some really good advice13:04Frame at 13:19 from Claude Code's creator has some really good advice13:19Frame at 13:33 from Claude Code's creator has some really good advice13:33Frame at 13:48 from Claude Code's creator has some really good advice13:48Frame at 14:02 from Claude Code's creator has some really good advice14:02Frame at 14:16 from Claude Code's creator has some really good advice14:16Frame at 14:31 from Claude Code's creator has some really good advice14:31Frame at 14:45 from Claude Code's creator has some really good advice14:45Frame at 15:00 from Claude Code's creator has some really good advice15:00Frame at 15:14 from Claude Code's creator has some really good advice15:14Frame at 15:28 from Claude Code's creator has some really good advice15:28Frame at 15:43 from Claude Code's creator has some really good advice15:43Frame at 16:00 from Claude Code's creator has some really good advice16:00Frame at 16:12 from Claude Code's creator has some really good advice16:12senior dev take16:26Frame at 16:40 from Claude Code's creator has some really good advice16:40Frame at 16:55 from Claude Code's creator has some really good advice16:55Frame at 17:09 from Claude Code's creator has some really good advice17:09Frame at 17:24 from Claude Code's creator has some really good advice17:24Frame at 17:38 from Claude Code's creator has some really good advice17:38Frame at 17:52 from Claude Code's creator has some really good advice17:52Frame at 18:07 from Claude Code's creator has some really good advice18:07Frame at 18:21 from Claude Code's creator has some really good advice18:21Frame at 18:36 from Claude Code's creator has some really good advice18:36Frame at 18:51 from Claude Code's creator has some really good advice18:51Frame at 19:06 from Claude Code's creator has some really good advice19:06
Watch next

More from this channel + related breakdowns.

43:15
Theo - t3․gg · Tutorial

A proper guide to Fable 5

How Theo turned a returned, unmetered Claude release into a five-and-a-half-hour unattended agent run that cleared a month of stalled pull requests for about $150.

July 6th
Chat about this