Most prompt engineering content is cargo cult thinking: people copying patterns that look like they work without understanding why they work. The honest truth is that the vast majority of prompt engineering advice, the chain-of-thought tricks, the "act as an expert" personas, the numbered instruction lists, produces marginal gains at best and actively clutters your thinking at worst. What actually moves the needle is a much shorter list, and it has almost nothing to do with syntax.
The Noise: What You Can Safely Ignore
There is a whole cottage industry built on the idea that prompt engineering is a technical skill analogous to programming. Write the incantation correctly and the model performs. This framing is mostly wrong, and it misleads founders into wasting time they do not have. A few specific examples of things that consistently underdeliver:
- Persona prompts like "You are a world-class copywriter with 20 years of experience" rarely improve output in any measurable way on modern models. The models already have that knowledge baked in. You are not unlocking a hidden mode.
- Elaborate formatting instructions at the top of every prompt. If you are specifying bullet points, headers, and tone in the same breath as the actual task, you have buried the task.
- "Prompt libraries" of pre-built templates for every situation. They tend to produce generic output because they are built for the average case, not your specific context.
- Threatening or flattering the model. Telling it that its "career depends on this" is not a strategy; it is noise the model processes and largely ignores.
None of this means you should write sloppy prompts. It means the optimisation effort most people are spending on syntax and phrasing would be far better spent elsewhere.
What Actually Matters
1. Context is the whole game
The single biggest driver of output quality is not how you phrase the instruction, it is how much relevant context you give the model before you give the instruction. Models are doing next-token prediction across everything in the context window. If your context is thin, the model fills in gaps with priors from training data. Those priors are average. Your situation is specific. The gap between the two is where bad output comes from.
In practice this means: before you write the instruction, write the situation. Who is the audience? What do they already know? What has already been decided? What constraints are real versus negotiable? What does a bad answer look like specifically? A prompt with rich situational context and a plain instruction will almost always beat a cleverly worded instruction with thin context.
2. The output you want, not just the task
Most prompts describe a task. Fewer describe the desired output explicitly. These are different things. "Write a product description" is a task. "Write a product description that a busy procurement manager at a mid-sized UK manufacturer would read and immediately understand what problem this solves, without any marketing language" is a target output. The second one gives the model a reader, a context, a register, and a constraint. It does not need formatting instructions because the output shape follows naturally from the specificity.
A useful forcing function: before you write your prompt, write one sentence describing exactly who will read the output and what they need to feel or understand after reading it. That sentence, added verbatim to your prompt, will often do more work than any prompt engineering technique.
3. Model selection matters more than prompt wording
Founders who use LLMs daily often settle on one model and then spend energy trying to coax it into tasks it is not well-suited for. Model choice is a higher-leverage decision than prompt wording. A reasoning-optimised model handles multi-step logic better than a fast general-purpose one, regardless of how you prompt the latter. A model with a longer and more reliable context window changes what you can even attempt. Routing the right task to the right model, even informally, is worth more than polishing prompt syntax.
4. Iteration beats optimisation
The instinct to get the prompt right before you run it is natural but mostly counterproductive for complex tasks. A faster loop, run it, read the output critically, identify the specific thing that is wrong, and adjust that one thing, produces better results than trying to anticipate every failure mode upfront. This is not the same as randomly tweaking. It is disciplined, targeted iteration where each run teaches you something concrete about where the model's mental model of your task diverges from yours.
5. Examples outperform instructions
If you want a particular output format, register, or style, showing the model an example of it is almost always more effective than describing it in instructions. This is not a new insight, but it is consistently under-used. One well-chosen example in a prompt does more than three paragraphs of formatting instructions. Two examples starts to constrain the output space meaningfully. This is especially true for tasks where quality is in the texture: tone of voice, reasoning style, how caveats are handled.
The Strongest Counterargument: "But Advanced Techniques Do Work"
The honest counterargument here is that some advanced prompting techniques, chain-of-thought, self-consistency, structured output constraints, demonstrably improve performance on specific categories of task. This is true. Asking a model to reason step-by-step before giving an answer does improve accuracy on multi-step reasoning problems. This is well-established and not in dispute.
But notice the qualifier: specific categories of task. Chain-of-thought prompting helps most on structured reasoning problems, maths, logic, multi-step analysis. It helps much less on generative tasks where the quality criterion is judgment or craft rather than correctness. Most of what founders and operators actually use LLMs for, drafting, summarising, classifying, extracting, researching, falls into the second category. The advanced techniques are real; they are just not as broadly applicable as the prompt engineering community implies. Using them selectively and knowingly is fine. Treating them as a general-purpose upgrade is where the cargo cult starts.
A practical rule: reserve structured prompting techniques like chain-of-thought for tasks where you can verify the answer is correct or incorrect. For tasks where quality is subjective or craft-based, context and examples will do more.
The Underlying Principle
All of the things that actually matter, context richness, output specificity, model fit, iterative refinement, few-shot examples, share a common root. They reduce the gap between what the model has to infer and what you actually want. Prompt engineering folklore, personas, magic words, numbered instruction lists, tends to operate at the surface level of the text. Real leverage comes from reducing ambiguity about the task, not from finding the right phrasing of it.
The practical implication for founders is this: stop optimising your prompts and start improving your inputs. The time you spend collecting better context, writing clearer output specs, and selecting the right model for the job will compound. The time you spend on persona phrasing and instruction syntax mostly will not.
A Note on Systematic Use
If you are using LLMs at any scale inside a product or workflow, rather than just ad hoc, a few of the prompt engineering fundamentals do become worth systematising: consistent output schemas, explicit handling of edge cases, temperature and sampling settings for the task type. But even here, the structural decisions matter far more than the linguistic ones. How you route tasks, what context you inject automatically, whether you validate outputs, these are engineering decisions. They are not really about prompt wording at all.
Is prompt engineering a real skill worth developing?
Yes, but narrowly. The genuinely valuable skills are: writing rich, specific context; describing output targets precisely; selecting the right model for the job; and iterating quickly on results. The syntax-level tricks most prompt engineering content focuses on are largely noise for everyday business tasks.
Does chain-of-thought prompting actually work?
It does, but on a specific category of task: structured, verifiable reasoning problems like multi-step maths, logic puzzles, or complex analysis with a correct answer. For generative tasks like drafting, summarising, or writing where quality is a matter of judgment, it helps much less than context richness and few-shot examples.
How much does model choice actually matter compared to prompt quality?
Quite a lot. Routing a reasoning-heavy task to a model optimised for reasoning will often outperform routing it to a faster general-purpose model with a polished prompt. Model selection is a higher-leverage decision than prompt wording for most non-trivial tasks.
What is the single most impactful change a founder can make to their LLM prompts?
Add more situational context before the instruction. Most prompts describe what to do but not the situation the task sits inside: who the audience is, what they already know, what decisions have already been made, and what a bad answer looks like. Filling that in consistently will improve output quality more reliably than any prompt technique.
Are prompt templates and libraries worth maintaining?
Only for well-defined, repetitive tasks with stable output requirements. For anything context-sensitive or where quality matters, pre-built templates tend to produce average output because they are built for the average case. Writing context-rich prompts per task beats re-using a generic template in most situations.