For example, Google defines the second meaning of "engineering" as:
2. the action of working _artfully_ to bring something about. "if not for his shrewd engineering, the election would have been lost"
(https://www.google.com/search?q=define%3AEngineering)
Merriam-Webster has:
3 : calculated manipulation or direction (as of behavior), giving the example of “social engineering”
(https://www.merriam-webster.com/dictionary/engineering)
Random House has:
3. skillful or artful contrivance; maneuvering
(https://www.collinsdictionary.com/dictionary/english/enginee...)
Webster's has:
The act of maneuvering or managing.
(https://www.yourdictionary.com/engineering)
Look up “engineering” in almost any dictionary, and it will list something along those lines as one of the meanings of the word. It is a well-established, nontechnical meaning of “engineering”.
the "engineering means working with engines" gibberish at the bottom is simply dishonest at best
"engineering" means "it's not guessing game"
I do that every morning, before applying my bus-taking engineering to my job.
Because I do prompt engineering for a living.
So many words lost their meaning today... I am glad I'm not the only one annoyed by this.
Words evolve over time because existing words get adapted in ways to help people understand new concepts.
maybe we started calling it "engineering" after we had some rules & calculations to make it "not-guessing-game"?
(1712) Newcomen Engine
(1776) Watt Engine
(1807) Atomic theory of Gasses (Dalton)
(1807) Concept of Energy (Young)
(1824) Carnot Cycle
(1834) Ideal Gas Law (Clayperon)
(1845) Relationship between work and heat (Joule)
(1840-60s) Laws of Thermodynamics (Carnot, Clausius, Kelvin)
The investment in the science of thermodynamics and the chemistry of fuels was largely motivated by the value of the steam engine, and the attempts to improve efficiencies allowing miniaturization, enabling locomotives and the railroad boom, and eventually automobiles and powered flight.
I think the era from say 1950..2020 has been a relatively unique period in history where science has been ahead of praxis (though folks in medicine or other fields might not have had that luxury). Recent advancements in AI preceding strong theoretical foundations might be a reversion to the mean.
https://www.nspe.org/about/about-professional-engineering/wh...
Or maybe it's a public service, which reduces instances of fraudulent behavior, and provides cleaner signal in the market of ideas.
Professional engineers would not have pushed Web3 or the worst abuses of social media.
This is not true for most so-called Engineers in the US. Anyone can declare themselves an engineer with no exam, no sponsor, no assermentation and no real legal ties to their shoddy work.
I don't think that's correct. While there are exemptions, each state requires anyone offering engineering services to the public to be licensed.
https://educatingengineers.com/blog/pe-license-requirements-...
That's just not true.
(Despite what Engineers Canada and related parasites tell you.)
There's an implicit assumption that anything an engineer does is engineering (and a deeper assumption that software as a whole is worthy of being called software engineering in the first place)
If the results of your work depend on a random generator seed, it's not engineering. If you don't have established practices, it's not engineering (hence "software engineering" was always a dubious term).
Throwing new prompts at a machine with built-in randomness to see if one sticks is DEFINITELY not engineering.
the approach uses random seeds, and the rigours make it repeatable.
if im thinking about mechanical engineering, something like the strength of a particular beam or the cycle life of a bearing is a random number. An engineer's job includes making random things predictable, by apply design tools like safety factors, and observability tools. thats why we prefer ductile materials; over brittle ones. both have a random strength around the spec, but one visibly changes before it fails, where the other doesnt. we can design in inspection processes that accounts for the randomness.
all kinds of tuning operations also start with somewhat random numbers and bring them to a spot. for the very contemporary example: training an ML model. start with random weights, and predictably change them until you get an effective function.
i dont think the randomness excludes "prompt engineering" from being engineering. instead, it's the rigour of the process in turning the random inputs into predictable outputs
Where does all the knowledge, laws of physics, and rules learned over many years to predictably design and build things come from, if not by throwing things at the wall and looking at what sticks and what does not, and then building a model based on the differences between what stuck and what did not, and then deriving a theory of stickiness and building up a set of rules on how things work?
"Remember kids, the only difference between screwing around and science is writing it down." -Adam Savage
"Great point, you're absolutely correct - things should not be floating around like that." - ChatGPT (probably)
So maybe "prompt engineering" is closer to real engineering than "software engineering" is!
Even minor changes to models can render previous prompts useless or invalidate assumptions for new prompts.
Changing the production or operating process in the face of changing inputs or desired outputs is the bread and butter of countless engineers.
Prompt engineering is honestly closer to the work of an o.g. engineer. Monitor the dials. Tweak the inputs. Keep the train on time.
But if you understand the model architecture, training process, inference process, computational linguistics, applied linguistics in the areas of semantics, syntax, and more— and apply that knowledge to prompt creation… this application of knowledge from systemic fields of inquiry is the definition of engineering.
Black box spaghetti-hits-wall prompt creation? Sure, not so much.
Engineering of the model architecture, sure. You can mathematically model it.
Prompts? Perhaps never possible.
You can no more assume the same exact production flow will produce equivalently for a different LLM model than you could for control of a different molecular compound put into product. If you choose only to consider it at the level of equipment assembly then sure, the basic rules of how you assemble the materials— the “physics”— doesn’t hold. If you do so at the same time that such efforts are informed by knowledge of the relevant fields such as material science and of course chemistry then you’re doing chemical engineering. Maybe you don’t want to call the construction workers engineers— though heck in that field many are! But certainly folks like the ones creating the guide posted are being informed by the exact sort of knowledge in the relevant underlying fields.
https://news.ycombinator.com/item?id=44978319
(They're not an LLM fan; also: I directionally agree about "prompt" engineering, but the argument proves too much if it disqualifies "context" engineering, which is absolutely a normal CS development problem).
There is engineering when this is done seriously, though.
Build a test set and design metrics for it. Do rigorous measurement on any change of the system, including the model, inference parameters, context, prompt text, etc. Use real statistical tests and adjust for multiple comparisons as appropriate. Have monitoring that your assumptions during initial prompt design continue to be valid in the future, and alert on unexpected changes.
I'm surprised to see none of that advice in the article.
I would like to add that predictable generation defeats the very purpose of generative AI, so prompt engineering in this context will never equate to what engineering means in general.
There’s one other type of “engineering” that this reminds me of…
2) I can tell you're not current with advances in AI. To be brief, just like with computer science more broadly, we have developed an entire terminology, reference framework and documentation for working with prompts. This is an entire field that you cannot learn in any school, and increasingly they won't hire anyone without experience.
Building a prompt is "prompt engineering". You could also call it "prompt crafting", or "prompt casting", but any of those would do.
Also, engineering also had a strong connotation of messing with stuff you don't understand until it works reliably. Your idea of it is very new, and doesn't even apply to all areas that are officially named that way.
Now it's all about Context Engineering which is very much engineering.
Now they come for engineering: software engineering, prompt engineering...
:P
_Even in that case_, if you can design prayers that get relatively predictable results from gods and incorporate that into automated systems, that is still engineering. Trying to tame chaotic and unpredictable systems is a big part of what engineering is. Even designing systems where _humans_ do all the work -- just as messy a task as dealing with LLMs, if not more -- is a kind of engineering.
> rules learned over many years
How do you think they learned those rules? People were doing engineering for centuries before science even existed as a discipline. They built steam engines first and _then_ discovered the laws of thermodynamics.
State your concrete problem and context. Then we funnel out by asking the AI to do a thorough analysis and investigate all the possible options and approaches for solving the issue. Ask it to go search the web for all possible relevant information. And now we start funneling in again by asking it to list the pros and cons of each approach. Finally we asked it to choose which one or two solutions are the most relevant to our problem at hand.
For easy problems you can just skip all of this and just ask directly because it'll know and it'll answer.
The issue with harder problems is that if you just ask it directly to come up with a solution then it'll just make something up and it will make up reasons for why it'll work. You need to ground it in reality first.
So you do: contrete context and problem, thorough analysis of options, list pros and cons, and pick a winner.
Reminds me of a time that I found I could speed up by 30% an Algo in a benchmark set if I seed the random number generator with the number 7. Not 8. Not 6. 7.
In my AI application I made deliberate decisions to divorce prompt engineering from the actual engineering, create all the tooling needed to do the prompt engineering as methodically as possible (componentize, version, eval) and handed it off to the subject matter experts. Clearly people who think this is the equivalent of choosing a seed shouldn't be writing prompts.
Nope. The job is still to come up with working code on the end.
If LLMs make your life harder, and you just don't use them, then you'll just get the job done without them.
But specialized instructions to weigh alternatives still works better as it ends up thinking about thinking, thinking, then making a choice.
Ask it to objectively list pros and cons from a neutral/unbiased perspective and then proclaim an answer, and you’ll get something that is actually thought through.
One could similarly argue software engineering is also just writing sentences with funny characters sprinkled in. Personally, my most productive "software engineering" work is literally writing technical documents (full of sentences!) and talking to people. My mechanical engineering friends report similar as they become more senior.
Yeah, precisely what I'm saying. I don't think "they write prompt 'engineering' instead of 'writing' to maintain the fragile egos of people who use chatbots" [don't agree? See Mr. "but muh soft skills!" crying down thread] is worth saying outside of HN if I'm honest.
Tech people do not feel good about "writing propt essay" so it is called engineering to buy their emotional acceptance.
Just like we call wrong output "hallucination" rather then "bullshit" or "lie" or "bug" or "wrong output". Hallucination is used to make us feel better and more acceptiong.
> Note: This tutorial uses our smallest, fastest, and cheapest model, Claude 3 Haiku. Anthropic has two other models, Claude 3 Sonnet and Claude 3 Opus, which are more intelligent than Haiku, with Opus being the most intelligent.
However, Anthropic has done some cool work on model interpretability [0]. If that tool was exposed through the public API, then we could at least start to get a feedback loop going where we could compare the internal states of the model with different prompts, and try and tune them systematically.
[0] https://www.anthropic.com/research/tracing-thoughts-language...
Then I had an idea: do I really want to be a "prompt engineer" and waste time on this, when the latest SOTA models probably already have knowledge of how to make good prompts in their training data?
Five minutes and a few back-and-forths with GPT-5 later, I had a working prompt that made the model follow all my instructions. I did it manually, but I'm sure you can automate this "prompt calibration" with two LLMs: a prompt rewriter and a judge in a loop.
I keep it short and conversational, but I do supervise it. If it goes off the rails just smash esc and give it a course correction.
And then if you're coming from no context: I throw a bit more detail in at the start and usually start by ending the initial prompt with a question asking it if it can see what I'm talking about in the code; or if it's going to be big: I use planning mode.
It's right there in the name. Large language models model language and predict tokens. They are not trained to deeply comprehend, as we don't really know how to do that.
LLMs mostly spew nonsense if you ask them basic questions on research or even master's degree-level mathematics. I've only ever seen non-mathematicians suggest otherwise, and even the biggest mathematician advocate for AI, Terry Tao, seems to recognise this too.
Without answers to these questions, I don't think we are ever achieving AGI. At the end of the day, frontier models are just arithmetic, conditionals, and loops.