speaker 1: Prompt engineering or prompt crafting, or just prompting, whatever word you use to describe it, it's all about how to effectively collaborate with an AI to get the best results, like GitHub Copilot. In this video, I'm gonna to show you something called the three s principle of prompt engineering. The three s principle stands for simple, specific and short. Easy to remember, right? The first s simple means that you should try to solve as simple a problem as possible with your prompts. For instance, let's say that we want to create an api that returns some weather data and uses swagger. When you use Copilot, it's tempting to ask for all of this and have it implement a solution in a single shot. While Copilot will happily try and do this for you, the more code that Copilot writes, the greater the chance, errors and what we call hallucinations, which are things that Copilot just makes up when it doesn't know an answer. In this example, Copilot uses files that don't exist, libraries that we don't have installed, and on and on. It's tough to deal with code like this because now you're in the business of fixing errors, not writing code. Instead, break your solution up into simple steps and let's perform them one at a time. When you work in simple steps, there's less code that you have to check for accuracy, and you can just move that much faster. Once we have a simple server, we can then add a route file for the weather. You'll notice that I'm using simple not just as a concept, but as an actual word in the prompt. You don't have to do this, but I do find that it helps cut down on the verbosity from the AI and gets me just what I need more of the time. Okay, now we can use this route. It's important to know that when you're using GitHub Copilot completions, like I am here, also called ghost text, that you have related files open as tabs. Otherwise Copilot can't see those files and it may give you bad answers. But now that Copilot has all this context here, we don't even have to ask Copilot anymore to do anything like use the route. It already knows what we're gonna na do next and just does it because the best prompt is the one that you don't have to write. Now, there are times when you're going to need more complex answers, and there's just no way around that. This is especially if you're not 100% sure how to do something and you need some guidance from Copilot. For instance, if we want to integrate swagger, which is an api documentation tool, there isn't really a way for us to be simple here because I don't know how to get started at all. I need to ask a more open ended question. And the more you ask for, the more specific you need to be. And that's our second s specific. If I ask an open ended question about how to integrate swagger here, I get an open ended answer. In fact, Copilot might not even know what language I want to work in. Why doesn't Copilot know about my project? Copilot tries to intelligently pull in context for you. This often means the editor area, which is the code you can see in the editor, but not all the code in the file. It also knows about the code that you have selected, which is a great habit to get into. So the Copilot knows exactly what code you want to talk about. To reduce the amount of guessing that Copilot has to do, your best bet is to provide the specific context. In this case, we can use the workspace agent in Copilot to have it look at our project and use that as the basis for this answer. Sor agents and Copilot are like experts on certain subjects. In this case, the workspace agent is an expert on your project. You can add further specificity by pointing Copilot directly at files. So if we want to create an interface here that matches the shape of the json and the data, we can do that with the file variable. There are other variables too, such as editor, which includes all of the visible code in the editor space selection, which includes the selected code and terminal last command and selection, which include information from the terminal specific always use specific prompts and always provide specific context to Copilot. Now, if you've been paying close attention so far, you may have noticed that I've been using our last s all along, and that's short when you talk to Copilot, you don't need to phrase questions as if you were talking to a human. You don't need proper grammar. You don't even need complete sentences. You don't have to spell things correctly. You can safely emit almost all of that and get the same answer faster. Type less, because typos don't matter. Now, while we've gone over these principles separately, you'll use them together to get the best results. For instance, if I wanted a css layout that had a fixed header, fixed footer, and body content that scrolled in the middle, I could write a pretty lengthy prompt to try and pull this off. But if you think about it, this is a bit of a step backwards for developer productivity, right? We want to learn keyboard shortcuts and be quick, not type everything that's in your brain. So how can we use the principle of simple, specific and short to pull this off? First we'll ask for a fixed header, then we ask for a fixed footer, and then we'll ask for a body that scrolls in between simple, specific and short. And we use the inline chat here to iterate our way to the answer that we wanted, instead of trying to do it all in one shot. And that's said, all you have to remember are the three s's simple, specific and short. And you've nailed the core principles of prompt engineering. And as you write more prompts, you'll just start to figure out what prompts get you the best results and make you the most productive. Make sure you check out all of our other videos on GitHub Copilot. And as always, happy smart coding.