“AI developer” is four different jobs. Which one do you need?
Most briefs that ask for an AI developer want an applied AI engineer. Some want an ML engineer. A few want a data scientist and have not realised it yet. Getting this wrong is the most expensive hiring mistake in the category.
The brief usually describes the wrong role.
“We need an AI developer to build a chatbot over our documentation” is an applied AI engineering brief. It needs retrieval, evaluation, prompt discipline and guardrails. It does not need anyone who can train a model, and hiring someone who can will cost more and deliver slower.
“Our forecasts are wrong and we do not know why” is a data science brief. Somebody has to establish what is being predicted, whether the historical data supports predicting it, and what accuracy would even count as good. Handing that to an engineer produces a well-built system answering the wrong question.
“The model works in the notebook and falls over in production” is an ML engineering brief. Serving, feature pipelines, monitoring and drift. This is the role most often missing from teams that have already done the science.
We ask which of these you need in the first conversation, and we will say so if your brief and your problem do not match. That is not a sales tactic, it is the difference between an engagement that works and one that quietly stalls at month three with everyone being polite about it.
What we ask an AI engineer, and what we ignore.
Every candidate can describe a transformer. Almost none of that predicts whether they can ship something that behaves under real traffic.
How do you evaluate this?
The single most discriminating question in the category. Engineers who have shipped AI have an evaluation story, a set, a metric, a regression process. Engineers who have only demoed it talk about prompts.
What does it do when it does not know?
We are looking for refusal and escalation as designed behaviour rather than as an afterthought. Anyone who has been on call for an AI feature answers this immediately.
Where does the data come from at inference time?
Retrieval design, freshness, permissions. A candidate who has not thought about whether the model can see documents this user should not is not ready for an enterprise deployment.
What did you stop using a model for?
Strong applied engineers have removed a model somewhere and replaced it with rules or a query. Candidates who have never done this tend to reach for a model as the default tool.
How much did it cost to run?
Token and inference economics separate people who have operated a system from people who have built a prototype. It is also the constraint that most often reshapes an architecture.
Show us something that failed.
We ask for a project that did not work and what was learned. The answers distinguish experience from exposure faster than any technical question.
What your brief probably needs.
The left column is roughly how briefs arrive. The right is what we would staff, and it is frequently not what was asked for.
| What the brief says | What it needs | Why |
|---|---|---|
| Build a chatbot over our documents | Applied AI engineer | Retrieval and evaluation, no training involved |
| Automate this multi-step process | Applied AI engineer | Orchestration and tool use, plus a great deal of ordinary software |
| Our predictions are wrong | Data scientist | The question needs framing before anything gets built |
| The model will not scale | ML engineer | Serving, pipelines and monitoring, not modelling |
| Extract data from these documents | Applied AI engineer | Usually a solved pattern; the work is in verification |
| Train a model on our data | ML engineer, sometimes | Worth challenging, a retrieval approach is often cheaper and better |
| Build our own foundation model | Almost certainly not | We will tell you why before quoting |
Most AI briefs need a forward deployed engineer.
The term comes out of the AI world and it is the most accurate description of what this work actually requires: an engineer embedded in your context, accountable for whether the thing works in your hands, present for the last twenty per cent where the system meets real data and real users.
It matters here more than in ordinary software because the failure mode is different. Conventional software either works or throws an error. An AI feature fails by being plausible, and catching that needs somebody who knows your domain well enough to notice when an answer is confidently wrong.
- Embedded, not assigned. In your rituals and your repository from week one, learning the process the system is meant to support instead of a written description of it.
- Accountable for the outcome. Measured on whether it holds in production, not on whether the sprint closed.
- Owns the evaluation. The set, the metric and the regression process, so that a model update or a prompt change cannot quietly degrade the feature.
- There after go-live. Drift, cost, edge cases. An AI system with nobody watching it degrades silently, and the first person to notice is usually a customer.
- Leaves the capability behind. Your engineers work alongside from the start. If the honest answer is that you should be training your own team, we will say so.
Systems these engineers have put into production.
Each of these is a page you can read, with the architecture and the constraints described, not summarised.
Rates, notice and how we interview, on one page.
The commercial mechanics are the same whichever role you are hiring, so they live in one place, not being restated on every page.
Hiring AI engineers.
The three that come up before rates do.
Everyone claims AI experience now. How do we tell?
Ask for the evaluation story and watch what happens. Anyone who has run an AI feature in production has been forced to answer how they know it still works after a prompt change, a model version bump or a shift in the input distribution, so they will have a test set, a metric and a process, and they will describe them without prompting. Candidates whose experience is demos and side projects will move the conversation towards model capabilities and prompt technique, because that is the part they have done. It is not a trick question and it does not need a technical interviewer to score. We run it on every candidate before you see them, and we will tell you what they said.
Should we hire for AI or train the team we have?
For applied AI work, training your existing engineers is often the better answer and we will say so. The skills that matter most (retrieval design, evaluation, guardrails, cost control) are closer to ordinary software engineering than the discourse suggests, and your team already knows your domain, which is the part that cannot be hired quickly. What is worth bringing in is someone who has already made the mistakes, to work alongside them for a few months. That is a smaller and cheaper engagement than a permanent hire, and it leaves the capability inside your organisation rather than inside ours.
Can the same person do the data science and the engineering?
Sometimes, and you should be sceptical when someone says yes. The two roles reward opposite instincts: data science is about resisting a conclusion until the evidence supports it, engineering is about shipping something that works and iterating. People who are genuinely strong at both exist and are rare and expensive. On a small engagement we would rather give you one person who is strong at the half that matters most for your problem, and be explicit about which half that is, than present someone as both and let you find out which one they are.