I prefer to call it "prompt alchemy" for exactly the reasons you described. It can't be engineering if you can't understand what you are trying to engineer with. Alchemists were sort of proto-scientists and engineers because they were trying to get use out of a physical world that they did not fully understand.
Ask HN: Is prompt engineering just snake oil?
91–100 of 206 posts
Re: Ask HN: Is prompt engineering just snake oil?
#92Earlier quoted context omitted.
When a building collapses you can’t just reboot it But in software you can simulate and test all you want before connecting it to the real world
To be fair, when the building collapses in the CAD simulation, you just "reboot" it with different parameters. Civil engineers don't actually put bricks or weld a metal.
Problem is that CAD is just an approximation of the real world and will never simulate it 100% faithfully.
Software on the other hand can technically be simulated 100% accurately, barring hardware or interpreter bugs.
Re: Ask HN: Is prompt engineering just snake oil?
#93Is sort of snake oil. People would have an entire arXiv article explaining "Explain Step by step" as prompt engineerning, but in reality, it's just natural language to say "step by step" if you want it to be step by step.
Re: Ask HN: Is prompt engineering just snake oil?
#94It's okay; software engineering isn't real either. (In many countries, the word "engineer" is regulated -- you can't call yourself an engineer without professional qualifications and oversight.) https://en.m.wikipedia.org/wiki/Regulation_and_licensure_in_...
Yeah, pretty much this. Only a subset of the actual activity that falls under the umbrella of "software engineering" could be called engineering in the traditional sense. The engineers working on aviation software and other low-level, real-time, performance critical systems probably need to use quite a bit of maths and are closest to doing what we traditionally consider engineering. All those teams working on web app…
in aviation, engineering is basically trying to get 5-6 sigma safety
Re: Ask HN: Is prompt engineering just snake oil?
#95It's okay; software engineering isn't real either. (In many countries, the word "engineer" is regulated -- you can't call yourself an engineer without professional qualifications and oversight.) https://en.m.wikipedia.org/wiki/Regulation_and_licensure_in_...
When a building collapses you can’t just reboot it But in software you can simulate and test all you want before connecting it to the real world
No amount of testing will prevent all errors, and certain bugs can cost human lives.
Re: Ask HN: Is prompt engineering just snake oil?
#96I just see it as proper thinking, but yeah prompt engineering sounds more catchy.
Re: Ask HN: Is prompt engineering just snake oil?
#97Earlier quoted context omitted.
> there will always be some skill There is a world of difference between the needs in governance in just having to write "Those decorations where I marked the area, make them a bit more Hans Holbein as opposed to Klimt", compared to knowing patching tricks so that if you asked the engine to draw a 'T' you were not being served a 'B'. This latter example - ask 'B', get 'T' - I have seen from Midjourney only a few hour…
I disagree it will ever be that easy for people to generate specifically what they’re looking for. I believe there will always be some amount of navigation of the latent space required, and people who don’t understand how to navigate it will struggle. To use your analogy, even if the horse is tame you still need to know how to ride it.
> that easy
Can you code? Can you illustrate? Can you build? Piece by piece, you sketch, implement, hone, finetune, improve, correct, retry, go into detail, expand... The ease of the process is relative to the tools adopted.
Of course there has to be knowledge behind it. Of course you have to know your tools. But "wild horse" and "diligent consultant", axe and scalpel require different degrees areas and modalities of competence.
A well built tool will build on the competences already natural for the professional (e.g. a graphic designer will be able to sketch and to instruct the machine in a reasonably standard language). Of course the better you know your tool, the greater the effectiveness. But currently, the systems can be strongly unreliable - they do not respect the request.
The user will have to learn to deal with a machine taking natural language as an input just like any manager has to know how to speak to personnel to obtain what is wanted. On the other hand, the implementation of "virtual personnel" which is reliable is a responsibility of the tool developers.
Re: Ask HN: Is prompt engineering just snake oil?
#98> Below is a list of some known non-speech sounds, but we are finding more every day. Please let us know if you find patterns that work particularly well on Discord! [laughter], [laughs], [sighs]....
This is likely a reflection of the data used to train the model - TTS models are trained on labeled audio, one form of which is subtitled audio streams. In subtitles / closed captioning, bracketed words are frequently used when there is something audible that is not speech.
Based on this insight, it should be possible to inspect the training data and extract a set of non-speech sounds the model is likely to generate well - but that doesn’t drive engagement of your users like asking them to experiment themselves does ;)
For example, closed captioning adds music notes (♪) when music plays or when people sing. According to the Bark docs, adding ♪ causes the model to output things as music.
Re: Ask HN: Is prompt engineering just snake oil?
#99In essence it's all about getting results, and specialisation might yield better results. Just because people think it sounds cool to call it 'prompt engineering' doesn't mean it's not a specialisation (or optimisation), even if the terminology is based on nothing.
I do think that it's not broad or deep enough (right now) to merit a completely separate area of expertise on its own, but it can be too big to fit within the minds and areas of expertise of people who already have their work cut out for them in their existing workdays. Think about most desktop computer users, they really have no clue how the computer works, and even asking them to change a resolution on a mirrored display might be too far removed from their knowledge base (and that is fine). This also applies to tokenisation prompt inputs; it might take too much for someone to simply tack that on to what they already do and know.
This is then were we get job postings and those need to be easily identified, so people can search for them, and this is where we get nonsense terms used to distinguish the desired applicants from the pool of work-seeking people.
Re: Ask HN: Is prompt engineering just snake oil?
#100Earlier quoted context omitted.
You should rethink that whenever you drive under a bridge or get on a boat. The reason they collapse or sink so infrequently is largely because engineers are accredited and held responsible.
Causality will be tough here. I could also credit the certification regulations just as much. And truth to tell, construction techniques are vital, yet we don't value the construction workers in this way. That is, it is a whole system. And largely comes to costs and known building techniques. After all, certified engineers built "galloping gerdy." (And I didn't even get into maintenance costs and application. )
Construction techniques are vital, but a civil engineer is employed to conduct the correct QA/QC on those techniques.
This doesn't devalue the effort of the work crew, but it does recognize you need accredited professionals at certain parts of the process to ensure public safety.
To be a bit more pointed: causality isn't difficult here. This legislation and professional practice was deliberately designed as a result of the numerous failures observed throughout the 1900s. The cause: multiple fatalities and unreliable infrastructure let to the regulation of the engineering profession. The effect: we are safer.