In 2023, my prompts looked like Google searches. “Write a summary of X.” “List the pros and cons of Y.” The model would produce something adequate. I’d use it, slightly disappointed.
What changed: I started treating the prompt like a design document, not a search query.
The output difference was embarrassing in retrospect. Same model, same tasks. Structurally different input.
Why This Still Matters in 2026
There’s a persistent belief that prompt engineering is temporary — that as models get smarter, the craft of input design becomes obsolete. The data doesn’t support this.
A 2026 MMLU-Pro study found that structured chain-of-thought prompting delivered an 18%+ performance improvement over unstructured queries on the same model. The mechanism doesn’t degrade as models improve. If anything, capable models respond more to well-structured input, because there’s more leverage when the base capability is high.
What does change: which techniques matter. Some approaches from 2023 are now default model behavior. A few newer ones — particularly around reasoning models — are underused.
The Two-Model Split
The most important structural shift in prompting since 2024: standard models and reasoning models require different approaches.
Standard models (Claude Sonnet, GPT-4o tier, Gemini Flash) are next-token predictors. You give them more structure, more examples, more explicit framing, and you get better output. The prompt does the reasoning scaffolding.
Reasoning models (Claude Opus 4.6, GPT-5.4, Gemini 3.1 Pro, o3) do their own thinking. If you give them explicit step-by-step CoT instructions, you’re sometimes interrupting a better process they’d have run anyway. Longer prompts can hurt.
This matters because: the prompting tutorial from 2024 telling you to always use chain-of-thought is giving you wrong advice for half the models you’re using today.
For reasoning models: give them the problem and the constraints. Let them think. For standard models: give them the structure.
Zero-Shot and Few-Shot: The Foundation
Zero-shot: no examples, just the task. Works well for simple, well-defined requests on capable models.
Few-shot: 2–5 examples of the input/output pattern you want. The model infers the pattern and applies it. This is the highest-leverage technique for output format consistency. Three good examples beat a paragraph of format instructions.
The mistake most people make: using examples that don’t represent the actual hard cases. Your examples should show the model how to handle edge cases — not the easy ones it would get right anyway.
Chain-of-Thought
CoT: ask the model to reason step by step before giving an answer. “Think through this carefully, then give your answer” is the minimal version. More explicit scaffolding for complex problems: “First, identify the key constraints. Then, consider each option against those constraints. Finally, recommend the best approach.”
This works because forcing explicit reasoning steps reduces the model’s tendency to jump to a plausible-sounding answer without checking it. The step-by-step output also lets you catch where the reasoning went wrong — which is actually the more useful property.
One caveat: on reasoning models, you often don’t need this. The model runs its own internal chain of thought. Explicit CoT instructions can produce worse results because you’re constraining a process that was already more thorough than your instructions.
Role Prompting
Weak: “You are an expert.”
Strong: “You are a senior software engineer with 15 years of experience in distributed systems. You have a strong bias toward operational simplicity over theoretical elegance, and you routinely push back on over-engineered solutions. When reviewing code, you always ask: what happens when this fails at 3 AM and the on-call engineer has never seen this system before?”
The specificity is the technique. Concrete roles with explicit values, biases, and behavioral heuristics produce output that feels like it comes from a real practitioner. Vague roles produce vague output.
This isn’t theater — it activates training patterns that correspond to how actual domain experts reason and write. I’ve used versions of this for a year. The difference between “senior developer” and a paragraph describing how that developer thinks is consistently 2–3 quality tiers in output.
Constraint-Driven Prompting
The problem with capable models: they can produce many valid outputs. Most prompts don’t narrow the space enough.
Constraints don’t just filter bad outputs — they define the target. “Write a marketing email” has an enormous output space. “Write a 150-word marketing email, no bullet points, no exclamation marks, one specific product benefit per sentence, audience is skeptical technical buyers who’ve been burned by AI hype” is a target. The model can aim at it.
Wrong constraints are better than no constraints. They tell you something about what you actually want.
System Prompts: The Infrastructure You’re Underusing
Most people write system prompts once and forget them. This is the single biggest missed leverage point.
Your system prompt is persistent behavioral configuration. It defines how the model behaves across every interaction in that environment. Getting this right is worth 10x the effort of prompting each individual query.
A good system prompt includes: the model’s role (specific, not generic), behavioral rules, output format defaults, and domain-specific context that doesn’t change across queries. If you’re restating your preferences and constraints in every conversation, that content belongs in the system prompt.
The reason people underuse it: the payoff isn’t visible in one query. It compounds across hundreds.
The Mistakes That Are Costing You
Vague roles, as above.
No examples when output format matters. If you care what the output looks like, show it.
Conflating standard and reasoning models. Prompting o3 like GPT-3.5 is leaving capability on the table. Same problem in the other direction with Claude Opus.
The most expensive mistake: prompting each query from scratch instead of investing in system prompts. You’re paying the prompting tax every time instead of once.
Adding “please” and “thank you.” Not because politeness is wrong — because these tokens shift the model’s register in ways you don’t want and take up space you could use for constraints. Be direct.
Building a Prompt Library
The teams getting consistent results from AI aren’t prompting from scratch each time. They have a library: tested prompts for repeated tasks, versioned and updated as model behavior changes.
Start with the five tasks you run most often. Write a good prompt for each. Test it on 10 real examples. Note where it fails. Update.
The discipline: never throw away a prompt that worked. Never use a prompt that hasn’t been tested.
Six months of this and you have infrastructure. The model isn’t smarter — but your ability to extract from it consistently is.
The Compound Effect
Bad prompts cost more than the immediate output quality. They make AI feel less useful than it is. You do less with it, develop fewer intuitions, build less infrastructure.
Good prompting compounds the same way bad prompting does — just in the other direction.
The technical ceiling of these models is high. Most people are operating well below it because the prompting work is unglamorous and the gap isn’t visible until you’ve done the comparison.
If you want to get past the prompt layer entirely — understanding how model architectures affect prompting, how to build prompt infrastructure for teams, what spec-level differences in instruction following mean for system design — that’s what Deep Stack is for. Each quarter: one layer of the stack, protocol-level depth, practical for teams actually building on top of it.
Also on EchoNerve: MCP Explained 2026 · AI Agents Decoded 2026 · Stop Explaining Yourself to AI · Complete Guide to Claude Chat, Cowork, Code