19:04Austin Marchese · Tutorial
Boris Cherny's 4 Step Playbook to 10x Your AI Productivity
A YouTuber translates Claude Code creator Boris Cherny's engineer-written adoption ladder, chat window to AI-native, into plain English.
August 17thThe argument in one line.
Every Claude Code workflow you've built is already a graph, and most run slow or break because they default to one step after another instead of the shape the task actually needs.
Read if. Skip if.
READ IF YOU ARE…
- You've built Claude Code skills or automations and want a vocabulary for why some feel slow or fragile.
- You're running multi-step AI workflows and suspect steps are waiting on each other for no reason.
- You want a structural way to decide when to parallelize, route, or loop instead of guessing.
SKIP IF…
- You've never built a multi-step AI workflow or skill — the framework has nothing to attach to yet.
The full version, fast.
Every AI automation is a graph, whether or not it was designed as one, and most default to a chain: one step after another. The video teaches the wait test (ask, at each step, does this actually need the result of the one before it?) to find false dependencies, then covers three shapes beyond the chain: the diamond (fan out to parallel workers, then merge), the branch (route to exactly one of several paths based on the input), and the loop (repeat until a check passes). Each shape has a matching failure mode: chains are slow and brittle, diamonds create false independence and silent failures, branches get over-engineered past about five routes, and loops can run away and burn tokens if there's no hard iteration cap.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 00:37
01 · Cold open
Claims a Stanford-adjunct course reframed his approach to Claude Code as graph engineering, not prompting.
00:37 – 04:56
02 · Layer 1: Graph engineering basics
Defines a graph as any multi-step process, introduces the wait test for finding false step-to-step dependencies using a research-report example.
04:56 – 05:31
03 · Sponsor: Fish Audio
Sponsor read for Fish Audio's S2.1 Pro text-to-speech API (voice cloning, emotion tags, MCP integration).
05:31 – 08:16
04 · The Diamond: fan-out, fan-in
Introduces the diamond shape: splitting a task to parallel workers and merging results, applied to the earlier research-report example.
06:04 – 07:21
05 · The Branch: skill routing
Introduces the branch shape: one input routed to exactly one path, illustrated with his own /improve-system skill that routes to different self-improvement actions.
07:03 – 07:48
06 · The Loop: validate the output
Introduces the loop shape: generate, evaluate, repeat until a check passes, applied to verifying technical outputs and an anti-slop review skill.
08:14 – 09:27
07 · The four graphs that matter, recap
Summarizes chain, diamond, branch, and loop as the four reusable building blocks, plus a subscribe/giveaway aside.
09:27 – 09:47
08 · Chain graphs: slow and brittle
Chains run one step after another and break entirely if one step fails; still the right starting shape for testing a new workflow.
09:47 – 10:53
09 · Diamond graphs: false independence and silent failures
Fanned-out sub-agents that secretly need shared context duplicate work or miss it, and the structure doesn't visibly break when one sub-agent fails.
10:53 – 11:21
10 · Branch graphs: over-engineering
Branching a single skill past roughly five paths is a sign to simplify or split it into multiple skills.
11:21 – 12:10
11 · Loop graphs: infinite loops
A client's unattended loop ran overnight and burned thousands of dollars in tokens; sets a hard maximum iteration count as the fix.
12:10 – 13:10
12 · The one skill underneath it all
Closes on structured problem-solving as the transferable skill, using his own move from mechanical engineering into a JPMorgan software job as proof, then points to a free walkthrough guide.
Lines worth screenshotting.
- Every AI automation, skill, or workflow you've already built is a graph, whether you designed it as one or not.
- The wait test: at every step, ask whether it actually needs the result of the step before it. If not, that dependency is false and the steps can run in parallel.
- A chain graph, one step after the other, is the default structure people reach for and the slowest, most brittle shape.
- A diamond graph fans a task out to parallel workers and merges the results, which can roughly halve total runtime on independent sub-tasks.
- A branch graph takes one input and routes it down exactly one of several paths, which is the structure behind 'skill routing.'
- A loop graph has AI do a task, evaluate the output, and repeat until the result passes a check, which only works if there's a real way to verify the output.
- Diamond graphs fail through false independence: sub-agents that seem parallel-safe but actually need shared context end up duplicating work or missing what the other one did.
- Diamond graphs also fail silently: a structure like this doesn't break outright when one sub-agent fails, which makes the failure harder to notice than a chain, where any broken step is obvious.
- Branch graphs get over-engineered once a skill tries to branch into more than about five directions; past that, the fix is usually to simplify or split it into multiple skills.
- Loop graphs without a hard iteration cap can run unattended overnight and burn thousands of dollars in tokens before anyone notices.
- Almost every workflow should start as a chain graph, because it's the easiest to test and experiment with, then get re-engineered into a diamond, branch, or loop once you understand where it's actually bottlenecked.
- The transferable skill under all four graph shapes is structured problem-solving, not any specific tool, which is why it carries across domains the way it carried the presenter from mechanical engineering into software engineering.
Every workflow is a graph, and most default to the slowest shape.
WHAT TO LEARN
Multi-step AI workflows are graphs whether or not you designed them that way, and the shape you pick, chain, diamond, branch, or loop, decides whether the workflow is fast and reliable or slow and fragile.
- Run the wait test on any multi-step workflow: at each step, ask if it truly needs the result of the step before it. A 'no' means the steps can run in parallel.
- Start every new workflow as a simple chain, since it's the easiest shape to test and debug, and only re-engineer it into a diamond, branch, or loop once you know where the real bottleneck is.
- Use a diamond shape (fan out to parallel workers, then merge) when sub-tasks are genuinely independent, but watch for false independence and silent failures where one parallel branch quietly does the wrong thing.
- Use a branch shape to route one skill down several paths instead of building a separate skill per path, but cap it around five branches before it turns into an over-engineered mess.
- Use a loop shape only when there's a real way to verify the output, and always set a hard maximum iteration count so an unattended loop can't run away and burn tokens overnight.
- The underlying transferable skill is structured problem-solving, not any specific AI tool, so the graph-thinking habit carries into whatever tool replaces the current one.
Terms worth knowing.
- Graph engineering
- Deliberately designing and optimizing the structure of a multi-step AI workflow, rather than only tweaking the wording of prompts inside it.
- Wait test
- A step-by-step audit of a workflow that asks, at each step, whether it truly needs the result of the step immediately before it; a 'no' means that dependency is false and can run in parallel instead.
- Chain graph
- A workflow where each step runs strictly after the one before it, in a single sequential line.
- Diamond graph (fan-out / fan-in)
- A workflow that splits into several parallel workers and then merges their results back into one output, shaped like a diamond.
- Branch graph
- A workflow with one input that routes to exactly one of several possible paths depending on what the input is, functioning as a router.
- Loop graph
- A workflow where AI produces an output, evaluates it against a condition, and repeats until the condition is met or a maximum iteration count is hit.
- Skill routing
- Using a single AI skill's branch structure to send a request down different internal paths, instead of building a separate skill for every path.
- False independence
- The failure mode where sub-agents in a diamond graph are assumed not to depend on each other but actually do, causing duplicated work or missed context.
- Silent failure
- The failure mode where a fanned-out workflow doesn't visibly break when one sub-agent fails, making the failure harder to detect than in a sequential chain.
Things they pointed at.
07:48tool/anti-slop skill
Lines you could clip.
00:00
“I need to stop prompting Claude. Instead, I need to start graph engineering.”
10:17
“He went to sleep. And when he woke up, the loop spent thousands of dollars on tokens because it got caught in an infinite loop.”
12:38
“The tools will change. What you work on will change, but your ability to problem solve will travel with you no matter what domain you're working in.”
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.
story
I just took a course by Andrew Ng, a Stanford professor, and I learned something I wasn't expecting. I need to stop prompting Claude. Instead, I need to start graph engineering.
And I realized that 99% of people watching this are graph engineering without knowing it. But the problem is that they're doing it wrong, and it's costing them time and money. So in this video, I'm gonna break down and simplify what graph engineering is, a method I learned from this Stanford professor, and how you can use it to build 10 times faster.
And at the end, I'll walk through one skill that changed my life that you'll unknowingly work on throughout this entire video. Now graph engineering can be broken down into three layers. The basics, the types of graphs, and what you have to avoid.
So layer one is graph engineering basics. So first, what are graphs? When we refer to a graph, think of it like a graph of a process that you're completing.
So for example, let's take a task of creating a report about the current state of AI. Step one is research YouTube. Step two is research Google.
Step three is create the report. Step four is review the report. And then step five is send the report.
This process, I just created a graph, which in your brain you can think of as a work or an automation. The process of optimizing the setup is graph engineering. Now I know what you're thinking.
This is really simple. I'm already doing this when I build any sort of automation or I create a specific skill within Claude. And, yes, you are.
You've been graph engineering without knowing it, which is why it's so exciting, but this is just the tip of the iceberg. Just creating graphs isn't engineering graphs.
The process of tweaking, designing, and optimizing is where it becomes graph engineering. So what is a basic way to analyze a graph for ways to improve it?
My favorite place to start is what I call the wait test. Go back to the original graph that we created and take a look at the process. In step one, we research YouTube.
We wait. Then we research Google. We wait.
Repeat till the end of the task. And this is likely in part because it's one step after the other. Well, this chain of tasks is one of the most basic structures of a graph that you can make, but it runs slowly and it can break easily.
So whatever is done on that first step was a waste, and then everything else won't get done. But how do you identify places that you can improve this? This is where the weight test comes in.
So walk through your graph step by step, and at every single step, ask the question, does this actually need the result of the one before it? If the answer is yes, then having one step after the other makes sense. But if it's not, that connection is useless and you're waiting for something that you don't need to wait for and you can run it simultaneously.
So it starts off with research. Does this research Google step need the result from the research YouTube step? The answer is no.
It failed the weight test. You could run the research Google while research YouTube is running. Now if we go to the create report, this needs the results from the previous steps.
So it passes the weight test. Then each step after that passes the weight test. So now in your head, you've identified a gap in the graph and you might be saying to yourself, why don't we just have step one and step two run simultaneously?
And this process of thinking through the graph and optimizing is graph engineering. You're understanding the nature of what you're doing and how you can optimize it based on the task at hand. And now by default, people bias towards doing one task after the other.
But as part of this video, I'm challenging you to think differently through your workflows and how to structure them. So on screen, there's a prompt that scans your current system and flags every step that's waiting on something it doesn't need to. At this point, you understand the basics, what it is, and theoretically, how you can engineer a graph so that it can be improved.
But what are the different types of shapes you can make? And in Annerang's course, they go through a lot of different structures, but I'm just gonna cover the ones that matter. Now before we get that, what we're covering today is optimizing your system to complete tasks more efficiently.
But at the end of the day, if Claude doesn't have the ability to do the actual task, then it won't be able to complete the workflow. And one of the limitations of Claude is generating custom audio, which brings us to today's video sponsor, Phish Audio and their new s 2.1 pro API. Phish Audio allows you to create audio directly from text.
So whether you want to clone your own voice or generate hyper specific sound effects, Phish Audio can get it done. And when I used their voice model, I was pretty blown away by how human it sounds. And as somebody who first started using these text to voice tools in 2023, there are three reasons why they have always excited me.
The first is it lets you add VoiceLayer to something you're building without all the effort that comes from recording your own audio. And I know a ton of people hate the sound of their voice, so now you can just avoid that. And it's really quite easy.
You just write a script, bring it into fish audio, and then generate a customized voice or use one of their supplied voices. So by reducing this friction, it just creates a lot more opportunity to do things. The second is their emotion tags are awesome.
They let you add direction in line and give the AI voice energy and life. I find that most AI voice generators fall flat or they don't hit the creative vibe you want, and this allows you to really specify at a word level exactly how you want it delivered. To showcase this, here is my AI clone voice explaining the next reason.
And you can see the emotion tags in line. Third, it integrates directly into what you already use. You guys know how important I think it is to integrate tools into a single command center, and Phish Audio allows for exactly that with their MCP and agent skill support.
You don't have to learn a whole new interface. You're adding a voice to a workflow you already have. So to get access to Phish Audio and their free API today, click the first link in the description and just start building.
Now layer two, this is the types of graphs. There are a ton of ways to graph a workflow, and you can see them on screen. But for this video, I only care about the stuff that matters for 99% of people, which comes down to three shapes you haven't used yet.
For each one of these, I'll cover what it is, when to use it, and then give you a prompt so you can start using it today. And as we go through this, I'm intentionally not worrying about the technical details because Claude handles a lot of that. Your job is to point it in specific direction, and then Claude can handle it from there.
So the first graph is the diamond. On screen, you can see a visual for what a diamond looks like if my drawing doesn't get the job done. But essentially, it fans out AI agents to work on a task simultaneously.
So the create a research report graph that we used earlier is a perfect candidate to reengineer and make a diamond graph shape. What we would do is make it so that the research YouTube and the research Google go simultaneously, and then those feed in to the create report, which will make it about two times quicker.
On screen, you'll see a prompt that will auto your system to see if this type of graph can be integrated into your workflows that you're currently running. Then on the right, here are some of my favorite fan out examples and how I use it. My personal favorite is research like I've already covered, and then doing code reviews for specific angles like security audit.
The next shape is branch. What this does is based on your request, it will funnel it in a specific direction. So on screen, you can see a visual of how this works.
It's fairly simple, but it is extremely powerful. One skill that I use every day is a skill called improved system that has this exact shape. And just to make this abundantly clear, whenever you create a Claude skill, it's essentially a graph.
It just depends on what shape it has. So you can alter specific skills to be designed however you want. Now, this improved system skill that I run, it looks at the context of the conversation and decides which way to improve the system.
I have a bunch of different branches, but one of them is improve a skill based on conversation history. I have a route that audits my entire system, and then I have a route that looks at all of my conversation history and identify trends and places to create skills. This singular skill, the improved system, is shaped in the branch format.
And a term you may have heard me use before is skill routing, where it's using one skill and directing it based on the context. And under the hood, this is just using branch graphs. So on screen, you'll see a prompt on how you can integrate branch graphs directly into your system based on what you're currently doing.
Now, third shape is a loop graph. On screen, you'll see the design of this, but how it works is it has AI do a task and then it has AI evaluate the output and gives it either a approval or it'll give feedback to AI to then improve the result. It'll then loop until the result passes the test.
A viral term that you may have heard before is loop engineering, which I have a video on my channel doing a deep dive, which I'll link at the end of this. But the reality is that this is just optimizing this exact loop graph.
Loop engineering is a subcategory within the graph engineering topic. And the key with any good loop graph is creating a way to verify the output. You can't know if something is approved or not if you don't have a good approval process.
So whenever I build a new product feature, I use a loop graph to verify the output. This is very effective for technical use cases because it's most of the times objective outputs.
Right? Was it done? Was it not done?
And so on screen, you can see a prompt that will help you set this up for whatever you're building. Now for nontechnical changes, my favorite use case is using a skill called slash anti slop, which reviews the output and will tell AI if it's slop or not and how to fix it. You can then have AI iterate until it passes this anti slop bar.
This anti slop skill is most certainly a rabbit hole, so I have a free guide on buildpartner.ai linked below, which will help you set it up for free using this plugin. Now at this point, we know the four different graphs that matter.
The chain, which is the one that you're using already by default, the diamond, which is great for multithreading tasks, the branch, which is great for skill routing and simplifying your system, and then the loop, which is best for enhancing and validating outputs. And each of these designs are just building blocks, and graphs can use one or many of these.
They're all just tools that you now have in your toolbox. And this is all great, but when should I and when shouldn't I use these things? Now before we get to that final layer, if this is your first video of mine, welcome to the channel.
But if this is your second or more, you know the vibes. This is our anti slob agreement. The visuals, the testing, the hours of research that went into this video is built for humans, not for AI robots.
Like this handwriting, you you no robot would write like this. This is like a four year old. This is for you.
Now all I ask is you subscribe as part of this agreement to help this content reach more people. As of filming this, we're at about 81,000 subs, so shout out to everybody who's already subscribed. Also, every video as a thank you, I give away a Claude Max subscription.
So this week's winner is whatever man one eight seven who's building a solitaire card game in Godot. Shout out everybody who's just having fun with the stuff they're building. Now for this video to enter, comment below with a topic you'd like me to cover or a question you have about graph engineering.
And every video you comment on counts as an additional entry. Now, layer three, what to avoid. At this point, you know what graph engineering is, what the types of graphs are that matter, and we're using Claude to help us implement it because we don't wanna get bogged down on the stuff that 99% of people, it doesn't matter for.
But we do need to be aware of some technical details that are under the hood because they do impact you. So for each of the four graphs that we've already covered, I wanna go through the biggest side effects and how you can avoid this. So for chain graphs, they can be slow and brittle.
Now I touched on this earlier, but they're slow because it goes one step after the other. And if one step breaks, the entire process breaks. Now I will say almost every workflow that you create should start as a chain graph as it's the easiest to test and experiment with, and you can avoid this limitation by going through one of the three graphs that I'm going through next.
For diamond graphs, you'll run into issues when there's a false sense of independence and then there's silent failures. So whenever you fan out requests one by one, this uses a process called sub agents. And each sub agent has its own context, so each individual sub agent doesn't know what the other one is doing.
And this is the problem when they actually aren't independent. You get two agents doing the same task twice and it burns through tokens or it misses the context that's actually needed. Now in terms of silent failures, a graph in this structure won't break if one of the sub agents fails.
And this means it can be harder to know when and what breaks versus a chain graph where any issue will become obvious. To help avoid and mitigate these issues, try and choose tasks where the cost of error is low. So if one sub agent fails, it won't ruin the entire task.
And then to identify a sense of independence, run the weight test that we ran through earlier in this video. Then there's branch graphs, and the problem here is when you overengineer.
I find once people first realize the power of creating branches within a skill, it becomes this crazy frenzy. Some people, they'll start thinking of using one skill to literally branch out and do everything, and that's kind of an anti goal. The general rule of thumb that I like to think of is anything that branches out into different workflows is try and keep it to no more than five.
Anything above that, just ask yourself, should I simplify this? And if you're not sure, ask Claude, should I simplify the skill or break it up into multiple skills? Then the problem with loops is infinite loops.
This is a horror story from one of the clients that I work with, but he went to sleep. And when he woke up, the loop spent thousands of dollars on tokens because it got caught in an infinite loop. We obviously don't want that, so use this prompt to audit any loops you have and make sure there's a maximum number of iterations it's able to run before it fails.
You're gonna be thankful you use this. Make sure you're not wasting tokens unnecessarily. At this point, we've dove deep into graph engineering, a topic that does not have to be complicated.
But there's one skill this whole video that you've been flexing without knowing it that I've yet to cover. And I wanna tell you a story about how this specific skill changed my life, and it's something that you really wanna focus on. So in college, I studied mechanical engineering, and I graduated with a four point o.
And my first job out of school was at JPMorgan as a software engineer. They hired me. I legitimately had no idea how to write code, but they made a bet that I was going to be able to learn and problem solve to become successful.
I ended up becoming a top performer in my analyst class, not because I started as the best coder, but because I had a very developed skill of problem solving, which I had honed while solving problems as a mechanical engineer in college. It was a different domain, but it was the same skill set. That is the entire reason this video is so important.
The concepts I cover here give you a way to think about problems. Graph engineering is a process of orchestrating Claude in the best structure to solve the problems at hand. And by understanding the basics, you now have a whole new lens to solve problems through and a way to think about it.
The tools will change. What you work on will change, but your ability to problem solve will travel with you no matter what domain you're working in. Now, you want a free step by step walkthrough to set up these graphs in your Claude terminal, I have a guide link below which uses my build partner plug in to help direct you through every step.
And if you got this far, you're a legend, and you'll love this video on loop engineering, which dives deep on optimizing loop graphs, which will automatically verify Claude's output so you don't have to check it. I'll see you over there. Peace.
The Hook
The bait, then the rug-pull.
A course by a Stanford-adjunct professor convinced this creator he'd been thinking about Claude Code wrong: not as something you prompt better, but as a graph you can redesign. He claims most viewers are already doing this without knowing it, and doing it badly.
Named ideas worth stealing.
01:21concept
The Wait Test
Walk through a workflow step by step and ask, at each step, whether it actually needs the result of the one immediately before it. A 'yes' means the sequential dependency is real; a 'no' means the steps can run in parallel instead.
Steal forauditing any multi-step Claude Code skill or automation for unnecessary sequential bottlenecks
08:14list
The Four Graph Shapes
- Chain (default sequential)
- Diamond (fan-out, fan-in)
- Branch (route to one path)
- Loop (repeat until verified)
The four reusable structures the video argues cover 99% of AI workflow design: a straight sequence, parallel-then-merge, a single router, and a generate-evaluate-repeat cycle.
Steal fornaming and choosing the shape of a new Claude Code skill before building it
How they asked for the click.
VERBAL ASK
12:21link
“you want a free step by step walkthrough to set up these graphs in your Claude terminal, I have a guide link below which uses my build partner plug in to help direct you through every step”
Soft CTA placed after the value delivery, framed as a walkthrough resource rather than a hard sales pitch; paired with a mid-roll subscribe/giveaway ask around the 8:30 mark.
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
AFFILIATECommission earned if you click.
OTHER LINKSAlso linked in the description.
- Loop Engineering, the full deep dive ↗
- Karpathy's method for Claude ↗
- 17 tricks to build 10x faster ↗
- Andrew Ng course I reference on open ↗
- Free 5-day AI playbook (what I used to build a $25M+ startup) ↗
- Use BuildPartner to build 10x faster with Claude Code (try free) ↗
- Want to build a SaaS product without hiring a CTO? ↗
Visual structure at a glance.
