Modern Creator
Sharbel A. · YouTube

How Anthropic Engineers Actually Use Claude Code

Seven habits behind Anthropic merging 30,000 code changes a day, each one turned into a Claude Code command you can set up tonight.

Posted
2 days ago
Duration
Format
Tutorial
educational
Views
9.9K
86 likes
Big Idea

The argument in one line.

Anthropic's scale comes from the boring systems around Claude, not a magic prompt: review intent, force proof of done, catch errors instantly, and give each Claude its own lane.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…
  • A solo founder or builder already using Claude Code daily who wants concrete commands to make it more reliable on a real project.
  • A developer who is drowning in reviewing AI-written diffs line by line and wants a faster review habit that still catches bugs.
  • Someone running several Claude Code windows at once who keeps hitting file conflicts and needs a clean way to split the work.
SKIP IF…
  • You have never opened Claude Code, since the video assumes you know sessions, CLAUDE.md and slash commands.
  • You want the details of Anthropic's internal Git replacement, which the video says nobody outside can use.
TL;DR

The full version, fast.

Anthropic went from about 2,500 to over 30,000 merged code changes a day, with more than 80% written by Claude, and the video breaks down seven habits behind that. Engineers review a change's intent instead of every line, run single-purpose watcher agents, keep a short no list in CLAUDE.md, and force Claude to prove its work with /goal and stop hooks. They add a post-edit hook as a red squiggly line, give each Claude its own worktree lane, and hand out goals instead of tasks, using /batch for big jobs. Setting up even one tonight makes Claude Code noticeably better.

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 →
Atomic Insights

Lines worth screenshotting.

  • Anthropic went from roughly 2,500 merged code changes a day in May to over 30,000 a day by September, with more than 80% written by Claude.
  • Reviewing the intent of a change (what it is trying to do) beats reading every line once Claude writes most of your code.
  • The session that wrote the code already believes it is right, so open a fresh session for important reviews.
  • An agent watching everything catches nothing, so give each watcher agent exactly one thing to monitor.
  • When Claude reviews code it tends to over-engineer, so the engineer's real job becomes telling it no.
  • Telling a reviewer to flag only problems that affect whether the code works correctly produces a far shorter, cleaner review than an open-ended one.
  • CLAUDE.md is a soft layer Claude tries to follow, so anything that must happen every time needs a hook.
  • A stop hook runs the moment Claude tries to finish and can send it back to fix work, costing zero tokens unless it has something to say.
  • The fastest way to make an agent better at your codebase is a tighter feedback loop, not a smarter model.
  • Going from five to 20 parallel Claudes gets roughly four times the work done, per an engineer on the Claude Code team.
  • Parallel Claudes in one folder trip over each other, so give each its own worktree and branch and merge one at a time.
  • Giving Claude goals such as improve the funnel, instead of tasks such as add a button, lets you stop watching every step.
Takeaway

Build the system around Claude, not a better prompt

WHAT TO LEARN

Claude Code gets reliable when you review intent, force proof of done, catch errors instantly, and give each Claude its own lane.

  • Send Claude a summary request and review the change's intent and design, then run /code-review in a fresh session so the reviewer is not biased by having written the code.
  • Run /loop for single-purpose watchers that report only when something is wrong, and use /schedule when it must keep running with your laptop closed.
  • Keep a short no list in CLAUDE.md and tell reviewers to flag only issues that affect correctness, which prevents over-engineering.
  • Make Claude prove it is done with /goal for a checkable definition of done, or a stop hook that blocks finishing while a check fails.
  • Add a post-edit hook that runs a linter and returns errors to Claude immediately, so mistakes are fixed before they spread.
  • Give each parallel Claude its own worktree and branch, hand out goals instead of tasks, and use /batch to split big jobs across workers.
Glossary

Terms worth knowing.

Worktree
A separate copy of your project with its own branch, so several Claude sessions can edit code at the same time without colliding.
Stop hook
A small script that runs automatically the moment Claude tries to finish and can block it from stopping if a check fails.
Linter
A tool that scans code and flags actual mistakes, used here as the checker a post-edit hook runs after every change.
MapReduce
A pattern where a big job is split into pieces, the pieces run in parallel, and the results are combined at the end.
/goal
A Claude Code command where you define what done looks like and a small fast model checks after every turn, keeping Claude working until it is true.
/batch
A Claude Code command that plans a large job, splits it into pieces, runs a separate Claude on each in parallel, then merges the results. It requires a git project.
The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

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

Anthropic's own engineers don't even read every line of code anymore. And that sounds completely backwards until you see how they actually use Claude code. Back in May, they were merging about 2 ,500 code changes a day.
And by September, it was over 30 ,000 a day. And more than 80 % of that code was written by Claude. So in this video, I'm going to show you the seven habits that make that possible and how you can set every single...
one of them in your own cloud code today. Let's get started. Anthropic recently published a post about how they handle their code and the problem they had was kind of crazy.
So many clouds were writing code at the same time that Git, which is the system pretty much every developer uses to keep track of changes to their code, just couldn't keep up anymore. So a team of seven people built their own replacement and moved their entire code base onto it in about five months. You can't use it.
They even say it's not meant to replace Git for normal people. But the part I actually care about and the part you can use is how their engineers work now. Because when Claude writes more than 80 % of your code, your whole job changes.
And to be fair, some of these habits aren't brand new changes. But seeing Anthropic run them at this scale is the best proof that they actually work.
And the first one is the one that sounds the scariest. In that post, the team says they now look at the intent of a change, aka what it's trying to do, instead of reading every single line of code. And I know that sounds dangerous, but they didn't stop reviewing.
They just changed what they review. In Anthropic's own video about how the Claude Code team works now, they explain that Claude handles the nitpicks and the humans check the bigger picture. Is this the right approach?
Is it touching something that it shouldn't? And does the design actually make sense? Here's how I do this in my own Claude Code.
For example, I just had Claude go through my newsletter signup flow in my website and improve it. And before I look at a single line, I send it this, which lets me go through the bigger picture instead of nitpicking every single line.
Then I run slash code review which is Claude's built -in reviewer and it goes through the change looking for actual bugs. From that I can either choose to fix everything it finds or fix some of the things it finds. Whichever one I prefer.
So instead of reading 400 lines I read three sentences and let the reviewer find the bugs. Oh and here's a hack for you. The session that wrote the code already thinks that the code is right so for anything important i open a brand new session and run the review there that way it looks at it with fresh eyes the same way a real reviewer would that covers the code claude just wrote but anthropic also has agents watching their systems around the clock anthropic runs what they call superfan these are claude's whose only job is to watch one part of their system they read logs they watch numbers and they catch the weird stuff that normal alerts completely miss.
Anthropic describes them as acting like an experienced engineer who has nothing better to do, which is basically every founder's dream employee. And you can build a mini version of this in Cloth Code with one command called slash loop. Here's the one I run.
Always starts with slash loop, then how often you want this to loop, and then the task that you actually want it done. And then you can define if nothing changed, don't say anything so that you don't get overloaded with information. And that's it.
Every 30 minutes, Cloth checks my website and it only says something when something's actually wrong. Now, just know that Slash Loop only runs while that session is open and it stops on its own after seven days. If you want something that keeps running even when your laptop is closed, there's Slash Schedule, which runs on a fresh copy of your project in the cloud at most once an hour.
That one needs a paid Cloth plan, pro or higher, and it can't... files sitting on your laptop, so it's better for checking your code. And the trick is the same one Anthropic uses.
Give each agent one thing to watch, because an agent watching everything ends up, well, catching nothing. But the more freedom you give Claude, the more it tries to do. And that's where Anthropic learned the most important lesson.
This is my favorite line in the entire post they made. Here's the quote. The role of the engineers was to tell Claude no.
Because Claude sometimes broke core rules of their system. And when they had Claude review the code, it pushed to over -engineer parts of it. Anthropic said these reviews can be myopic, which is a fancy word for short -sighted.
So their engineer's real job became saying no. And there are two ways I do this myself. The first one is a short no list inside of my Claude .md, which is the file Claude reads at the start of every session in your project.
Every time Claude does something I don't want, it goes on that list. And you don't even have to open the file yourself. You can just tell Claude, add this to the no list in my Claude .md, followed by what it is that you want it to add to that no list.
In my case, that rule is already in my no list, as you can see. And if I want to see the whole list, I just ask it to show me my Claude .md. And this is what's on mine.
I have two Claude .mds, one that is global for all of my Claudes and one that is specific to this project. Keep it short though. Anthropic's own advice is to look at every single line and ask, would removing this cause Claude to make a mistake?
And if not, then just cut it. The second one is giving Claude a break when you ask it to review something. Watch the difference.
First, I'll ask it to review my code and find problems. And then I'll do the same thing, but with a break. I'll tell it to only flag problems that affect whether it works correctly and does what I asked for.
It's interesting that this one is our... And look at how short and clean it is. Meanwhile, this one is still running and it has three different massive steps to complete before it calls it done.
And it spun up three background agents. The first run just finished and look at how massive it is compared to this one. That second prompt is based on Anthropix's own docs, where they warn that chasing every single finding leads to overengineering.
And by the way, every prompt, command and setting function from this video I put into a free doc in the first link in the description below. So you can copy them straight into your own setup.
If you're an AI founder, I genuinely recommend subscribing to my newsletter so that you're the first to know whenever I drop anything new. Now, just know that Claude .md is the soft layer. Claude tries to follow it, but it's more of a suggestion than a rule.
So if something has to happen every single time, you need some Claude can't ignore. Claude has a bad habit of saying it's done when it's not actually done.
At Anthropic, that doesn't fly. Their Claude code team says Claude's work comes back with tests and screenshots attached. And Anthropic's own docs say the most useful thing you can give Claude is a way to check its own work.
And there are two ways to force this in Claude code. The easy one is slash goal. I just type slash goal and then I define what done looks like.
For example, every link on my website works and you've shown me proof you checked each one. And now after every turn, a small fast model checks if that's actually true. And if it's not, Claude just keeps going on its own until it is.
And if you're not sure how to word your slash goal prompt, just ask Claude to write the slash goal for you and paste what it gives you in. For example, this is the slash goal it recommends that I paste in. I mean, it's a lot more detailed.
The definition of done is a lot clearer. But that being said, the main slash goal run is still going and it's still finding links that aren't working. So it's fixing them one at.
a time and it won't stop until it is completely done. One thing to know, though, that checker can't run anything itself. It only sees what Claude shows it.
So write your goal as something Claude can actually prove, like showing you it checked every link, for example. The harder one is a stop hook. A hook is basically a little script that runs automatically at a set moment and a stop hook runs the second Claude tries to finish.
So if your check fails, Claude isn't allowed to stop. And the easiest way to set one up is to just ask Claude to do it for you.
You can literally tell it, add a stop hook to this project that does X, Y, Z, fill in the blank and blocks you from finishing if any of those don't meet the condition. So now if Claude tries to finish while even one link is broken, it gets sent straight back in to fix it. And the best part is a hook costs you zero tokens unless it actually has something to tell Claude.
That's the difference between asking Claude nicely and actually forcing it. But that only checks work at the very end.
Anthropic catches the mistakes the second they happen. You know when you're typing up a doc and a red squiggly line shows up under a typo, so you fix it right there before it spreads? An engineer on the Cloud Code team said this in a talk, and I quote, the fastest way to make an agent better at your code base isn't necessarily a smarter model, it's a tighter feedback loop.
So they give Cloud its own red squiggles, a hook that runs right after after every single edit, checks the code and sends any errors straight back to Claude. And again, the easiest way to set this up is just to ask Claude to do it for you.
You can say, add a hook to this project that checks fill in the blank and sends any errors straight back to you so you fix them before moving on. And it will do just that. It picks the right checker for your project, which is called a linter, AKA a tool that flags actual mistakes in your code and sets it all up for you.
Then you can just give it a normal job like add a newsletter signbox to my homepage and now every time it edits a file it gets checked right away. So if Claude makes a mistake it sees it the second it happens and fixes it before moving on.
That makes one cloud a lot better, but one cloud can only go so fast. That same engineer from the cloud code team also said that going from running five clouds at once to 20 gets you roughly four times the work done. Now, if you watched my video on why anthropics engineer stopped building AI agents, you might be thinking, wait, didn't you just tell me to stop running a bunch of agent?
And that's a fair question. In that video, the problem was building a brand new agent for every. single job, one for content, one for emails, one for outreach.
And every single one of them needed their own training and babysitting. This is the opposite. Every one of these clods is the exact same clod with the same exact skills, just working on a different job at the same time.
So you're not hiring 20 different employees, you're cloning your best one. But if you just open five clod code windows on the same project, they'll start tripping over each other, editing the same files at the same time. So they give each clod its own lane.
It's called a work tree, which is just a separate copy of your project. So each clod has its own space to work in and setting this up is way easier than it sounds i open three new sessions and in each one i just tell claude work in a work tree called landing page for example and it sets that up then the same prompt but with newsletter and the second one and bug fixes in the third one and claude creates its own copy of my project and moves itself into it so now i've got three clods in three lanes and none of them are stepping on each other.
She even gives each one its own color. And it sounds small, but she said it genuinely helps her keep track of which cloud is doing what. And here's a hack for you.
Each lane gets its own branch, which is just a separate line of changes. So when they're done, you can review and merge them back in one at a time. But with three lanes, you're still the one handing out all the work.
In Anthropic's own video about how the Cloud Code team works, they explain that they give each cloud goals instead of tasks. So instead of asking it to add a button here, it's improved the funnel and they don't watch every single step anymore.
And for the really big jobs, they found those out. They split the work up, give each piece to its own Claude, check every result and keep the good ones. One of them called the MapReduce problem, which is a fancy way of saying, split it up, do it all at once, then put it back together.
And in Claude code, you can do exactly that with SlashBatch. example, I type slash batch and then with my goal, give every page on my website a proper SEO title and description, which is just the title and the little description Google shows under your link. And first, Claude makes a plan.
It splits the job into pieces and it shows it to me. Once I approve and say yes, then a separate Claude takes each piece all at the same time. So instead of one Claude going through my pages one after the other i've got a whole team of clouds doing them all at once as you can see first it made a plan i can reject revise accept or accept an auto mode i can go through my plan here on the right and in my case all is accepted and as you can see it gave every worker a goal a slash goal command and after the workers finish its plan is to go through and merge all of their calls them and verify that everything is working just know slash batch needs your project to be in git because that's how it gives every piece its own lane and there's one last thing they do that i honestly did not expect that same engineer runs her agent on a remote machine and steers them from her phone.
She even said she wrote parts of her talk while walking over from her hotel. And I do the same exact thing with my Mac Mini. Inside a Cloud Code session on my Mac Mini, I type slash remote control.
Then I open the Cloud app on my phone, go to code, and there's my session right here. Now I can check on it, answer its questions, and give it the next job from anywhere I want. Just know this needs a paid Cloud plan.
It won't work if you're paying through an API key, which is the pay -per -use way some developers connect the cloud. So here's where I land.
None of this is some magic prompt. It's all the boring stuff around Claude. Reviewing the intent instead of every line.
Giving each agent one thing to watch. Telling it no. Making it prove it's done.
Catching mistakes the second they happen. Giving every Claude its own lane and handing it goals instead of chores. And you don't need to be shipping 30 ,000 changes a day for this to work.
Set up even one of these tonight and your Claude code will be noticeably better tomorrow. So tell me in the comments, which of these seven are you setting up first? And as always, every prompt, command and setting file from this video is free in the first link in the description.
If you enjoyed this video, then leave a like. Or if you're new to my channel, then subscribe because I've got a ton more content like this coming your way. Oh, and would you look at that?
The algorithm gods seem to think that you're really going to enjoy this next video as well. So click it and I'll see you there.
The Hook

The bait, then the rug-pull.

Anthropic's engineers stopped reading every line of code, and the video shows why that is not as reckless as it sounds. Sharbel A turns seven of their habits into commands you can run in your own Claude Code.

Frame Gallery

Visual moments.

One-click upgrade to your Google

Get more breakdowns in your search results

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.
Watch next

More from this channel + related breakdowns.

41:10
Theo - t3․gg · Review

Finally a Good Small Model

A 41-minute teardown of Claude Haiku 5.5: the price sheet, the 100,000-token cliff hiding under it, and the one job a cheap model is actually good at.

October 9th