Prompt Engineer: Is It a Real Job?
4 min read · updated August 3, 2026
The question is usually asked as though it has a yes or no answer. It does not, because “prompt engineer” never named one job. It named a bundle of four quite different activities that happened to be new at the same time, and the bundle came apart.
What the title named
When the term appeared, working with a model meant discovering, by experiment, how to make it do a thing at all. The people doing that were doing four separable activities at once:
- Discovery. Finding out what a model could do and what phrasing unlocked it. Genuinely novel work at the time, and genuinely valuable, because nobody knew.
- Craft. Writing the actual instructions well — unambiguous, ordered, with examples that carry the format. This is a writing skill more than a technical one and it is still real.
- Systematisation. Turning a prompt that worked once into something versioned, tested and safe to change.
- Evaluation. Deciding whether a change helped, which in practice is the hardest and least glamorous of the four.
The reason the title felt like a job was that in the early period the first activity dominated. Discovery is the one with the shortest shelf life: once something is discovered, it is written down, and the next person reads it instead of finding it.
Where each part of the work went
This is the useful part of the answer, because it tells you where the work is now rather than making a claim about how many job adverts exist.
| Activity | Description |
|---|---|
| Discovery | Largely written down. Techniques that were folklore are now documented patterns — few-shot, chain of thought, structured output, self-consistency — and models have been trained to need less coaxing. What remains is discovery specific to a domain or a task, which sits with whoever knows the domain. |
| Craft | Absorbed into the application engineering role, and into domain experts who write instructions for their own area. It is now a component skill in a larger job, in the way that writing good SQL is a component of backend work rather than a job called SQL engineer. |
| Systematisation | Became ordinary software engineering: prompts in version control, reviewed, tested, rolled out behind flags. Nothing about it is prompt-specific once you accept that a prompt is source code. |
| Evaluation | Grew into its own discipline and, in larger teams, its own role — the person who owns frozen sets, judges and regression gates. This is where most of the durable value of the original bundle ended up, and it is the least like what the title suggested. |
The pattern is not that the work disappeared. It is that a new activity, once understood, gets distributed into the roles that own the surrounding system — which is what has happened to every new technical activity, and is predictable from what a skill is attached to.
There is a second force worth naming, because it explains why the bundle could not have held together even if the discovery had continued. A person who writes prompts but does not own the system they run in has no way to know whether their change helped: the measurement lives with whoever owns the evaluation, and the deploy lives with whoever owns the service. Splitting authorship from measurement is uncomfortable in any engineering discipline and it is untenable in one where the only way to tell whether something works is to measure it. Roles that cannot close their own feedback loop get absorbed by roles that can, and that is what happened here.
Where it is still a whole job
Three situations, and they are real rather than consolation:
- Where the domain knowledge is the scarce input. A clinician, a lawyer or a claims specialist writing and maintaining the instructions for a system in their own field is doing work an engineer cannot do. The title is sometimes attached to this and it describes something coherent — though the person is usually better described as the domain owner of a system.
- Where the surface is adversarial. Teams building guardrails, running red-team exercises, or working on how systems get talked out of their instructions do prompt-level work full time, because the adversary keeps producing new material. This is closer to security than to writing.
- Where a company’s product is the prompt layer. Model providers, evaluation companies and tooling vendors employ people whose entire job is the interface between instructions and behaviour, because that interface is what they sell.
Reading an advert with this title
The title itself carries almost no information, so read the responsibilities and ask three questions:
- Does the role own an evaluation? If yes, it is a real job with a durable core, whatever it is called. If quality is assessed by someone trying it, the role is a demo function and will be reorganised.
- Does it write code? A role that produces prompts for someone else to integrate has no control over the system it is judged by, which is an unhappy position regardless of the field.
- Is there domain depth in the requirements? If the advert wants someone who knows insurance claims or radiology reporting, the prompt part is the interface and the domain is the job. That is a strong role.
A fourth, quieter test: ask what happens to this role when the model is upgraded. If the answer is “we rewrite the prompts”, the role is maintenance on something fragile. If the answer involves running an evaluation and seeing what moved, the team has built something that survives a model changing underneath it.
If this is the work you want
The instinct behind wanting this job — an interest in language, in precision of instruction, in the gap between what you said and what was understood — is a good instinct and there is a lot of work for it. It is just distributed differently than the title suggested.
The highest-leverage move is to add the two things the title lacked: the ability to measure, and the ability to ship. Someone who writes excellent instructions, can prove with a frozen set that a change helped, and can put it in production behind a flag is not competing for a shrinking category of job. They are an application engineer with an unusually strong version of the most-used skill in the role.
Conversely, the honest warning: a portfolio consisting of prompts is a weak artefact, because a reader cannot tell whether they work. The same prompts with an evaluation attached become evidence. That conversion — from craft to evidence — is the whole of the career advice here, and it is the same move a portfolio needs.