When job titles stop describing the work, how do we match people with opportunities?
A company advertises for an AI Engineer.
One candidate has spent years training machine learning models. Another builds applications using foundation models. A third specializes in evaluation, monitoring, and production reliability.
All three could reasonably apply.
Yet depending on what the company actually needs, only one might be the right match.
The problem begins before the interview. The employer and the candidates may be using the same title to describe different kinds of work.
“AI Engineer” sounds specific. Until someone asks what that person will actually do on Monday morning.
Will they train a model? Build a retrieval system? Connect an agent to business software? Investigate unreliable outputs? Reduce inference costs? Decide when a system should ask a human for help?
A title can introduce a role. It cannot answer all those questions.
And when hiring systems treat the introduction as the specification, matching becomes guesswork.
The Research Behind the Confusion
In research announced on September 10, 2026, Andela analyzed 47,101 technical job postings from Fortune 500 companies and scored 2,026 distinct skills.
Among roughly 1,832 postings carrying titles such as AI Engineer and ML Engineer, 53% required skills drawn from at least two established roles. Andela also identified 23 recurring skill bundles that did not map to a standardized title, with one subsequently discarded for accuracy.
That finding deserves a careful reading.
It does not mean that 53% of all AI job advertisements are wrong, or that everyone using these titles misunderstands AI. It describes a particular sample interpreted through Andela’s proprietary skills taxonomy.
But it raises an important question: how much useful information does a job title preserve when the work crosses several professional boundaries?
The provocative title of this article is therefore a challenge, not a literal claim.
People understand many of the capabilities involved in AI engineering. What they cannot safely assume is that every employer bundles those capabilities in the same way.
A Job Title Is a Compressed Description
Titles compress information.
“Backend Engineer” suggests a broad family of responsibilities. “Data Scientist” suggests another. That compression helps people navigate an organization, compare opportunities, and describe their careers.
However, compression loses detail.
Two people with the same title may have very different levels of experience with deployment, security, experimentation, or customer-facing systems.
Two people with different titles may be capable of delivering the same outcome.
AI work makes that limitation especially visible because a single project can combine software engineering, data preparation, model behavior, evaluation, infrastructure, and business judgment.
Consider a hypothetical customer-support assistant.
Getting it into production might require someone to:
- Retrieve information from approved sources.
- Integrate with an existing support platform.
- Evaluate whether responses are accurate and useful.
- Prevent access to another customer’s information.
- Escalate uncertain cases to a human.
- Monitor latency, cost, and failures.
An employer could package these responsibilities into one role or distribute them across a team.
Either approach can work. But the title alone does not tell a candidate which arrangement they are joining.
The ambiguity is in the bundle of responsibilities behind the label.
Renaming the Role Only Solves Part of the Problem
More precise titles can help.
An employer distinguishing application engineering from model research gives candidates useful information. Clearer naming should be encouraged.
But creating a new title for every combination of responsibilities has limits.
A company might need application development, retrieval evaluation, and operational monitoring today. Six months later, its architecture and priorities could change.
The title may remain while the work shifts.
There is also no guarantee that two companies will interpret a newly coined title consistently.
A better approach keeps titles as useful navigation while making the underlying requirements explicit.
The hiring question becomes:
What must this person be able to accomplish, under which conditions, and with what evidence?
That question survives changes in terminology.
Match People to Outcomes First
Imagine two hypothetical job descriptions.
The first says:
We need an experienced AI Engineer with Python, LLM, and vector database experience.
The second says:
We need someone who can build a support assistant grounded in approved documents, evaluate answer quality, integrate it with our existing platform, and operate it within our privacy, latency, and cost requirements.
The second description still needs detail. But it gives everyone a clearer starting point.
An employer can derive capabilities from those outcomes. A candidate can explain relevant experience. An interviewer can design an assessment around the actual work.
This suggests a practical sequence:
Define the outcome. Identify the capabilities. Examine the evidence. Discuss the gaps.
A title can sit above that sequence. It should not replace it.
Knowing a Tool Is Different From Delivering a Result
Capability matching can fail if it becomes a longer keyword checklist.
A profile listing Python, a model API, and a vector database does not establish that its owner can build a dependable retrieval system.
Tool familiarity matters. But it answers a narrower question.
Can the person diagnose why relevant documents are missing? Recognize when an evaluation set is misleading? Explain a tradeoff between quality and response time? Identify a failure that requires human review?
Those are questions about applied judgment.
A useful capability statement connects an action to an outcome and its conditions:
Can evaluate a document-grounded assistant using representative questions, identify unsupported answers, and explain the limits of the evaluation.
That statement is more informative than knows RAG.
It also creates a clearer basis for discussing evidence.
Evidence Needs Context
A polished demonstration can show that something works in a selected situation. It does not automatically establish readiness for every production environment.
Likewise, a successful team project does not reveal what one individual contributed unless that contribution is explained.
Useful evidence therefore needs context:
- Contribution: What did the person personally design, implement, or decide?
- Conditions: What data, tools, support, and constraints were available?
- Evaluation: How was the result assessed?
- Limitations: What remained unresolved or outside the person’s responsibility?
Confidentiality matters too. Candidates should not have to disclose an employer’s private code or customer data to demonstrate competence.
Sanitized examples, structured walkthroughs, references, and appropriately scoped assessments can offer alternatives.
The aim is to make a hiring decision better informed, not to demand an unrestricted archive of someone’s working life.
The Right Match Includes the Gaps
A capability profile should make uncertainty visible.
Someone might demonstrate strong application engineering and evaluation skills while having limited experience operating a high-volume service.
That could be an excellent match for a team with established infrastructure support. It could be a poor match for a role requiring sole ownership of production operations.
The same candidate can be suitable in one context and unsuitable in another.
This is why a single match percentage can conceal too much.
A more useful result explains:
- Which essential capabilities have supporting evidence.
- Which capabilities are adjacent and need validation.
- Which gaps can realistically be addressed with training or team support.
- Which responsibilities require experience the candidate has not demonstrated.
Employers must also separate genuine requirements from preferences. Otherwise, capability matching simply reproduces the unrealistic job description in a more detailed format.
The objective is a justified match, with its assumptions visible.
Better Matching Should Work in Both Directions
Candidates also need to evaluate the opportunity.
A person hired to develop applications may discover that the employer expects model research. Someone hired to improve evaluation may find that no evaluation process exists and that immediate deployment is the only priority.
Clear capability requirements help expose these differences before a contract is signed.
They also make room for questions about ownership:
Who approves deployment? Who maintains the data? Who handles incidents? What support does the new hire receive?
Matching should establish whether a person can do the work and whether the organization provides a credible environment for doing it.
What This Means for Pexelle
For Pexelle, the opportunity is to make the relationship between people and work more legible.
A useful capability profile would help someone explain what they can do, the evidence behind that claim, and the conditions under which it holds.
A useful opportunity profile would explain the outcomes required, the capabilities that matter, and the responsibilities the person will own.
Connecting those profiles could make overlooked experience easier to recognize. It could also help employers distinguish a strong adjacent candidate from someone who already meets a critical requirement.
But this approach must avoid creating another rigid classification system.
Capabilities evolve. Evidence ages. Assessments have limits. People need ways to correct inaccurate descriptions and demonstrate growth.
Verification is most useful when it supports better questions and accountable judgment.
The Question Beyond the Title
We can keep debating what an AI Engineer should be called.
Clear terminology has value. But even a well-chosen title cannot carry the full specification of a changing job.
The more consequential questions are practical:
What needs to be done?
What capabilities does that require?
What evidence supports this person’s ability to do it?
And what remains uncertain?
When those answers are visible, a title becomes a helpful summary.
When they are missing, the title becomes a promise that nobody has properly defined.
The future of matching people with opportunities depends on making the work, the capability, and the evidence clear enough to judge.
Source : Medium.com
