Is prompt engineering still a real job?

For a brief period, "prompt engineer" appeared as a standalone role with striking salaries attached. Those postings have largely thinned out. This is usually reported as the field collapsing, which misreads what occurred.

The work was absorbed. Writing effective prompts turned out to be one component of building AI products rather than a discipline of its own — closer to knowing SQL than to being a database administrator. It became a skill inside other roles instead of a role.

This is a familiar pattern rather than a surprise. Webmaster, social media manager and mobile developer all had a period as standalone titles before dissolving into broader engineering and marketing roles. The dissolution is usually a sign the skill became normal, not that it became worthless.

Part of the shift is that the techniques got absorbed into the products. Much of the early craft consisted of workarounds for model limitations — elaborate formatting instructions, coaxing structured output, phrasing tricks that improved reasoning. Later models handle most of that natively.

Structured output is the clearest example. A substantial amount of early prompt engineering existed to persuade a model to return valid JSON, and that problem is now solved at the API level by schema constraints. The skill did not transfer; the need disappeared.

What that means practically is that prompt technique has a short shelf life. Anything you learn that compensates for a current weakness is likely to be obsolete within two model generations, which is a poor foundation for a career but a perfectly good thing to know.

What survived is more valuable than clever phrasing. Anyone can discover that asking a model to think step by step sometimes helps. What is genuinely hard is building a system around a model that behaves acceptably across thousands of unpredictable real inputs.

That means evaluation harnesses, retrieval pipelines, guardrails, fallback behaviour, cost control and monitoring. Those are engineering problems, and they are what teams are actually hiring for now under titles like AI Engineer or LLM Application Engineer.

Evaluation is the most durable of the group. A labelled set of examples with known-good answers keeps its value when the model changes, the framework changes and the vendor changes — which is more than almost anything else in this field can claim.

• Designing evaluations that reveal whether a change actually improved anything
• Retrieval — getting the right context in front of the model reliably
• Handling failure gracefully when the model is wrong
• Managing latency and cost at production volume

Some organisations do still post prompt-focused roles, typically where the work is content operations at scale, internal tooling, or red-teaming and safety evaluation. These are real jobs, but they are usually narrower and paid closer to operations than to engineering.

If the salary figures from the early hype are what drew you in, look at AI engineering roles instead. That is where the compensation went, along with the interesting problems.

Red-teaming is the exception worth watching. Finding the inputs that make a system behave badly is a genuine specialism with growing demand, particularly as more products give models the ability to take actions rather than only produce text.

If you have been working seriously with these models, you likely have more relevant experience than you are giving yourself credit for — but the framing matters. "Wrote prompts" reads as a hobby. "Built and evaluated a retrieval system that answered support questions with a measured accuracy improvement" reads as engineering.

Describe systems and outcomes rather than interactions. Then check your resume against a real AI engineering posting, because these roles are keyword-filtered heavily and the vocabulary gap is often the only thing standing between you and a first conversation.

Name the measurement explicitly. The single most persuasive sentence available to someone in this position is one that says how they knew the system worked, because it separates them from a very large number of candidates whose entire experience is informal experimentation.

The gap between where prompt-focused work sits and where the hiring is concentrated is mostly ordinary software engineering. Being able to write maintainable Python, work with an API under real error conditions and deploy something is the bulk of it.

Add data handling next. A great deal of what determines whether an AI product works is whether the right information reaches the model, and that is a data problem before it is a modelling one.

Then build one thing end to end and measure it honestly. The measurement is the part that converts an enthusiast into a candidate, and it is the part almost nobody coming from the prompt-only side has done.

• Python and general engineering practice, including tests and deployment
• SQL and moving messy data around without corrupting it
• Retrieval: chunking, embedding, filtering and ranking
• Evaluation sets, and the discipline of running them on every change