Sixteen Claude Code Habits From $31,141 and 1,000 Hours of Use
A creator who says he's burned $31,141 on Claude Code turns that spend into sixteen concrete habits, from running evals on prompts to keeping a backup model on standby.
Posted
2 days ago
Duration
Format
Listicle
educational
Views
80.4K
1.3K likes
57 · 43
Big Idea
The argument in one line.
Claude Code stops being unreliable the moment you stop trusting single outputs, tight step-by-step leashes, and MCP prototypes, and start running evals, definitions of done, and lean custom skills instead.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You already use Claude Code daily and want to cut wasted tokens and inconsistent output quality.
You run or advise a business layering AI into real workflows and need those workflows to be repeatable, not lucky.
You've hit context-window bloat or rising Claude Code bills and want concrete levers to pull.
SKIP IF…
You've never opened Claude Code or a similar coding agent, since this assumes you already know the basic commands.
You want a step-by-step install/setup tutorial; this is optimization advice for people already using the tool.
TL;DR
The full version, fast.
Nick Saraev says he's spent $31,141 and over 1,000 hours on Claude Code, and distills that into sixteen habits ordered simplest to most advanced. The throughline: Claude is non-deterministic, so never trust a first output, run evals instead, and give the model a way to check its own work. Stop maintaining separate skill docs that drift from the code; inline instructions instead. Let Claude write its own prompts, watch what's eating the context window, and loosen the leash by stating a definition of done rather than step-by-step instructions. Diagnose before fixing, prototype with MCP but scale with lean custom skills, run scoped tasks in parallel, and start fresh sessions with a handoff note instead of letting context rot accumulate.
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.
Nick states his spend ($31,141) and hours (1,000+) on Claude Code and previews sixteen habits ordered simplest to most advanced.
00:29 – 03:19
02 · Don't trust the first output
Claude Code is non-deterministic; the same prompt can swing from a great result to garbage across repeated runs, so evals (running a prompt 10x and counting the pass rate) replace gut-check trust.
03:19 – 04:38
03 · Give it a way to check its own work
Treat a first Claude output like a first draft: build in a revision loop (screenshot compare, score, standardized test) so it can catch and fix its own mistakes.
04:38 – 06:38
04 · Let the code be the context
Separate skill docs and notes drift from the code as versions climb; inlining instructions directly into the code keeps the model reading the real source of truth.
06:38 – 08:11
05 · Let Claude write your prompt
State the outcome and audience, then let Claude interview you for the details rather than hand-writing every instruction; Claude is now better at prompt engineering than most humans.
08:11 – 10:11
06 · Watch what's eating your context window
About 30% of a fresh context window is gone before you type anything (system prompt, tools, MCP, memories, skills); check /context regularly and prune or /compact before it fills.
10:11 – 11:54
07 · Loosen the leash
Granular step-by-step instructions and long 'never do X' lists are scar tissue from older, weaker models; state a plain definition of done and let Claude choose its own process, like a contractor.
11:54 – 13:01
08 · Diagnose before you start a fix
Ask Claude to list every problem before touching code, cross off what you don't actually want solved, then hand back only the problems you want fixed.
13:01 – 14:56
09 · MCP servers
MCP connectors are the fastest way to prototype (one click, verify it works), but they're heavy on context at scale; validated MCP workflows should graduate into lean custom skills.
14:56 – 16:50
10 · Run scoped tasks in parallel
Break a build into 4-6 mutually exclusive, tightly scoped tasks and run them simultaneously with one merge step at the end, trading a bit more error rate for real speed.
16:50 – 17:52
11 · Always start fresh with a handoff note
Long sessions accumulate contradictory instructions; ask for a 'summarize where we are' note (done, decisions, next steps, open problems) and hand that to a fresh session instead of continuing.
17:52 – 19:01
12 · Ask side questions with /btw
A dedicated side-question command lets you ask clarifying questions while the main task keeps running, without polluting its context or forcing a wait-then-repeat cycle.
19:01 – 20:53
13 · Fan out and fan in
Delegate research across the search space to cheap subagents in parallel (fan out), then combine their findings into one prompt for a strong model to make the final call (fan in).
20:53 – 22:17
14 · Set up your CLAUDE.md
Structure CLAUDE.md into a summary of what's where (via /init), preferences, capabilities, and lessons learned; re-audit it every model update since stale assumptions quietly bias every decision.
22:17 – 23:52
15 · Keep a backup tool ready
Mirror CLAUDE.md into agents.md so a second tool like Codex can pick up the same project context if Claude Code has an outage or quality dip.
23:52 – 25:21
16 · Have CLAUDE.md learn from its mistakes
When Claude fails, record the positive fix (like 'batch the file reads') instead of only a banned action; ask 'how could you have done that faster with fewer tokens?' after every skill-building session.
25:21 – 25:59
17 · Maker School
Soft pitch for Nick's 90-day accountability program, Maker School, framed with a money-back first-customer guarantee.
Atomic Insights
Lines worth screenshotting.
Claude Code is not deterministic: running the same prompt six times can produce a shipped-quality result once and complete garbage the other five, so the first output is never enough to trust.
Building reliable Claude Code workflows is a statistical research process: run the same prompt 10 times, count how many pass, and only keep a change if the pass rate actually goes up.
Giving Claude a way to check and revise its own work, like a screenshot diff, a Lighthouse score, or a comparison example, raises output quality more than any single prompt tweak.
Skills and notes drift out of sync with the code they describe as version numbers climb, so burying instructions directly in the code as inline comments keeps the two sources from diverging.
Claude is now better at writing its own prompts than most human prompt engineers, so asking it to interview you for requirements beats hand-writing a long prompt yourself.
About 30% of a fresh context window is already spent before you type a word, eaten by the system prompt, built-in tools, MCP connectors, memories, and skills.
MCP connectors are the fastest way to prototype (one click, verify it works), but they're too heavy on context to run in production, so validated MCP workflows should get rebuilt as lean custom skills.
Treating Claude like a contractor with a clear definition of done, instead of an in-house employee needing granular step-by-step instructions, produces better results with current models.
Diagnosing before fixing (list the problems, don't touch code yet) lets you cross off issues you don't actually want solved, instead of paying for a fix-then-undo cycle that costs twice the time and tokens.
Running 4-6 scoped, mutually exclusive tasks in parallel with a merge step at the end is faster than working sequentially, at the cost of a slightly higher error rate.
Starting a new session with a 'summarize where we are' handoff note beats continuing a long thread, because it strips out the contradictory instructions that accumulate over a long conversation.
Asking side questions with a dedicated command while Claude works on the main task avoids polluting context and skips the wait-answer-repeat cycle of interrupting the main thread.
Fanning research out to cheap models and fanning the results into one strong model for the final call gets broader coverage, faster, for less money than having the expensive model do the whole search.
A CLAUDE.md file should be re-audited every time a model updates, since a single stale assumption baked into it, like an old revenue figure, quietly biases every decision the model makes afterward.
Teaching CLAUDE.md the positive fix, like 'batch the file reads', instead of only the negative rule, like 'don't retry the old API', actually changes future behavior instead of just listing past failures.
Keeping a backup coding tool wired into the same project folder, via a mirrored agents.md file, means an outage in one tool doesn't stop the business.
Takeaway
Sixteen habits for reliable Claude Code output
WHAT TO LEARN
Every habit here traces back to one idea: Claude is non-deterministic, so structure, checks, and scoped context matter more than any single clever prompt.
02Don't trust the first output
Claude Code is non-deterministic: the same prompt run six times can swing from a home run to complete garbage, so one good result proves nothing.
Run a prompt as an eval, ten times minimum, count the pass rate, and only keep a change if the new pass rate beats the old one.
03Give it a way to check its own work
Treat Claude's first attempt like a first draft: give it a way to check and revise its own output (a screenshot compare, a score, a test) before you accept it.
A revision loop, even a rough one like a Lighthouse score or a side-by-side example, raises output quality more reliably than tightening the original prompt.
04Let the code be the context
Separate docs and skill notes drift out of sync with the actual code as versions climb, so the model ends up reading a stale spec instead of the real thing.
Inline instructions and comments directly into the code itself so Claude reads the current source of truth every time, instead of a notes file that's still on an old version.
05Let Claude write your prompt
State the outcome and audience you want, then ask Claude to interview you for the details, rather than hand-writing every instruction yourself.
Claude has been trained specifically to prompt other AI teammates, so meta-prompting through it now beats manual prompt engineering for anything beyond a quick one-off ask.
06Watch what's eating your context window
Roughly 30% of a fresh context window is already spent before you type anything, split across the system prompt, built-in tools, MCP connectors, memories, and skills.
Check /context regularly, turn off MCP connectors and skills you're not actively using, and start a fresh instance or run /compact before the window fills up.
07Loosen the leash
Older, tightly-leashed prompting (granular step-by-step instructions plus a wall of 'never do X' rules) is scar tissue from weaker models; current Claude infers most of that on its own.
Replace step-by-step instructions with a plain definition of done: state when the task counts as finished and let Claude choose its own process, like a contractor rather than an employee.
08Diagnose before you start a fix
Ask Claude to list every problem it sees before touching any code, since its idea of 'the problem' won't automatically match what you actually want fixed.
Cross off the problems you don't want solved from that list before asking for the fix, or you'll pay for round two undoing changes you never asked for.
09MCP servers
MCP connectors are the fastest way to prototype a workflow (one click to sign in and verify it works), which is exactly what makes them worth testing first.
Once an MCP-based workflow is proven, rebuild it as a lean custom skill; MCP stays heavy on context and adds a few seconds of startup verification on every boot.
10Run scoped tasks in parallel
Break a build into 4-6 mutually exclusive, tightly scoped tasks (hero section, feedback form, logout bug) and run them simultaneously instead of one at a time.
Parallel scoped tasks trade a slightly higher error rate for meaningfully faster delivery, closed out with one merge step at the end.
11Always start fresh with a handoff note
Long sessions accumulate contradictory instructions ('don't do X' followed three chats later by 'kind of like X'), and the model splits the difference instead of picking one.
Before starting a new session, ask for a summary of what's done, the decisions still open, what's next, and any open problems, then hand that note to a fresh instance.
12Ask side questions with /btw
Interrupting a long-running task to ask 'what does this mean?' forces you to wait for it to finish before you get an answer, then wait again for the original task.
A dedicated side-question command answers educational or clarifying questions without polluting the main task's context, in parallel with the work already running.
13Fan out and fan in
Fan cheap, short-context subagents out to research a topic as widely as possible before committing a strong, expensive model to the final call.
Combine everything the cheap subagents found, plus any hypotheses that go against the mainstream literature, into one mega-prompt the strong model uses to decide.
14Set up your CLAUDE.md
Re-audit CLAUDE.md every time a model updates, even incrementally, since a single stale number (like an old revenue figure) can quietly bias every decision the model makes afterward.
Structure it in four parts: a summary of what's where (generate with /init), your preferences, what it's actually capable of, and lessons learned, told as positives not just banned actions.
15Keep a backup tool ready
Businesses with zero backup model grind to a halt during a Claude Code outage; a mirrored agents.md file in the same project folder is the fix.
Mirror CLAUDE.md into agents.md so any update to one updates the other, and a second tool like Codex can pick up mid-project with the same context.
16Have CLAUDE.md learn from its mistakes
When Claude fails at something, an old API call, a wrong assumption, don't just record the ban; ask 'how could you have done that faster with fewer tokens?' and record the actual fix.
Give CLAUDE.md positive instructions like 'batch the file reads' instead of a growing list of negatives; a well-tuned file can save several hours a week.
Glossary
Terms worth knowing.
MCP (Model Context Protocol)
The standard behind one-click AI plugins and connectors in tools like Claude Code and Codex. Fast to prototype but heavy on context once verified.
Evals
Repeated test runs of the same prompt, scored for pass rate, used to prove a prompt change actually improved output instead of just feeling better on one lucky run.
CLAUDE.md
A project-level instructions file Claude Code reads at the start of every session, where preferences, lessons learned, and definitions of done live.
Context rot
The drop in model quality and rise in cost that happens as a conversation's context window fills with old, contradictory, or irrelevant instructions.
/btw
A Claude Code command for asking a side question without derailing or polluting the context of the main task already running.
Fan out / fan in
Delegating research to several cheap subagents in parallel (fan out), then combining their findings into one prompt for a stronger model to decide (fan in).
/compact
A Claude Code command that compresses the current conversation's context, useful to run proactively rather than waiting for automatic compaction to trigger.
“MCP is typically very heavy on context, and it includes a bunch of silly bullshit you never really wanted in a tool spec anyway.”
profanity plus a specific technical opinion→ TikTok hook↗ Tweet quote
18:55
“If you screwed this up, what you would have done is fix the whole thing, including the too casual bit, and now you'd have had to re-casualize this, which would have taken twice as many steps, twice as much time, and twice as many tokens.”
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.
17px
metaphoranalogy
I've spent over $30 ,000 on Claude Code over just the last few months. These are my real invoices. Feel free to take a look.
I've also spent over a thousand hours on models like Opus 5 .5, Astra, and so on. And in this video, I want to give you guys everything that I wish I knew when I started. Okay, these are not going to be the simplest of hacks, but in order to really squeeze the proverbial wet towel of Claude Code, you do need to get into the nitty gritty.
That said, I've arranged it from simplest to most complex so that regardless of where you are in the scale hierarchy, you guys can get some value. And let's start with the first, which is not to trust the first output. Now, I currently work with a multi -billion dollar business that I think is quite guilty of trusting the quality of the first output, and it's led to some major headaches down the skill chain.
I'll talk a little bit about that later, but to start with, an unfortunate thing that most people don't realize about Clod and other large language models is they are not deterministic systems. To really unpack that, what I mean is if you give it the same prompt multiple times, every time it will give you a different result and sometimes these different results might be a little bit different and other times they'll be completely different not at all even close to the same thing and so let's say you guys are coming up with a sick prompt to i don't know generate scripts for a youtube video or something crazy like that huh well maybe the first time you pass a prompt in it does a really good job Is that enough for you to take that prompt and then save it in your business SOPs and actually standardize your whole company with that?
No, you can't trust the first output. The reason why is if you were to run that same output, let's just say six times, the first time that you ran it, you'd go, oh my God, this is awesome. But the second time you might very well say, this is absolute crap.
This sucks. Maybe the third time it's okay. But the fourth and fifth times you go, what the hell is going on here?
Claude, did you fall down some stairs? Before finally the sixth time, you know, reels you back. What ends up happening with prompts is.
Because there's minor deviations, essentially, in the statistical nature of models, the first time that you run it, you might end up in a maximum, which is a high -quality situation. But the second, third, or fourth times you run it, you might end up... in a minimum, which is a low quality, low value output situation.
And so your job as a prompt engineer, really your only job as somebody building systems, maybe for yourself or for other companies with Claude and other models is just to minimize the peaks and the troughs of, you know, your own usage to basically standardize it so that you know what you're getting every time you ask it for something.
Okay. So the way you do that is. You run a set of prompt evaluations over and over and over again any time you're looking to build something into a workflow.
Now, these are technically termed evals. okay? So if you've never heard of this term before, you'll see this a lot in large language model engineering, and evals are an important thing to understand when trying to progressively improve systems.
It's not enough just to run it once, be like, that's good, and then put that to bed. What you need to do is you need to run it 10 times. Count the number of times out of 10 that it actually worked.
If it's 7 out of 10, then it's 7 out of 10. And then when you make an adjustment to the prompt, count the number of times that that worked. Compare that to the former run, and if your new run is better, let's say it scores 8 out out of 10 instead of seven out of 10, then keep that new run.
This is at the core, a statistical research process. Every time you do this, you're basically a scientist. The second thing I want to talk about is giving Claude and other models a way to check their own work.
What I mean by this is let's say you give it a task like, hey, Claude, can you, I don't know, write me an essay on X, Y, and Z. You know, a lot of the time Claude will do this, but let's say you didn't roll the lucky dice this time because you didn't have a good set of evals and your prompt is sort of all over the place.
You know, the quality might be pretty poor. And so the way I like to think about this is first drafts. And if you guys have ever written an essay, you've probably gone through a process like school recommends you do, where you write a first draft, a second draft, you know, maybe a final draft, and then finally your actual finished revised paper.
Well, when you only have Claude... give it to you one time on only one attempt, it's not surprising the quality is going to be low because it's just like you've only ever had a first draft of a paper, right? Same thing.
Your first draft usually sucks balls, pardon my French. So what you need to do is you need to give it a way to check and then fix its own work before attempting it all over again. And so what tends to happen is the more that you do this, the more the quality at the end of the day is going to go up.
And even if you have a relatively poorly specified set of evals, A lot of the time, simply giving it a revision loop, say through some sort of screenshot, some sort of example comparison, or maybe some sort of like standardized test. Let's say it's a website, giving it a lighthouse page speed insights test can usually significantly improve the quality since it now has something to actually compare to.
The third thing I want to talk about is how to let the code be the context. So I see this a lot and it's a byproduct of skills, which were, you know, the sort of naive way of operationalizing and standardizing tasks. that Anthropic launched a couple of years ago and the rest of the world basically hopped on in exchange.
But skills really are not the best way of doing things anymore. And the reason why is because, you know, let's say you're developing some sort of skill or some sort of app. Typically the way that, you know, a model or a cloud code in this case will work on the app is it'll work on both the code, but it'll also work on a bunch of supplementary things at the same time.
So let's say it's working on, you know, some sort of code to, I don't know, generate thumbnails or something like that. As you go up in version number, as you go from V1 to V2 to V3 to V4, the code will have been updated. But oftentimes these notes, let's say, will still be on V1, the spec and the log might also say V1.
And as a result of that, essentially there is a difference between the source of truth and then the context that Claude and other models use to manage the source of truth. As a result, the two sources drift apart. A much more effective way of doing this now is actually just inlining all of your code directly into the app.
And so you could actually, for instance, scroll down to the description of this video, copy and paste the transcript, maybe specifically the part that I'm talking about now, and give that to Claude. And I think you guys will find in any sort of programming -related task or skill -related task, just burying things directly into the script will significantly improve your evals, which is ultimately what we're doing all this for, right?
And so in this case, now when we say, hey, can you add a logout button to the navbar? Now, instead of having to read through the notes, back in the log, it'll actually just be able to go through your, you know, code directly, see the inline comments, and so on and so forth.
So this sort of has to read that every time it does work. And the quality will be far better. I've tested this across multi billion dollar businesses and others.
And this is the way to do things. Obviously, the main exception here is your clod .md, where you store things like how you want it to work. So preferences, lessons, transcripts from Nick's Arrive YouTube videos.
But this doesn't actually fundamentally change what the code does. Next major thing I want to talk about is letting clod write your prompt. A lot of people are already out with their pitchforks for this one.
But back in the good old days, we used to be the best prompt engineers. I prided myself on my prompt engineering skills and so on and so forth. The unfortunate reality is AI is better than us at it now.
It's better at it than us now. because that's just one of the things that Anthropic has baked into Claude, its ability to communicate with other teammates, it can prompt other teammates. And so rather than say to Claude, hey Claude, I want X for Y audience, do it in this way and that way and this way and that way and that way, and you have all the info you need, go ahead.
Actually just say, hey, I want X thing for Y audience. I'd like you to help me write a prompt. After that, Claude will now ask some questions to you.
Like, who's it for? You'll say founders. What does great actually look like?
And you'll give it a one page example. Do you have any examples? Then actually, you know, it'll give it.
When you do prompting like this, a sort of meta prompting, you actually end up with significantly better outcomes because Claude is just far highly effective at doing this sort of thing. It's just been trained or baked into the way that Claude knows AI agents and other models tend to learn. And so, you know, you're still initiating the action, but Claude is now one level of best.
abstraction up, at least compared to where it was a couple of years ago. The prompts themselves aren't even that important. It's just knowing how to prompt Claude to have it prompt itself.
Now, this is a super quick and simple ask. You know, it's something that you do on a daily basis and you understand the procedure. Obviously, you can skip that and just, you know, say, Claude, I want you to go to this website in this way and give me this piece of information.
That's fine. But for anything that's larger in scope, many projects that might be consuming large token budgets, doing it this way will achieve far better outcomes than anything else. The fifth thing I want to talk about is to really deeply watch what is eating your context window.
In case you guys didn't know, the way that context works is you can actually type slash context into any chat with Claude models in order to see this. Your context window, aka the total amount of context Claude can fit in its head while working on your work, is already typically taken up quite significantly by default things that is system provided literally out of the box before you even type a word.
So for instance, in gray here is the system prompt. That might be your Claude .md. here might be your built -in tools the orange here might be mcp connectors next might be memories and finally here in green might be your skills what that means realistically is I don't know, I'm kind of eyeballing this, but about 30 % of the context is already taken up before I say anything.
Now when, you know, you end up filling in a chat with a bunch of random queries and a bunch of random asks, obviously the longer that context window goes on, the more pricey every request will be, but also the dumber the model itself becomes due to context rot and a bunch of other just unavoidable factors when working with probabilistic agents like this.
And so what you're going to want to do is, if you are not actively using you know let's say all of your mcps you're going to want to turn as many of these off as humanly possible if you're not using you know your skills you're going to want to cut down as many of those as humanly possible you know when you're prompting a model if you are nearly full or if you find the model maybe not responding the way you want to or if you spend a bunch of time having the model design a prompt for you okay to feed into itself don't just keep on prompting it within that window actually just copy that prompt and then move to a fresh instance okay one that'll be closer to here and then continue the conversation over there.
As long as that prompt contains all of the context and relevance and so on and so forth, you should be fine. Another way you can do this is you can use slash. compact.
That's something that's quite good nowadays, although there are some issues with how it currently compacts tool definitions and stuff that might be fixed by the time you watch this video. Using slash compact often is pretty reasonable. I tend to slash compact way earlier than Cloudwell Auto Compact for me for that reason.
Next thing I want to talk about is loosening the leash. Now, back in the good old days of AI models, God, I sound like an old man here, but back in like 2020, 2021, 2022, you needed a really tight leash around models. What I mean by that is you really had to go back and forth to get what you wanted.
You really had to give it all the ways not to do the thing so that it knew not to do any of those things while it did the thing. What you can do now is you can drop the highly granular step -by -step instructions and treat cloud more like a contractor than an in -house employee. You know, what I mean by that is if you guys aren't in business.
The way you treat an in -house employee is typically you'll actually give it the task specifications, and then you'll tell him or her how to do the task as well. And, you know, in that way, they'll optimize their processes according to the way that you lay it out, and then you'll get something pretty cool. The way that you work with contractors is typically they already have a pre -established set of processes.
You know, they're a contractor, they're a freelancer, they're working for themselves for a while, they know how to do the thing really well. And so typically you'll pay them a little bit more money, and then they'll use their highly optimized process, which they've built over the course of potentially hundreds of thousands of projects, to do it way faster.
faster and better than maybe your process could look like. And then maybe you'll consult with them and ask them questions. So rather than giving it a step -by -step how, okay, treat it like a contractor.
Just give it a good definition of done. hey, you know, you're done when this is true, that is true, and that is true. Assuming that those are true, you are good to go.
If you have any questions, feel free to ask. If you don't know, you know, maybe you can include that in your cloud at MD and also never skip tests or whatever. So you don't need this crazy scar tissue, like, you know, stuff or crazy, never, no, never, never statements from older models.
Cloud now is pretty smart and can infer a lot of what you want. As long as you focus on high level principles, like, hey, if you don't know anything, really just ask me, because this is pretty mission critical, then you'll do just fine. Next major.
thing I want to talk about is diagnosing before you start a fix. And let's say there's some sort of bug. Instead of saying, hey, I want you to fix the whole app, it's not working.
Say, list all of the problems with this app. Don't rewrite or do anything yet. The reason for that is because if you have it actually do the fix, if the problems are not problems that you actually anticipated or not problems that you actually want solved, keeping in mind that Claude has his own definition of what a problem is and what might be worth solving, you simply saying it's broken, fix it, might not actually lead to anything.
Instead, you really need to enumerate the problems and then give it the problems that you want it to solve. So for instance, it'll then list a bunch of problems for you. Maybe there's four problems here.
Vague opening says it twice, too casual and no example. You're like, no, actually the casualness is fine. That's not what I wanted to do.
So then you can just cross that out. And then what you can do is you can actually just give it the three things that you actually want it to fix. In this case, you are saving in token budget and you're also significantly improving the amount of time that it takes to get to that point.
You can imagine how if you screwed this up, what you would have done is been like, hey, can you just fix this whole thing? It would have fixed it, including the too casual bit. And now you would have had to recasualize this.
essentially in the next step, which would have taken twice as many steps, twice as much time and twice as many tokens. Next major thing I want to talk about is MCP servers, which stands for a model context protocol. Now, generally speaking, the way I work nowadays is I'll almost always prototype a system for myself or for many clients that I work with, with an MCP connector.
And when I say MCP connector, to be clear, I mean things like plugins. things like connectors in both Codex, Cloud Code, and their analogous terms in other apps as well. And so if it's a plugin or it's a connector, if it's like an OAuth, most of the time it's really this MCP, model context protocol under the hood, and that's what I'm referring to.
And the reason why is because it takes you one click to like, you know, spin up the MCP, click a button, sign in, and then you're done. You can actually move on and verify that it works. Once you've verified that it works though, it's suboptimal to scale.
And so I see a lot of processes in larger businesses that I work with that have really jumped in with both feet to try and implement AI across their whole stack, where these common day -to -day processes are still done with MCP servers. The reason why MCP is great is because it gets you up and running really quick. But the downside to MCP is it's typically very heavy on context, and it includes a bunch of silly bullshit that you never really wanted in a tool spec anyway.
And so instead, what you do is you turn what you just did for economic outcomes, once you've verified it's possible, into a... a lean custom skill. And now you're approaching, you know, a highly more, I want to say, nuanced and a highly more filtered list of tool call, you know, definitions and the tool spec.
And it'll be significantly easier on both contexts. And it'll also be significantly more likely to be correct. Another thing that really sucks is every time you load up cloud code with a bunch of MCPs, there's an additional like few seconds of startup time because cloud has to verify the MCPs work, actually send and receive some signals, sort of like housekeeping to make sure everything's above board.
I absolutely hate waiting for that. So I'll try and prune my MCPs, my connectors list in Cloud Code's case, as much as possible for spinning things up. And I find this typically saves me like three to five seconds every time I boot.
Next thing I want to talk about is how to run scoped tasks in parallel. So the way that I personally use Cloud is I no longer just say, hey, Cloud, can you do X for me? OK, yes, Nick, I did X.
Great. Now can you move to Y? Instead, what I'll do is actually highly scope specific tasks, and then I'll have Claude manage them all in parallel using subagents, agent teams, or other offerings.
So let's say you're designing some cool website. What you can actually do is you can have multiple agents work on multiple parts of the website at the same time. Claude typically does this natively, but you can also encourage it by saying things like, do this in parallel by running mutually exclusive scoped tasks.
That's a personal favorite of mine that tends to significantly speed up development. The reason why is because now let's say there's a bug with the logout.
Let's say there is some improvement to the hero section you want to make. And let's say there's some alteration of the feedback form you want to do. Rather than waiting for Claude to do all of these sort of in sequence, what you can do is you can actually have all three of these done simultaneously.
And then you can just have a merge step that merges all of them. OK, so basically, instead of it looking like and bear with my drawing here, instead of it looking like, hey, Claude, do this. OK, Nick, for sure.
I've done this. What should I do next? Hey, Claude, do this.
OK, Nick, I'm done with that for sure. What should I do next? Hey, Claude, do this.
Instead of these. steps. What we're doing now is it's more akin to this.
We're actually saying, hey, Claude, I actually want you to do all of these things up ahead. You know, I want you to fix the hero section, the feedback form, the logout button, some other thing. And then over here, all we're going to do is merge.
Okay, so this is, you know, sort of like your initial instruction. This over here is the all the big list of scope tasks that you want to do. And then this over here is going to be a merge step, which is really simple.
Now, the key part of this is obviously when you do the task, you need to make sure that you're not having multiple agents work on the same thing. Cloud will do this by itself, you typically don't need to worry too much about that. But you know, what you're doing here is you're saving a little bit of time at the expense of obviously a slightly higher error rate.
And I like doing that because I think you need to move fast and insert current year here. Next up, always start fresh with a handoff note.
What I mean by this is in a very long session, obviously you have context rot like we talked about earlier. The more back and forth you have, the more silly things enter Claude's mind. Simply as a byproduct of, you know, your human prompting skills, you will say, hey, don't do X.
But then three or four chats later, you'll say, yeah, I want it to be kind of like X. And it'll think, well, he said don't do X, but he also said kind of like X. I guess I'll kind of go in the middle and then you suck, right?
Instead of doing all that, what I always like to do when Claude isn't giving me results that I want is I just take, you know, a simple prompt that says, summarize where we are. So give me what is done, give me all the decisions I need to make, give me the things that are next, then give me a list of open problems. And then I simply fix anything that I think is wrong in that summarization prompt, and then I hand it off to a new message.
Typically, Claude will understand that, okay, this is obviously handed off by a previous session, so I should start with that in mind. It'll ask you anything that maybe is outstanding from your compacted summary. And then you get significantly higher context quality as a result of, you know, the way shorter prompt.
And I also find, as mentioned earlier, that it's cheaper. Next up, ask side questions with slash BTW. Nobody basically does this, which I find really funny, but I'm constantly slash BTWing because one thing that you'll realize is the longer that Claude and other, you know, models grow more agentic, the harder it is to know what the hell is going on.
I mean, how many times has this probably happened to you in the line? just a few weeks or months alone. You give Claude some big tasks like, hey, refactor the checkout flow.
It starts doing a bunch of stuff. And then 10 minutes later, you come back to and you're like, hey, where the hell were we again? You start scrolling through all of your chats and you realize like, dude, I have no idea what's going on.
So what you do is you wait naively for it to finish and then give you the update. And then you read it, not understanding what the hell is going on. Ask it the same question again.
Now you have to wait a big chunk of time for it to finish. Instead, parallelize that by asking it side questions with slash BTW. So anytime Cloud's working, you literally type slash BTW and just say, hey, what does this thing mean?
And it will actually answer you while it's working on that other session. This, number one, does not pollute the main context with educational or informational questions about what it is that you're trying to do. And number two, it's just way faster and way easier.
So you guys should 100 % be using slash BTW wherever humanly possible. You know, I think we all probably sort of understand this. Any Yu -Gi -Oh players in the chat, you know, these are your hands of Exodia versus like the head or the body of Exodia.
You want your body to be really expensive, but you couldn't really care less about the hands, if I'm honest. The whole idea is, you know, if you have a task, you can almost always improve your ability to do the task by learning more about the problem. What I mean by this is you can research more about approaches that other people have done to try and solve the task.
You could check all the papers on a subject. You could look through a bunch of blogs or, I don't know, Reddits or something like that to try and determine, okay, what are all the things that basically people have tried throwing at this thing before? When you do this, your task quality significantly improves.
The only issue with that is oftentimes it costs a lot of money in order to do all that research. So the optimal way to do this is just... Pay a little bit of money to a really cheap model to scan the search space as widely as humanly possible.
Have it fan out. Deliver you as much of this information as it can because they all have cheap and short contacts. And then just give it to your stronger model to actually make the call.
So in our case with, you know, I don't know, an Opus 5 .5 or 6 or Fable or whatever model you are using at the time that you are watching this video. Feed in your task with something like, hey, I want a fan out and fan in strategy where you delegate to cheap subagents to find out as much information on XYZ topic as humanly possible, best approaches in, you know, insert current year, things that maybe most other people don't currently use.
And then I also want you to just like ideate and hypothesize a bunch of approaches to doing this that maybe aren't normally supported in the literature and see if there's anything to support that. Then I want you to combine that all into a mega prompt for a stronger model, like, you know, maybe your successor opus fable.
ethos, whatever, and then how to make the decision. When you do this, you get more coverage. It's way faster and also costs you less money than having Opus do it all.
I cannot tell you just how much this fundamentally evolves my personal prompting strategy. I would highly recommend you guys use fanout, fanin, wherever possible. Obligatory, set up your cloud .md.
This is similar to context rot. If you're just always feeding in dumb things that are no longer relevant, like I was recently, where I was feeding it the deprecated revenue figures from a few months ago, and it kept on making decisions for me based off of of deprecated revenue numbers.
Like, you know, my risk tolerance was way lower. The amount of money I was willing to throw at problems was way lower. You know, my portfolio wasn't as fully fleshed out.
So I didn't have, you know, high quality pieces that it recommended me to, you know, sell to other people and so on and so forth. Make sure to just check your Cloud to NMD. Check it literally right now.
Pause the video if you have to. Double check that everything that is in there is actually relevant. There's zero point to sending even a single character or wasting even a single character of both, you know, your token budget and then also Cloud's intelligence.
The only information that should be in there is stuff that you genuinely want to be in there. The way I like to do this is I always say a summary of what's where.
You can just generate that with a backslash init. Super easy. Then just give it some preferences.
So in my case, I actually say give me full file paths and I say use Python. You know, what can it do? Hey, you know, feel free to do whatever the hell you want within these capacities.
If you're not sure, ask me before, but I generally trust you. Here's some information about me. Here's some lessons that I've learned and so on and so forth.
That's fine. Just make sure that you're not feeding in the same thing that you were feeding in models of yesteryear. Every time a model gets an update, even a highly incremental one, you should be going through this process again to ensure that your Cloud .MD and system prompts in general are very high quality.
Next, keep a backup tool ready. As unfortunate as it is, cloud code is not always fantastic. Sometimes there are outages in cloud.
Sometimes there are quality fluctuations as an unfortunate result of just model economics and tokenomics and stuff like that. So what I see a lot of the time in maker school, and then all over the internet is when cloud codes down everybody and their mom is on Twitter or YouTube saying cloud code is down and the reason why is because they're just not getting any damn work done because they don't have a way to back up and so what I'll do is I will run cloud code as my main tool But I will always have a backup model like Codex or another model in the same folder with me, usually like a Codex or an agents .md or something similar.
And so what I'll do is, you know, agents .md is like sort of other models, versions of a Cloud .md. I will symlink, which just means connect the Cloud .md in my directory to the agents .md. I'll mirror the contents such that anytime Cloud updates a Cloud .md, it'll also update agents .md.
um and then you know if it's ever out i can just like drag and drop codex in and say hey codex you know pick up where your brethren claude left off it says claude that guy sucks but you know does it anyway i never really have to suffer an outage um you'd be surprised at the number of large teams that i've worked with you know we're talking again billion dollar teams that do not have any sort of backup or any sort of like you know, diversity of models.
When cloud code goes down, they are legitimately hamstrung and economic productivity within that company grinds to a halt. Don't let that be you. And by the way, cloud recently updated such that it now even understands agents .md.
So while I'd still recommend having a cloud .md in your workspace, you could also just have an agents .md and then just hot swap models out anytime cloud needs it. Have a cloud learn from its mistakes. build that into the Cloud .nd.
So let's say you make a mistake, you know, and the mistake is, I don't know, you are trying some old API. And every time Cloud tries the old API, it fails. You're like, okay, you know, update the Cloud .nd so you don't do this again.
It might write something like don't retry the old API. But that sucks. What you're telling it to do, again, is you're telling it what not to do.
Instead of giving it like negatives, okay, and trying to fill the whole thing with a bunch of lists of things it can't do, instead, give it positives. Say things like batch the file reads, let's say, which is the actual solution to the problem. So don't just give it a bunch of problems, okay, because, you know, that seems like learning, but it's not.
Give it the solutions as well. And a simple and easy way I always get Claude to do this for me is I will just say, how could you have done that faster with fewer tokens? And I will generally ask this every single time I'm building a skill into like an eval loop like we talked about before with, you know, prompt lucky dice rolls.
When you do this and you feed all that stuff in with a tool like slash insights and so on and so forth to your Claude .md, your Claude .md usually becomes like a real powerhouse operation. And so my Claude .md, for instance, probably saves me, you know. three or four hours a week just in all of the mistakes that cloud usually makes with you know a given set of tasks that it no longer has to and even high level instructions surrounding like hey could you open this file for me when you're done working on it or something also saved me a tremendous amount of time and if you use terminal tools like ghost tty orca or these other approaches they can also be very powerful because there's just very difficult sort of navigation natively in those apps as a result okay hopefully you guys appreciated that video if you guys like learning about ai automation and other cool generative technologies, and you want to learn how to monetize those for your own business, freelancing career or agency, definitely check out maker school is the first link in the description.
It's my 90 day accountability program where we'll guarantee you your very first customer for a paying AI or automation service, or I'll give you all your money back 100 % back to you guys can check the reviews. We have lots of people that are absolutely crushing that program more than I can even begin to count. If you guys also like this channel and want to keep supporting it, please like subscribe and comment down below.
I'll leave you all with a great big thank you and I'll catch you guys in the next video.
The Hook
The bait, then the rug-pull.
Nick Saraev opens by putting a real dollar figure on his Claude Code habit, over $30,000 in a few months, and uses it as proof he's earned the right to hand over what he calls everything he wishes he knew from day one.
Frameworks
Named ideas worth stealing.
02:41concept
The Evals Loop
Run the prompt 10 times
Count the pass rate
Change one thing
Re-run 10 times
Keep the version that scores higher
A repeatable test-and-compare process for judging whether a prompt change actually helped instead of just feeling better on one lucky run.
Steal forany prompt template used more than once in a business workflow
11:14concept
Definition of Done (contractor mode)
Replace granular step-by-step instructions with a plain 'you're done when X, Y, and Z are true' spec, then let Claude choose its own process like a contractor instead of an in-house employee.
Steal forany recurring task spec in CLAUDE.md or a skill file
19:01model
Fan Out / Fan In
Fan out: cheap subagents research the problem space in parallel
Fan in: combine findings into one mega-prompt
Hand the mega-prompt to the strongest model to decide
Splits expensive research work across cheap models, then reserves the frontier model for the final judgment call.
Steal forany research-heavy task before a big build decision
20:53list
CLAUDE.md structure
Summary: what's where (generate with /init)
Your preferences (file paths, language, style)
What it can do (state capabilities, don't underestimate)
Lessons learned (positive fixes, not just banned actions)
The four sections Nick keeps his CLAUDE.md organized into, regenerated after every model update.
Steal forany CLAUDE.md file that's grown stale or contradictory
CTA Breakdown
How they asked for the click.
VERBAL ASK
25:26product
“definitely check out maker school... it's my 90 day accountability program where we'll guarantee you your very first customer for a paying AI or automation service, or I'll give you all your money back”
a single soft pitch in the last 30 seconds after 25+ minutes of pure value, framed around a money-back first-customer guarantee rather than a hard sell
Add Modern Creator as a preferred source and Google shows you more of our breakdowns in Search, Top Stories, and AI Overviews. It only changes what you see, and you can undo it in your Google settings anytime.
Add to Preferred SourcesOpens your Google source preferences with us pre-loaded. Tick the box and you're done.
A creator shows a live head-to-head test proving that rendering bulky Claude Code context as a compressed image, instead of raw text, cuts the bill by 30-59% with zero loss in recall.
A five-step AI pipeline — generated painting, AI video, frame extraction, dithering, and free deployment — that turns a couple dollars of image and video credits into an animated, expensive-looking website hero.
Cerebras published exactly how its internal knowledge base works, and it's a plain retrieval pipeline any team can copy — no graph visualizations, no floating brain, just Slack and Wiki and code stitched into one queryable table.
A 14-minute benchmark rebellion: seven live side-by-side demos, one OpenRouter API key, and a four-path procurement map that makes Opus 4.8 look expensive.
00:48
01:08
01:27
01:47
02:06
02:26
02:45
03:05
03:44
04:03
04:23
05:02
05:21
05:41
06:00
06:20
06:58
07:18
07:37
07:57
08:36
08:55
09:15
09:34
09:54
10:33
10:52
11:12
11:31
12:30
12:49
13:28
13:48
14:07
14:27
14:46
15:25
15:45
16:04
16:24
17:03
17:22
17:42
18:21
18:40
19:19
19:38
19:58
20:17
20:37
20:56
21:16
21:35
21:55
22:34
22:53
23:32
24:11
24:31
24:50
25:10
25:49
06:44
6:02:49
22:52
23:48
15:01
Video of the Day14:34