Austin Marchese breaks down Boris Cherny's Claude Code workflow and applies it to real-world use cases
Austin Marchese, creator of the podProse-adjacent AI workflow content, walks through Boris Cherny's (creator of Claude Code) publicly shared methods for getting the most out of Claude Code.
Summary
Austin Marchese researched Boris Cherny's publicly available interviews, threads, and posts to reverse-engineer how the creator of Claude Code actually uses his own tool. The video covers six core strategies Boris uses — plan mode, minimal claude.md files, verification loops, parallel sessions, slash commands/Claude skills, and a long-term mindset about model improvement. Austin supplements each strategy with his own practical adaptations and specific prompts that non-engineers can apply immediately. A recurring theme is that most people over-engineer their AI setup when the opposite approach — minimal instructions, deliberate planning, and trusting the model — produces better results.
Key Takeaways
FULL TRANSCRIPT
Introduction: Researching How Boris Cherny Actually Uses Claude Code
Austin Marchese: Boris Cherny, the creator of Claude Code, says that his setup is pretty vanilla. So I started researching Boris and how he works. I dug up interviews, threads, everything he shared publicly about how he actually uses Claude Code. Despite him having an engineering background, all the principles he uses anyone can apply. So in this video, I'm going to show you exactly how he starts every project and show you how I've personally been applying these workflows.
Section One: Plan Mode
Let's get into the first section, which is all about plan mode. Here's one of the biggest features that you're probably missing. And here's a clip of him talking about how he uses it and how he babysits Claude Code.
Boris Cherny: Probably 80% of my sessions I start in plan mode. And once the plan is good, it just stays on track and it'll just do the thing exactly right almost every time. Before you had to babysit after the plan and before the plan — now it's just before the plan.
Austin Marchese: So 80% of his sessions start in plan mode. He clearly outlines the importance of babysitting before Claude Code starts building, and he mentioned that once a good plan is locked in, building is almost automatic.
So why does this matter so much? Most people open Claude Code, type what they want, and let it run — there's not a lot of planning involved. Yes, AI is great at solving problems, but the problem it thinks it should be solving and the problem you actually want it to solve aren't necessarily the same thing. If your request is vague, you get the wrong solution, and then you spend hours debugging something you could have avoided from the start. Generally speaking, AI is set up to solve problems as quickly as possible, not necessarily correctly. You may think a problem is solved, but it didn't actually solve what you wanted it to solve.
I've seen this firsthand. One of the clients I was working with had a bug on their website — the numbers weren't correctly displaying. Instead of fixing the display, Claude actually went into the database where it was getting the information, changed the value, and then marked it as resolved. It fixed one thing, but then that broke like five other things in the app because it changed the value. It didn't actually solve the problem the way we wanted to solve it.
Boris's approach is different. He's not trying to just attack it right away — he's planning. There's a quote I love to reference from the Navy SEALs: move slow to move fast. He has all the thinking happen up front, and then the execution is essentially automatic.
So before you build anything, hit Shift+Tab twice in your terminal and that will enter plan mode in Claude Code. Go back and forth until it's something you really like. Perhaps ask it to interview you to see if there are any gaps in your assumptions, and then you can have it start building. Here's a specific prompt you can use before you start building:
"Interview me about this. What is the core problem this solves? Who is this for? What does success look like? And what should this not do? Summarize it back to me before you write any code."
Now Claude will proactively ask you questions about things that previously it probably would have made assumptions about. This is all about putting Claude in the best position to succeed.
Section Two: Claude.md
The next part is probably what surprised me the most about his entire strategy — and it's about claude.md.
When you've used Claude Code, you might have seen a file called claude.md. It's essentially a set of instructions that Claude reads every time you start a new chat. Think of it like giving Claude a cheat sheet about how you want to work, and it's specific to you. Boris uses this the way a lot of people use it: whenever there is a mistake, he'll update the claude.md file to make sure it doesn't happen again. A simple prompt you could use here is:
"Based on this conversation, can you update claude.md so this doesn't happen again?"
This is extremely powerful, but there are limitations. A lot of people think the more instructions they give, the better the results. So they create this massive claude.md file with every rule they can think of and never try to clean it up. But Boris does the opposite. Here's a clip of him talking about how he handles it when this file gets extremely long.
Boris Cherny: Our claude.md is actually pretty short. I think it's like a couple thousand tokens, maybe something like that. If you hit this, my recommendation would be delete your claude.md and just start fresh.
Interviewer: Interesting.
Boris Cherny: I think a lot of people try to over-engineer this. And really, the capability changes with every model. What you want is to do the minimal possible thing in order to get the model on track. So if you delete your claude.md and then the model is getting off track — it does the wrong thing — that's when you kind of add back a little bit at a time. And what you're probably going to find is that with every model you have to add less and less.
Austin Marchese: His advice is counterintuitive, at least to me. But what he's saying is that if claude.md is bloated, just delete the entire thing and start fresh. His point is that because these models are getting better every day, what you needed six months ago is likely built into the model right now. And generally, if you give it a ton of instructions, the more you give it, the more likely Claude is going to get confused and not apply the rules that are actually critical.
So he'll just delete the whole thing — which for me is a little bit scary. That might be him just believing in Claude Code a little bit too much. Honestly, I'm not sure about that. But Boris's approach where he says do the minimal possible thing to get the model on track is absolutely spot-on. And what he does is if he sees the same issue again, he'll just add it back to the claude.md.
To be totally honest, this isn't something that I do — I feel like I'm a little scared. But what I do instead of deleting it is run a simple command:
"Update my claude.md to remove anything that's no longer needed, contradictory, duplicate information, or unnecessary bloat impacting effectiveness."
I found that this is an effective middle ground, but feel free to take Boris's advice and just periodically delete the entire thing. And if you're not using the claude.md file and updating it over time, make sure to start doing that.
Section Three: Verification
These first two strategies are all about getting better results. But how do you actually make sure Claude did what you were hoping it was going to do? The next key thing Boris does is about verification.
Here's a post from Boris on Twitter that really stuck with me: "Give Claude a way to verify its work. If Claude has that feedback loop, it will two to three times the quality of the final result."
In theory, this sounds awesome — you can just have Claude check what it did and see if it did it correctly. But how do you do this in practice? He gives two steps. One: give Claude a tool to see the output of its work. Two: tell Claude about that tool. That's really it. And then he says Claude will figure out the rest.
For me and you, what does this look like in practice? If you're building something with a website, Boris uses Claude Code, opens a browser, tests what it built, and iterates until it actually works. Here are some other strategies. If you're using Claude for content or writing, you could say: "Review this against my brand guidelines and flag anything that doesn't match." Or if you're building automations, you could say: "Run this workflow and verify the output matches what we expected."
Above all that, the simplest approach that just catches everything is to add to your claude.md: before you do any work, mention how you could verify that work. Now Claude will tell you what its verification plan is before it actually starts building. And if there's no clear way to verify it, maybe there's a better way to go about it.
A pro tip here — after going back and forth with Claude Code a bunch, here's something you could run:
"Please go back and verify all of your work so far. Make sure you used best practices, were efficient, and didn't introduce any issues."
Section Four: Multiplying Yourself with Parallel Sessions
You're planning, you're keeping instructions minimal, and you're verifying. But what if you could do more at once? This is probably the biggest force multiplier to increase your efficiency with these tools — and it's about multiplying yourself.
Boris has a tweet where he talks about the importance of working in parallel. There's a lot of technical jargon there like Git worktrees — if you want to look that up on your own time, go ahead. But it probably doesn't matter because that's for more robust engineering teams. What's important for you is his concept of partitioning different workflows. He'll have multiple Claude sessions running at the same time, each one focused on a different task. The key is that each task is partitioned so they're not overlapping.
A simple way to think about this: if you had two people working on the exact same thing at the exact same time, you'd have wasted effort and they'd likely clash with whatever files they're working on. This is the same thing with Claude. If you have multiple sessions working on the same thing, it's counterproductive.
Boris would approach it with this in mind. He says two context windows that don't know about each other tend to get better results. A fresh session could look at a problem with no baggage and might see something obvious that your first session missed because it was too deep in the weeds and had context that was fogging its problem-solving. Creating a new window and just starting from scratch is the equivalent of turning it off and coming back and it just works.
Section Five: Inner Loops and Claude Skills
Boris's fifth strategy is about creating an inner loop. He calls repeated tasks his inner loop — these are things that he does many times throughout the day. You may not realize it, but if you think about it, you're going to find a lot of these inner loops in your own work.
A quote from him: "I use slash commands for every inner loop workflow that I end up doing many times a day. This saves me from repeated prompting."
Slash commands allow him to quickly call things that he repeatedly does, and he's taken a more systematic approach. Now, Boris uses something called slash commands to handle these more repeatable things, but there's something called Claude skills that's way more applicable to what you're doing.
Claude skills are essentially a way to document a process so that you can call it directly in Claude Code to complete that process every single time. In a sports analogy, a prompt is you telling a player to dribble the basketball. But a Claude skill is the exact play to run — like a pick and roll — and AI knows exactly how to run that play every single time.
For Claude skills, think about the inner loops that you have throughout the day. For me, some of the skills I use for my clients — one example is I work with an engineering firm and there's something called a Local Law 97 report. I'm able to use a skill that generates the same report in the same format in the same style every single time I run it. The only thing that changes is the data that I reference. This is an inner loop that my team has to do throughout the day, but once we've created a skill for it, it's infinitely repeatable.
These are so powerful and I cannot stress how important they are. Boris uses this in his own way, and this is something you just can't ignore. If you don't know where to start, just use this prompt:
"Based on the project I'm working on, what Claude skills should I create?"
It'll give you the direction. You can just go from there.
Section Six: Build for the Future
There's one more mindset shift that ties all of these different concepts together that Boris explains extremely well — and it's about building for the future. This is something that a lot of people ignore. Here's an excerpt directly from Boris.
Boris Cherny: We have a framed copy of the Bitter Lesson on the wall. This is Rich Sutton — everyone should read it if they haven't. The idea is the more general model will always beat the more specific model. There are a lot of corollaries to this, but essentially what it boils down to is: never bet against the model.
Austin Marchese: Restating this: every piece of scaffolding or micro-tweaks to improve the model's output that you do will probably be unnecessary in the next six months. The reason is that the model is just getting better. Now, that's not a reason to not build things. But it's important to understand that AI models get better every single day. So it's about thinking: where should you focus your energy?
If you've watched some of my other videos, you know how I feel about writing optimized prompts — respectfully to everyone out there who says to optimize prompts, because ultimately the model is just getting better and you don't really need an optimized prompt. You need to just give it the right direction. Instead, you should be spending your time on your information model — everything that you're feeding the model and the system that you're using to get AI better over time. This is the context that is put on top of the model to get you those outputs.
So remember this when you're tweaking prompts: is this worth the 10% improvement right now, or should you just spend your time assuming the model will be better next month and working on other things? Because AI will never be as bad as it is today — which is frankly very scary.
Recap: Boris Cherny's Six-Part System
So with all that in mind, let's recap Boris's system.
One: use plan mode. Move slow to move fast. Have the conversation before Claude starts building.
Two: create a minimal claude.md file. Less is more, and if you have to, start fresh.
Three: verification. Give Claude a way to check its own work.
Four: multiply yourself. Parallel sessions, fresh context for hard problems.
Five: systemize your inner loops. Document once, run forever. Use Claude skills.
Six: build for the future. Expect that the models are going to get better, not worse. Plan accordingly.