How to hire for AI-native skills

Every growing company in 2026 wants to build AI-native and there's various ways to define it. IBM focuses on genAI, and HBS is telling us how to architect AI native businesses. But how do you hire for these new businesses or transformations of legacy systems? Do you hire a 20 year old that grew up with the phone, Google, and ChatGPT, or a 20-year old veteran that understands strategy and has spent a lot of time doing data analysis manually; a proficiency that's clearly not required anymore.

The AI-native capability is genuinely new, new enough that it doesn't map cleanly onto a traditional resume. So "AI-native" gets used as a vibe, and hiring for a vibe is how you end up with a team that can talk about agents but have never delivered product grade AI products.

It helps to remember where the phrase came from, and how recent that is. "AI-first" was Google's 2016 framing: AI added on top of the products a company already made. "AI-native" is what that turned into after ChatGPT arrived in November 2022 and simply using AI stopped being a differentiator.

That's the whole problem with it as a hiring bar: "AI-native" is more than just using ChatGPT and Gemini. It's a mindset, a way of thinking about building where you ask the question: how can AI do this for me? It's also an attitude of experimentation, automation and systems-thinking.

When I'm building a team to build AI-native products that are production-ready, I look for fundamental skills: data understanding, machine learning models understanding, cloud-native, workflow automation, output evaluation, and curiosity to build with new tools.

1. Can they work with data?

This is the unglamorous foundation, and it's the one many young people don't have experience with. I want evidence that someone has lived in the messy part: scraping or sourcing data, doing the analysis, and questioning the quality of it. Do they check whether the data is what it claims to be? Have they cleaned a dataset before? Do they have real database experience? Can they write a SQL query?

One clarification I have to make: It's not an absolute must. I've met smart people that have used AI to prototype decent products. It's one piece of evidence out of many.

2. Do they understand machine learning modeling?

A lot of people moving into agent-building arrive from classical machine learning. That background is valuable, especially tools like Python, pandas, and PyTorch. This is the discipline of taking a dataset (public or your own), choosing a model or algorithm, and building it out to predict some X. If your product needs a prediction model, that experience is gold.

I'm screening for judgment as much as skill here. The classical-ML instinct is to reach for a trained model; the AI-native instinct is to know when a model is an overkill and an API call plus good context engineering does the job faster and cheaper. The strongest candidates understand both. They can build the model when it's warranted, and they can also tell you when simple statistics is sufficient.

3. Are they cloud-native?

There's still a live debate about whether you should be running your own models locally or leaning on hosted, cloud-based ones. I don't need a candidate to have settled that debate. I need them to know it exists and to understand both sides. Someone who can walk me through the trade-offs: cost, latency, privacy, control, the operational tax of self-hosting. Ideally, they have enough hands-on time with AWS, GCP, or Azure, so I can trust them to make that call in the context of my organisation.

4. Have they actually automated a workflow?

This is the one where the market is fuzziest, because "I built an agent" now can mean so many things. Everyone says it. ChatGPT will happily set up a scheduled task for you these days, and people call that an agent. What an engineer will tell you is that it's a beginner's script on a timer. It's a good start.

What I'm looking for is workflow-automation experience: the ability to compose systems of agents, or a harness as it's sometimes referred to now. Agent one hands an output to agent two, which hands its output to agent three, etc. and somewhere in that chain there's a loop, where an agent looks back at what the others did, learns from it, and makes a different decision the next time. That's the difference between a person who can run a scheduled task and a person who can design an autonomous pipeline that improves itself.

The reason this matters for an AI-native product portfolio is that the products worth building are self-learning. The single-prompt automations are already commoditized. The next challenge is in agentic orchestration, and orchestration is a skill you can only demonstrate by having done it. And that, not many people have experience with yet, as we're leaning into agentic architectures.

5. Can they measure whether it works?

Ask a candidate how they know their AI system is any good. The basic answer is that they ran it a few times and the output looked right. That's a good start, but it's not an evaluation. You need a framework in place to catch when the model changes, or a real edge case shows up in production. I've watched teams spend months trying to understand why a model behaves a certain way, and not be able to predict outcome consistently.

What I screen for is someone who builds the measurement in from the start: an evaluation set with known-good answers, metrics that map to what the product needs, and a way to catch a regression before a user does. Sometimes that's a golden dataset and an accuracy number; sometimes it's an LLM-as-judge rubric for outputs that have no single right answer; sometimes it's a live metric watching real usage. The specific method matters less than the instinct, which is to treat "is this working?" as a question you answer with data. Classical ML made that instinct second nature. A lot of people arriving from prompt-first tooling never had to learn it, and it shows the first time their agent quietly underperforms.

6. Are they curious enough to build on their own?

The first five are hard skills, this one is an attitude. The tools turn over every few months now. Someone who was AI-native in 2024 is average by 2026 unless they kept trying new things. So I look for evidence that a person experiments without being told to: a side project they published over a weekend, a model they tried the week it came out, a tool they picked up just to see what it could do.

I don't need the prototypes to be polished, or even to work. I'm looking for the reflex. Someone who builds to learn will teach themselves whatever the next tool is; someone who waits for a training course will always be a release behind. When a candidate can walk me through something they made just to find out if they could, that tells me more than any line on their resume, because it's the one thing that doesn't go out of date.

If I compress the six into one filter: I'm not hiring people who can use AI tools. Those are everywhere now. I'm hiring people who can reason about data, models, infrastructure, orchestration, and evaluation well enough to build the tools other people will use, and who stay curious enough to keep building as those tools change. That capability doesn't easily announce itself on a resume, which is exactly why the companies that learn to screen for it directly are going to out-hire the ones still waiting for the perfect CV to show up.