Prompt Engineering Is Just Engineering

"Prompt engineering" got treated for a while like a mystical skill — a collection of tricks and magic phrases that unlock better output. The actual skill underneath it is a lot less exotic than that, and a lot more familiar to anyone who's already good at writing specs, filing bug reports, or briefing a teammate: precision.

The tricks were never the point

Early advice about prompting models was full of specific incantations — "think step by step," certain phrasings that supposedly unlocked better reasoning. Some of that had a real, measurable effect on older models. As models have gotten better at inferring intent, most of that effect has faded, and what's left standing is the boring stuff that was always true of any spec, written for a human or a model:

• Ambiguity produces ambiguous output. "Make this better" gets you something, but not necessarily the something you wanted. "Reduce this function's time complexity without changing its public signature" gets you a specific, checkable result.
• Missing constraints get silently invented. If you don't say what's out of scope, the model will guess — sometimes right, sometimes not. The same is true of an underspecified ticket handed to a junior engineer.
• Context you assume is obvious usually isn't. A model doesn't know your team avoids a particular library for a reason that predates the current codebase, unless you tell it. Neither would a new hire.

Why this framing matters more as models improve

As models get better at handling underspecified prompts, it's tempting to conclude that precision matters less. The opposite is closer to true: better models are more capable of acting on a precise, well-scoped request, which means the ceiling for how good the output can be goes up when you invest in the ask — and the floor for a lazy ask stays roughly where it was.

The gap between a mediocre and a great result from the same model is increasingly not about which "hack" phrase you used. It's about whether you did the work of actually knowing what you wanted before you asked for it.

What to actually practice

• Write the request like a ticket, not a chat message. What's the goal, what's the constraint, what does done look like.
• State what NOT to do when it matters. "Don't touch the existing tests" prevents a whole class of unwanted scope creep.
• Iterate like a code review, not a retry. If the first output misses the mark, say specifically what's wrong, rather than rephrasing the same vague ask and hoping for a different roll.

None of this is a trick. It's the same discipline that makes any specification useful, applied to a collaborator that happens to be a model instead of a person. The engineers who were already good at writing clear specs had a head start on "prompt engineering" long before the term existed.