An AI-native professional is not an AI specialist.
It is someone whose working method has been rebuilt because AI is now part of their normal environment — and who still owns every decision. A Java developer can be AI-native. So can a security architect, a platform engineer or a product manager.
People who build AI systems. ML and AI engineers, LLM engineers, MLOps, applied AI, data scientists.
A specialisation. We recruit it, on the AI & data practice.
People whose own work has changed. Any technical discipline, any seniority — the change is in the method, not the job title.
A criterion. It applies to every search we run.
The distinction matters commercially. If you only hire AI specialists, you get a small team that understands models and a large team that works as it did in 2022. The compounding advantage sits with the people who have changed how the everyday work happens.
What changed in an ordinary week
Writes the interface contract and a failing test before anything else, because that is what makes delegation safe. Implementation is drafted by an agent, reviewed line by line, and a whole manual integration step has disappeared.
The signal is not the agent. It is that the order of the work changed.
Reviews far more documentation and vendor material than before, with a strict rule about what never leaves the environment. Findings are drafted fast, then verified by hand — because a confident wrong conclusion in security is expensive.
Scope went up. Scepticism went up with it.
Automated the request queue nobody asked them to automate. Infrastructure changes are generated against a policy check, and nothing reaches production without a plan they have read themselves.
Leverage that other people in the team now depend on.
Not “can you explain every line”. No senior engineer reads every line their team writes either. The question is whether you would know if it were wrong — and whether you own it when it is.
- Not reading volume. The strongest people we meet have stopped reviewing character by character and started designing checks: tests, types, evaluations, policy gates, staged rollout, observability.
- Not tool collecting. A long list of subscriptions is not a method.
- Not a seniority proxy. It is not about years. It is about whether someone can tell good output from bad in their own domain — and some of the best at that are three years in.
- Not optional accountability. Someone still signs their name to what ships. That part has not changed, and probably will not.
- Scope: individuals take on work that used to need a second person or an external party.
- Quality: verification designed into the process tends to raise the floor, not just the speed.
- Composition: a team of six who work this way needs a different shape than a team of ten who do not.
- Retention: these people leave organisations that stop them working the way they now work.
We are not in the business of being suspicious of AI.
A lot of hiring advice right now is really just discomfort dressed up as rigour: if a person did not type it, it does not count. That position is already losing, and in two years it will look ridiculous. Nobody will be reading thousands of generated lines, any more than a staff engineer reads every line of their team’s work today.
What replaces line-reading is not trust. It is engineering: checks that fail loudly, evaluations, small reversible releases, observability, and a person whose name is on the outcome. That is more rigour, not less — and it is what lets one capable person now carry work that used to need three.
- “Can you explain every line?”
- Output volume treated as a red flag
- AI use as evidence of weakness
- Years of experience as the proxy for judgement
- “How would you know if this were wrong?”
- What have you built that catches it for you
- What got bigger because of how you work
- What happens when it breaks at 2am