Skip to content

Stop calling it “Prompt Engineering”

You don’t need to be an engineer to be good at prompting.

Prompt engineering is a term that’s been thrown around endlessly in the last 18 months: companies offering $300k+ salaries, developers with years of experience dropping everything to become Prompt Engineers, and a slew of articles about why everyone needs to hire one. So, to that point, do you need to hire a Prompt Engineer?

Well, it’s a messy question, because no one seems to agree what Prompt Engineering actually is. But I’d like to put to you that you probably already have the people you need – at least for writing prompts. It’s just that you don’t know it yet, and they don’t either. Let me explain.

A picture of a gate post with lock on it and the gate ajar.

“Prompt Engineering” is an unhelpful term

Firstly, what do people mean when they say “Prompt Engineer”? Read around and you’ll find that, broadly, people are talking about one of two things:

  • “The AI Whisperer” – someone with experience using LLMs, who knows how the models respond to certain inputs, and knows all the “hacks” and “tricks” to get the best outputs. They might be an enthusiast, they might work in tech, but they’re not necessarily an “engineer”.
  • “The AI Engineer” – someone who has the skills and experience of the AI Whisperer plus that engineering background. They know how to code (probably Python). They have knowledge of relevant tools, experience with the non-functional requirements (NFRs, such as security) specific to Gen AI, and the general engineering skills required to build the products around the prompts.

The thing is, “Prompt Engineer” is a poor name for either of these. Start with the AI Whisperer. This is a useful set of skills and experiences, but it’s not an “engineer”. These “hacks” and “tricks” don’t require a deeper technical understanding. In practice, it’s better to think of this as a competency, just like being good with Excel, or good at using Google. It’s something that, with a little help and experience, can be picked up by technical and non-technical people alike.

Calling it “engineering” risks discouraging people who don’t have a traditional engineering background (such as programming) from picking up these skills.

AI Engineers are essential, but not for writing prompts

So if the AI Whisperer can be boiled down to a competency – let’s call it “prompting” – what about the AI Engineer? If this is someone with the competency of prompting and the deep knowledge of an engineer, what’s not to love? Why not call them a Prompt Engineer?

An AI Engineer certainly is a valuable role (hence we employ several of them!). That deep understanding of NFRs – the performance, data and security concerns specific to Gen AI – is essential in an enterprise context. I’m sure a lack of this expertise is one reason why many organisations are struggling to scale up beyond proof-of-concepts.

But if we need AI Engineers to do so much work around the prompts, does it make sense to ask them to do the prompting too? Or is this like asking a car mechanic to moonlight as a taxi driver because of their deep understanding of cars?

It turns out that the best people to write prompts are those with the best context, and that’s rarely going to be your engineers.

Your Subject Matter Experts should be writing your prompts

Time and again I’ve seen projects start with the assumption that the engineers should write the prompts. Here’s what typically follows: the engineers know they don’t have the context they need, so they reach out to those who do, the Subject Matter Experts (SMEs). These could be a product team, or perhaps specialist domain experts. A back and forth ensues, and with time the responsibility for “prompting” gradually but irrevocably shifts from the engineers to the SMEs.

When you take a step back and think about it, this shift makes total sense. Good prompting requires a deep understanding of the business domain and goals but only a light understanding of LLMs themselves. So it’s much easier to get an SME sufficiently up to speed with LLMs than to get engineers fully clued up on the business context.

And this is good news! It means that most businesses already have the people they need for writing prompts. All that remains is to give them a little support.

Anthony Pengelly from Softwire speaking at latern in front of a crowd. He is pointing at a presentation behind him.

Your AI Engineers can support your SMEs

To get SMEs quickly up to speed with prompting, you need tooling, and you need a little knowledge-sharing.

Firstly, no-code/low-code tooling. This is an ever-changing market but there’s plenty out there. One that we’ve used with clients is Microsoft Prompt Flow. It provides a drag-and-drop approach to writing and chaining prompts. Non-technical users can develop and evaluate their own flows, while the engineers can set up useful scripts and tools, such as external integrations or data manipulation.

This brings me to my second suggestion, which is to provide SMEs with quantitative evaluation of prompts and flows. Measuring the efficacy of prompts is useful during development, but also as you scale to production: it ensures that new models or changes to your application don’t have a detrimental effect on the quality of the AI solution.

Ideally you would set up automated evaluation to give quick feedback to your SMEs, and in fact evaluation against predefined “correct” answers is built into Microsoft Prompt Flow itself. However some scenarios need a real pair of eyes, and in these cases you can bring an expert human assessor into your testing process, or even give production users a means of rating AI outputs.

Finally, knowledge-sharing. Having your engineers share those “hacks” and “tricks” I mentioned should be quick and easy, and will help your SMEs play catchup. More important though is to give basic training on NFRs such as security and performance. This should include guidance on things like mitigating prompt injection and optimising token usage.

Prompting is becoming a more universal skill, not a specialism

As the models have improved, the space for “hacks” and “tricks” has shrunk. We’ve seen prompting shift from “iF yOu wRiTe yOuR pRoMpT iN aLtErNaTiNg cApS aNd sEnD iT oN a tUeSdAy mOrNiNg, yOu’Ll gEt bEtTeR rEsUlTs” to something closer to a general communication skill. If this trend continues, it will become harder to justify roles that solely specialise in writing prompts. Instead, as Gen AI reaches into all areas of an organisation, it may become the norm for everyone to be writing prompts related to their individual skills, technical or otherwise.

But with research underway and models changing quickly, could anything break this trend? Well, prompting itself seems likely to change. A significant breakthrough along the lines of Golden Gate Claude could allow us to stop treating LLMs as opaque, which might lead to more hacking and model manipulation. And OpenAI’s new o1 series introduces chain-of-thought models that respond better to goal-setting prompts, rather than sets of instructions. But none of these change the need for domain expertise when applying LLMs in any specialised field.

So while Gen AI and prompting will keep changing, the value of domain expertise is here to stay. The sooner your SMEs learn prompting, the better. It’s time to stop calling it “Prompt Engineering”.