A few years ago, almost no one described themselves as a “prompt engineer.” In a short span of time, the term evolved from a standalone job title to a skillset, or even a sub-skill. Initially marketed as an essential capability for working with AI, prompt engineering now sits at an awkward intersection between hype and practice, as models become easier to use and require fewer explicit instructions.
This article argues that prompt engineering describes a real activity, but not a distinct or durable discipline. Its value is contextual and derives from deeper expertise, rather than standalone.
To understand how this framing emerged, it helps to start with the origin of the term.
Where Did the Term Come From?
The term does not come from classical software engineering, nor was it coined in a foundational research paper. It emerged bottom-up, from user behavior and tool friction, at a moment when many people were trying to understand a new class of systems. The label gained traction by borrowing authority from its “engineering” half, even though, at its core, it refers to formulating inputs for probabilistic models.
Why did it catch on? It sells the idea of easy access or sort of a “shortcut” promise (no coding, no math) and is marketable as a new, “future-proof” skill.
Over time, the term expanded into an umbrella for multiple practices that vary significantly by domain and context. To see what it actually represents, it is more useful to look at how it appears in practice.
What Is “Prompt Engineering” in Practice?
In practice, prompt engineering is not a new engineering discipline. Its primary objective is to formulate effective inputs for large language models. More precise descriptions would be “instruction design,” “query formulation,” or “interface literacy.”
These terms are less compelling from a marketing perspective, but they describe the activity more accurately.
Observed in real-world use, the skills grouped under “prompt engineering” tend to fall into three distinct levels.
Level 1- User Level Skill
This is the level most courses focus on. It typically includes teaching users how to:
- Clearly formulate prompts and requirements
- Iterate through trial and error
- Use examples (few-shot or multi-shot prompting)
- Verify and correct model-generated output
At this level, the skills involved are closer to communication and user experience than to engineering.
Level 2 – Applied in Software Products
As AI tools become embedded in software products, developers grow more aware of differences between models and their behavior across contexts. Through experimentation, they determine which tools and configurations fit a specific use case.
In this setting, prompt engineering typically appears as:
- Versioned prompts
- A/B testing of outputs
- Constraints and structured output schemas
- Integration with code, data, and business rules
This is where prompt-related work begins to generate real value. However, it does not exist independently of software engineering; it is a component within it.
Level 3 – Research and Advanced Systems
At this level, practitioners start from an explicit understanding of model limitations: lack of true understanding, unstable memory, and no inherent notion of truth. These constraints lead to hallucinations and unreliable output if not addressed structurally.
Here, the language model is treated as an orchestrator rather than an expert. Domain expertise is externalized into tools such as databases, APIs, or deterministic computation systems, which the model can call when appropriate. Designing such systems requires substantial engineering beyond prompt formulation.
How a complex, level 3 AI system may look like (where prompt plays just a small role):
This is why few people operate at this level. It demands strong software engineering, data engineering, and product reasoning. It is also not easily teachable, because it depends heavily on real system constraints and context. At this stage, prompts play a relatively small role compared to architecture and tooling.
Are There Still Jobs for “Prompt Engineers” Today?
Short answer: yes. There are roles today that include “prompt engineer” or similar responsibilities in their titles or descriptions. However, these roles are rarely standalone in practice.
In most organizations:
- Prompt-related work is part of broader AI deliverables
- Prompts are written by developers, ML engineers, or product engineers
- Dedicated roles appear primarily in companies with AI-core products
At its simplest, prompt engineering means knowing how to efficiently formulate inputs for probabilistic models. As models diversify and specialize, techniques that work well for one system often do not transfer cleanly to another. This further reduces the likelihood that prompt engineering persists as an independent role, as models and interfaces continue to change.
A lawyer working with one system, a software developer using another, and a researcher using a third will each interact with models differently. They will each use specific tools. The commonality lies in domain expertise, not in universal prompting techniques.
Why Avoid the Hype?
There is a long history of aggressively marketed shortcuts, often promoted through boot camps or rapid retraining programs, that appeal to people seeking fast entry into technical fields.
Career transitions into IT and related domains are possible, but they rarely succeed through shortcuts. The framing of prompt engineering as a quick path into AI work follows a familiar pattern.
For comparison, during the dot-com bubble, it would have been easy to sell courses in “search engineering.” Over time, people learned through practice how to use search interfaces more effectively, while the most valuable skills emerged elsewhere, particularly in areas such as online marketing, product strategy, and systems design.
Conclusion
Prompt engineering exists and will continue to do so as an activity, and as a practical concern when working with language models. However, it is neither a standalone discipline nor a durable skill in isolation. Its value depends entirely on context, domain knowledge, and integration with broader systems.
The focus, therefore, should not be on mastering prompts as an end in themselves, but on developing the underlying expertise that gives those prompts meaning.