Transcription
I'm going to show you three prompt tips for Claude Fable, Anthropic's smartest AI model ever. I sold my AI company for millions at 30, so I've spent a decade learning how to work with AI. And here's the twist with Fable, the best prompts are not what you think.
Starting with number one, give Fable your goal, not the steps. Okay, so last week for example, I moved my whole content pipeline over to Claude Fable. I pasted in my old mega prompt, which is what I spent months fine-tuning. It has like 14 different steps, formatting rules, an example for all these different edge cases. I hit enter and waited for Claude Fable to produce the magic. But honestly, the output was a little bit worse than just using my normal Opus. Worse.
So, I ran an experiment. I deleted 12 of the 14 steps and left only two lines, my goal and my constraints. And that result was much better and smarter than my old prompt, even though I didn't have to specify all of these different rules and steps. So, here's the big lesson. Fable is a genius that thinks for itself. So, when you script every step, you are actually capping the smartest model on Earth at your own level of what you think it should do. And this isn't just my opinion, Anthropic's own documentation validates this. Prompts written for older models usually give too many orders and they make Fable's answers worse. So, their guidance is to state your goal, state your constraints, then get out of the way. Unlike older models, like Fable's reasoning actually runs on every single request. So, you don't have to tell it to think harder or reason at this step. It's essentially like deep thinking is built into every single thing it does. So, just let it do that.
Now, using previous models, like usually outlining more steps means you have more control over the outputs, and that was true for older models. With Fable, it completely flips this. So, here's an example of bad versus good for prompting Fable specifically. So, bad would be like, "Here's what to do. Step 1 2 3 14." And like, over-specifying basically what to do. And this is normal, by the way. This is the normal way people prompt today using Opus and Sonnet. But, using Fable, Anthropic highly recommends just giving it the goal, giving it the limits, and let it figure it out. So, instead of having to specify all 14 steps that you think it should do, just tell Fable what you want. Fix the crash on uploads over 100 megs. This is an example. Keep the change small and add a test. So, this is the same task, but over here we were specifying like exactly what we think it should do. Over here in the good example of the prompt, we are telling Fable what our problem is, and trusting Fable to figure it out within the constraints that we've set. So, an analogy here is like, imagine hiring a Michelin star chef, and you hand them a microwave manual. That's insulting. Nobody would actually do that in real life, okay? So, think about it like you talk to the chef, you explain, "Oh, this is the kind of food you like. Here's my budget, i.e., constraints." And then let the chef cook. In other words, let Fable cook.
But, a short prompt is worthless if Fable doesn't know why you're asking. So, prompt engineering tip number two is give the reason, not the request. So, a few days ago, for example, I dropped a 40-page report into Fable and said, "Summarize this." Then I got back a pretty competent, but as you can expect, generic summary. So, I added a single sentence before the request. I'm prepping a 5-minute update for non-technical investors deciding whether to fund our next round. Now, I don't actually have investors. I thought this would just be fun uh as an exercise, but same report, same model, but this time Fable pulled out three key statistics that an investor would actually care about, and it flagged the one risk that is really, really important and which was kind of drowned out in its previous generic report, and then Fable just cut everything else since I specified it's a 5-minute update. So, this one sentence changed the entire output.
So, bad version of the prompt, good version of the prompt. The lesson here is that Fable does its best work when it knows why you're asking. When it doesn't know why, it guesses, and when it guesses, it'll try to do everything. Uh and that's the problem. You don't really want it to do everything. You want it to do the thing you need done. And Anthropic actually released a template for this. Here's the template. I'm working on this larger task for this audience. They need whatever my output enables. With this in mind, here's the request. So, the areas in pink are the ones you would fill out. Yellow portions are just the templates that you would leave there. So, you would fill in these blanks, these pink areas, fill them in every time, and Fable will connect the task you're asking it to do with the bigger picture instead of trying to invent its own reason why you might be asking for this.
So, let's go back to the original example so you can see how it kind of fits in. So, this is the larger task, prepping a 5-minute update. Who is it for? Non-technical investors. This is our audience. They need to make this decision. This is the larger task, audience, and then this is what the output of Fable's work enables. It's going to help these investors decide whether to fund our round two. And then with this in mind, summarize the report. This was the original ask that we asked for, the original task over here, right? We put it at the end and we added all of this context before the task itself. We added the bigger picture, like what is the real reason we're doing this, we added the audience, and then this is what the output enables, helping people come to a specific decision. It's the difference between telling a taxi driver head north versus telling them I need to be at the airport by 6. Both will get you moving, only one gets you where you're actually trying to go. This one is not going to get you where you're trying to go when this is really where you're trying to go.
Now your prompts are short and they carry meaning, but one problem left, Fable will do a lot more than you asked. This brings us to prompt engineering tip number three. Tell Fable when to act and where to stop. You have to set boundaries. Fable is the most genius AI model in the world right now, okay? Give it a hard task and a single request will run, it'll gather context, it'll do the work, it'll verify its own outputs, but you know, I asked it to look into a billing bug in one of my end-to-end automations and it diagnosed the bug perfectly. The problem is it kept going. Like it started rewriting everything to prevent what it called the whole class of issue. Um, this is impressive but like not what I asked for. Um, it probably is going to break other things accidentally. Okay, it's like it's like you're asking for one thing fixed and then it starts remodeling the entire room of your house. Okay, but it's a very smart model. It's a very smart model and that's exactly why you need your boundaries to be clear because it can do so much and it's going to try to do a lot unless you specify boundaries.
Okay, so what do I mean by boundaries? So Anthropic's [snorts] own documentation recommends drawing two explicit lines in your prompt. First is a stop line. So when you describe a problem, the job is the diagnosis, not the fix. And you just want to make that super clear to Fable. Let it report its findings, and then wait for your approval. And then the second thing you want to include is a go line. The go line is once Fable has enough information to act, it should act and hand you a recommendation instead of a survey of every option it's considered. Now, without these two, stop line and a go line, Fable either does too much or it takes forever planning. But when you incorporate both of these, then Fable does what you actually want without breaking a bunch of other things.
So, an example bad prompt would be like fix the login bug, because it's going to fix that and then attempt to fix a whole bunch of other things and refactor a whole bunch of other things and probably break a bunch of stuff in the process. So, here's a good prompt. Diagnose the login bug and report your findings. Don't change any code until I approve a fix. This is the stop line. Once you have enough information, give me one recommendation, not a list of options. Okay, that's the go line. Think of Fable as a brilliant genius new hire. Okay, they're brand new. On day one, they're so overeager that they're going to like reorganize your entire company without being asked cuz they just They just want to prove themselves. >> [laughter] >> But we already know Fable is a genius, okay? So, we have to put these constraints in place. Um, don't think of it like you're holding the model back. Think of it like you are just being ultra clear what Fable's job description is supposed to be.
So, to recap, these are the three prompt engineering tips for Claude Fable. Give it your goal instead of over specifying steps explicitly. Okay, give the reason for your goal, like the bigger picture why it's doing it, not just the request, okay? And number three, set clear boundaries. That stop line, that go line, etc. And your output quality will massively improve when you make these changes and switch to Cloud Fable.