Prompt Principles

Prompt Engineering was so 2024, welcome to prompt principles in 2026!

When prompt engineering was becoming the thing it was in 2024-2025, everybody was trying to craft “the perfect prompt” to get outputs. Whether that’s altering the system prompt provided to the model or providing some words in-conversation, the result was to alter the behaviour and outputs of the model and try to get it to do things.

We all may know by now this is just context engineering. I think it’s just a matter of effective communication vs human drivel that sounds like instructions.

In any case, I wanted to talk about some principles of prompting that I believe are worth much more than “the perfect prompt” that goes beyond even just models. That’s “Prompting Principles”.

I say principles because this is irrelevant of which model you are using and which version of said model you use. Think about it - the model comes up with an update and suddenly your prompt no longer works and you get different outputs. In other cases, there’s some slight delta or difference in what you want to do that makes your “perfect prompt” not worthy of the task that you want to accomplish.

Enter “Prompt Principle”.

These bypass the idea that you’ll ever craft the perfect prompt and more gives you some wiggle room to be as specific or broad as you want or need for the task at hand. The great news: This requires no coding experience, BUT, this does not disregard the first principles approach to engineering because some of those principles do apply here.

Bonus: Not all of this is strictly AI or LLM focused, it’s applicable in real world conversations and workplace communications as well! I think one of the things LLM’s are doing for us is helping us along with effective communications as well!

Principle #1: Clear Instructions

This can actually be broken down into several sub-points I’m going to cover, but the idea is simple: Clear Instructions yield better results than vague or ambiguous ones. This goes beyond just prompts but in general communications as well.

If you instruct:

Write this essay for me.

You’ll get some tacit, bland, superficial post that technically looks correct and may even seem like a good post at first glance, but once you get into the details, there’s vague and ambiguous arguments, it has no tone, no voice, and is the statistically strung together sum of words that seem most correct for the generic request you provided.

If, instead, you instruct:

Write this essay about software engineering with 3 points about the principles of engineering with an introduction to the history of software engineering, lead to the ways in which these principles have shaped the outputs of software and provide 3 additional points that talk about why it’s important to understand the meaning behind the software

Suddenly, you’ll get a much better essay with clear arguments, a line of thinking that can be followed and less bland writing that might actually be plausible and worth a read.

Now let’s break down by what I mean by “Clear Instructions” even further so it’s clearer.

This is all based on Alex Hormozi’s Star System because it’s just a really great breakdown of how work gets done and how you communicate those needs to someone else.

Alex has actually done a few of these videos. This one linked above is the most recent and the most comprehensive one he’s done yet.

I’ll go thru the points here for clarity.

Star System: That

Aside the importance of describing the “What” is describing “That” the thing needs to get done. Sometimes context gets construed or interpretations are ambiguous. It’s important to specify “the thing” that needs to get done.

Star System: What

This is the “so what” or the overall goal of the task at hand. If you can clearly describe the thing you want to accomplish, you’re already most of the way there. Most people don’t clearly articulate themselves and get indignant for some reason when you ask for clarification.

Let’s be real: You can’t assume what someone else knows unless you explicitly tell them.

The only way to be certain that someone knows something is to put it in plain words that can easily be understood, given the context with as little jargon or abbreviations as possible.

Star System: How

Sometimes we assume someone or something knows “how” something should get done. Sometimes a training step is required and it could be a simple “this is my preference on how I want this delivered/packaged.” or it could be as complex as taking a course and downloading some content about it to the entity performing the work.

Understanding the “how” behind something is a combination of preferences, expectations as well as process and operations.

Star System: When

Understanding deadlines and timelines is also a critical data point in clear instructions. Knowing the “when” a deliverable needs to be made will go miles in understanding a task.

In prompting, this may be less important since most agents come back in seconds to minutes. However, for effective human-to-human communications, this is important to understand deadlines and timelines to ensure a task gets complete without falling off a ledge.

Star System: Block/Circumstances

Sometimes there are real circumstances that prevent one from accomplishing a task. Understanding these and removing the blocks will help mitigate the chances of something not getting done.

Principle #2: Clear Outcomes

The second principle is around clearly describing the outcomes you are seeking as a result of this operation.

Principle #3: Definition of Done

The principle of the “Definition of Done” or what a complete end result looks like is clearly describing the finish line. People are notoriously bad at describing what “Done” looks like. The better and clearer you can describe this, the more refined outputs you’ll get from working with an LLM, especially in coding projects.

Principle #4: Examples and Anti-Examples

If you are able to produce examples of what you want, you’ll give the model something it can repeat. This is great for tasks that involve large code edits, but are monotonous or repetitive in nature but too distinguished to use a regular expression for the change. Think multi-line changes since tools like sed and perl are not great at multi-line regexp edits.

Providing anti-examples or counter-examples are a great way of showing what NOT to produce and you can definitely include this in your prompts. This is also good for cleanup tasks that need to remove certain changes from your work.

Conclusion

If you’re looking at all of this going “that’s a lot of instructions!”, great! Now you have a clear measuring stick for understanding the leverage this can get you. If the time it takes you to get the job done is faster than the time it takes you to clearly articulate the outcomes, then you may wonder about the leverage you get from delegation.

The counter balance to that is if you get good at articulating and describing the needs and desires of the task at hand, then you will invariably get good at writing and documenting and communicating those needs faster and someone else can execute on them just as quickly.

Also, note how many of these principles don’t apply to just AI, but to just plain human-to-human communication as well! Think about how much more effective you could be in your job if you just communicated yourself correctly, cleared your context window and articulated what needed to be said in a much clearer fashion.

How would that impact your work?

What kinds of results do you think you’d get?

How much less stressful would you life be if you were finally heard and understood?