How do you tell real AI experience from a resume keyword?

How do you tell real AI experience from a resume keyword?

You test an AI claim the same way you test any other claim on a call: by its shape. A candidate who worked on the real thing gives you a model name, a purpose, a failure, and a number. A candidate who used the tools like everyone else in 2026 gives you a list of nouns and stops. The specificity test that separates a decision from a description works here too, on a topic where the keyword now shows up on almost every resume.

Two lessons feed straight into this one. Building AI and using AI are different jobs drawn from pools of very different sizes, and an AI claim has to sort onto one side before anything else about it means much. RAG, agents, evals, and MCP are the actual parts a using-side engineer assembles, and the words a candidate reaches for tell you which parts they have touched. This lesson puts both to work on a live claim in front of you.

Which side of the line is the claim on?

The claim sits on the using side almost every time. Nearly every "GenAI experience" line on a resume in 2026 describes calling a rented model through an API and building a product around the answers. Training a model from scratch is the far rarer claim underneath the same words. The skills-wall lesson covers the same sort for a line buried in a list of fifteen technologies; here the candidate is describing it out loud, which gives you more to work with.

The sort still matters even when the answer is almost always the same, because the rare case is worth catching. A candidate describing training runs, datasets they built, or a model they shipped from scratch is on the building side, and that person belongs to a pool a few thousand deep worldwide. Everyone else is describing product work with a model in the middle, and the rest of this lesson is about telling a real version of that from a keyword.

What does a real using-side answer contain?

A real answer names which model, what it was built for, what it got wrong, and how the team knew whether it got better. Each part is checkable and each part is a specific memory when the work was real. Which model: GPT, Claude, Llama, or something smaller, because "AI" alone names nothing. What it was built for: a support assistant, a search feature, an internal tool, with a user on the other end. What it got wrong: every real AI feature has failure cases, and a person who built one can describe theirs without prompting.

The last part, how quality was measured, separates a shipped feature from a demo. A keyword answer stops after the model name. "We used GPT-4 for our chatbot" is true of thousands of features built in an afternoon and thousands more that ran for two years in front of paying customers, and nothing in the sentence tells you which one you are hearing about.

What does mentioning evals tell you?

It tells you the person worked on a system that had to stay reliable over time, past the point where a demo only has to work once. An eval is a repeatable test of an AI system's output, and a team only builds one after the first version ships and someone needs to know whether the next change made it better or worse. A model can answer well on Monday with no test behind it. Knowing it still answers well after fifty changes over six months needs a score, and evals are that score.

A candidate who can describe their evals, what got scored and how the number moved, has operated a feature past the point where most side projects stop. A candidate who describes a chatbot with no mention of how they checked it worked has probably not gone past that point, even if the description sounds fluent. The gap between the two is the same gap production ownership marks everywhere else on the call: a story with a measurement in it, against a story with none.

When is prompt engineering a real claim?

Prompt engineering is real when it comes attached to a shipped system and a measurement of what changed. Writing the instructions that go to a model, a prompt, gets harder as a product grows: instructions accumulate edge cases, results have to stay consistent across thousands of runs, and small wording changes move the eval score in ways nobody predicts from reading the prompt cold. That work is real engineering, and a candidate who can describe a specific fix, "we added an example that stopped the model dropping the currency symbol," is describing it.

On its own, with no product and no measurement behind it, the phrase describes exposure. Everyone who has used a chat tool at work has written a prompt. The phrase alone on a resume line, unattached to anything that shipped, carries close to the same information as "used a search engine."

What is Hugging Face?

Hugging Face is a site that hosts machine learning models and datasets publicly, along with the code that runs them. Teams and individuals upload a model they trained or fine-tuned, along with the data it learned from, and anyone can download it, read about it, and see how much it gets used. It functions for the AI community roughly the way GitHub functions for software generally: a public record of work rather than a private claim about it.

That makes Hugging Face activity checkable in the same way a GitHub profile is. A candidate who uploaded a fine-tuned model, wrote up how they built it, and can point you to the page has left evidence you can look at without reading a line of code. Empty or absent Hugging Face activity says nothing on its own, because most engineers doing real using-side work never need it. Present activity, on the other hand, is a strong tell for hands-on model work.

What does AI-native mean for the req?

AI-native means the product depends on a model rather than adding a feature that happens to use one. A search tool with an AI summary bolted onto results everyone already had is an existing product with a feature added. A tool where the model is the product, and nothing works without it, is the AI-native case. Engineers on an AI-native team spend real time on model behavior, cost per request, and evaluation, because those parts carry real weight in what they ship.

What about a candidate who says AI will replace them?

Read it as a statement of the candidate's own view of the tools. It says little on its own about their skill. Some engineers who say it are being candid about a real worry in the field. Some are being self-deprecating about a task the tools compressed. Neither reading tells you much about whether the specific work they describe, with the model, the purpose, the failure, and the measurement this lesson walked through, was real. Whether AI will replace software developers is a live and honest question in the industry, and a candidate's answer to it is one data point about how they think, sitting next to everything else the call already told you.