Prompt engineering is overrated
# Prompt engineering is overrated
There is a busy little economy online selling magic words. Packs of two hundred power prompts. Secret phrases that supposedly unlock hidden modes. Courses on incantations. I understand why it sells, because it flatters a hope we all have, that there is a hidden key and you only need to find it.
I have spent the past year using these models for work that ships every day, and my honest conclusion annoys people: the exact wording of your prompt is the least important part of getting good results. It matters a little at the edges, and I will be specific about where. The stuff everyone obsesses over is mostly noise.
The four crowds
The obsession takes recognizable forms. The secret phrase crowd believes saying take a deep breath and work through this step by step flips a switch inside the model. The template crowd pastes a thousand word wall of rules and warnings in front of every request. The role play crowd opens with you are a world class expert with twenty years of experience, as though flattery changes the computation. And the punctuation crowd genuinely believes capital letters and exclamation marks make the model try harder.
All of it gets sold as engineering. I get the appeal. It feels like a craft, it gives you something to collect, and it hands you a knob to turn when the output disappoints.
Why the incantations faded
The uncomfortable explanation is that models improved underneath the folklore. The old tricks date from an era of genuinely weaker models that needed their hands held through every step. Back then, think step by step produced a real lift, because the model would otherwise rush to a sloppy answer. Modern models tend to do that reasoning on their own, so the phrase mostly adds words to something already happening.
The expert role play tells a strong model something it effectively already has, and your actual instruction does the steering regardless. Shouting in capitals achieves nothing beyond making the prompt harder to read. Most of these habits are harmless. The cost is the hour you spend rewording a request to get an answer nearly identical to the plain version you started with. People do that constantly and call it work. It is polishing the doorknob while the door stands open.
The biggest lever is context
Here is where the real gains live, and nobody sells a course on it because it sounds too plain. The model only knows what you put in front of it. When I get a bad answer, the cause, roughly nine times out of ten, is that I asked a question depending on things the model could not possibly know. It lacked the document. It lacked an example of what good looks like. It lacked the constraints I was silently holding in my head.
The moment I paste in the actual material, the real file, the real data, the real background, the answer improves dramatically, and no clever wording was involved. Consider how a coworker would handle the same request. Given no background, they would guess or ask. The model cannot ask, so it guesses, and then the guess gets blamed on phrasing. Before reaching for a magic phrase, ask a simpler question: does this thing have everything it would need to answer well. The honest answer is usually no, and escalating instructions have been papering over that gap.
Show one example
The second lever feels like cheating the first time it works. If you want output in a particular shape or tone or format, stop describing the format in prose. Paste one finished example and let the model copy the pattern.
I have repeatedly struggled through three paragraphs of format description, given up, pasted a single completed example, and received exactly what I wanted on the first try. A real example pins down the spacing, the tone, and the level of detail, including every property you would never think to write as a rule. Written descriptions of a format stay ambiguous. An example is exact. When the first example leaves something wrong, add a second that corrects it, and the pattern locks in tighter. Any time a description starts growing, that growth is the signal to show instead.
Hand it a tool
The third lever is access. A model on its own predicts text from what it already contains. The same model connected to search, to code execution, to your files, becomes a different animal entirely.
Ask a model to do arithmetic in its head and it can slip. Let it write and run a few lines of code for the same arithmetic and it is right every time, because now a calculator is involved instead of a guess. When an answer is wrong, the productive question is rarely how to reword the request. It is whether the model had any way to reach the true answer at all, or whether you asked it to guess at something it should have looked up or computed. A mediocre prompt with the right tool beats a beautiful prompt without one, essentially always.
Correct it, do not reroll it
The fourth lever is the most underrated: treating the exchange as a loop. The common pattern treats a prompt like a slot machine. Pull, inspect, pull again with slightly different words, hope. That is a lottery.
The productive pattern reads the output, locates the specific failure, and reports it. The tone is right and the second point is factually off, fix that. Wrong date here, the correct one is this. Closer, now shorter. One round of specific correction beats ten rounds of rewording the opening, because a correction delivers new information while a reword reshuffles the old request. Specificity is the active ingredient. Saying that is wrong, try again gives the model nothing. The people getting great results are steering across three or four turns, treating the first answer as a draft to react to rather than a verdict on their prompt.
Sometimes the model is the problem
The lever nobody wants to hear about, because no course can be sold on it: use a stronger model. If you are locked in a rewording battle with a small or old model, you are doing labor a better model would simply absorb. I have watched someone spend an afternoon engineering a prompt for a weak model when the stronger one would have answered the lazy one line version correctly. The model is usually a bigger variable than anything typed into it. Confirm you are not asking too much of something too small before investing in phrasing.
The checklist, in order
When an answer is not good enough, I run through five questions in a fixed order.
Did it have the context, the real material, or did I expect mind reading. Did I show an example of the shape I wanted. Did it have the tool to reach the answer, or was I demanding a guess. Did I correct the output specifically, or just reroll. Is the model strong enough for this task at all.
Wording sits below all five. Those questions repair the large majority of bad outputs, and most repairs never touch phrasing.
The fair caveat
Wording is worth something, and pretending otherwise would be its own kind of hype. On genuinely tricky tasks, where instructions are subtle or easy to misread, clarity and precision help. Answer in three short bullet points beats a vague request for something brief, because it is exact rather than magical. Removing a contradiction the model kept tripping over produces a real fix. And at production scale, where one prompt runs thousands of times, small consistent wording gains compound, so teams tuning production prompts are doing sensible work.
The ratio is the point. Wording is the final ten percent. Nearly everyone works the percentages in reverse order.
The actual skill
What separates people who get great results was never a vocabulary of incantations. It is clarity about what they want. They know exactly what they are asking for, notice which information is missing, spot when an answer is subtly wrong, and steer it back. That is an old skill, the one behind a good freelancer brief or a well written ticket, pointed at a new tool.
A prompt reflects how clearly you understand your own problem. A vague request cannot be rescued by phrasing, and a clear request fed with real context barely needs any. So when the next pack of secret prompts crosses your feed, smile and keep walking. Give the model the material, show it an example, hand it the tool, correct its work, and use one strong enough for the job. The words you type are the smallest part of the game.
More plain spoken breakdowns like this one live at [xavierfok.com](/).
Get new guides and videos first — join the Telegram channel.