In third grade I had to write a how-to for making a peanut butter and jelly sandwich. I thought I'd nailed it. Four steps:
- Get the bread.
- Get the peanut butter and the jelly.
- Spread the peanut butter on one slice, the jelly on the other.
- Put them together.
My teacher read it, looked up, and asked one question:
Where did the knife come from?
I had the vision. I'd skipped the environment. The knife was real in my head (I'd seen it in the drawer that morning) so I assumed it was real on the page. It wasn't.
three phases of getting this wrong with LLMs
When I started taking prompt engineering seriously last year, I realized I was repeating the third-grade mistake. The arc was familiar enough that I think most people walk it.
Phase one: the one-liner. Single sentence. Expect the model to read your mind. When it fails, fight with it in the next turn instead of fixing the prompt.
Phase two: the notebook. Start saving prompts that worked. Notice that consistency matters. Notice that some prompts are doing work the model can't actually do without more setup around it.
Phase three: the environment. Realize the prompt isn't an instruction. It's a room. The model can only use what's in the room. If the knife isn't in the room, the sandwich doesn't get made, no matter how clearly you described the spreading motion.
what I write now
Three things stacked on top of each other:
- Context: where the ingredients live. What the model has access to.
- Constraints: how to use the tools, and how not to.
- Acceptance criteria: what "finished sandwich" actually looks like, in enough detail that the model can self-check.
There's no magic word. There's no clever phrasing trick. Prompt engineering is the same skill as writing a good bug report or a clear design doc: assume the reader doesn't have your context, then put the context in the document.
