Why "Prompt Engineering" Is Mostly Snake Oil

You can stop optimizing your system prompts. Not because prompts don't matter — they do — but because the cottage industry that sprang up around "prompt engineering" is selling a skill with a half-life of about six months, and most of what it teaches was never real in the first place. The actual skill is knowing what you want from the model. The rest is theater.

The Credential That Isn't

There are people on LinkedIn with "Prompt Engineer" in their title who charge $200/hour to write system prompts. There are courses — dozens of them — promising to teach you the "science" of prompt engineering. Some of these courses cost more than a month of Claude Pro. What they teach, in most cases, is a combination of obvious advice ("be specific"), outdated tricks ("say 'think step by step'"), and formatting superstitions that stopped mattering two model generations ago.

The fundamental problem is that prompt engineering as a discipline is built on a moving target. A technique that improved GPT-3.5 output by 20% might do nothing for Claude 3.5 Sonnet. A formatting trick that worked in March might be irrelevant by June because the model got better at interpreting natural language. The people selling prompt engineering courses are selling maps to a coastline that reshapes itself every quarter.

I've watched this happen in real time. In 2024, there was a widely shared technique involving XML tags in Claude prompts — wrapping your instructions in specific XML structures supposedly improved output quality. It worked, sort of, for a while. Then Anthropic improved Claude's instruction-following and the XML wrapping became unnecessary for most use cases. The technique didn't become wrong exactly — it just stopped mattering. The people who built courses around it kept selling those courses.

What Actually Matters (And It's Not What They're Selling)

Here's what I've found after two years of daily LLM use across Claude, GPT, and various open-source models: the things that consistently improve output are so boring that nobody could build a $500 course around them.

Be specific about what you want. Not "write me a blog post about AI" but "write a 1,200-word article about how Claude's extended thinking feature performs on code debugging tasks, using a conversational tone, with specific examples." This isn't prompt engineering. This is communication. The same skill that helps you write a clear email to a contractor helps you write a clear prompt to a model. There's no secret technique — there's just saying what you mean.

Give the model context it needs. If you want Claude to write in your voice, show it examples of your voice. If you want it to analyze data, give it the data. If you want it to follow a specific format, show it that format. This is obvious, but most "prompt engineering" failures I see are actually context failures — the person didn't give the model enough information to do the job, then blamed the prompt.

Tell it what not to do. Models have default behaviors. If you don't want Claude to add caveats and qualifiers to every statement, tell it not to. If you don't want GPT to use bullet points for everything, say so. Negative instructions — the things to avoid — often matter more than positive instructions. This isn't a secret. It's in every model's documentation. For free.

Use the right model for the task. No amount of prompt engineering makes a small local model good at complex reasoning. No prompt trick makes GPT-4o faster than GPT-4o mini. The single biggest improvement most people can make isn't in their prompts — it's in their model selection. This is something the prompt engineering industry would rather you not think about, because "use a better model" isn't a sellable skill.

The Chain-of-Thought Trick and Its Descendants

The one technique from the prompt engineering world that has genuine, replicable value is chain-of-thought prompting — asking the model to reason through a problem step by step before giving an answer. This works. It's been validated in research. It measurably improves performance on math, logic, and multi-step reasoning tasks.

But here's the thing: every major model now does this automatically. Claude has extended thinking. GPT has its reasoning models. The technique that was once the crown jewel of prompt engineering got absorbed into the models themselves. You don't need to ask Claude to "think step by step" anymore — you can just turn on extended thinking and it does this by default, better than any prompt could induce.

This is the pattern that should make you skeptical of prompt engineering as a long-term skill. The best techniques get absorbed into the models. The mediocre techniques stop working when models improve. And the bad techniques — "pretend you're an expert," "I'll tip you $200 for a good answer," "this is very important to my career" — were always superstition dressed up as methodology.

The Part That's Real

I don't want to be entirely dismissive, because there is a real skill underneath all the snake oil. It's just not the skill that's being sold.

The real skill is problem decomposition — knowing how to break a complex task into steps that a model can handle reliably. This is a software engineering skill, not a prompt engineering skill. If you're building a pipeline that takes a PDF, extracts the key arguments, cross-references them with a database, and generates a summary, the hard part isn't the prompts. The hard part is the architecture — which steps to automate, where to put human checkpoints, how to handle failures. The prompts at each step are usually simple. "Summarize this document in three paragraphs, focusing on the financial claims" doesn't need optimization. It needs to be clear.

There's also a real skill in understanding what models are good at and what they're not — which is closer to knowing your tools than to "engineering." Knowing that Claude handles long documents better than GPT for certain extraction tasks, or that GPT-4o's image generation follows compositional instructions more reliably than Midjourney — this is tool literacy. It matters. But calling it "engineering" inflates what it is, and the inflation is the point, because engineers get paid more than people who "know their tools."

The $200/Hour Question

If someone offers you a prompt engineering consultation, here's what you should ask them: what specific, measurable improvement will this produce, and how long will that improvement last?

If the answer is vague — "better outputs," "more consistent results," "unlock the model's potential" — you're looking at snake oil. If the answer is specific — "I'll build you a structured extraction pipeline for your legal documents that reduces review time by X hours per week" — that's real work, but it's not prompt engineering. It's systems design that happens to involve prompts.

The best AI practitioners I know — the people who actually ship things with LLMs — spend almost no time optimizing prompts. They spend time understanding the task, choosing the right model, building good pipelines, and handling edge cases. Their prompts are clear and simple. They'd never call themselves prompt engineers. They're just builders who use LLMs as one tool among several.

What to Do Instead

Stop taking prompt engineering courses. If you've already taken one, you probably learned some useful basics about being specific and providing context — good, you have those now, move on. The marginal return on further prompt optimization is almost zero for most people.

Instead, spend that time learning how the models actually work at a high level — not the weights and transformers, but the practical patterns. Learn what context windows mean in practice. Learn when retrieval-augmented generation helps and when stuffing everything into the context works fine. Learn how to evaluate whether an LLM output is good or confabulated. These skills compound. Prompt syntax doesn't.

If you're building something production-grade with LLMs, invest in evaluation — systematic ways to measure whether your outputs are good. A/B test your prompts if you want, but test against "no prompt engineering at all, just a clear instruction" as your baseline. You might be surprised how often the simple version wins.

The prompt engineering industry will fade as models get better at understanding intent. It's already happening. Two years ago, you needed careful prompting to get a model to follow a format. Now you just describe what you want and it works most of the time. The gap that prompt engineering fills is shrinking every quarter. The people selling courses know this. That's why they're selling courses now, while the market still believes the gap is wide.

Write clear instructions. Give sufficient context. Choose the right model. That's it. Everything else is decoration.

This article is part of The Weekly Drop at CustomClanker.

Related reading: Claude's Extended Thinking — Worth the Wait, The Fiddling Trap, System Prompts: What Actually Works