Here is a job posting I have read in four different fonts this year: "Seeking an AI/ML Engineer. PhD or MS preferred. Deep understanding of transformer architectures. Will leverage LLMs to build customer-facing features." Two sentences in, the requirement and the job have already divorced. The first sentence asks for someone who can do original research on model internals — a skill that, at a frontier lab, commands total compensation widely reported to run into seven figures. The second sentence describes calling an API. That gap, between the credential being demanded and the work being done, is the most expensive misunderstanding in technical hiring right now, and almost everyone is paying for it.
The conventional take says AI is a new discipline, so you must go and hire a new kind of person to do it — an "AI/ML developer," a separate exotic species adjacent to but distinct from your software engineers. I think that framing is mostly wrong, and that it is wrong in a way that costs companies money, time, and a year of stalled projects. The thing you are actually trying to staff is engineering. The math is mostly already in the model.
The job you're posting isn't the job you're hiring for
Separate two things that the title "AI/ML developer" deliberately blurs. One is research: designing novel architectures, training or fine-tuning large models from scratch, publishing, pushing the state of the art. The other is engineering: taking a model someone else trained and turning it into a feature that works, costs what it should, and doesn't fall over on Friday. These are different jobs, different people, and different price tags. The posting above asks for the first and pays for it, then assigns the second.
For the overwhelming majority of companies — anyone building a product rather than a model — the work is the second job, all the way down. You are not going to out-train OpenAI, Anthropic, or Google. You shouldn't try. Your competitive surface is what you build on top: the retrieval, the data, the evaluation harness, the guardrails, the latency, the cost ceiling. None of that requires a dissertation on attention mechanisms. It requires someone who has shipped production software and is not romantic about it.
What an "AI/ML developer" actually does all day
Watch the calendar of someone doing real AI product work and the glamour evaporates fast. They are wiring an LLM into a retrieval pipeline and discovering the retrieval is the hard part. They are cleaning data that arrived in nine inconsistent formats. They are writing an evaluation set because "it looks good in the demo" is not a release criterion. They are arguing with a token budget, chasing a hallucination back to a bad chunking strategy, and instrumenting the whole thing so they can tell tomorrow whether today's prompt change helped or quietly broke something.
Look at that list. It is data engineering, backend engineering, testing discipline, and observability — the exact skills a strong senior engineer already has, pointed at a model whose output is probabilistic instead of deterministic. The frameworks in play — orchestration libraries, a vector database, an evaluation and tracing layer — are new names for problems engineers have solved for twenty years: move data, call a dependency, handle failure, measure the result. The novelty is real but narrow. It does not justify treating the whole role as alien.
The model-training fantasy, and the rare case where it's real
There is a version of this work that genuinely needs a researcher: you are training a foundation model, fine-tuning at scale where a wrong hyperparameter burns five figures of compute, building a novel architecture, or doing real applied ML where the model itself is the product — fraud scoring, recommendation, computer vision on your own labeled data. Those teams exist and they are worth their seven-figure packages. If that is you, you know it, and you are not reading a job posting that confuses the two roles.
Almost nobody else is in that situation. The honest reason "build our own model" keeps showing up in plans is that it sounds defensible to a board, not because it is the right engineering call. The 2025 wave of enterprise GenAI post-mortems — the widely cited finding that the large majority of corporate generative-AI pilots delivered no measurable bottom-line impact — was not a story about insufficient model brilliance. It was a story about integration, data, and evaluation: engineering problems, dressed up and then under-resourced because the company hired for the wrong job and left the actual work unstaffed.
The scarce skill isn't model math. It's discipline against non-determinism.
Here is the part the credential-hunting job posting misses entirely. The genuinely hard, genuinely scarce skill in AI product work is not understanding how a transformer computes. It is engineering reliable behavior out of a component that gives you a different answer to the same question twice. Determinism is the floor every other piece of software stands on, and AI takes it away. Everything downstream — your tests, your error handling, your definition of "correct" — has to be rebuilt for a system that is right most of the time and confidently wrong some of the time.
That is a senior engineer's instinct, not a researcher's. It is the person who asks how this fails before asking how it demos, who writes the eval before the feature, who assumes the model will regress and builds the harness to catch it. A PhD who has never carried a pager will not necessarily have that reflex. A ten-year backend engineer who has been burned enough times absolutely will. When you hire AI/ML developers, that reflex is the thing to interview for — not whether they can derive backpropagation on a whiteboard.
How we actually staff this
At EltexSoft — a boutique studio of 35-plus senior engineers, every one with at least five years of production experience — our AI/ML practice grew out of the engineering team, not beside it. Over the past couple of years building production AI pipelines, the people doing the work are full-stack and backend engineers who learned the AI layer, plus a focused Python/AI-ML group. We treat AI coding tools the same way: Claude Code and Cursor are reviewed accelerators, not crutches, and every pull request — model-touching or not — is read by at least one other senior engineer before it merges. The model being non-deterministic is exactly why the human review bar goes up, not down.
One concrete example of where this lands: we built a generative-AI application for an entertainment client that reads screenplays and generates visual scene compositions, compressing work that used to take a sketchbook artist months into a process that runs in minutes. The hard parts of that build were not novel model research. They were document processing, retrieval, prompt and output discipline, evaluation, and the plumbing to make it fast and affordable enough to use. That is engineering work, done by engineers — which is the whole point. And it is why, when we evaluate vendors or models, we validate the capability against the actual problem, never the version string on a spec sheet.
If you're evaluating the space broadly, what AI consulting really is maps it. Our AI engineering services show what production AI work looks like when engineers run it.
So who should you actually hire
Commit to this and the strategy gets simpler and cheaper. First, look at the strong senior engineers you already employ and give them the AI stack — most of them can pick up retrieval, orchestration, and evaluation faster than the market can find you a unicorn, because the foundation transfers directly. Second, when you do hire externally, hire for production engineering judgment first and AI exposure second; "has shipped reliable systems and understands how LLMs fail" beats "has read every paper" for the work in front of you. Third, reserve the genuine ML researcher — the seven-figure hire — for the genuine research problem, and be ruthlessly honest about whether you have one.
The phrase "hire AI/ML developers" smuggles in an assumption that AI work is a separate priesthood you must recruit into from outside. For the small slice of companies training their own models, fine. For everyone else, it is engineering with a probabilistic dependency, and the person who can do it well is the senior engineer who treats the model as a component to be tested, budgeted, and distrusted — not a miracle to be worshipped. Hire the person who ships. The ones still impressed by the demo are not it.