.png)
We keep having the same conversation with hiring managers. They tell us they need someone for AI. Not a machine learning engineer, not an MLOps specialist, not a data scientist who happens to work with large language models. Just "someone for AI." And when we push a little further and ask what that person will actually own in ninety days, the answer gets vague fast.
That vagueness is not a small thing. It is the single biggest reason AI hiring cycles drag on so much longer than they should.
Most technical hiring works backwards from a known gap. A team loses a backend engineer, they hire a backend engineer. The scope is understood because the team already knows what the last person did all day. AI hiring rarely works that way, because in a lot of organizations, nobody has done the job yet. There is no incumbent to point to. So the job description gets written from a wish list instead of a role.
We think this is why so many AI postings read like a merger of three unrelated jobs. A little bit of data engineering, a little bit of applied research, a little bit of product strategy, and an expectation that this one person will also explain the technology to the board. That is not a job. That is an org chart's worth of responsibility poured into a single req.
Here is the part we think gets missed. When a posting is vague about scope, it does not attract flexible, well rounded candidates. It attracts two very different groups, and neither is usually who the team actually needs.
The first group is candidates who are themselves generalists, comfortable dabbling but without deep expertise in any one part of the stack. They will apply confidently because the posting is broad enough that almost anyone could argue they fit. The second group is strong specialists who read the vague scope as a warning sign. They assume, often correctly, that the role has not been thought through, and they pass rather than risk landing in a job that keeps shifting under them.
So the net effect of an unclear AI posting is adverse selection. The candidates most likely to apply are the ones least likely to be the right fit, and the ones who could actually do the work self select out before a recruiter ever sees the resume.
We would argue that "AI person" is now as meaningless a phrase as "computer person" was decades ago. Building a recommendation model, fine tuning a language model for a narrow domain, standing up the infrastructure to serve models at scale, and evaluating a vendor's AI product are four different disciplines. They share a vocabulary, not a skill set.
Some hiring teams know this and hire precisely anyway. Others treat it as a distinction without a difference, on the theory that a smart enough hire will figure out whichever piece is missing. Maybe that is true in a small startup where one person really does wear every hat. It is much less true anywhere with existing infrastructure, existing stakeholders, and an existing definition of what "done" looks like. In those environments, the wrong kind of AI specialist does not fail because they are not smart. They fail because they were hired to solve a problem that was never precisely stated.
Before a single interview is scheduled, we push clients to answer a short list of questions. What will this person be accountable for on day ninety, not day one. Which existing systems or teams will they need to work through, and who currently owns those systems. Is the work closer to research, where the deliverable is a model that performs well, or closer to engineering, where the deliverable is a system that runs reliably in production. And critically, has anyone internally done a version of this work already, even informally, who can weigh in on what the role should look like.
Teams that can answer these questions before writing the posting move faster, not slower. The interview process gets sharper because everyone is evaluating against a real scope instead of a wish list. The offer gets easier to make because there is no lingering doubt about whether the candidate can actually do the job as described, because the job was described accurately in the first place.
We are not arguing that generalist hires never work. Early stage teams sometimes need exactly that kind of flexibility, and a broad AI hire who can move between tasks can be genuinely valuable there. Our disagreement is with using generalist language as a shortcut for a role nobody has scoped yet, in organizations where the work is specific enough that vagueness just becomes a hidden cost paid later, usually in the form of having to hire the role all over again.
The real question worth debating is not whether AI roles should be broad or narrow. It is whether hiring teams are willing to do the harder work of defining the role before they go looking for the person to fill it.
