We're rewriting two job descriptions and got stuck on whether to list prompt engineering as a requirement. The disagreement is real, not cosmetic, and I can't resolve it cleanly.
The skeptic case on my team: every "prompt trick" we documented in 2024 is now either built into the tool or made irrelevant by a model that just understands the messy ask. The clever phrasings, the role-play preambles, the "think step by step" rituals. They aged like UI workarounds, useful right up until the interface got fixed. By that logic, hiring for prompting is hiring for knowledge of a bad version of a thing that's actively improving.
The other case: the people who get good results consistently are not doing tricks. They're doing something older. They decompose a vague request into parts, they specify the format and the constraints, they notice when the model confidently invented a column that doesn't exist in our schema and they know it doesn't exist because they actually understand the data. That part has not gotten easier with better models. If anything a smoother model hides the failures better, so the skill of catching them matters more.
Where I keep landing: "prompt engineering" as a named technique is temporary, but it's pointing at a durable skill that's mostly just precise problem specification plus enough domain knowledge to audit the output. Which would mean we should hire for the underlying thing and never write "prompt engineering" on a req, because the label will be embarrassing in two years and attracts people who learned the tricks instead of the judgment.
The objection I can't shake is that I might be smuggling. Maybe "precise specification" is so general it's not a skill you can screen for, and the people defending prompting are defending something concrete and teachable that I'm waving away. So: durable skill, temporary artifact, or am I redefining it into uselessness?