DEV Community

Cover image for The Prompt Engineering Mental Model Most People Get Wrong
Mathieu Kessler
Mathieu Kessler

Posted on

The Prompt Engineering Mental Model Most People Get Wrong

I've written over 1,300 prompts. I test them, I publish them for free, and I watch what happens when people use them.

And there's this pattern I can't unsee anymore. Someone grabs a prompt, pastes it in, gets a decent result, and stops there. Someone else grabs the same prompt, tweaks it for their situation, gets a first result, realizes it's not quite right, adjusts, and ends up with something genuinely useful. Same starting point. Completely different outcome.

The difference isn't the prompt. It's what happens around it. How you set it up, how you read the output, what you do when the first result misses the mark.

Not the prompt itself. The thinking behind the prompt. There are maybe five mental models that, once you internalize them, make you better with any model, any prompt, any task. I want to walk through them because I don't see anyone else writing about this stuff, and I think it matters more than the prompts themselves.

You're delegating, not searching

The biggest mistake people make is treating AI like a search engine. You type a question, you get an answer. That's the wrong frame entirely.

What you're actually doing is delegating to someone who is smart, fast, and has zero context about your situation. Like a new hire on their first day. If you said "write me a report" to a new hire and walked away, you'd get something useless. You know this. So you'd explain who it's for, what format they expect, what happened last time, what "good" looks like.

"Write a project status report."
Enter fullscreen mode Exit fullscreen mode

vs.

"You're writing a weekly status report for the project director.
Non-technical executive audience — they care about schedule,
cost, and the top 3 risks. Nothing else.

One-page summary up front. Direct tone, flag bad news early.
Red/Amber/Green status for each work package.

Here's last week's report: [paste]
Here's this week's data: [paste]"
Enter fullscreen mode Exit fullscreen mode

The second one isn't a better prompt. It's a better briefing. And it's the exact same skill as delegating to a person. I actually realized at some point that my prompts got dramatically better when I stopped thinking about "prompt engineering" and started thinking about how I brief my team.

If your prompts suck, check how you delegate to humans. Might be the same problem.

You need a trust framework before you need a better prompt

This one took me months to figure out, and I only got there because I work in an industry where if someone acts on bad AI output without reviewing it, people can get hurt. Real physical harm.

So I had to get very precise about when I trust the output and when I don't. Not after I read it. Before.

If I'm asking AI to reformat something I wrote, or brainstorm off my own notes, I can use it pretty much directly. I'm the source material. The AI is just reshaping it. Fine.

If it's a first draft for someone outside my team, or code that touches a database, I read it carefully. Every paragraph, every function.

If it's giving me numbers, dates, citations, anything regulatory, I verify every single thing. This is where hallucinations hide and it took me embarrassingly long to learn this lesson. The dangerous outputs aren't the obviously wrong ones. They're the ones that look polished and professional and happen to contain a fabricated statistic on page 3 that you skim right past because the writing is so smooth.

Now the first thing I do before writing any prompt is decide: am I going to use this output directly, review it, or verify it line by line? That decision shapes everything downstream.

Context windows will bite you

Quick technical thing. The AI forgets. Between conversations, it has zero memory. Within a conversation, it has a limit, and once you blow past it, your early instructions start disappearing.

I lost 20 minutes of work once because of this. Had a long conversation where I spent the first 10 messages dialing in the exact tone for a document. Asked for a final draft at message 40-something. Got back the model's default generic style. All my tone instructions were gone from the context window.

Since then: I put the important stuff up front. And for anything complex, I break it into stages.

Step 1: "Analyze this data, list the top 5 findings"
→ I pick the 3 that actually matter
Step 2: "Expand findings 1, 3, 5 into paragraphs with evidence"
→ I edit and add my own interpretation
Step 3: "Write an executive summary. Under 200 words, no jargon"
Enter fullscreen mode Exit fullscreen mode

You're not having a conversation. You're managing state. And you need to inject your own judgment between each step, which is where the actual value comes from.

Write specs, not wishes

Number one cause of bad AI output is a vague prompt. Not a bad model. A vague prompt.

"Make this code better." Better how? Faster? More readable? Fewer lines? The model guesses. You wanted something else.

I started writing prompts the way I write function signatures. What goes in, what comes out, what the constraints are. Name the format explicitly. Tell it what to leave out. ("No introductions, no filler." You'd be amazed how much this helps.) Show it an example of good output instead of trying to describe what you want in words. Use numbers instead of adjectives because "brief" means nothing and "under 150 words" means something.

Bad: "Summarize this meeting."

Better: "Pull out the 3 decisions, the open action items with
owners, and any deadlines. Bullet points. No discussion context.
Under 100 words."
Enter fullscreen mode Exit fullscreen mode

Side effect: getting better at this made me better at writing Jira tickets. Ambiguity is ambiguity regardless of who's on the receiving end.

The centaur thing

There's this chess story from 2005. A tournament where you could enter as a human, a computer, or any combination. Grandmasters entered. Top chess engines entered.

The winners were two amateurs with three laptops and a good process for knowing when to trust the engine vs. override it.

I think about this constantly. The point isn't that AI is powerful. It's that the human+AI team beats both, and that the process matters more than how good either party is individually.

I have a rough split in my head. I do the judgment work: deciding what matters, understanding context nobody wrote down, making calls with incomplete information, anything with safety or ethical weight. AI does the volume work: processing lots of text, maintaining consistency, generating variations, applying patterns I've defined.

The failure mode I keep seeing is people asking AI to make judgment calls. Priority decisions. Risk assessments. And it'll do it, confidently, in clean bullet points. And it'll be wrong in subtle ways that only someone with domain knowledge would catch.

My workflow now: I set the constraints and define what I want. AI drafts. I cut and revise. AI formats the revised version. I review one last time and ship. Each handoff is deliberate. I don't outsource the thinking parts, and the AI doesn't wait around when it could be generating.

What shifts

I still write prompts, and I still publish collections of them. They're useful starting points. But the thing that actually made me better at working with AI was internalizing these patterns. The prompts are the what. The mental models are the why. And once the why clicks, you stop needing someone else's prompt for every new situation.


Free prompts and workflows at NerdyChefs.ai and GitHub.

What mental model changed how you use AI? Drop a comment.

Top comments (0)