Finding AI Developers

Three roles wearing one label

Model builders. They train and fine-tune models, and their work is research-adjacent. You need this when your problem genuinely has no existing solution, which is rarer than most roadmaps assume.

Applied and integration engineers. They take existing models and build reliable products around them: prompt and retrieval design, evaluation, fallbacks, cost and latency management, and the unglamorous work of handling the cases where the model is wrong. Most commercial projects need this profile.

Data engineers. They build the pipelines both of the above depend on. Many stalled projects are data problems wearing a modelling costume, and this is the hire that unblocks them.

Writing a posting for the first when you need the second is the most common failure here. The candidates you attract will be qualified and wrong, and the ones you need will skip a posting that reads like a research role.

Evaluating without in-house expertise

If nobody on your team can judge the technical answers, stop trying to judge the technical answers. Judge the things you can assess.

Ask how they would know it was working. Strong candidates talk about evaluation early and unprompted: how they would measure quality, what they would do about the cases the system gets wrong, how they would catch a regression. Weak candidates talk about which model they would use.

Ask what they would do when it fails. Every system built on a model is wrong some of the time. Someone who has shipped one has opinions about fallbacks, human review and confidence thresholds. Someone who has only built demos usually does not.

Ask them to explain a past project to a non-specialist. This is not a soft-skills test. Explaining a technical decision in plain terms to somebody who cannot check you is most of the job on a contract engagement, and the ability to do it correlates with actually understanding the decision.

Ask about cost and latency. Production experience shows up here immediately, because both are constraints you only feel once something is live.

Use a paid trial

For work you cannot assess by reading, a short paid trial on a real problem of yours is the highest-information step available. A week, scoped tightly, paid at their normal rate.

What you learn is not only whether the output is good. You learn how they handle an ambiguous brief, whether they tell you when your framing is wrong, and how they report progress on something you cannot verify yourself. On a contract engagement those matter as much as the technical result.

Scope the trial as its own project with its own acceptance criteria. A trial that trails off without a verdict costs you the week and teaches you nothing.

Signals and false signals

Worth weight: shipped systems that stayed live and were maintained; the ability to name what did not work and why; a clear account of how quality was measured; evidence of working within cost and latency limits.

Worth less than it looks: familiarity with a long list of model names, which changes every few months; demos with no evaluation behind them; volume of published side projects, which measures enthusiasm rather than reliability.