Prompts are briefs: what a Prompt Engineering 101 lab taught me

I've been using LLMs daily for a while, mostly by typing whatever came to mind and fixing the answer afterwards. This weekend I worked through KodeKloud's Learn by Doing – Prompt Engineering 101, a short set of labs on Mixtral-8x7B. Nothing in it was rocket science, but it changed how I think about prompts: they aren't questions, they're briefs. The model does what a new teammate would do with a vague ticket. It guesses.

Here's what stuck.

Detail beats cleverness

The first lab was the most humbling. "Explain caching" gets you a generic essay. Add who it's for, what to cover and what to skip, and the answer changes completely:

Explain HTTP caching to a junior backend developer.
Cover Cache-Control and ETag, one short example each.
Skip CDNs.

Every constraint you leave out is a decision the model makes for you.

Give it a role

"You are a senior TypeScript interviewer" shifts the tone, the depth and the vocabulary in one line. I already did this sometimes; the labs made me notice how much the persona quietly sets the bar for the answer. A reviewer persona nitpicks, a teacher persona explains. Pick the one you actually need.

Fence off the input

This one I'll use most. When you paste a log, an email or a chunk of code, the model can mistake part of it for instructions. Delimiters fix that:

Summarise the error in the log below in one sentence.
 
<log>
...
</log>

It also makes long prompts easier for me to read when I come back to them.

Break it into steps

Asking for a full database schema in one go gave me something that looked fine and had gaps. Splitting it, list the entities, then the relationships, then the SQL, gave a better result, and when something was off I could see which step went wrong. Same thing we do when breaking down a ticket.

Show, don't describe

I used to write paragraphs describing the format I wanted. Two examples do it faster:

Turn commit messages into changelog lines.
 
fix: null check in cart total -> Fixed a crash when the cart was empty.
feat: add dark mode toggle    -> Added a dark mode switch in settings.
 
perf: lazy load images on home ->

The model copies the pattern, including the bits you'd struggle to put into words.

Say how long

"In three bullet points, under 50 words" is a small addition that saves a lot of trimming. Without it, length is the model's choice, and it tends to choose long.

The takeaway

Put together, a good prompt answers the same questions a good task description does: who is doing this, what exactly, in what order, what does done look like, and how much of it. I'd already been writing those for people. Now I write them for the model too, and I spend far less time rewriting its answers.