You're Prompting Claude Wrong. Use this Stanford Method Instead

0:00 I just took a course by Andrew Ing, 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

0:08 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,

0:15 I'm going to 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

0:24 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

0:32 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

0:42 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

0:53 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 workflow or an automation. The process of optimizing the setup is graph

1:02 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.

1:10 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

1:19 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 weight

1:29 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

1:40 the task. And this is likely in part because it's one step after the other. 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

1:48 break easily. So, whatever is done with 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

1:56 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

2:04 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.

2:12 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

2:21 well 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.

2:31 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

2:39 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

2:48 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

2:56 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

3:04 engineer a graph so that it can be improved. But what are the different types of shapes you can make? And in an course they go through a lot of different structures but I'm just going

3:11 to cover the ones that matter. Now, before we get to 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

3:18 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, Fish

3:27 Audio, and their new S2.1 Pro API. Fish Audio allows you to create audio directly from text. So whether you want to clone your own voice or generate hyperspecific sound effects, Fish Audio

3:37 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 texttovoice tools in 2023, there are three reasons

3:47 why they have always excited me. The first is it lets you add voice layer to something you're building without all the effort that comes from recording your own audio. And I know a ton of

3:55 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

4:04 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

4:13 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

4:23 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

4:33 you already use. You guys know how important I think it is to integrate tools into a single command center. And Fish Audio allows for exactly that with their MCP and agent skills support. You

4:44 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 Fish Audio and their free API today, click the first link in the

4:54 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

5:03 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

5:11 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 a specific

5:19 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

5:27 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 re-engineer and make a diamond graph

5:38 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

5:47 quicker. On screen you'll see a prompt that will audit your system to see if this type of graph can be integrated into your workflows that you're currently running. Then on the right,

5:54 here are some of my favorite fanout 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

6:03 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

6:13 powerful. One skill that I use every day is a skill called improve system that has this exact shape. And just to make this abundantly clear, whenever you create a claw skill, it's essentially a

6:22 graph. It just depends on what shape it has. So you can alter specific skills to be designed however you want. Now this improve system skill that I run, it looks at the context of the conversation

6:32 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

6:40 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

6:49 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

6:58 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 the third shape is a loop graph. On screen you'll see the

7:06 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

7:16 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

7:25 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

7:34 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.

7:44 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

7:53 this up for whatever you're building. Now, for nontechnical changes, my favorite use case is using a skill called slant slop, which reviews the output and will tell AI if it's slop or

8:02 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 build partner.ai AI

8:12 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

8:20 default. The diamond which is great for multi-threading tasks. The branch which is great for skill routing and simplifying your system. And then the loop which is best for enhancing and

8:29 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,

8:38 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

8:46 know the vibes. This is our anti-slab 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

8:55 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,

9:03 we're at about 81,000 subs. So, shout out everybody who's already subscribed. Also, every video is a thank you. I give away a Claude Max subscription. So, this week's winner is Whatever Man187 who's

9:13 building a solitire card game in Go Dot. 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

9:22 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

9:29 is, what the types of graphs are that matter, and we're using claw to help us implement it because we don't want to get bogged down on the technical stuff that 99% of people it doesn't matter

9:38 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 want to go through

9:46 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

9:53 and if one step breaks, the entire process [music] 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.

10:02 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

10:10 and then there's silent failures. So, whenever you fan out requests one by one, this uses a process called sub aents. And each sub aent has its own context. So, each individual sub aent

10:19 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

10:28 context that's actually needed. Now, in terms of silent failures, a graph in this structure won't break if one of the sub aents fails. And this means it can be harder to know when and what breaks

10:37 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

10:46 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

10:55 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

11:04 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

11:12 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

11:22 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

11:30 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

11:41 to run before it fails. You're going to be thankful you use this. to make sure you're not wasting tokens unnecessarily. At this point, we've dove deep into graph engineering, a topic that does not

11:49 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 want to tell you a story about how this specific skill changed my

11:57 life. And it's something that you really want to focus on. So, in college, I studied mechanical engineering and I graduated with a 4.0. And my first job at a school was at JP Morgan as a

12:06 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

12:15 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

12:24 as a mechanical engineering 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

12:32 think about problems. Graph engineering is the 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

12:41 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

12:49 you're working in. Now, if you want a free step-by-step walkthrough to set up these graphs in your cloud terminal, I have a guide linked below which uses my build partner plugin to help direct you

12:57 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

13:06 output, so you don't have to check it. I'll see you over there. Peace.