"Prompt engineering is dead" is one of the field's favourite recurring headlines. Each model generation makes some clever prompting trick unnecessary, and someone declares the whole discipline obsolete. They're catching a real trend and drawing the wrong conclusion. The tricks are dying. The engineering is becoming more important, not less.

What actually died

The early prompting era was full of folklore: magic phrases that supposedly unlocked better performance, elaborate role-play framings, incantations passed around like spells. "You are a world-class expert..." "Take a deep breath..." Some of these genuinely helped on weaker models. On modern models, most are noise. The models are better at understanding plain, direct instructions, so the party tricks have largely stopped mattering. Good riddance — they were always cargo-cult.

If that's all prompt engineering was, it would indeed be dead. But that was never the substance.

What replaced it: actual engineering

The real discipline is about constructing reliable, well-specified instructions — and in production, about everything wrapped around the user's raw input. This matters more as systems get more ambitious, not less.

Clarity and specification. The biggest gains come from being clear about what you want, what the constraints are, what the output should look like, and what to do in edge cases. Vague prompts get vague results. This isn't a trick; it's the same skill as writing a good spec for any system. Ambiguity is the enemy.

Structured output. When an LLM's output feeds another system, you need it in a reliable format — JSON, a specific schema, a fixed structure. Getting models to produce consistent, parseable output every time is real engineering: clear format instructions, examples, and increasingly, constrained-generation features that force valid structure. A pipeline that breaks when the model returns prose instead of JSON is a prompt-engineering failure.

Examples (few-shot). Showing the model a few examples of the input-output pattern you want remains one of the most effective techniques going. It often beats paragraphs of description, because it demonstrates rather than tells. Choosing good examples is a skill.

Decomposition. Hard tasks often work far better split into a sequence of simpler prompts than crammed into one giant instruction. Knowing when and how to break a task apart is core to building reliable LLM systems.

The production reality

In a real product, the user types something short and messy. What the model actually receives is that input wrapped in a carefully constructed prompt: system instructions, relevant context retrieved for this query, formatting rules, examples, guardrails. Building that wrapper well is prompt engineering, and it's the difference between a feature that works reliably and one that fails unpredictably in front of users. The user never sees it, which is exactly why people underestimate it.

Why testing is the unsexy core

Here's the part that separates folklore from engineering: you don't know a prompt is good until you've tested it across many inputs. A prompt that works on the three examples you tried can fail on the fourth. Serious prompt engineering means building a test set of varied inputs and measuring how the prompt performs across all of them — then iterating. This is the same systematic, evidence-based loop as any other engineering, and it's the opposite of hunting for a magic phrase.

How to be good at it now

• Be ruthlessly clear and specific. State the task, constraints, format, and edge-case handling explicitly.
• Show, don't just tell. Include well-chosen examples.
• Specify output structure and use constrained-generation features when output feeds other systems.
• Decompose hard tasks into reliable steps.
• Test systematically across many inputs and iterate on evidence, not vibes.
• Drop the incantations. If a phrase doesn't measurably help on your test set, it's superstition.

Prompt engineering grew up. It stopped being about secret phrases and became about specification, structure, and testing — the ordinary, unglamorous craft of building reliable systems. That version isn't going anywhere, because the better models get, the more we ask of them, and the more it matters that we ask precisely.