30:40Theo - t3․gg · Tutorial
Mythos is here, it's time to start tokenmaxxing
A 30-minute field report on burning $5,400 of subsidized AI inference in ten days — and what actually came out of it.
June 12thThe argument in one line.
The quality gap in AI-assisted coding comes not from better prompts but from three compounding system habits: planning before any code runs, a CLAUDE.md that self-corrects after every mistake, and a verification loop that forces the model to check its own work.
Read if. Skip if.
READ IF YOU ARE…
- A non-technical builder using Claude Code to ship real production software who wants the practices the tool's own creator uses.
- A developer who has hit a ceiling where Claude keeps repeating the same mistakes session after session.
- Anyone managing a team that shares a Claude Code environment and needs a lightweight system for compounding quality over time.
- Someone who has been over-engineering prompts and wants a simpler mental model for where to invest their energy.
SKIP IF…
- You want a deep technical walkthrough — the host is non-technical and the tips are intentionally abstracted.
- You are already familiar with plan mode, CLAUDE.md, and slash commands from Anthropic's own documentation.
The full version, fast.
Boris Cherny built Claude Code and shares his workflow publicly across tweets and interviews. Five principles drive quality: start every feature in plan mode and refine until solid; maintain a short CLAUDE.md that captures every mistake as a permanent rule and delete it when bloated; give Claude a verification loop for backend logic while you handle the UI; package repetitive prompts into slash commands; and stop optimizing prompts — invest in CLAUDE.md and skills instead, because that context compounds while the model improves for free.
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 →Where the time goes.
00:00 – 00:36
01 · Intro
Host credentials and promise: five tips from Claude Code's creator plus personal application.
00:36 – 07:46
02 · Tip 1: Plan Mode
Start in plan mode, iterate until solid, then switch to auto-accept. Every individual feature gets its own planning step. Live demo on community platform. Starter prompt provided.
07:46 – 13:14
03 · Tip 2: CLAUDE.md (The File That Learns)
CLAUDE.md as compound engineering loop. Keep it short due to lost-in-the-middle effect. Host adds activity.md and scratchpad.md for cross-session progress tracking. Agent routing table pattern shown.
13:14 – 16:05
04 · Tip 3: Give Claude a Verification Loop
Boris's #1 tip: feedback loop gives 2-3x quality. Split verification — Claude handles automated checks, human handles browser UI. CLAUDE.md rule template provided.
16:05 – 17:35
05 · Tip 4: Inner Loops, Commands and Skills
Package repetitive workflows as slash commands in .claude/commands/. Commands vs skills analogy: cook the cake vs the full recipe. Bootstrap prompt to let Claude identify your repeating patterns.
17:35 – 18:55
06 · Tip 5: Never Bet Against the Model
Bitter Lesson: general models always win. Stop optimizing prompts; invest in CLAUDE.md and skills because they compound and nobody else can copy your specific session history.
18:55 – 19:35
07 · Outro and CTA
Like, follow, free Skool community link, inner circle application.
Lines worth screenshotting.
- A good plan lets Claude one-shot the implementation — time in plan mode compounds directly into fewer correction loops.
- Treat CLAUDE.md as a compound engineering loop: every mistake Claude makes becomes a permanent rule so it never repeats.
- Boris Cherny's own CLAUDE.md is only a few thousand tokens — when it gets bloated, delete it entirely and start fresh.
- LLMs forget content in the middle of long documents; a short CLAUDE.md beats a thorough one every time.
- A verification feedback loop produces a 2-3x quality jump — that number comes from the engineer who built Claude Code.
- Verification splits by competency: Claude handles lint, type-checking, and unit tests; humans handle the browser UI.
- Every repeating workflow deserves a slash command — Boris uses /commit-push-pr dozens of times per day.
- A slash command is 'go cook the cake'; a skill is the full recipe with temperatures and timings.
- The Bitter Lesson says the more general model always beats the more specific one — so prompt scaffolding built today is overhead in six months.
- Stop optimizing prompts. The model improves for free. Your CLAUDE.md with your specific session history is the one thing nobody else can copy.
- Every model upgrade means rules that were critical six months ago are now built into the model itself.
- An agent routing table in CLAUDE.md tells Claude which sub-agent to use for which task, preventing it from reaching for the wrong tool.
Five habits that make Claude Code actually work.
WHAT TO LEARN
Quality in AI-assisted development comes from systems that compound over time, not from smarter prompts written in the moment.
- Starting in plan mode before any code is written reduces correction loops — LLMs predict based on context, so a detailed plan is direct input quality control.
- CLAUDE.md works as a self-correcting memory: every mistake Claude makes becomes a rule that prevents the same mistake in every future session.
- Keep CLAUDE.md deliberately short. The lost-in-the-middle effect means a 500-line file gives you less reliable behavior than a 100-line one.
- A verification loop — any mechanism that lets Claude check its own output — reliably multiplies quality without requiring more complex prompts.
- Split verification by competency: automated code checks (lint, types, tests) belong to the agent; UI judgment and feel belong to the human.
- Repetitive prompts should become slash commands stored in .claude/commands/ — the filename is the command, the file is the prompt, no further setup required.
- Prompt scaffolding has a shelf life. The model improves continuously, so specific workarounds become obsolete; persistent context in CLAUDE.md and skills does not.
- Your project context is a genuine competitive moat — anyone can paste the same prompt, but nobody else has the accumulated session history encoded in your CLAUDE.md.
Terms worth knowing.
- Plan mode
- A Claude Code operating mode (activated by Shift+Tab twice) where the model plans without executing changes, allowing iterative refinement before any code is written.
- Auto-accept edit mode
- A Claude Code mode where the model applies edits automatically without pausing for confirmation, used after a solid plan is in place.
- CLAUDE.md
- A markdown file in the root of a project that Claude Code reads automatically at the start of every session, used to store persistent rules, architecture context, and learned corrections.
- Compound engineering loop
- The practice of writing every Claude mistake into CLAUDE.md as a permanent rule so the mistake never recurs across future sessions.
- Lost in the middle effect
- An observed LLM behavior where content in the middle of a long document is recalled less reliably than content at the start or end, making shorter context files more effective.
- Inner loop
- Boris Cherny's term for a task performed many times per day that should be packaged as a slash command to avoid re-prompting.
- Slash command
- A saved prompt stored as a markdown file in .claude/commands/; the filename becomes the command name and the file contents are the prompt that runs when invoked.
- Bitter Lesson
- An essay by Rich Sutton arguing that general-purpose learning always outperforms domain-specific engineering, cited by Boris Cherny as the rationale for not over-investing in prompt scaffolding.
- Idempotency
- A property of an operation that produces the same result whether executed once or many times; important when users click buttons rapidly and risk triggering duplicate API requests.
- Sub-agent
- In Claude Code, a specialized agent instance the orchestrator delegates tasks to — such as a front-end or back-end agent — configured via the agent routing table in CLAUDE.md.
Things they pointed at.
Lines you could clip.
12:25
“If Claude has that feedback loop, it will 2-3x the quality of the final result.”
18:15
“Never bet against the model.”
18:45
“Nobody else has your CLAUDE.md with the lessons your sessions taught it.”
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.
metaphoranalogy
00:00Boris Cherny, the creator of Cloud Code, has been sharing everything about how he uses it, threads, interviews, public posts. And so I went through all of it and pulled the most important bits. And after working with enterprise companies like Microsoft and Datacamp, spending hundreds of hours inside Cloud Code and building full production apps with it.
00:16I'm giving you his best tips for getting closer to mastering Cloud Code and how I've been applying these in my own work. And despite his engineering background, don't worry because every one of these works whether you write code or not. Let's get straight into it.
00:31So tip number one, plan mode. Okay.
00:34It's probably the most underrated tips out there and I think people are not using it enough. So this is a thread where he talks about this exact thing. So for him, most sessions start in plan mode, shift tab twice to get to that mode on Cloud Code.
00:48If my goal is to write pull request, I will use plan mode and go back and forth with Cloud until I like its plan. From there, I switch on to auto accept edit mode, and Cloud usually can one shot it. A good plan is really important.
00:59So what he's mentioning here, this tip over here is one of the ones that I condone the most. And in fact, I use plan mode every time.
01:08Every time that I open Cloud Code and want to develop a new feature. And it should be like this because of how coding agents work. Okay?
01:15Think about it. Coding agent is essentially a large language model in the background, and LLMs are statistical machines. They are going to predict based on what you're asking for.
01:24It's going to look through its training data and look prompts that are similar to the ones that I mentioned. And based on that and a few other things, it's going to generate the code that satisfies that the most.
01:34But the problem is since NLMs work on probability, there's always a chance that the code generation or parts of the code generation are going to be somewhat wrong.
01:43And essentially, our goal is to try to minimize that room for error. And one of the ways in which we can do this is by giving it enough context, and the second way is by giving it accurate context.
01:56So the first thing is just to go through back and forth. Okay? Over here, you just wanna give it as much context as possible.
02:01So you wanna ask any questions that you have. Okay? The first thing is just make it clear to yourself what you're building.
02:08Okay? That's very important. And the second part to that is just to understand if what we're building, if we're building in the right way, and it's the right strategy given what we're working with.
02:17At least I'm talking from a software development point of view. For example, I might be building a recording tool. Right?
02:23Recording software tool. And I wanna understand how the recording aspect works. How does the camera turn on?
02:30How does that get displayed and streamed on a screen? Obviously, I don't know anything about it. So my idea would be on this back and forth to research other competitors, see how they do them, and see if we can extract, you know, the type of architecture that they're using, the infrastructure they're using, what databases they're using.
02:47Right? It might be some databases that are better for storing video rather than text, for example.
02:53So all these questions, it's good to ask at the start. And then once we are happy with all the questions and we're happy with all the context, uh, that we give it, perhaps we have some preferences with how we want the software tool to be built and that can change the plan drastically. But anyways, once you get that hour all the way, now we're like, okay.
03:10I'm pretty happy. Now let's go ahead and make the plan after I I give it all the context. Now it's gonna make the the plan, and then we're gonna revise it.
03:17We're gonna revise it thoroughly, especially if you're a nontechnical person like me. You might find some technicalities that you don't understand. And so in this plan mode, it's also the best time to answer any of those questions that you might have on the plan.
03:29Okay? So make sure it's clear for you. And once the plan is good enough, then there's a higher probability that the execution is gonna go very, very, very well.
03:40So I thought I'd show you an example on what good planning and execution looks like. And here I am showing you a real project that I'm working on. It's my own community platform where I will be hosting my cohorts, um, my private community soon as well.
03:55And this is not a mock up project like most videos show you when they talk about Glockcode. You know, they they show you a little standalone feature or they usually tend to build websites, which are really simple. This is a real functional project that's in production as well.
04:10So you can actually check it out, but I'm not giving you the URL yet. Okay? Mhmm.
04:14So right now, I'm just testing it with friends. But the whole point with this is that you probably have been in school or some other community platform. You can see so many moving things.
04:22It's not a AI generation tool where you put in a prompt and then you create a video. It's not an app like that. There's a lot of moving parts.
04:30And for every single moving part k. For example, we're opening the post here. We have a We're recording.
04:35We We have an audio feature as well. We have a comment section feature. Okay?
04:40So for every single little thing that you see on the screen, let's say for creating the post and adding stuff on a post and all this. Okay? This by itself has its own planning step.
04:50Adding the text has its own planning step. Okay? Deleting the post has its own planning step.
04:57Okay? The comment section has its own planning step. You see, for every individual feature, for every small feature, we have a decent amount of planning for it.
05:06It's obviously good that you have a general planning, okay, for how the overall software is going to work. But then inside that, for every little batch of features that you work on, every single feature has to have its own plan.
05:19Because even though the features look small, there's a lot of very little things that you have to take account for. So for example, I'm gonna be very, very, very quick here. When you like the post and then you don't like it.
05:33Okay? When you click it, it's going to trigger an API request and then I'm gonna trigger an API request to also remove that from the database.
05:42So we're reading directly to the database. So you have to think, for example, as well, what happens if I click too quickly? Okay.
05:50That's called idempotency. So what happens if I click too quickly? What's gonna happen?
05:53Is it's gonna break? Okay? So there's a lot of edge cases that you have to take into account that comes with testing as well.
06:00But it's it's good that if you can cover that on the planning stages, that's good. A lot of the planning stages involves as well the UI, how that's going to look like, okay, the positioning of it, and so on and so on. Okay?
06:11And you get the idea. And to quickly help you out, here is a specific prompt you can use to kick start any project. Before we start building, interview me about this.
06:19What are the core problems this solves? Who is this for? What the success look like for a project like this?
06:23And what should this not do? Summarize it back to me before we write any code, and that should get you kick started with that back and forth I was talking about before. Now tip number two, the clod dot m d file.
06:33This is probably the most important file in your project. And so this Claude markdown file sits in the root of your project folder. And so Claude reads it automatically every time you start a session.
06:44Okay? You don't need to paste it. You don't need to remind Claude code.
06:47It's just gonna go ahead and read it. And here is Boris' tweet on this.
06:51So our team shares a single Cloud MD for the Cloud Code repo. We check it into git, the whole team contributes multiple times a week. Anytime we see Cloud do something incorrectly, we add it onto the Cloud MD so Cloud knows not to do it next time.
07:02Other teams maintain their own Claude MDs. It is each team's job to keep theirs up to date. And that's what he calls the compound engineering loop.
07:10Every time Claude does something wrong, the fix gets written into Claude. M d as a permanent rule. And I had to stop and admire how efficient his claw dot m d file is.
07:20I mean, look at it. There is no verbosity at all over here.
07:23There's no long descriptions. He puts he enumerates number one, number two, number three, and inside those, he just has commands, which is so efficient. I mean, one point that I have to make is that this is a development workflow as well, and he's obviously a developer, so that's why he's able to do this.
07:39But the whole point with this is that try to be as concise as possible. And I'll show you how mine looks like as a non technical person. We have Telet and we have the project and then we mention the files.
07:52Right? We mentioned the markdown files. So we just let Glocko know that they exist and it should use it because then we're gonna mention it below.
08:00We mentioned the text stack really quickly and then we mentioned progress tracking as well. So this is, I would say, a step forward to the basic ClotUpd file that people use. So this is something that I use and works very well for me.
08:12I want Cloud Code to have some sort of progress tracking so that we can persist the progress across sessions. And my version of it is to have two files, the activity dot m d file and the scratchpad dot m d file.
08:25Okay? And you can see the description of what each does and a few more things. Right?
08:29And so I don't wanna get too much in-depth with this cloud dot m d file because it gets a bit developer heavy. But the main things that you must have is the project context. Okay?
08:36What the project is about, architecture, the overall objective, maybe perhaps some user flows as well. It helps a lot.
08:43Some conventions, do's and don'ts. Okay? And as I say, you can keep asking Cloud Code and it will get better and better and better, keep adding better rules.
08:51So So those are the two basic things and additions that I personally make are adding some progress tracking rules. Okay? And this is a good example of the compound loop.
09:00So I like to add, as I said here, the activity dot m d file, the scratch pad dot m d file. Okay? And I mentioned them specifically.
09:08So I don't have to add the whole context of the activity dot m d file scratch pad. I just say, hey, you know, if you need to do x or y or you need to update on progress, refer to the at activity. Md file or scratchpad.
09:20Md file or just mention the the path straight away, right, docs and what. Clot is already smart enough to figure out, um, what files we're talking about. And yeah.
09:28When I mean I mean, other things could be agent routing table. So you're treating it as a as a human essentially.
09:36So you're basically are telling CloudCall, okay. So if you need to deal with UI components, layouts, design, use the Magic NCP and the front end agent. Be specific about these so it doesn't end up using some other tools and agents that we don't need.
09:49And when I talk about agent, it's more of a sub agent. Okay? So we're essentially whenever we're having a conversation, we're actually talking to an orchestrator.
09:57And then the orchestrator can talk to different sub agents. So we have this front end sub agent, back end sub agent. Okay?
10:03And yeah. But anyways, as I said, I don't wanna get too specific. If you have questions about this, make sure to ask them in the comments below or get into my free school community.
10:12And here is the counterintuitive part with the ClawDettery file. You might think, oh, I'll just add as much context as possible. Well, if you actually watch more of Boris, you'll see that in one of his interviews, Boris says that their Cloud.
10:25Md file is actually pretty short. So our Cloud. Md is actually pretty short.
10:29I think it's like couple thousand tokens, maybe something like that. It's a couple thousand tokens. And his advice when it gets bloated, just delete the entire thing and start fresh.
10:39And you'll see here that my CloudMD file is yours 94 lines. Okay?
10:43And I could actually make it shorter. And my argument to why we keep ClawdMD files pretty compact and short is because LLMs suffer something called the lost in the middle effect, which is if you give an LLM a piece of text to analyze, as you increase the size of that text or you increase the number of tokens in that document, you'll see that if you ask questions about the document that the LLM tends to forget what's in the middle and remember most stuff about the start of the document and at the end of the document.
11:11And so his main reasoning is to do the minimal possible thing to get the model on track because every model upgrade, you'll need less because rules that were critical six months ago are now built into the model. So the model just gets smarter over time. Quick announcement before I continue.
11:26After working with Microsoft and Datacamp, I'm finally putting together an inner circle where I will show you how to master Cloud Code energetic engineering, probably the highest leverage skill you can learn in this decade. And so whether you're a business owner automating your operations, a manager upscaling your team, or someone who wants to build automations that streamline your own job, this is for you.
11:46And the best part is that you do not need to be technical. And so if that sounds like you, I'll leave a link for you to apply in the description below. I'll see you there.
11:53And now tip number three. And if you take one thing from this video, make sure to take this one because Boris calls it his number one tip, and I'll read you the tweet. A final tip.
12:01Probably the most important thing to get great results out of Cloud Code. Give Cloud a way to verify its work. If Cloud has that feedback look, it will two three x the quality of the final result.
12:09Cloud tests every single change I land to Cloud AI code using Cloud Chrome extension. It opens a browser, tests the UI, and iterates until the code works and the UX feels good. Verification looks different for each domain.
12:19It might be as simple as running a bash command or running a test suite or testing the app in a browser or phone simulator. Make sure to invest in making this rock solid. Two to three x.
12:29That's not from some random tutorial. That's from the guy that built the tool. Okay?
12:32So you would have to trust. So I agree with this tweet. I think this tweet is very valuable as well, especially with the last part where he mentions that verification looks different for each domain.
12:41Because personally, I don't use the Cloud Chrome extension to test the UI UX. Okay?
12:46I find it, in my opinion, pretty whack with the type of software that I'm building. For a lot of the software that I'm building, I tend to be the ideal user. And if I'm not the ideal user, I rather get feedback from the person that would use the tool.
12:59So maybe it is the case that he's talking about more of the technical side. So maybe he has Claude Chrome just going the tool to check if this certain button redirects the app to the right page and so on.
13:11So if that's the case, I guess it works, but most of the tests that I tell Clocko to do are more internal or in the back end. So I ask it to run certain commands. Lin checks, so scanning code for common mistakes, bad patterns on used variables, so just catching dumb errors before I ship any features.
13:26Then we have type checking. If you use TypeScript to catch things like passing a string where a number is expected. Unit tests to test individual functions in isolation, so does this function return the right thing given this input?
13:37Then we have integration tests, build checks, and formatting checks between other things. And so I have Cloud Code run all of that because it catches errors that I would never spot by reading the code myself.
13:48Yeah. So I do that whilst for the front end, I test that myself in the browser because Cloud Code is ingrained at judging how things look or feel. Okay?
13:56And if you're unsure or stuck on where to start with this, try adding this line to your Cloud therm d file. Before you implement any feature, mention how you could verify that feature. Now Cloud should tell you its verification plan before it starts building.
14:10And the best thing is that I don't only use this inside the Claude dot m d file, but I use versions of it when I'm prompting Claude code. Because I said, you should always be skeptical of what Claude code generates, and by verifying it, you'll see that the quality jump is immediate. Now we get on to tip number four, inner loops.
14:28Boris has built this concept he calls inner loops, and these are tasks that you do many times throughout the day. These are very simple prompts that you just probably get to do every single time, and you just package it into this simple slash command. Here is his tweet.
14:40I use slash commands for every inner loop workflow that I end up doing many times a day. This saves me from repeated prompting and makes it so Cloud can use these workflows too. Commands are checked into git and live in dot Cloud slash commands.
14:51For example, Cloud and I use a slash commit push p r slash command dozens of times every day. The command uses inline bash to precompute guest status and a few other pieces of info to make the command run quickly and avoid back and forth with the model. That makes a lot of sense.
15:04So basically, any simpler task that you run more than once with a prompt, you just save it as a command, and Boris uses these dozens of times a day. And here is how it works. So the way it works is that you create this commands folder, and inside it, you create these markdown files.
15:18Okay? So this commands folder, you can either add it on the dot cloud folder per project or globally so that it applies to any Cloud Code instance that you open. And this markdown file, the file name becomes the command name and the contents of the file are just the prompt that you run every time.
15:35That's the entire setup. Now you might be naturally confused or curious about the differences between these inner loops or commands and skills. Well, let me explain you.
15:44So a skill goes into much more depth. Think about it as the recipe for a cake. We have all the different tablespoons of ingredients, all the different weights, the temperatures at which things have to be cooked, the way they have to be cooked.
15:58Okay? These are the skills. These inner loops or commands are more generic.
16:02They're simpler. They're just prompts. You could think about it as go ahead and cook the cake.
16:07That's pretty much it. That's all a command or inner loop is. Power with these inner loops or or commands is that we can just run them relatively quickly.
16:15Okay? They barely need any inputs. They're simpler tasks.
16:18Right? Just run the slash command and you just keep going. For some skills, you might need to add some inputs.
16:22Right? Maybe a YouTube URL or something. This shouldn't require any.
16:25And I understand that the concepts of inner loops or commands might be hard to differentiate from the skills concept. And so what I want you to take away from this is that whenever you see a repetitive workflow inside ClockCode in any project, make sure to package it in some way so that you don't have to keep writing the same prompt or give the same instructions to Cloud Code.
16:43That's the main point. But if you still wanna move forward with this, I have a prompt prepared for you. So just write the following inside Cloud Code.
16:51Based on the project I'm working on, what slash commands should I create, what skills should I build, and what rules should I add to my Cloud. Md. I added a cheeky little end to that prompt over there so that you add useful stuff into your Cloud.
17:04Md file as well. And if you type this prompt, then Clod will identify your repeating patterns for you, and this will save you from a lot of pain from repeating yourself all the time on your next Clod Code sessions. And now we get on to tip number five.
17:17This last piece ties everything together. In an interview, Boris talks about something called the Bitter Lesson. It's an essay by Rich Sutton, one of the pioneers of reinforcement learning.
17:26Boris says that they have a framed copy of it on the wall at Anthropic. This other general principle that I think is maybe interesting where you can build for the model and then you can build scaffolding around the model in order to improve performance a little bit.
17:39The core idea is that the more general model will always be the more specific model. And let me explain. What that means for you is that every piece of scaffolding, every micro tweak on every prompt, every prompt hack you build to improve Claude's output will probably be unnecessary in six months because the model just keeps getting better.
17:57And that's not a reason to stop building. It's about where you focus your energy, at least when it comes to agentic coding. And so Boris restates it simply, never bet against the model.
18:06So the idea is to stop over investing in perfect prompts. The prompt that you write today will need less optimization next month because the model underneath you improves for free. So instead, what you wanna do is to invest in your .
18:19That's your cloud.md, your skills, your reference documents, your project context. That's what compounds. And that's what .
18:26Okay? Anybody can paste the same prompts into Cloud because nobody else has your cloud.md with the lessons your sessions taught in.
18:33Nobody else has your skills built from your specific workflows, and that's the real system. And that's it. Those are all the tips that you need to know to get you one step closer to mastering Claude code and agentic coding.
18:44And if you enjoyed the video, please give me a thumbs up and a follow. It really helps the channel a lot. And if you enjoy these kind of videos with the cool motion graphics that I've been testing, let me know in the comments below as well.
18:53I wanna hear because any feedback is good feedback. I'll also leave a link to the school community if you wanna access the free resources that I left in this video and also something very special.
19:06I'll leave a link as well for access to an exclusive inner circle where I'll teach very few of you, k, a reduced number.
19:14I'm looking between 20 to 50 people probably to learn how to master Cloud Code, whether you are a business owner looking to automate their own workflows inside their business or a professional that's looking to upscale themselves with Cloud Code or maybe someone else that is looking to build a software tool, for example, as well.
19:30Okay? So thank you so much, and I'll see you in the next one. Bye.
The Hook
The bait, then the rug-pull.
Boris Cherny built Claude Code and has been sharing his exact workflow publicly across tweets, threads, and interviews. Frank Nillard went through all of it, pulled the five tips that actually matter, and tested each one building real production software as a non-technical founder.
Named ideas worth stealing.
07:46concept
Compound Engineering Loop
Every time Claude does something wrong, the fix is written into CLAUDE.md as a permanent rule so the mistake never recurs.
Steal forAny project where Claude keeps repeating the same category of error across sessions.
13:14model
Verification Split
- Claude: lint, type-check, unit tests, integration tests, build checks
- Human: browser UI testing and feel judgment
Divide verification responsibility by competency — Claude handles deterministic checks, humans handle visual judgment and feel.
Steal forAny agentic coding setup where quality is inconsistent.
16:05analogy
Commands vs Skills (Same Kitchen, Different Depth)
Commands are simple reusable prompts (cook the cake); skills are full-depth procedural recipes with inputs, conditional steps, and specific outputs.
Steal forDeciding where to invest when packaging a recurring Claude Code workflow.
17:35concept
The Bitter Lesson Applied
Rich Sutton's finding that general learning beats specific engineering, restated as: never bet against the model. Invest in persistent context (CLAUDE.md, skills) rather than prompt scaffolding.
Steal forDeciding how to allocate optimization time in any AI-assisted workflow.
How they asked for the click.
VERBAL ASK
18:55product
“I'll leave a link for you to apply in the description below.”
Mid-roll pitch at ~11:24 for inner circle program; outro doubles as second CTA with free Skool community link and inner circle application. Low-pressure delivery consistent with educational tone.
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
Visual structure at a glance.
