You could make this same argument about a lot of work that fall onto "engineering" teams.
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)
i dont see where a random seed would have any bearing on "a specific approach, based on rigour and repeatability"
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
It can perfectly be engineering if you have the right validation process. It is, if you can prove that the given randomness can provide satisfactory results to solve the given problem on 99,995% of the cases, then you have a product that solves a given problem following a typical engineering approach.
> Throwing new prompts at a machine with built-in randomness to see if one sticks is DEFINITELY not engineering.
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
Perhaps. My point is that the word "engineering" describes a specific approach, based on rigor and repeatability.
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.