> I honestly don't see anything that's truly unique to ML here. - The workloads are specific (lots of offline batch processing, accelerator powered offline stu

> I honestly don't see anything that's truly unique to ML here. - The workloads are specific (lots of offline batch processing, accelerator powered offline stuff, then speed/power/resource constrained inference stuff) - The hardware is specific (ML accelerators are for ML, you don't really use TPUs for anything else do you?) - Debugging is specific (ML-specific tools like XLA) - Labeling is specific (e.g. labeling audio, video, 3D points requires specific tooling) If what you're saying is, "ML engineering sounds like engineering" that's obvious and was never a point in contention. OP's comment was "a couple of motivated engineers can make ML work" and my point is -- kind of, but at scale you need a lot of very specific things which are best done by specialized folks. That there are billion dollar ML infra companies, as well as companies with ML infra teams that are hundreds of people, means that folks are finding it worthwhile to have, say, a team of folks who work on deploying nets efficiently and only that. Or a team of folks who only build labeling tools. Or a team of folks who only build model evaluation tools. My ramble was mainly to illustrate just how many sub-problems there are in ML and why ML infra is rightfully a big business -- there's a reason companies that use a lot of ML don't just have 2-3 randos building everything end-to-end for each model. > The part that is described as "model training" in ML is just done manually by developers and expressed as iterations in engineering. I would therefore think that the skillset is very much transferable and much of the apparent novelty is just traditional software engineering and management practices hidden behind ML jargon. Yeah ML engineering is engineering, so plenty of skills transfer between ML engineering <-> other engineering. But if you want to go from other engineering -> ML engineering, you do have to learn ML-specific things that I would not dismiss as "novelized software engineering" or just "jargon."