Prompt engineer: a job that lasted eighteen months
For roughly eighteen months, prompt engineer was a job title people were hired into, wrote about and built courses around. It is now largely a component of several other roles rather than a role of its own, and that is not a verdict on the people who held it. It is what happens when a skill exists because a tool is hard to use and the tool gets easier. Models improved at following ordinary instructions, which removed most of the elaborate technique that justified a specialist. What remained turned out to be inseparable from two things the specialist usually did not own: knowledge of the domain, which is what tells you whether an answer is good rather than plausible, and the evaluation set, which is what tells you whether a change helped. A person writing prompts without either is optimising against an opinion.
Prompt engineer, in short
Contested title| In one sentence | Was a standalone job for about eighteen months and has largely been absorbed into the roles around it. |
|---|---|
| Judged on | Output quality on a defined task, when the role exists at all as a separate one. |
| Fails when | It is hired as a permanent position, because the skill is now a component of several other jobs. |
| Most confused with | AI engineering, which has absorbed most of it. |
The title is used for several different jobs, or is being absorbed into neighbouring ones. No compensation figures: see methodology.
What actually happened
Early models rewarded technique. Specific phrasings, elaborate scaffolding, careful ordering of examples: these produced measurably different results, and someone who had learned them by trial and error was genuinely more effective than someone who had not.
That gap narrowed quickly. Later models follow plain instructions well, and most of the technique that mattered became either unnecessary or built into the tooling. What was a specialist skill became something a competent engineer picks up in a fortnight.
The second thing that happened matters more and is discussed less. As systems moved from demonstrations into production, the constraint stopped being the prompt. It became retrieval, evaluation, cost and the organisational work of getting anything used, none of which a prompt specialist was positioned to own.
Why the skill is inseparable from two other things
Domain knowledge. Judging whether an output is correct, rather than well-formed, requires knowing the subject. On anything specialised, a prompt specialist without the domain cannot tell a good answer from a fluent wrong one, which is precisely the failure mode these systems have.
The evaluation set. Improving a prompt means measuring whether it improved, against cases somebody agreed were correct. Without that, iteration is a sequence of opinions and it frequently makes things worse on categories nobody was looking at.
Both of those belong to other people, which is the structural reason the role did not hold. A specialisation whose work depends entirely on two assets it does not own tends to be absorbed by whoever owns them.
Why hiring for it now is usually a mistake
The posting still appears, and it is generally a symptom rather than a need. An organisation writing it has usually noticed that output quality is disappointing and concluded that the prompts are the problem.
In most cases they are not. Take twenty failing examples and look at what the model was actually given: if the right information was not in the context, that is retrieval, and no prompt fixes it. This diagnostic takes an afternoon and redirects most prompt-hiring decisions.
Where the prompts genuinely are the problem, the person to hire is an engineer who will also own the evaluation set, or a domain expert who will define correctness. Either is more useful than someone who does only the middle step.
Where the technique still earns its keep
Two places, and neither is a job. The first is output format: getting a model to return something a downstream system can parse, every time, is fiddly and worth doing carefully, and it is the kind of work that rewards someone who enjoys the puzzle.
The second is cost. A prompt that has grown to several pages is paid for on every request, forever, and shortening it without losing behaviour is a real engineering exercise with a measurable return. On a high-volume system this can be worth more than any quality change, and almost nobody does it because nothing prompts them to look.
Both sit naturally inside AI engineering, alongside the evaluation work that tells you whether either change was an improvement. Neither is a week's work on its own, which is the point: they are tasks inside a job rather than a job.
What it says about the other titles
This is the clearest case on the site of a job title being absorbed, and it is worth reading as a warning rather than as a curiosity. Several of the titles on our careers page will go the same way, and we do not know which.
The position that survives is not a title. It is being the person who can tell whether a system is actually working, which requires owning a measurement and understanding a domain. Those two things have been the durable part throughout, and they were exactly what this role lacked.
