How to hire an AI engineer, and what it costs

"AI engineer" is a job title covering at least three different jobs, and the expensive mistake is not paying too much — it is hiring an excellent person from the wrong one of the three.

This matters more than usual because the field is new enough that titles have not settled, and because a candidate who can talk fluently about models is not necessarily someone who has shipped one into production where it had to keep working.

The three jobs behind the title

For most companies the answer is the middle row, and most job adverts describe the top row. That mismatch is why so many AI hires are a disappointment on both sides: you interviewed for research skills and then gave the person an integration job.

Be honest about which you need before writing the advert. If nobody on your team can say whether you need a model trained or a model called, that is the question to resolve first — and it is cheaper to resolve with a short consultation than with a salary.

What the role costs

Rates move quickly enough that quoting a figure here would be wrong within months. Check live data instead: Levels.fyi and the Stack Overflow Developer Survey both publish current compensation by role and region, and both are more reliable than a range in a blog post.

Three things are consistently true whatever the current numbers are:

• AI engineers command a premium over equivalent backend engineers, and the premium is larger the more research-adjacent the role.
• Salary is roughly two-thirds of the real cost once employer taxes, equipment, software and recruitment are counted.
• The scarcity is in production experience, not in model knowledge. Plenty of candidates have built impressive demos. Far fewer have run something where wrong answers reached a customer.

How to tell a builder from an enthusiast in one interview

Ask about failure, not about capability. Anyone can describe what a model can do; only someone who has shipped can tell you what went wrong.

1. "Tell me about an AI feature you shipped that did not work at first. What was wrong?" The useful answers are about retrieval quality, chunking or evaluation. An answer purely about prompt wording suggests demo experience rather than production experience.
2. "How did you know it had got better?" Listen for an evaluation set built before shipping. "It felt better" is the single most common gap, and it is the one that makes quality unmanageable later.
3. "What would you do if a document in the corpus contained instructions aimed at the model?" This is prompt injection. A candidate who has not thought about it will design something you cannot safely give tools to.
4. "How did you control the cost?" Caching, per-account caps, choosing a smaller model. Inference is a variable cost that scales with usage, and someone who has never watched that bill will not design against it.
5. "When did you decide not to use a model?" The strongest signal available. Engineers who reach for a model for classification or routing problems are expensive in ways that show up later.

When not to hire one at all

Three situations where a hire is the wrong instrument:

• The work is one feature. A single AI feature is weeks of work, not a permanent role. Hiring a person for it means you own a salary after the work is done.
• Nobody can define what good looks like. An AI engineer cannot tell you what your product should do. If the requirement is "add AI", you will pay a senior salary for someone to discover you did not have a use case.
• Your data is not ready. If answers must come from documents nobody has organised, the first six months is data work. Hire for that instead, or fix it before hiring.

Adding AI to an existing SaaS covers picking the job worth giving a model, which is the question that decides whether you need anyone at all.

Hiring versus contracting, for this role specifically

The general trade-offs are in agency, freelancer or in-house, but AI work has one wrinkle worth knowing: the first build teaches you most of what you needed to know about the role.

Companies that contract the first AI feature and then hire write much better job descriptions afterwards, because they have discovered whether their problem is retrieval, data, evaluation or something that was never an AI problem. Hiring first means writing a job description against a guess.

What we do

We do AI and LLM integration and RAG systems as scoped engagements, which is frequently the cheaper way to find out what you actually need before committing to a salary.

If you would rather compare firms first, the best AI software development companies explains the four different businesses that share the label and which one you probably need.

On the first call we will say if your problem is a data problem, a scoping problem or not an AI problem — all three are common, and all three are worth hearing before you start recruiting.

Frequently asked questions

References

1. Levels.fyi — Levels.fyi
2. Developer Survey — Stack Overflow