Prompting: a specialised skill or a basic professional one?

Two claims that block thinking

The first arrived with consumer generative models: prompting as a new discipline, with its experts and its recipes. The second came as a backlash, as models grew tolerant of imperfect phrasing: if asking normally now works, the topic supposedly no longer exists.

Both share a flaw: they talk about different objects without saying so. Writing a clear request to an assistant to draft meeting notes, and designing the system instruction of a service handling thousands of requests a day, are not the same activity. The first is usage. The second is an engineering building block. Conflating them produces circular debates and, inside companies, badly calibrated expectations.

This analysis makes no prediction about the rise or disappearance of a Prompt Engineer role. It describes what the word "prompting" concretely covers depending on context, and where the real difficulty sits.

Prompting as a general professional skill

For a professional using AI systems at work — analysis, writing, summarising, exploring, preparing a decision — prompting is not a discipline. It is an extension of a much older skill: knowing how to formulate a request. What separates effective use from frustrating use comes down to a handful of behaviours, all transferable across tools.

• State the objective clearly: what you want, and what the output will be used for. A request without purpose returns a generic answer.
• Provide the useful context: the material, the audience, what has already been tried, what is out of scope. The model does not know the situation.
• Make constraints and format explicit: length, tone, structure, level of detail, language. Many disappointments come from an implicit format.
• Iterate rather than ask for everything at once: correct, narrow, request a variant, ask for reasoning to be made explicit when useful.
• Verify the answer: cross-check facts, figures, quotes and references. Well-written output is not accurate output.
• Know when not to trust the result: high-cost errors, recent information, regulated domains, no verifiable source.

This level transfers in a few hours of guided practice. It produces a real and immediate gain, and it does not justify a job title. It is, however, quietly entering many professional expectations — much like using a spreadsheet or a document search tool properly.

The real maturity marker: verification

The most visible difference between two users is not phrasing but what they do with the answer. One takes it as is; the other knows which parts are verifiable, which are not, and stops using the output when uncertainty exceeds what the context allows. That judgement is a professional skill, not a technical one.

Prompting as a component of an AI product

The subject changes nature as soon as the prompt stops being written by a human for themselves and becomes part of a system that runs automatically, for users who never see it and cannot correct it. The prompt is then code: it has an interface, dependencies, versions, side effects and costs.

• Templates and variables: the prompt is parameterised; what varies must be identified, escaped and controlled, including when the input comes from a user.
• System instructions: they set the role, the scope, the prohibitions and the behaviour under doubt. This is often where functional safety is decided.
• Context: what goes in, where it comes from, how it is selected, what happens when it is too long or empty.
• Structured outputs: a downstream system consumes the answer, so the format must be guaranteed — with defined behaviour when it is not respected.
• Tool use: once the model can trigger actions, the question becomes permissions, reversibility and human validation.
• Versioning: a modified prompt is a deployment. Without history, nobody can explain why behaviour changed.
• Evaluation and regressions: a test set replayed on every change, otherwise every local improvement is paid for elsewhere, silently.
• Security: hostile inputs, instruction-hijacking attempts, leakage of information present in the context.
• Cost and latency: prompt and context length are paid on every call and felt in every interaction.

At this level, "writing a good prompt" is one skill among a dozen, and rarely the limiting one. What blocks a production system is usually data, evaluation, edge-case handling and orchestration — not the elegance of the wording.

Comparison: personal prompt versus production prompt

Take one need: summarising a customer complaint to prepare a reply. The personal version and the product version do not answer to the same quality criteria.

The second is not "the same prompt, better written". It is a software component of which the text is only one part. That is exactly why "do we need a prompting specialist?" has no general answer: it depends on where the prompt sits in the system.

What model progress actually moves

Recent model generations follow instructions better, tolerate rough phrasing and require fewer contortions. Part of the early craft — incantation-style formulas, rigid structures, elaborate decompositions designed to route around limitations — loses value. That is observable, and it explains the second claim.

But this erosion hits the most superficial layer. It changes nothing about what stays outside the model.

• Framing: a more obedient model does not invent the problem to solve, the scope, or the forbidden cases.
• Context: the quality of what you supply remains decisive; no model guesses information it cannot access.
• Evaluation: knowing whether one version beats another is measurement work, independent of model generation.
• Orchestration: chaining steps, calling tools, handling failures and retries remains engineering.
• Control: permissions, traceability, behaviour under doubt, and where human validation sits.

Put differently: models gradually absorb the tricks, not the responsibilities. What is a decision — what the system should do, on which data, how far, and how we check it — cannot be delegated to the model.

Placing your own practice honestly

For a professional, the point is not to settle a public debate but to describe your own level without overclaiming. Three positions are clearly distinct, and they open different doors.

• Professional usage: I use these systems regularly at work, I can frame, iterate, verify and spot the cases where I must not rely on the output.
• Usage design: I built working practices for a team, defined what can and cannot be delegated to the system, and supported adoption.
• Product component: I contributed to prompts embedded in a product, with evaluation, edge-case handling, versioning and behaviour monitoring in production.

All three are verifiable in an interview. "Prompt engineering expert" is not, and turns against whoever uses it fairly quickly. Describing the actual level, with context and outcome, is both more modest and far more solid.

• Prompting
• AI literacy
• Copilots