Hiring your first AI engineer: don't hire a researcher

A founder I know spent four months and a six-figure salary on an AI hire. The hire had the right credentials. Strong ML background. Published work. Could explain transformers at a whiteboard better than anyone in the room. Nice person, too.

Four months in, there was no shipped system. There was a document explaining the theoretical approach. There was a benchmark of three open-source models on a custom dataset. There was a Jupyter notebook that ran, once, on the hire's laptop. There was no thing that a customer could use. There was no pipeline in production. There was no dashboard. There was no code in the main repository, because the hire had "not decided on the right architecture yet."

The founder did not hire a bad person. The founder hired a good person for the wrong job. They hired a researcher, and they needed a shipper. Those are different humans, and in 2026 the difference is the whole ball game. Every founder I talk to keeps making this mistake, and I want to save you from making it.

Here is the claim, stated flatly: the person you need for your first AI hire in 2026 is not the person with the best understanding of how the models work. It is the person with the best track record of getting a working system in front of a paying customer in under a month. Those are almost never the same person. They are hired off different resumes, interviewed with different questions, and paid with different incentive structures. If you conflate them, you will spend six months and half your runway on a really well-reasoned document.

A researcher is someone whose job, for most of their career, has been to understand and improve models. They read papers. They run benchmarks. They have opinions about architectures. They care about the difference between a 0.87 and a 0.89 on a metric you have never heard of. This is a real skill and it is useful to real companies and I am not dismissing it. But the job they have optimized for is not your job. Their job is to make a model better. Your job is to make a customer's problem go away.

A shipper is someone whose job has been to take a working-ish model, wire it to a real-world system, handle the ten thousand edge cases that separate a demo from a product, and deploy it where customers can touch it. They do not have opinions about attention mechanisms. They have opinions about retries and state and auth and observability. They have shipped something. You can ask them "what is the last AI system you built that is currently running in production serving real users" and they will have an answer, with a URL, and they will remember the bugs and how they fixed them.

In 2026, models are good enough that the first hire should almost always be a shipper. The frontier models do most of what you need out of the box. The delta between "the best possible model for your use case" and "Claude or GPT with a decent prompt" is usually smaller than the delta between "the agent runs in production" and "the agent runs in a notebook." You do not need someone to squeeze 3% more accuracy out of a model. You need someone to squeeze 100% more reliability out of a pipeline. The model is no longer the bottleneck. The system around the model is.

There is one exception. If your entire business is predicated on a model capability that the frontier labs do not offer, a specific domain, a specific language, a regulated setting where you cannot send data to an API, you need a researcher, because you are going to be training or fine-tuning your own model and that is a different job. If this is you, you probably already know it. If you are not sure whether it is you, it is not you. Hire a shipper.

Ask for a URL. Not a portfolio. Not a GitHub. A URL. Something currently running, serving real users, that they built or meaningfully contributed to. If they cannot give you one, they have not shipped. I do not care how many papers they have published. Papers are not shipping. Notebooks are not shipping. Internal demos are not shipping. A URL is shipping.

Ask them to describe a bug they fixed in production. Not a theoretical failure mode. A specific bug. What the symptom was, how they found it, what the fix was, how long it took. Shippers light up on this question. Researchers sometimes get uncomfortable, because their role has not put them in the "3am on a Sunday" seat.

Ask them how they would instrument a system. If the answer is detailed and boring and involves the words "structured traces" and "per-run logging" and "assertion at the output layer," you have a shipper. If the answer is "we'd set up Weights and Biases and track loss curves," you have a researcher. Both are valid. Only one is what you need first.

Ask them what they would cut from the first version of your system. The right answer is always "more than you think." Shippers are ruthless about scope. They cut features that researchers would defend, because they know the features that do not exist cannot break. If your candidate cannot name three things they would cut, they are not thinking like a shipper yet.

Ask them to look at the system they would build as a business problem, not a technical one. A shipper can answer "who is this for, what is the minimum thing that would be useful to them, and how would you know if it was working" without touching the code. A researcher will want to get to the architecture. Neither is wrong as a person. Only one of them is going to ship you something in ninety days.

Then, and this is the part most founders skip: give them a take-home. Not a Leetcode puzzle. A real one.

"Here is a CSV of real-ish support tickets. Build something that categorizes them into these five buckets and reports its confidence. Ship it as a runnable thing, a URL, a CLI, anything I can actually use. Take as long as you need. Most candidates finish in a day."

Then see what they ship. Not what they planned. What they shipped.

The ones who ship something rough but working in a day are your shippers. The ones who send a three-page document about their approach and no code are researchers. The ones who send neither are not going to hit your deadlines. This is not a trick question. It is exactly the job. If they cannot do the job in a controlled exercise with a day of their time, they cannot do it when it is the real one with a month of yours.

One more thing. When you are a non-technical founder hiring your first AI person, you are vulnerable to being impressed by credentials you cannot evaluate. "Worked at DeepMind" sounds impressive. It is impressive. It is also not a signal that the person can ship your thing. The most productive AI engineers I know have weird resumes, self-taught, or switched in from adjacent fields, or came up through product instead of research. Credentials are a weak signal. Shipped work is a strong signal. Interview for the strong one.

If you are a researcher reading this and you feel called out, I am not saying you are a bad hire. I am saying you are a second hire, or a second-year hire, or a specialty hire for a specific kind of company. There are companies where you are exactly right. Most of the founders reading this blog are not at those companies. They need someone to build the thing and get it in front of a customer. That is a different job, and the hiring process for that job is not the one that finds you.

Hire for who you need now, not who you will need in two years.

And when you do finally hire them, the shipper, the one with the URL, give them an agent and a week and watch what happens. If they have not produced something running by the end of week one, they were lying on the interview. Good shippers produce something within days. The speed is not because they are rushing. The speed is because they have done this before and they know what to skip.

That is the whole job. Find someone who has done it before. Find someone who can show you the thing. Hire them.