Anthropic Reveals How to Prompt Claude Code 10x Better

By the end of the video, you will be  significantly better at prompting Claude's   Opus 4. 5 model because I'll be going through  many of the best practices that the Anthropic   team have shared on their own website and  that many of their staff have shared on   Twitter as well. I'll be going through  a lot of the ideas in a much easier to   understand format with diagrams because going  through the website can be pretty boring. But before getting started, I should share that I  have a Black Friday sale going on right now on my   Claude Code masterclass. I go through every  single feature of Claude Code in the class,   as well as a lot of bonus content that I  haven't talked about before on the channel   and you won't find anywhere else on YouTube.   I also have a Black Friday sale going on right   now for my own application HyperWhisper,  there will be a link to it down below. Anyway, so a lot of the ideas we'll talk  about will also apply to Sonnet 4. 5 and   Haiku 4. 5. First of all, when prompting the  model, you want to use a less aggressive tone

because using an aggressive tone by saying  something like you must always use a web   search tool or something like that can  trigger the model into fearing making a   mistake and it will trigger tools that it  didn't actually need to trigger and that   can lead to a more chaotic output and then  basically lead to worse performance overall. But if you use a more directive prompt by saying  something like use tool X when condition Y is met,   answer directly otherwise, then it  will perform much better because it   can just follow procedures that you  have given it. And of course now,   because it's not using tools unnecessarily  out of the fear of making a mistake or errors,   it will give you better and more precise outputs  instead. And I thought this metaphor was pretty   good because treating the model like a rebellious  teenager by always yelling at it and saying like,   you must do this, must do that, can cause  more anxiety in the model and then basically   lead to worse performance compared to just  treating it like a competent employee instead. Now, over a year ago, some research did show  that using negative prompts did lead to better   performance out of models, but it seems that  time is slowly coming to an end because that   can lead to overusing tools in a certain  way and just lead to worst output overall,   especially when coding. So bad prompts would  be something like you must use a search tool   whenever the user asks any question,  always search first before responding,   never skip searching. That would lead to worst  output and be less efficient than saying something   like use a search tool when you need current  information or facts that you're uncertain about. And one thing that the Anthropic team did make  and will be linked down below is a Claude Code   migration plugin. So basically by installing this  plugin, it changes many of the system prompts that   may be in your code base to be less aggressive  because they say that aggressive language can   lead to tool over triggering. And they give some  examples here of how you can use softer language.

Next up, you want to be more action orientated  when prompting model. So previously,   if you gave a earlier version of a Claude model,  a vague prompt, like can you suggest improvements   as code? Then what it would do is it would  actually often do an implementation for you   instead of actually suggesting improvements.   And if you're still using the same prompt,   hoping that it will do an implementation for you,  it no longer will actually do the implementation. And it will just give you suggestions instead,   which is exactly what some people do want because  now it follows instructions more precisely. So if   you were hoping that it would actually do the  improvements for you in some suggesting them,   then you want to be more explicit and actually  say like, can you refactor this code and   implement the changes directly? So previously  saying something like suggest would actually   lead it to carry out the implementation that you  gave it, but now it won't do the implementation   because it will just give you suggestions.   Another important idea is that Opus 4. 5

now has a tendency to over engineer in some ways.   For example, if you gave it an open ended request,   which you may have done you would have said  something like refactor the authentication   logic and then Claude Opus 4. 5 because it's  really eager to impress you may think like,   okay, I'm going to come up with a new  interface, come up with new helper classes,   a new config file and more like  abstraction or something like that. And then it like makes much more changes than you  would have actually anticipated. And in reality,   you may have actually only wanted one  or two of the files changed instead. So   instead of what you should do is you should be  more precise and constrained in your prompts. So you should say something like,  Refactor the authentication logic,   modify in place, no new files,  keep it minimal. And it's like,   okay, understood. We will only  change any existing files. So this is pretty important if you didn't  previously already have a habit of constraining   your prompts. You can also add similar logic  to your claude. md file for Claude Code. So you don't always have to write this.   Another important point is that Opus 4. 5

can be conservative now when exploring your code. So you want to encourage exploration where  possible. So for example, if you now say,   fix a bug in the user module, then instead  of looking at the surrounding context and   seeing how the files relate, to the user  module, it will just like make up some   like idea of how the rest of the code base  works based on its training data. And that   can lead to like a broken fix overall  because it's missing important context. It's just like guessing what kind of things  that other files would include and then lead   to more errors. But now if instead you say read  the entire user module and its dependencies,   understand the dataflow, then propose a fix,   then it will actually go ahead and  start exploring the code base more,   building a mental model of how everything works  and relates together. And then whatever fix   it does come up with will be more accurate and  based on all the remaining and surrounding files. Of course, if you are using plan mode within  Claude Code, that will trigger off sub-agents   that will explore the code base for you. So you  may not have to worry about this quite as much,   but if you're not using plan mode, then you  should either trigger an explore sub-agent or   you should get Claude Code to do the exploration  itself. And remember that you can trigger the   explore sub-agent manually by doing @ and then  explore, and then just giving your prompt in here.

Now, if you also want richer outputs from the  models, you have to give richer prompts. So   if you just say, build me a login page in React,  then it would give you a really simple barebones   like output, like super concise, like not a lot of  information there. But if you say something like,   building a login page in React include  full animations, form validation,   error messages, accessibility features, a  polished visual design go beyond the basics,   then it will give you significantly  better output, which means that Opus 4. 5 will deliver comprehensive feature rich solutions  when explicitly asked. It will end up being more   concise and give you more minimal like outputs  if your prompt is quite minimal and concise.    I do go through this in a previous video  where I teach you how to use Claude's   brand new front end design skill to come  up with better designs with Claude Code,   but So essentially what's happening right now  with the models is that when you give it really   simple minimum prompts, then you're facing  something called distributional convergence. So the model has a lot of training data  distributed in this way. So you have like   unique fonts, bold colors, complex  animations, and all of this stuff.    And all of the uniqueness here is kind of  washed out and merged and mixed together. And basically you get this like high probability  center instead. So any patterns that are safe,   common, like well used, like popular fonts and so  forth, all converged altogether into like a Inter   font purple gradient, minimal because these kind  of designs are universally acceptable, but also   very generic as well. And this can be useful when  you're coding with Claude Code itself, because if   you ask Claude Code to implement a authentication  system for you, then you don't want it to come   up with a brand new wacky unique authentication  system because that may lead to security risks. And you want Claude Code to write an  authentication system that actually works   and is universally well used. But of course now,  if you're using the same logic that Claude Code   uses to make a secure authentication system that  like works universally, it can lead to It's going   to worst performance when it comes to design. So  essentially what you want to do is offer Claude   Code explicit guidance, such as avoid Inter fonts,  user unique fonts, add complex animations, create   a bold color scheme, and then it will like avoid a  lot of the ideas kind of in the center over here,   and then combine related ideas on like the edges  and the vicinity of the training data that it has. And that can lead to better output overall as  well, because it's directed to sample from the   like creative and specific regions to come  up with better designs than sampling from   like the center of the like training  data cloud that it has. Of course,   this is somewhat of a simplification, but I  think the diagrams do help you understand that   idea. But yeah, I think a good way to think  about this is that when it comes to design,   the model will put in more effort into its  output if you your input.

Next up is that if you're providing the model with  rules, then if you provide a very bare basic rule,   never use abbreviations, then the model will  be like, man, why is this rule so arbitrary?    Am I just gonna follow it blindly? What is the  motivation here? Then it will basically follow   the rule very blindly and say instead of saying  versus, it will say versus and serve saying   ETC for et cetera, it will use like the full  like version and that can ultimately lead to   like very awkward output that you did not intend  for it to give you. But if you are giving a rule,   then you should give some motivation for why  that rule actually exists. So if you say never   use abbreviations, then add some context such as  for formal legal documents to avoid ambiguity. And then code is like, yeah, I got  it. Like, I understand the goal is   clarity and formality. I will  apply this principle broadly. And then basically that will allow the  model to understand the why behind the   rule and then generalize the principle that  you are getting at. To create higher quality   outputs. Now you're probably thinking, what does  this mean practically when you're coding? So you   could have a rule that said something like,  always use try catch blocks around API calls. But after, if you expand on the rule, always  use try catch blocks around API calls,   our monitoring system relies on caught exceptions  to trigger alerts and unhandled rejections   cause silent failures in production that are  difficult to debug. Or before, you would have   had a rule saying something like, add comments  explaining complex logic. Afterwards, you would   have a rule like, add comments explaining  complex logic, especially business rules. Our domain in insurance claims processing has  non-obvious requirements that aren't apparent   from the code itself, and future  developers won't have access to the   original stakeholders. And what this means  is that when you generally write like this,   rules generalize intelligently, which means that  the Claude models understand the principle behind   the rule and not just the rule itself. And  that allows it to make trade off decisions. So for example, if you have two rules that  conflict and you didn't realize they conflicted,   then it knows what concern matters more for  that particular case. And then it won't waste   time being confused, like not knowing which  rule to actually apply here. If your claude. md file fills up or you have many  different things across a project,   then some rules may begin to conflict, which  is why having the motivation behind the rule   written with the rule itself is important.   It also allows a model to flag edge cases.    So if there's a situation where there  may be an exceptional sorts because some   library requires it or something like that,  then it will be able to flag that to you. And also it will be able to apply the spirit  of the rule, which means that Opus 4. 5 will   be able to handle novel situations  where that rule may not apply exactly,   but it comes up with another good idea because it  knows and motivation behind it. So essentially,   if you're writing a rule, you  should say the rule statement,   the business and technical reason behind the  rule, and then any consequence that may happen   if it's violated or like what other benefit  comes from actually having followed the rule.

Next up is about verbosity. So by default,  like the Claude 4. 5 models tend towards   efficiency and may skip verbal summaries after  two calls and just jump straight to next action. And this can create a more streamlined  workflow, but you may prefer more visibility   into what's actually happening  behind the scenes. So for example,   like if you just leave it on the default  verbosity and you say to Claude Code because   you're using it for something non coding  related, because it's a good agent overall,   you say something like research competitive  pricing and then update the spreadsheet.    Then Claude Code will be as efficient as  possible and then give you a final output. And you're kind of like, why did I get this  output? Like, why is it like this? Essentially,   like the model's process has been hidden  after each tool call that it did and each   information that it fetched online. And then  you would probably be more confused about why   it gave you that particular output because  you can't read any reasoning behind what   happened. But if you say something like research  competitive pricing and update the spreadsheet. After each major step, provide a brief summary  of what you found and what you did. Then it's   kind of like, okay, well firstly, I'm going to  find the competitors found free, like here are   their websites. And then it finds the data,  extracted this and these are the variations. And then it like tells you what exactly  it updated. And then when you're going   through the history, you can read through  everything that it did. And it feels like   the entire process is more transparent and  you can feel more confident in the solution   or like output that I gave and you can also  include something like this after completing   a task that involves a tool use, provide a  quick summary of the work that you've done.

Now next up is controlling the formatting  of the responses that the Claude models   give you. So you want to avoid negative  prompting when it comes to formatting. So   you may have said something like, do not  use bullet points or markdown formatting,   and that basically imposes a bunch  of restrictions on the model. And then the model is too focused on what  not to do, and that can lead to more awkward   and unnatural outputs and responses. But  if you use more positive framing and are   more directive and say something like, Write  your response as flowing prose paragraphs,   use complete sentences that connects  ideas naturally. Then that will give   you a significantly better output than if  you tell the model what not to actually do. And this can be pretty important when you're  using the Claude models quite a lot when it   comes to writing. Next up is that the Claude  4. 5 models, Excel and parallel tool execution.

And Sonnet 4. 5 is particularly aggressive when  it comes to firing off multiple operations in   parallel, which means that if you're  using it for research, for example,   then it may run three or four web searches in  parallel, which are more speculative, whereas if   you got it to run it one by one instead, then  the next research query may be based on the   results of the previous research queries results.   So for example, if you get it to read a bunch of   configuration files and summarize the differences,  then often it will do it all in parallel. And then it may lead to a more chaotic output  than if you got it to do it one by one or turn by   turn. What this can look like more practically is  that when it comes to coding, if you have it run   multiple install commands in parallel, then it may  be the case that installs two things and they are   conflicting in some ways, and then it gets stuck  in like a loop or like a cycle. But fortunately   this behavior is pretty steerable because if  you included this prompt in your claude. md file, then it will like be even more  parallelized and it will do more things   in parallel whenever possible. And  if you want to reduce the amount of   parallelization that it does because you  noticed the output quality being worse,   then you can use this prompt instead  to ensure that there are pauses and   like thoughts between each step. And another  problem that can happen with the Claude 4. 5

models is that you should try avoid using the  word think when you have thinking mode off in   Claude Code, for example, especially when using  Opus 4. 5 because that's particularly sensitive   to a word. So basically, if you use a word think  with a Claude model and you don't have thinking   mode on and you say something like think step  by step before answering, then it can lead to   a bunch of noise and like a long-winded answer  because it's not actually capable of thinking. So if you need to have thinking mode  off, then you should say something   like carefully consider and evaluate  constraints, then give a final answer,   no intermediate reasoning. So saying words like  consider, believe, evaluate, have a similar   meaning, and it can lead to a better output  quality with thinking mode off than using

the word think. But yeah, that is basically  actually how you can be prompting Opus 4. 5 and the other Claude 4. 5 models really well.    There are some sample prompts that  you can include in your claude. md file in this page, but it is like very  long to read through, but maybe handy   for certain people. And remember that there is  a Black Friday sale going on right now for my   Claude Code Masterclass and also my HyperWhisper  software. Both of them will be linked down below.