Why AI engineers are hard to hire, and what helps
When an AI engineering search runs five months, the instinct is to fix the process. Usually the problem is the profile, and it calls for a different approach.
Read More
Two years ago, a manager with an open engineering position asked one question: how do we fill this? In 2026 there's a question before it: do we still need to?
That question deserves a straight answer. AI has taken over part of the work engineers used to do, and that work is unlikely to come back. Admitting it is the first step to a useful answer.
The line between the work AI took over and the work it left to people is rarely about junior versus senior, or simple versus complex. Here's where it actually falls, and how to tell which side your open role is on.
The work AI handles reliably has one thing in common: someone already decided what needed to happen, and the remaining task was to produce it.
That includes boilerplate, first drafts, translating between two well-defined formats, test scaffolding, the tedious middle of a well-scoped task, and documentation of code that already exists.
This change is real. Work that took three people two years ago now takes one, and that person is faster than the three were.
The work that resisted has a different shape: someone has to decide what needs to happen and be accountable if the decision is wrong.
That means deciding what to build, knowing which edge case will cost you a customer, understanding why a spec that seemed clear to everyone still shipped the wrong thing, and being the person who gets the 3 a.m. call and knows the whole system well enough to find the problem.
All of that depends on carrying context, which builds up in a person over months of making mistakes and learning why. An AI model can't get it from a prompt.
Take the job description and answer one question honestly:
Does this role receive decisions, or make them?
A role that receives decisions (implement this, migrate that, follow a pattern that already exists) is one where a smaller team with better tools can do the same work. That calls for better tools and processes, and hiring into it is expensive.
A role that makes decisions (chooses the approach, owns the consequences, is the person others ask) keeps its weight as tools improve. It often becomes more important: a team producing three times the output needs much better judgment about what to produce.
Most open roles are a mix. The useful exercise is to estimate the ratio, because it tells you whether you're hiring one person or three.
Here's the part that surprises people: the roles that remain got harder to fill.
Most companies ran this same analysis at about the same time, and most concluded they need fewer engineers who receive decisions and more who make them. Demand concentrated on a narrower group of profiles, while the supply of people in that group stayed about the same.
That's why teams that decided to hire less are finding it takes longer. They now compete for a specific kind of engineer, against every other company that reached the same conclusion.
If the position holds up after this exercise, the next question is how to fill it, and there are more options than the two most teams consider: direct hiring in your own market, setting up an entity where the talent is, an employer of record for someone you found yourself, or a partner who finds the engineer and also employs them.
Each option solves a different problem, and that difference matters more than the price.
We wrote about which one fits which situation. Start there before you compare rates.
Learn more about nearshore software development by reading the articles from our blog!
