Welcome to the NZRT Wiki Podcast. Today we’re looking at Prompt Engineering.

So what exactly is prompt engineering? Put simply, it’s the practice of designing the inputs you give to a large language model so that you get accurate, useful, and consistent outputs back. Think of it as learning how to communicate with an AI in a way that actually works.

Let’s start with the core principles. There are five of them. First, be explicit — state your task, the format you want, and any constraints as clearly as possible. Second, provide context — include relevant background information right there in your prompt. Third, use examples — giving the model a few examples before your real question dramatically improves accuracy. Fourth, specify your output format — tell it whether you want JSON, a table, a bullet list, or plain prose. And fifth, constrain the scope — tell the model not just what to do, but what not to do.

Now let’s walk through the main prompting patterns.

The first is zero-shot prompting. No examples at all — you just rely on the model’s existing knowledge. Imagine asking it to classify the sentiment of a product review as positive, negative, or neutral. You give it the review text, and off it goes. Straightforward.

The second pattern is few-shot prompting. Here you provide two to five examples before your actual request. So you might show it that a review saying “Loved it!” is positive, “Broken on arrival” is negative, and “It’s okay” is neutral — then you present your real review and let the model follow the pattern. This significantly improves accuracy, especially on classification tasks.

Third is chain-of-thought prompting. Instead of asking for a direct answer, you ask the model to reason step by step before giving you a result. For example, you might give it a maths problem — a store has one hundred and twenty items, thirty percent are on sale, how many are full price — and ask it to work through each step. Showing its reasoning dramatically reduces errors.

Fourth is role prompting. You assign the model a persona to shape its response style. Something like telling it to act as a senior New Zealand tax accountant and answer in plain English. That framing steers the tone, vocabulary, and depth of everything that follows.

And fifth is structured output prompting. When you need machine-readable results, you just specify the format. You might say: return a JSON object with keys for name, date, amount, and currency. Clear, precise, done.

Now, when it comes to writing a system prompt, the order of your content matters. The recommended structure is: start with a role or persona, then describe the task, then list your constraints and rules, then specify your output format, and finish with any examples.

Let’s talk about what goes wrong. There are six common failure modes to be aware of.

The first is hallucination — the model invents facts to fill gaps. The fix is to ground it with retrieved context, a technique called Retrieval-Augmented Generation, or RAG.

The second is when the model ignores your instructions. This usually happens because your key rules got buried in a long prompt. Move them to the top or the very bottom where they carry more weight.

Third is verbose output — the model just goes on too long. Add an explicit length constraint, something like “be concise, maximum one hundred words.”

Fourth is wrong format — the model doesn’t give you what you asked for. Provide an exact format example so there’s no ambiguity.

Fifth is sycophancy — where the model agrees with incorrect statements just to please you. Counter it by explicitly telling it not to agree if something is wrong.

And sixth is over-refusal — the model refuses a perfectly valid request. This usually resolves when you rephrase and add context about your intent.

Finally, let’s look at some ideas from researcher Andrej Karpathy, who frames large language models as the core of a new kind of operating system. In this view, the model is like the CPU, and your prompt is the program running on it. The context window — everything the model can see at once — is like RAM, so you want to be deliberate about what you put in there. You can extend a model’s capabilities by giving it access to external tools. When you chain a model together with tools and memory in a loop, you get what’s called an agent. And here’s one of the most practical insights: verifying an answer is easier than generating one from scratch. That means you can use a language model to check its own outputs — a powerful technique worth building into your workflows wherever accuracy matters.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.