Hey, this is the definitive Claude Code

course for advanced users. I use Claude

Code and AI agents in my own business

everyday to generate over $4 million a

year in profit. I also teach around

2,000 people how to use Claude Code and

other tools to improve their lives both

personally and business. Okay, so this

course is going to assume a foundation

of Claude Code experience. It's not for

total beginners, but if you are total

beginner and you happen to stumble on

this course, that's okay. Just look over

my left shoulder here, click that

button, and then I have a 4-hour guide

that will walk you through everything

you need to get to the point where you

understand what I'm about to say.

Assuming you're still here, no fluff,

here's what we're going to cover. Let's

start with an advanced look at

Claude.mds and system prompts, and learn

how to optimize these to actually

improve quality, which is simpler than

you think. We'll then cover agent

harnesses and how to build larger

projects with Claude Code. After that,

we'll chat agent teams and other

examples of extreme task

parallelization. Then we'll do skills,

sub-agents, and other forms of

organization. After that, I'll cover

Carpathy's auto research approach for

improving stuff progressively over time,

and a few actual use cases you can apply

this to, not just fancy demos. We'll

then talk browser automation, the major

players. We'll do computer use, browser

use, and which tools to apply to

different use cases depending on what

you want. I'll then cover how to deal

with performance fluctuations in Claude

Code because they do happen, as well as

some alternatives that you guys could

use and ways to bundle in multi-agent

orchestration into your workflow. We'll

then cover workspace organization, so

for personal, business, and then even

client projects assuming you're selling

the sort of thing as a service. Security

for larger projects, we'll chat stuff

like the recent auto mode. We'll talk a

little bit about OAuth. And at the end,

I'll finally round it out with a

discussion about where I think Claude

Code is going and the future of work

more generally. Hopefully you're as

excited as I am to level up your Claude

Code skills. Please use the bookmarks

and chapter headings as needed to jump

around the course. Subscribe to the

channel, and let's get into it.

So for most of the course, I'm going to

be building directly using the Claude

Code extension inside of Antigravity.

That's this over here. If you don't have

Antigravity installed, this isn't

installation tutorial, but get that from

Google's official antigravity.google

website. Then head over to to

click on Claude Code for VS Code, give

that an install, and then everywhere you

go, you'll have this little Claude logo

that you can use to spin things up.

After a brief login, you'll have more or

less the exact same layout that I do. I

want you to know, though, that the

Claude desktop app is also getting

better and better by the day. And

because Claude is attempting to get you,

obviously, on their infrastructure as

opposed to on your own, they're just

continuously adding new cool features

that allow you to do things like mobile

development and so on and so forth. So,

everything I'm going to show you today

works in both the Claude Code tab of the

Claude desktop app, also works natively

inside of a Claude Code's extension with

an anti-gravity or some other, you know,

IDE-like thing. So, if you're

intimidated at all by the way that I've

laid things out, what all these

different folders mean, and how they

collaborate in order to improve your

workflow, I'm going to cover all that in

this course. First, though, we're going

to cover claude.md and other advanced

system prompts. Basically, how to set up

your system prompts in a very efficient

and effective way, both to save you

financially, but also to improve the

quality of your outputs, and

significantly minimize the amount of

time it takes to build anything. So,

what is a claude.md really? Well, as far

as I could tell, it's four things. The

first is it's a form of knowledge

compression, okay? And when I say

knowledge compression, what I mean is,

instead of Claude having to read through

your entire workspace, you know, file by

file, like for instance, over here,

instead of it having to open up every

single folder here, every single one

here, read through all of the files and

so on and so forth, to be able to reason

and then make high-level declarations

about your code base or folder,

what your claude.md

okay, is it basically just compresses

all of that down into a highly succinct

summary of what the heck is going on in

your freaking folder. So, that the next

time you say, "Hey, what was that file I

made a couple of weeks ago about X, Y,

and Z?"

Claude doesn't have to look through

every single file in your code base, you

don't have to spend a tremendous amount

on tokens, and you also don't have to

wait a long time. It's just sort of

baked into the claude.md, or at least a

reference to where the file lives is

baked into the claude.md. Um so you can

actually like reason with it at a

superficial level, at a bird's eye

level, as opposed to actually going down

through the weeds.

So that's sort of like the very first

thing that I'd say, you know, a

Claude.md is.

The second thing that a Claude.md is is

it's obviously your own preferences as a

user.

And what you'll find is, you know, more

or less every time Anthropic updates

Claude code, you have better and better

baked-in native preferences and

conventions for things like, you know,

delivering you file paths or

how to deal with like documentation or

debugging or how to update itself and so

on and so forth. But obviously, Claude

code lags behind these preferences a

little bit

because they have to see what users are

actually using it for and and you know,

like they collect that information and

figure out what ways to make things more

effective. So if you're an advanced

user, as I am, you'll have a list of

these preferences and conventions that

improve your user experience. And

advanced users will always have just

some better preferences that kind of

adapt their own workflow as well as, you

know, programming conventions, um ways

to organize information, structures, and

and that sort of thing. Okay? So it's

both a form of knowledge compression,

but it's also preferences and

conventions that are not natively baked

in that you get to decide on.

The third thing that Claude.md is is

it's a declaration of capabilities.

Now, I don't know how many times this

has happened, but if you do not have a

substantiated enough Claude.md, and then

you have, let's say, a skill somewhere

in your your workspace where you have

just some knowledge sort of floating

around in a few files.

And you say, "Hey Claude, do XYZ thing

for me. Go, you know, find some

knowledge on XYZ person or go do some

research or you know, compile a plan

using XYZ framework."

Half the time, okay, if it's not in your

Claude.md, Claude will just look at you,

metaphorically obviously, it doesn't

have eyes yet. And it will say like,

"Oh, like I don't have a built-in way to

do this. Sorry, what were you referring

to? Do you want me to build something

from scratch? I'll happy to do it."

And this this sort of slow down loop is

completely unnecessary. And so what

Claude.md allows you to do is basically

allows you just to itemize, okay?

You know, everything your agent can

currently do within your workspace and

you can make that really clear. You

could say, "Hey, you currently have

access to this functionality. You can do

this. Hey,

you know, you can build a full step plan

that lasts 10 or 15 minutes and then

execute it on an autonomy." In fact,

that's my that's my preference or the

convention that we're using. You know,

you can call this API, you can call this

database, you can retrieve all this

information, you can act autonomously

using browsers and so on and so forth.

The reason why that's important is

because as agentic as Claude is,

hopefully we're we're all still on the

same page here

about this fact. Claude still lacks a

lot of agency, okay? If you ask it to,

you know, help you do something or if

you ask it how long it would take to do

something, it'll often significantly

underestimate or overestimate because

it's not really factoring in its own

agentic capabilities. Like I asked it

the other day, "Um hey, you know, how

long is would this XYZ thing take to

build?" And then it was like, "About 3

months or so because you would have to

build this, you'd have to build that,

you'd have to build that." And it's

obviously like, "No, I don't have to

build that. I'm asking you to build it.

You could build it in 5 seconds, so why

don't you just go ahead and do it?" Or,

you know, you're having it do some API

stuff and then it sends you a little

command line interface prompt and it's

like, "Hey, just pump this into the

terminal." It sort of needs reminders

that no, I don't have to do this. That's

why I'm asking you to do it. So, you can

actually do all of this stuff, Claude.

Declaring capabilities in this way,

whether it's your own personal like

tooling or workflows or whatever or it's

you know, Claude understanding that it

has the ability to do things that it

might not realize at first glance is

pretty important.

And then finally, the fourth thing that

a Claude in MD is is it's a log of

failures and successes. What I mean by

this is as you accumulate various files,

as you accumulate, you know, bits of

code through your project and stuff like

that, every single one of these things

is hard-won. You didn't get them for

free. Realistically, you spent tokens

and then your time, which are soon to be

two of the world's most valuable

resources. And so, because you spent all

this time and energy, it is more

efficient for you to take all of the

learnings basically from every single

piece of development or so, every single

action Claude does And then insert it in

its next system prompt, then just have

it restart kind of from scratch every

time. You know, viewed another way,

mathematically, if this is the total

space of all of the different possible

things that Claude could do when you

say, "Hey, do X."

What this log of failures and successes

is doing is it's basically carving out

big chunks of this theoretical solution

space and it's saying, "Hey, no, you you

don't do anything over here because

we've already tried all this stuff over

here." This kind of looks like a planet.

Meaning the only things that you can

actually try, the only things that you

should try are kind of the things that

exist in between.

Okay, so basically what this log of

failures and successes does

is it just allows you to immediately

cross out like 80% of all possible

things Claude could do cuz it knows it's

actually tried that in the past and then

in that way focus its time, effort, your

tokens, your money, and then your your

energy on the 20% that actually matters.

So, these four will exist in different

sections in your Claude MD. They'll also

exist at different levels, both global

and local. So, what I'm going to do next

is run you guys through high ROI ways to

combine these four sort of principles

behind system prompts and then apply

them both in global, local, and then

also give you guys sort of like a little

workflow loop that you can use in order

to understand how to update this

effectively. And this isn't just going

to be some big long system prompt that

I'm giving you guys like I think we

probably all seen floating around

various sources in the internet. The

reality is like Claude MDs are highly

personal devices.

But these are going to be a list of

short principles that will almost

certainly help you design better

projects and then get more done, whether

economically or otherwise. So, the way

that all this is organized within Claude

code is using two different scopes,

global and local. And if you didn't

already know, basically there are a

variety of different places that Claude

code upon initialization will look to to

get the prompts that is injected at the

very top of its context window.

Okay, the two big ones for us are the

user over here, which is equivalent to

your global, and then also the project

over here, which is equivalent to your

local. And so basically what this means

is if you have a file called Claude.md

all caps that exists within this folder

on your computer somewhere,

it'll load that up on every Claude code

session whether or not you're working in

the same workspace or another one.

Now, if you have a Claude.md capital

Claude. lowercase md located within a

dot Claude folder within your specific

repository directory, then it'll also be

loaded. And in this way, you know, you

sort of have like a global precedent

that's always injected at the top of

every single thing, okay? No matter

what. And then you also have sort of

smaller little um you know, local

Claude.md that's also injected. And

collectively when I say, you know,

system prompts from here on out, really

what I'm referring to is I'm referring

to both of these. I'm not just referring

to one of these.

And because global is injected on every

single run, there's sort of like

different strategies in order to divide

the four things that we just talked

about. Um basically on your global

Claude.md, makes more sense to put

high-level reasoning and then your own

personal beliefs. And then in local

Claude.md, makes more sense to insert

local low-level knowledge. So, stuff

like I just talked about with the um

workspace itself. So, you know, if I

were just enumerating all of these

things, up here, okay, you'd put your

preferences, like your global

preferences. These could be things like,

"Hey, you know, when you return a file,

I want you to return the absolute file

path to click on it because whatever

editor I'm using doesn't really have uh

take that into account." You know, it

could be things like uh programming

conventions. "Hey, I want you to program

using I don't know, object-oriented

programming." Or, "Hey, I want you to do

like functional programming in in Rust."

"Hey, when I ask you to develop a new

project, I always want it done in Rust

as opposed to, you know, Python." Or or

something like that. Alternatively, it

could be stuff like uh "Hey, you know,

if I ask you to do something using a

tool you're unfamiliar with, always go

and read the API documentation first

before attempting to start because every

other time that you've attempted to do

something without the API documentation,

you typically run into loops, you waste

XYZ tokens, so make sure to load the API

docs. By the way, if you can't load the

API docs through uh you know HTML, then

make sure to like load up a a Chrome

DevTools MCP server to go and get that

stuff, even if it's dynamically loaded

through JavaScript. Okay, so these are

high-level reasoning strategies. These

are your own preferences. These are your

own conventions. And then also um these

are going to be just sort of like agency

capabilities, so stuff like, "Hey

Claude, you can actually do X, Y, and

Z." If you believe that you can't for

whatever reason and you're wrong, you

can absolutely, you know, go and do

whatever you want. The local low-level

knowledge, okay, this is going to be

stuff like backslash init, which I'll

show you guys in a second. Um so it's

going to be like a compressed version

of all of the knowledge on your

workspace. Instead of Claude having to

in the future go through every single

file, it'll just be able to read the

Claude on the data sort of a loose

understanding, like, "Okay, what's

where? Why have we built this? What's

the purpose of this workspace?" and so

on and so forth. Some additional things

you can do are things like context about

you and your goals and your own

reasoning strategies, your own

communication styles. So I'm going to

give you guys examples of my own Claude

on the data in a moment where you guys

see that I actually give it a lot of

context about who I am and why I want

what I want. Um I'll run it through, you

know, reasoning strategies that I

personally use that have, you know,

yielded me a lot of success in the past.

They may actually not necessarily be the

optimal reasoning strategies, but which

I tend to understand and because I'm

communicating with this thing in every

freaking every 5 seconds nowadays, I'm

I'm better capable of understanding what

it's putting across if we use those

principles.

Um and then yeah, those high-level

preferences and then generally good

token conservation strategies. Whereas

with the local, you know, it's a

description of the project where

everything is low-level preferences,

like specific API docs and usage. If you

are using, you know, the GoHighLevel API

to do some project or whatever, you can

actually just like have the whole

GoHighLevel API existing within your

project. That'll minimize the number of

tool calls that um Claude has to make

to, you know, some sort of research

sub-agent go and do the thing for you.

Instead, it can remain local, reduce

total token usage, and then also just be

faster and then more accurate. And then

capabilities within the project. And

then that takes me to the local

workflow. So And then that takes me to

workflow. So, there's two sort of

workflows here that I want to talk

about. There's the local workflow, and

then there's the global workflow. And

the local workflow is going to be

responsible for updating our local

Claude and MD, and then the global

workflow is going to be responsible for

updating our global Claude and MD. Like,

it'd be nice if I could just give you on

a silver platter a bunch of stuff to put

in your Claude and MD, right? I think

that's what a lot of people want. But,

you're going to end up a much better

both developer and then a much more

productive person if you understand the

principles at play here and develop your

own.

So, initially to start, um anytime

you're developing anything in in Claude

code or whatnot, obviously you need to

plan your feature. And I say feature

here loosely, you know, I use Claude

code as basically like my business

assistant nowadays, and so I use it to

do anything from reading my emails to

grab me new summaries in the morning to

to communicate with XYZ people to design

me, you know, uh websites and so on and

so forth. So, feature here is really

loose. I'm not just talking like about a

five-coded project. I'm talking about

anything.

But, what you do is you start by

planning a feature, right? And then if

you think about it logically, what

Claude does next is it instantiates the

feature. However, over the course of

planning and instantiating, okay, it

will fail a bunch.

It'll also succeed a bunch of other

times. And ultimately, there'll be a

giant list of learnings between, you

know, step one to step two. And so, what

you do after you instantiate is you

actually compile all those learnings,

okay, into some efficient um high

information density thing that doesn't

see a lot of tokens, then use that to

update the Claude and MD.

And so, this is your local workflow for

managing your system prompt. And you

basically just do this every time. You

plan something, it'll do a bunch of

failures on the way, then you'll

instantiate it, you'll take all those

learnings, update your Claude and MD.

That way, the next time you plan a

feature, it'll already have all the

benefits of the failures, plus, you

know, any additional things that it

learned along the way.

And so, the first time around this loop,

you know, it might take uh I don't know,

let's say X time to develop a feature.

The second time around this loop, you

know, maybe shaved

off 10% of the the the search space, and

it's a lot faster. The third time you

go, maybe it takes 0.8X. Okay? And so,

like, the time will just get faster and

faster and faster every time until

eventually you develop things um using

Claude in a similar way that you would

develop if you were not using Claude.

Now, here's where it differentiates

between the global workflow. What

happens is, you know, as you accumulate

a variety of failures, successes, and

learnings, and so on and so forth, your

current local Claude MD gets really,

really good. After all that's done, what

you do is, you know, after hundreds of

these runs, okay, you can either pull a

slash insights feature or you can run

that yourself. Let me show you guys how

to do.

What this will do is this will compile

not like at a local level, but at a

global level all of the things that

Claude attempts

uh pretty consistently and then

struggles with pretty consistently. You

know, it's like, "Oh, hey, I noticed

that not only on that one project, but

also on more or less every project,

Claude consistently goes down silly

rabbit holes it doesn't need to um and

then tries coming up with its own stuff

instead of just consulting the docs."

And so, you know, after this is done

three or four times, obviously there's a

trend, right? So, what you can do is you

can take that information and then you

can pump that in your global.

Um after that, what I'd recommend is is

I'd recommend you manually review

because Claude is an agent at the end of

the day, and the more AI steps you have,

the more you compound probabilities, and

the less likely that it becomes that

Claude itself is making like the right

call. You know, if like Claude is

independently 90% successful on a task,

and then you give it to another Claude

which is 90% successful to a task, and

then you give it to another Claude, you

know, what you're really doing

mathematically is you're going um 0.9

raised to the three. And if you just do

a little bit of math there, that's not

90%, right? 0.9 to the three is 73%.

And so, I guess what I'm trying to say

is um the more steps you have without a

human in the loop here, uh the lower the

likelihood that your total determination

will be correct. And because this is

your Claude.md, it is your global

preference and convention file, it will

be applied to every future project.

Meaning, if there is a place you should

spend human time on, it is this exact

step here. So, I'd recommend manually

reviewing that. Once you manually review

that, then you can add some high high

ROI bullet points to your Claude.md and

so on and so forth, you know, just like

a high information density version, and

then you can actually update the the

Claude.md. And And you can repeat this

loop a few times if you'd like before

finally going back to the local loop.

And so I mean it's kind of like I don't

know what you want to call it, like an

infinity sign, okay? Kind of starting

here, you're going

kind of like this, and then you're kind

of looping back, and then you're just

doing this over and over and over and

over and over again. Obviously, you're

going to spend a lot more time in this

loop, but eventually you're going to go

down to this loop.

And this is how I personally develop

using Claude.in.md. This is why my

workspaces are super tight, and then

instead of me, you know, using a vanilla

version asking it, "Hey, go do X, Y, and

Z," and then it like stumbles around,

uses 20,000 of my tokens, and god knows

how many of my dollars. And when I say,

"Hey, I'd like you to do X, Y, and Z

thing. I'd like you to scrape some

leisure over." It already has all that

stuff baked in, while still being

flexible enough that I could change them

anytime that I want. Okay, so next, I'm

going to show you guys basically my

workflow every time I start with a new

project, assuming that I've already done

a little bit of work in the project. I

don't have a Claude.in.md, and I don't

really have any of that like advanced

tooling or system prompt harnesses stuff

set up. This is exactly what I would do

step by step. So, first of all, you need

to open up a folder. I was just lurking

about to my toes earlier. That is sort

of embarrassing.

But anyway, in antigravity, just go open

recent, and then I'm just going to open

up something. Why don't I do you know,

antigravity example right over here.

And you know, when I'm in this folder

right over here, obviously there are a

bunch of different files and, you know,

configurations. This one is using Gemini

for a while.

So, what I'd like to do next, I'd like

to open up a Claude code. And so, I'll

click on that button over here. Let's

close out the agent window cuz I'm team

Claude at least for the moment. Thank

you, space invader.

And really like the first thing that you

do is, you know,

you develop on your own. I always

recommend just like don't try baking in

any opinions into a Claude.in.md until

you've at least developed with out a

Claude.in.md or some sort of advanced

system prompt for a little bit. And the

reason why is because like you'll find

Claude's actually really good out of the

box. As mentioned, they're incorporating

more and more of these features natively

within it.

And so, like it's it's great. It's not

like the harness that makes the

intelligence. It's obviously the

intelligence inside of it that sort of,

you know, communicates with your system

prompt to to get good. But right now,

it's already fantastic. Anyway, after

you've done some developing for a while,

this is obviously some sort of website

here. It's like a template using Veet.

Just go {slash} init, just like that.

And basically, {slash} init will go

through, read every single file in your

workspace, which I'm currently doing

with fast mode, if you're wondering why

this is probably faster than than what

you're doing.

And then at the end of it, it'll come up

with a basically like a highly optimized

Claude.md that succinctly and

effectively summarizes the placement of

everything here. And you can see it just

generated one called Claude.md. So,

comes with the build dev lint commands.

Note that no test framework exists from

architecture review key dependencies and

their roles, then some style conventions

as well. So, now I'm going to open up

this Claude.md. Okay, and why don't we

just move this over to the main window,

so it's a little bit easier to see. And

you can see that more or less it it just

at a very high-level summary takes every

single line in my entire workspace, then

it just significantly increases the

information density at a cost of like

total comprehensiveness. So, what I have

now is I is I have a summary of

everything.

So, that means is the next time that I

ask Claude anything about my workspace,

okay, the next the next go around,

um I don't actually have to like have it

like run through every single thing in

the file. Like, for instance, what I'm

going to do here is I'm just going to

call this like

um I don't know, xyz.md.

Or actually, you know, why don't I just

delete this for now.

You know, if I had asked this Claude

version something

about dark mode, "Hey, what are my

opinions on dark mode?" It's going to

check its memory for notes on the

preferences, not going to find anything.

And notice how it's just going to say

there's there's there's nothing at all.

So, what I could say is read through

whole project and find my preferences.

And now what it'll do is it'll, you

know, essentially launch some sort of a

genetic search with readmes and so on

and so forth until it finds something

about dark mode. In this case, it was in

the Gemini.md.

Um but I want you guys to know that, you

know, whether or not you have it in a

Gemini.md or it's just sort of written,

it'll eventually figure it out.

Now, the issue is, you know, how what

what sort of usage did we just uh do in

order to get that?

If I just scroll all the way up here, uh

type {slash} contexts, you know, the

system prompt was 0.6%. Free space was

messages was 0.9%. So, that last message

chain there with the tool calls and

everything like that might have

realistically taken like 5 or 6,000

tokens. I don't need to do that sort of

thing ever again. You know, if I bring

that back and go cloud.md and then if I

just open up a new instance and I say,

"Hey, you know, what are my opinions on

dark mode?"

Obviously, it's going to read the

cloud.md and you know, instead of me

having to use god knows how many tokens.

If I go back to {slash} context, you

know, you see that I've now you only use

0.2%. So, basically save myself what's

that like 6,000? And let me tell you

these cloud tokens ain't free, man.

Anthropic's increasing the price uh

pretty aggressively especially recently

when they realized 99% of the world is

now operating using their infra. So, I

guess what I'm trying to say is I'm

spending like literal like money, but

I'm also spending time and to me the

bigger thing is time. But, what are some

other things asked? I mean, like think

about deployment. If you have any sort

of like front-end or full-stack

experience, you'll know like, you know,

usually the flow is you start with a dev

server. You use that dev server via npm

run dev or equivalent to like figure

things out on your uh you know, develop

various features and so on and so forth.

Then you'll build, you'll do some sort

of linting and then once you're done,

you'll have to like preview it, you'll

you'll push to production or or sorry,

you'll push to staging and then verify

that and then eventually you push to

production, right? Like obviously, this

is something that I could have learned

just by going through the folder

structure, seeing source, public, node

modules, all these things. But, you

know, I'm just listing them out over

here so that instead of you having to

actually read any of that filing or

tooling, you know, you can do it in god

knows how many what's that? Five tokens,

six tokens or something immediately.

Likewise, you know, I see where things

are laid out. So, in this case, this is

obviously a single page application. The

entire app lives in a single component.

Nav here or services project sections

all markup and logic is here.

Um it is evident if you were to actually

click on app.jsx and then scroll through

that that is the case. But, look at how

many more tokens app.jsx is versus, you

know, just that brief little description

in uh cloud.md. If I were to copy and

paste the entirety of this into

something like a word counter, you could

see it's 827 words approximately 1,100

tokens. Okay, if I go back to my

cloud.md, like how long is how long is

this? It's 22. So, that's a what? 45x

compression ratio. That sort of

compression is how you ultimately get a

significantly better and more effective

clot because you are not shoving a

tremendous amount of tokens at the

beginning of any query.

Um and you know, as we hopefully know,

uh token length tends to scale inversely

with the quality of the output. The more

tokens in a context window, not only the

more money are you spending, but

typically the lower quality of the

results are. So, just avoid all that by

initializing and then storing a bunch of

information about, you know, what the

project is on. Uh you'll be you'll be

much happier for that. But, you know,

slash init isn't the only thing that I

would do. From here, I'd actually start

importing a couple of my preferences and

then things that I've tried. So, I don't

know, let's just say I'm going to remove

the gemini.md for simplicity. Let's just

say I'm developing a new feature and um

actually, why don't we just visualize

app? I don't know okay, what it looks

like. Let me actually take a look at

this thing. So, it'll run the dev server

so I can see in the browser. And

immediately I'm thinking like, "Hey, you

know, this is actually kind of

inefficient." When I say visualize app,

I basically just want you to launch it.

So, store in your cloud.md that when I

ask you to run the dev server or open

the app, I just want you to open it in

my Chrome instance as well. I don't just

want you to run the dev server. You

know, basically, next time I say this, I

don't want it just to like say, "Hey,

the dev server's here, give it a click."

And then I'm like, "Okay, can you just

open it cuz I'm already here?" Um I just

want it to open it automatically, right?

Okay, cool. And I see, you know, it's

kind of over here. Um so, that's nice.

Definitely not a fan of the design. I

don't like how it scrolls through. I'll

just say, "Hey, I want you to

significantly improve the perceived

visual quality of the application. Go

and look up uh you know, the Apple

website and then compare that to our

website. Make some changes that just

improves both the perceived visual

cohesiveness, quality, etc." Must have

been a Gemini website. Anyway, let's uh

see what it does here. It's fetching

Apple site for design reference, reading

the current app code in parallel. And

now it's just doing a bunch of updates,

editing the CSS, nav-link,

hero-background, and so on and so forth.

And you can see that it is actually

updating the site. I mean, it's doing it

currently in real time, but uh it's

looking significantly better. It's also

picked up some new colors and so on and

so forth. Now, what's cool is it

actually just opened up a second uh

project for me right over here um

because earlier on I stored my

preferences that I don't want it to just

give me the link. I actually want it to,

you know, open open stuff up. So, that's

nice. Obviously, we have better

designing and stuff like that. But, the

key part here is when I say, "Okay,

great. Nice job. How could you have

arrived at these conclusions and done

everything that I just asked you to do

faster?" Okay, and now look, we're

already at the point where we're capable

of optimizing a fair amount of these

design issues. Instead of 20 edit calls,

which is what I did before, what I could

have done is just do one right call. So,

the reason why that took like 30 seconds

or so because it was editing the CSS

file line by line across 20 sequential

tool calls. I should have read the file,

rewritten the whole thing in my head,

done a single right to replace index.css

in one shot.

Yes, I'd like you to save this in the

cloud.md. Do it as a user preference

section. So, asking it questions like,

"How could you have arrived at those

conclusions and done everything I just

asked you to do faster and for fewer

tokens?" is pretty powerful. Doing this

consistently as you develop and design a

project and then having a running log of

changes to the cloud.md is also quite

valuable.

Another thing you can do is you could

set a meta prompt in the cloud.md and

that's personally what I always do. That

basically says like, "When you have made

a mistake, I want you to update the

cloud.md with a running log of things

not to do next time.

When you've made a mistake, I want you

to update the cloud.md with a running

log of things not to try next time."

Essentially, I want this to be almost

like a mini experimenter's or research

person's notes that shows what a future

cloud instance should not do while

working on this project. Update the

cloud.md to reflect what I just said at

the very bottom. Okay, now it has a

section called lab notes what not to do.

This is going to show a bunch of

failures as well as learnings and

successes and so on and so forth. And

we're already honestly like halfway down

the loop. Now, this is a very contrived

example because I'm literally just

building a website. But, imagine that,

you know, instead of just a website,

you're building a workspace that is

meant to contain all of your business

basically entirely. All of your SOPs

it's meant to contain all of the work

that you do on a daily basis. It's meant

to contain your to-dos and so on and so

forth. Having information like what I

just showed you for this project would

be invaluable across more or less all

levels of both development and then also

productivity. And that's personally what

you should ultimately be working

towards.

So, anyway, we can make this as

complicated as we want, obviously, but

hopefully you guys see that loop at

work. We plan a feature, so we just did

this. It was simple enough that we

didn't need to use a dedicated plan

mode, but obviously I still one-shotted

it. After it implemented the feature,

along the way it did a few things that

realistically could have done better.

So, what do we do after? We take those

learnings, we compile them, and then we

update the Claude and MD. And this is

sort of a meta example since I literally

was doing it while I was building the

Claude and MD, but hopefully you guys at

least understand conceptually I'm sort

of what you do. After four or five of

these runs, there's probably a fair

amount of stuff here that you can take

advantage of. And that's where an

insight run would make sense. So, let me

actually zoom in and then just delete

this so you guys could see.

In case you didn't know, insights is a

simple slash command that basically runs

a bunch of sub agents across all of your

Claude conversation history. The benefit

to that is now not only are we running,

you know, and and changing our local

Claude and MD,

we're also evaluating all of like the

patterns in communication that we've had

with Claude and MD over the course of

the last, I don't know, could have been

like few days, could have been months,

could have been, I mean, years depending

on how soon or late rather you are

watching this video. So, um just like we

optimized our local Claude and MD, now

we can start optimizing our global. And

while it's chewing away because insights

does take a fair amount of time, okay,

I'm just going to create a new file

here.

I'm going to call it global Claude.md.

I'm just going to give you what I would

consider to be, at least as of the time

of this recording, probably like some of

the higher ROI principles to make sure

to include. Um I include this in my own

global Claude and MD because I think

it's just very very valuable. So, I'll

say global Claude.md.

This is inserted at the beginning of any

conversation with Claude across all of

the user's workspaces. So, first I'd

have a profile section, so this is a bit

about Nick.

So, you know, I don't know, it'd be like

Nick is a 30-year-old

and J

high-performing

internet entre

preneur.

He runs a YouTube channel at 350

subscribers or 350 by the time I make

this uh publish this video. 350,000

subs, an Instagram channel,

and so on and so on and so forth.

Okay, and so I have a bunch more

information which I've taken from just a

couple of other systems I built. Um this

one here is Nick is a 30-year-old and

Jay, here's his revenue. So, here are

all the different things that contribute

to my revenue. Here's some churn math,

um some of the companies that I'm

currently owning, uh some teams, right?

So, it's me, it's an editor, it's a

LinkedIn newsletter person, it's a bunch

of AI agents, bunch of information on

YouTube as well as my goals, and then

ultimately I'm on Instagram as well. And

you're thinking like, Nick, this is

crazy. Why would you insert all this

information in your global Claude and

MD? Well, the reason why is because I

want this on every conversation that I

have with it to understand who I am and

to take that into consideration when

discussing things with me. I can't say

how many times I'm having a conversation

with Claude and because I don't have

context like this cuz I'm in a naive

thing with no personal system prompt

injecting the context when I know I say

something along the lines of, "Hey,

what's the best solution for X, Y, and

Z?" And then it says, "Oh, you're going

to want to do this solution." And then I

say, "Why?" And then it'll say, "Oh,

because it's the cheapest." Right? It

only costs 0.2 cents, whereas the all

other solutions cost $5. And I'm

thinking, "Well, if you knew a little

bit about who I am, you'll know that

money is not the primary bottleneck

right now. I prefer you to exchange my

my money for my time."

Um so, just giving it some like

high-level principles like that is is

very important. Anyway, while I was

doing that, um the actual Sherpa AI

Insights report um is ready. So, I'm

just going to tell it to open it so I

can take a look at it with you guys.

And now you'll see there's an HTML page

basically that runs through everything

about Claude, all of the insights across

all of the sessions. Looks like 1,000 AI

or 49 messages across 200 sessions. I

don't know where this chooses the cut

off. It looks like it's like about a

month or so.

Um although keep in mind that like this

is Claude code specific and I don't know

if this encapsulates all the

conversations I've had with it on the

desktop app, but pretty good. And you

can see here that, you know, there's a

bunch of context about what I work on

and and so on and so on and so forth and

how I use it and all this stuff.

So, the the important thing to do is

existing features to try section. You

can just copy this in the Claude code

and add it in Claude in MD. So, for

instance, when using Chrome DevTools MCP

or browser automation, always kill stale

Chrome processes in a clean profile

before starting. If the MCP tools fail

twice, stop and ask the user for

continuing to retry. Never waste tokens

on repeated failing browser calls. This

is actually quite valuable just given

how many times I have tried to have it

run, you know, Chrome DevTools MCP and

it's failed.

Um, same thing over here.

Same thing over here, you know, with

some face swap information and stuff

like that. You can copy all this in the

Claude and it will set it all up for

you, which is pretty valuable. As well

as it it can even go and build like new

skills based off of things that you

consistently ask. So, that's that's more

also what I'm doing here.

Um, anyway, the the value with this is

basically to like copy the entire thing,

go back here, paste it in.

Can say, "This is my Claude insights

file. It describes at a high level a few

of the obvious design patterns in my

thinking, and then a couple of the

issues that I've had communicating with

you and other versions of you. I'd like

you to distill this into a list of high

information density snippets that I can

paste into a global Claude.md to be both

token conservative, but also avoid most

of the mistakes that you typically

make." And I'll just press enter. It's

going to give me some information about

that. And over here, we actually have

the changes. And this is very high

information density, right? It basically

took a bunch and said, "Don't

overexplain, overengineer, add un-

requested improvements. When making

widespread changes to a file, use one

write instead of many sequential edit

calls. Speed matters. Don't fetch

well-known websites." Again, a rerun

browser automation and, you know, so on

and so forth. Just Just some high-level

stuff.

It looks like it just inserted that in

here, which is quite nice. So, now, what

do we have? We have, if you remember,

some context on me in the global

Claude.md. We also have some high-level

reasoning rules and principles. And

really, what we're just missing is some

um token conservation strategies. And

you could see this by uh you know, you

can go back

uh rewind the video if you'd like some

more on that. But, basically, you want

context about you, your goals, and your

reasoning strategies, some high-level

preferences about, you know, what it is

that uh it is currently doing that is

wrong that you would like it to fix, and

then some good token conservation

strategies like not docs first. So, what

I'm going to do is underneath

interaction rules, I'll also just say

oh, and what's really interesting I'm

seeing one of my rules are actually

directly contradicting some of the other

rules. Don't fetch well-known sites.

I'll actually just remove that.

Um that's the human in the loop part,

right? Just look to see if any two rules

directly contradict each other. Then

I'll say

when a user asks you to use a

non-trivial platform,

one for which you do not have contacts

in, always look up the documentation

first. You can do so by looking into API

documentation plus platform name.

After, if for whatever reason you can't

access the docs for JavaScript reasons,

launch a Chrome DevTools MCP Chrome

instance so that you could still copy

and paste all that data. No matter what,

if you're working on a project for whom

API documentation is available, you

should always go through the API

documentation to avoid 99% of the

errors. The tokens we spend reading the

docs will save us a lot of tokens in

trying to use things that don't work.

Cool. So, I'm going to copy that.

And now I have my global Claude in MD.

And you know, I could always just have

Claude actually insert that into the

global Claude in MD. Um I could also

just like go and find the find the

finder. So, I'm going to go to finder on

Mac. Basically, you can find your global

Claude in MD just by going to your Mac,

in my case users, I'm on next to arrive.

And then um there's a hidden folder here

which you can't actually see just right

out of the gate. You should be able to

go uh shift command I think it's comma

or period. There you go. Uh shift

command period. Once you're done with

that, you can scroll all the way down to

where it says Claude. And then over

here, um you'll see that there is a

Claude in MD that lives within that

Claude. So, what I can do now is I can

just reveal this folder in my finder,

compare it to that folder in my finder,

and I can actually just go drag and drop

this in.

Now I have global Claude, and I can just

remove this Claude.

And replace that with this Claude.

Awesome. So, now all future

conversations that I have with Claude

across all of my uh workspaces and all

of my folders will include the

information that I just provided. And

hopefully you guys see how simple it is

to run that loop. Um granted, this is an

informal loop. I'm not really showing

you guys like a simple formal streamline

process, but hopefully you see how easy

it would be to build that in again as

like a meta Claude.

Let's talk a little bit about agent

harnesses. So, agent harnesses, the term

anyways, gotten a ton of interest over

the last couple of months because it's

sort of new and exciting, but very few

people actually understand what it

refers to and what it means.

An agent harness, to be clear, is just

Claude code. Claude code is the harness

around the model Claude that enables it

to do things like call various tools and

get actual economically valuable work

done.

For those of you that don't know, um all

that like AI models are are just text

interfaces, right? It's just text in

text out. A harness is what turns

something that can only communicate in

text into something that is ultimately

capable of like controlling our

computer.

So, the way that I personally think

about the question, "What is a harness?"

is a harness is just everything that

wraps around the LLM that is not the

actual LLM itself.

So, in our case, it's Claude code. It's

the system prompt. It's the hooks. It's

the tools that it has access to, and

it's the parameters therein that control

things like when the memory auto

compacts, how many messages you can send

in a turn, what the total number of

token limits are, and so on and so

forth. For the purposes of this demo,

let's pretend that this over here is our

Claude Space Invader, okay? And so, this

is sort of like the the the large

language model itself. This is actual

Claude.

And so, Claude is obviously like a

galaxy brain intelligence. It's been

trained on god knows how many books and

blog posts and encyclopedias and so on

and so forth. But, you know, Claude is

sort of it sort of exists in this

boundary where it can't actually do

anything outside the real world unless

it's given the tools and the ability to

do so.

And so, um one example of things that

Claude has access to are said tools. So,

that's things like uh I don't know, the

ability to use bash, okay, use a

terminal, the ability to use I don't

know, grep, which is how it finds things

around your computer, and so on, and so

on, and so forth.

Another thing that it has access to,

kind of going back and forth, is some

form of memory ink, right? What it can

do is it can read, so it can read things

that are stored in this memory, and then

it can also write, so it can add, sort

of update things as needed.

You know, there's obviously also a

variety of other things here that it has

access to. And you know, if it didn't

have access to all these things, again,

it would just be like an agent or a

model, sorry, that exists in the box.

And so, that's really the difference

between, you know, LLMs and agents.

Agents are LLMs plus a harness, whereas

LLMs by themselves, large language

models, they can't really do anything.

They obviously um

operate entirely in the domain of

knowledge. So, just given the fact that

it's called a harness, you can kind of

think of it as, you know, I'm going to

draw a really crappy dog here. Put

another way, here's a really crappy

rendition of a what I initially wanted

to be Canadian dog sledding, and what

ended up being looks more like Santa

with a big fat beard riding a

questionable reindeer. Uh but basically,

you can imagine that like this right

over here, this is your LLM, this is the

actual model intelligence, and then you

over here, okay, this is your harness.

This is actually like the the code part

of Claude code that sort of controls it.

And so, the LLM wants to go in a bunch

of different ways, it wants to do a

bunch of things. What the harness does

is it just sort of narrows down its

direction. And you know, you can kind of

almost think of it like uh the barrel of

a gun or something like that, right?

Whereas, you know, back in the day, you

might have had like cannons, and then

you might have loaded those cannons with

big uh

massive cannonballs, and they're huge.

And what you'd do is you'd stuff some

additional gunpowder underneath and

stuff like that. And those cannons would

kind of, you know, despite the fact that

they were operating off the same

fundamental technology, which is

gunpowder, they might not really be able

to go so far. I don't know, let's just

say 50 m.

Nowadays, obviously, we have um this is

my really crappy gun drawing. With, you

know, more or less the exact same

technology, you put some sort of bullet

in there, right? But then, because of

the technology that surrounds the core

thing, which is the gunpowder, you know,

the bullet can go a lot farther. So,

maybe instead of 50 m, now it can go, I

don't know, 250 m or so.

So, this is how I this is how I think

about harnesses, okay? And I don't mean

to just show you a bunch of silly grade

school analogies, but it is important to

realize that like that is what um now

Claude Code really is. And because

Claude Code is a harness, obviously,

there are a bunch of other people that

have tried making their own harnesses as

well. Just like we have frameworks like

React and View and then Next.js and and

and Knox, we also have a bunch of

different harnesses that have been

developed that supposedly work on and

then improve on on specific aspects.

What are some of those aspects? Things

like security, right? Automatic

permissions, so plan mode versus default

mode versus the new enable auto mode and

then bypass permissions mode. You know,

there are some harnesses out there,

okay? There are some a gigantic SDKs and

stuff like that, not going to name any

names, but

um there are some of them that are

probably a little bit less secure than

others. Such that if they were to read a

Twitter thread that looked like this,

maybe they would actually execute sudo

rm -rf and delete your entire hard

drive, right? Bunch of examples of

people screwing around with this. This

is an example of Codex, which um you

know, being an extraordinarily competent

model, I can't really talk down too much

on. But this is an actual conversation

that uh you know, it had with somebody

that I found on Twitter. You know, the

model basically tried to running

something that was like rm -rf, which to

make a long story short, in case you

didn't know, just deletes everything.

And uh here it says, "Well, the shell

policy actually blocked the raw rmrf.

So, what I'm doing is I'm removing those

generated directories like in the shell

policy with a Python cleanup instead.

Same effect, less policy friction,

right?" It's just going to go ahead and

delete the entire thing. You know, the

the harness impacts a model's ability to

get things done. It also impacts

ultimately the safety. It impacts like

the memory and so on and so on and so

forth. And so, hopefully, at least now

you guys understand what the harness is

before I show you guys some examples of

different versions of it. Obviously

Claude code is the major harness today,

but there's a great blog post over here

by LangChain that more or less describes

a way to create different harnesses.

The model gets a certain type of context

injected into it prompts memory skills

or conversation. Then you also have

orchestration, things like Ralph loops

which is really big a while back that

was a different type of harness.

You know, there's a certain persistence

of data, actions, and then the ability

to both observe and verify so with

screenshots and stuff like that.

One harness that a lot of people are

using now is this sort of droid idea,

which was built by Factory AI. So droid

is like a publicly available harness

that you can run and download today.

pi.dev is also exploding in terms of

popularity. So whereas Claude code, you

know, obviously needs to run with Claude

infrastructure, right? Claude is the

model underlying Claude code. This pi

coding agent is sort of like the

open-source provider of it. You can feed

in more or less anything that you want

including Claude and then just have it

operate inside of this this harness. And

you know, what this does is it just

changes the way that we store memories,

it changes the way that we store certain

files. It's sort of like modifies, it's

almost like an alien or bizarro version

of Claude code in so far that it changes

a few of like the fundamental constants

like how long before context compaction,

you know, how to try different types of

solutions and stuff like that. Various

baked-in behaviors regarding Claude code

and and so on and so forth. And the

reason I'm covering this is because, you

know, this is something that was very

fundamental to Anthropic. The back end

of November the 26th, 2025 they wrote a

big long blog post called Effective

Harnesses for Long Running Agents, which

at the time kind of changed the game.

And I would say this is the beginning of

the kickoff of Claude code superiority

over most other harnesses.

And so, you know, here it describes

various different ways to work on long

running coding projects and manage

environments and stuff like that. And so

obviously this is something that's like

very fundamentally baked into Claude

code. If you want to understand Claude

code at an advanced level,

you can't get better than getting it at

a harness level. Okay, so you know,

obviously this is a Claude code course,

it's not another harness course, but you

should at least know what agent

harnesses are before you proceed to the

rest of the course because, you know,

the more understanding of harnesses you

have, I think the better you'll be able

to appreciate and then I digest and

ultimately execute on what I'm about to

show you.

Next, I want to chat a little bit about

parallelization, about things like agent

teams, about sub-agents, and a couple of

other ways of distributing work to

minimize the amount of time and effort

that goes into things while also

increasing the quality of the output.

Okay, so I say agent teams here, but

let's start with parallelization. A big

question that I think a lot of people

have is, well, first of all, what the

heck is parallelization, which is just

doing multiple things simultaneously

instead of waiting for sequential things

to finish. And then the second one is

like, Nick, why the hell should we

parallelize our agents to begin with?

And to that I say, have you ever, you

know, sent a long-running task request

to Claude code and actually had Claude

execute on something for more than a few

minutes? For the vast majority of the

time, you're just sitting there

twiddling your thumbs. Twiddling your

thumbs is not very economically

productive, so if I have ways to not

twiddle my thumbs, I will do so. And I

really, I guess mean is that autonomous

agents just take a long time to finish

tasks.

You know, when we started with this

stuff, or at least when I started with

this stuff last year, you know, Claude

could realistically work on things for

30 seconds.

The other day, I had Claude work on

something for over 15 minutes.

And so, if all I'm doing is just sitting

there waiting for it to do this

15-minute task, you can imagine that my

productivity is basically going to be

punctuated by me just sitting around

watching it, it does something, I get

the result, make some minor changes,

wait for another 15 minutes, and so on

and so forth. That's not very efficient.

So, parallelization allows us to reduce

the total amount of time by a factor of

at least a few, from 15 minutes to maybe

a couple minutes, so it'll be able to

work on smaller, more more

self-contained things.

Um the two will also just get power

quality.

Another thing is that many tasks feature

independent steps that can be broken

down. So, for instance, let's say I'm

doing some sort of task, okay? And this

is just like how long it would normally

take if you go serially. And so, the

option A is just to do what most people

do, which is where they'll do, I don't

know, they'll do step one, and then

they'll do step two, and then they'll do

step three, and then they'll do step

four.

So, that's 1 2 3 4.

This task over here takes 5 minutes.

This task over here takes 5 minutes.

Stack over here takes 5 minutes. And

this task over here takes 5 minutes.

What's the total amount of time kind of

collectively? Well, it's 20 minutes,

right? So, that's sort of A you know,

the serial way that most other people do

things. Well, guess what? Turns out a

lot of tasks don't need to necessarily

be like that.

If I just copied all of this stuff over,

okay? And then instead ran a couple of

these in parallel, so I actually had I

don't know, three of these

simultaneously and then kind of combined

all of them. If I did something maybe

more akin to this instead. Hopefully you

guys could see now, okay? Instead of

everything taking

you know, 5 minutes, 5 minutes, 5

minutes, and 5 minutes. Maybe what I'm

capable of doing realistically is this

takes 5 minutes.

This takes 5 minutes. And then the

integration step about these three which

were two, three, and four

only takes 2 minutes. So, what I'm doing

is I'm basically converting a task that

previously took 20 minutes and I'm

turning it into one that took 12

minutes.

Which you know, if you just did a little

ratio, 12 over 20 is equal to 3 over 5.

And so, what I'm capable of doing is

getting it down about 40% about 60% of

the total work. Hopefully you guys see

when you have tasks that can actually be

broken down in this way, aka a task that

you can expand and run simultaneously

through some form of parallelization.

Just makes more sense to do all three of

these things simultaneously rather than

one parent agent being responsible for

everything like doing one and then doing

two, then doing three, then doing four.

What we can do is we can take two,

three, and four, stack them on top of

each other, add an additional step five

called a synthesizer, and then take the

results of these in and do it do it in

like a fraction.

Um another big reason is that agents are

what are called stochastic, aka they

don't always return the same answer. So,

if I ran, you know, Claude five times on

basically the exact same thing. Every

single time I have a slightly different

response, okay? Every time I have a

slightly different response. And just to

show you guys what I mean by that, I'm

going to open up um my Claude code over

here, and I'm actually going to open up

three different tabs. Let me just

visualize this. Stick this right in the

middle.

Okay, and then over here, let me just

make sure that all these are operating

the same. I'm going to say, "I'd like

you to determine five ways to improve

this code base."

I'm just going to paste this across all

three of these. I'll paste, and I'll

paste. Now, I'm just going to run all

three of them. And I just want you to

notice sort of what's going on here.

Obviously, the first thing it's going to

do is try reading the key files, but

check out the different solutions

basically that it's coming up with on

all three of these different runs. So,

in the first run, okay, uh breakage

broken image paths, missing title and

meta tags, nav links hidden inside

mobile with no replacement, project

cards aren't actually links, no keyboard

focus styles or script to content link.

The second was broken image paths,

missing meta tags, no mobile nav, but

now look, placeholder links everywhere,

typo in footer.

Okay, and you can see that, you know,

basically the more times we run these

you know, agents, and then the further

away they get from the beginning, the

more they tend to diverge. And there's a

physical reason for that, right? Like at

the very beginning, if this is sort of

like I don't know, the total answer. At

the very beginning,

you know, red is pretty similar to

black.

But eventually, it diverges a fair bit.

Green similar to red, and then it

diverges a fair bit. Blue similar to all

these, but it diverges a fair bit. And I

guess the point that I'm trying to make

is like, you know, over here, uh let's

pick another color so it's pretty

obvious that these are all a bit

different. We'll do purple. Over here,

these this is sort of like the zone of

similarity, right?

But then after you make it to a certain

point, because of the multiplicative

nature of how large language models work

under the hood, they're basically

multiplying the statistical

probabilities of like one token after

the other after the other after the

other, uh you have massive divergence in

the end result. And so, you know, this

might go ABC, this might go BCD, this

might go ABE, this might go ABZ, and

this might go ACQ, or something like

that.

What you can do is you can actually just

run five times. And now notice if I run

this once, I'd only get A, B, C. But

because I've run this another time, I

got all the way to D. I run this another

time, I got all the way to E. You know,

if you would just count up all of the

different unique answers here, I have A,

I have B, I have C, I have D, I also

have E, I even have Q, and then I have

Z.

So you can see here that like I'm

basically getting 2.5 times the total

number of possible answers by running

things multiple times and then just

averaging out and taking all the unique

outputs, right?

That's really the the principle of

stochasticity. Because they don't always

return the same answer, if you

parallelize your agents, you can

actually run multiple times with same or

similar queries.

Uh and then you can actually have

different answers given to you that just

sort of live outside of the distribution

uh or average run, which is pretty

amazing. So I'm going to show you guys

how that works specifically with um

debate and stochastic consensus models.

If anybody's seen my Agentic AI course

on that, you'll know more or less what I

mean by that. I'm also going to show you

some fan-in, fan-out um researching

flows as well as some some sequential

pipeline handoffs.

Uh but really the the fourth and final

reason is because model performance

degrades as context increases. So the

shorter and the cleaner your context

windows are, typically the better the

results are as well.

Uh what I mean by this is, you know,

because the parallelization aspect

typically involves sub-agents, which I'm

going to show you guys a little bit

about, you get to avoid the problem

where the increasing length, number of

tokens, um leads to poor performance.

And so you know, if like on average or

this is more or less the relationship

between the number of things in your

context window and then the performance

of the model, uh we are going to we're

going to end up just almost always

staying right around here, which is the

zone of good. By the way, I just made

that up. It's not actually called the

zone of good. Hopefully you guys

understand the distinctions there

though. Um when you parallelize and then

feed tiny chunks of a problem to

multiple agents, they can all be at the

zone of good. You don't actually have to

like go all the way down here. It's not

just one agent that's doing all the

work.

Okay, so so what are examples of how to

parallelize in the first place? Well,

there's like a built-in function called

agent teams now in Cloud Code, which

does a fair amount of this. So I'm going

to show you guys some ways to do that.

But, I just wanted to chat a little bit

more generally without even going into

agent teams first before I show you some

demos. Um of like different ways that I

personally approach problem-solving and

I've seen some of the best and the

brightest use CloudCode for this sort of

parallelization.

And I'm going to call them common team

patterns, okay? Um essentially, there's

three main things I want to cover. The

first is the ability to fan out and then

fan in. And so, that's where you

actually spawn a bunch of different

research sub agents and then you have a

synthesizer sub agent which takes all of

their outputs. And then, um based off of

the outputs of that synthesizer, you can

do either more fan out fan in flows or

you could do some form of final

synthesis step. Okay, so what I mean by

that is like let's say before you have a

query and it's, you know, I want to find

the best, okay, absolute best APIs

for my feature, whatever the feature is.

It's X feature, I don't know, it's like

some app that generates things,

whatever. So, I want to find the best

APIs out there for this feature that,

you know, allow me to very quickly and

easily do the things I want to do.

We can imagine like if you were to do

this um in the old-school linear path,

what would happen is CloudCode would

spin up, okay, in the same thread

research on site number one

and then go on site number two

and then go site number three

and then go on site number four, right?

And what would be occurring the entire

time that we're going through all these

different websites?

Well, the length of our total contacts

would increase, meaning our performance

on average would also decrease, okay? In

addition, it's taking time. So, it's 5

minutes here, it's 5 minutes there, it's

5 minutes there, it's 5 minutes there,

and so on and so forth. Then at the end,

what it would do is it'd have a final

synthesis step, which I'm just going to

call S, which would basically combine

one, two, three, and four together,

which could take a certain other amount

of time, maybe another 5 minutes, before

finally giving you your answer.

And so, the cost of the answer, okay, if

you think about it as like almost like a

line item.

The cost of the answer is, you know,

first of all, 25 minutes, which is

obviously non-preferable to instant, and

then, you know, a fair amount of tokens

on poorer

quality outputs.

You know, you're probably going to end

up spending a similar amount of tokens

regardless, but you're spending those

tokens on poor quality outputs because

you're kind of you're kind of down here

as opposed to up here, right? You're

you're here where you don't want to be.

Now, what fan out and fan in is is very

similar to what I showed you guys

earlier. You have a research query, and

that's, you know, find best APIs.

And so, what it does is Claude Code

basically goes in and then immediately

spawns,

okay? Let's just say

four research agents.

And so, now we have research agent one,

research agent two, research agent

three, and then we have research agent

four.

Okay, and so, what we're doing is here

is we're we're we're fanning out.

These all operate totally independently

accumulating their own context windows.

Because they're new agents, they're

almost always in the zone of good. Maybe

they'll push a little bit farther beyond

that, but they're still pretty good.

Once we're done with that, what we do is

we do the opposite, which is the fan in,

and we feed all of those into a final

synthesizer agent. That synthesizer

agent now has a different prompt. The

prompt is not, "Hey, go do this

research." The prompt is, "Hey, here's a

bunch of context from a bunch of other

models that have already done the

research." Meaning the prompt has to be

shorter. We then apply high-level

reasoning strategies and principles to

make that a synthesizer as smart as

possible, and say things like, "We want

you to integrate anything that overlaps,

as well as any outliers, and then score

them slightly differently." And so, you

know, rather than being all the way over

here with our big thing, you know,

probably we're somewhere over here in

the middle, which means the performance

is going to be a little bit better. And

then, obviously, the synthesis step can

occur in approximately the same amount

of time as the actual research, because

you you spawn almost an infinite number

of sub-agents to go do research for you.

And so really what happened now is you

have 5 minutes here, you have 5 minutes

here. You know, just add these up, it's

10 minutes. And so not only are we

significantly faster, we're also a lot

higher quality because now we have all

the the data and information laid out to

the synthesis agent. More importantly,

there are different models that are

better at different things. And so

within Claude, you have not only your,

you know, heavy lifter, which is usually

the Opus models, but you also have, you

know, your Sonnet models. And then,

although not a lot of other people use

them these days, you also have your

Haiku models. And so what you can do now

is for the research, which consumes a

massive number of tokens, but

realistically doesn't usually need like

a ton of reasoning for it, it's more of

like data extraction, you use something

cheap like Haiku and Sonnet. And then

for the synthesis, you use something

like Opus. Because you're applying

different models at different steps, not

only is it um going to going to occur

much faster cuz Sonnet works faster than

Opus, so maybe instead of 5 minutes

here, it's actually, I don't know, 3

minutes, but then the cost is going to

be a small proportion of the money that

you normally would have spent, just

because of the way that pricing on

Claude works, right? Pay attention here

to the fact that Claude Opus, you know,

in this case, 4.6 is 5 bucks, Sonnet 4.6

is 3. So we immediately save 60% right

there.

And that's just your base input tokens.

That's not taking into account um you

know, like the the the the massive

difference in also output token cost and

so on and so forth. And obviously things

get even better if you go down to Haiku

and and so on and so forth. And so you

can formalize this as a skill if you

would like, okay? I'm not going to. I'm

just going to feed it in a simple

prompt, but um this will illustrate what

I mean. Let's say I'm right over here in

my project, okay? Let me just delete

this um global cloud.md because we don't

need that anymore.

Then I'm going to essentially, let me

just go back here and then copy the

actual text.

As I use a fan out

fan in and researchers synthesizer

approach

to research the question

how best should I optimize this

codebase? Minimum five subagents, use

Sonnet to do the research and

contemplation.

Individual contemplation, Opus to

synthesize.

So now, what's going to occur is rather

than we us just waiting non-stop for all

of these, what this is going to do is

it'll fan out six Sonnet research

agents. Each are going to investigate a

slightly different optimization axis.

They're all going to focus on slightly

different things. Then they're going to

synthesize all of those results back

together with Opus. If I zoom out, you

can actually see all six of them running

simultaneously. D- despite the fact that

we're not using this agent team feature,

we're just using the sub agent feature

right now.

Uh you know, all of these things

basically immediately are generated.

Their contexts are quite short. So I

mean, in the grand scheme of things,

this is a much shorter context than we

would ultimately accumulate in our main

agent. All of them are focused on

slightly different things, which are

obviously autonomously managed by that

orchestrator. And then finally, these

six agents can finish in a linear amount

of time as opposed to, you know, like

multiple one.

So this just finished the architecture

research. It's going to wait for the

remaining five agents now. All right,

and it looks like it just finished all

six research runs. So now it's going to