"AI Engineer" Is a Fake Job Title

There's a pattern playing out in company after company right now. A business decides it needs AI, so it spends big to hire an "AI Engineer." Three months in, the project stalls. Leadership greenlights a new initiative, hires someone even more expensive — and stalls again.

It's tempting to blame HR, or the engineer. Both are wrong. The logic of the hire was broken from the root — and almost everyone is using it.

I've spent the last few years on both sides of this gap. I've rebuilt undocumented operational processes — cost control, settlement reconciliation — across departments for a multinational retail operation, and then wired AI into them. And I've designed and shipped AI products of my own. That combination is exactly why the gap is so visible to me: the thing most companies are hiring for is not the thing that makes AI work.

The bottleneck moved — and most companies didn't notice

For the last two years, "getting AI to work" was treated as a technical problem. So, instinctively, every company went hunting for engineers who "know AI." The highest-click résumé keywords became LangChain, RAG, vectorization, fine-tuning.

But something is happening fast: the capability of the models themselves — and the maturity of the tooling around them — is collapsing the barrier to "using AI" at an exponential rate. The RAG system that took an engineer two months to write last year takes a week with an off-the-shelf API today. The prompt-tuning that needed a specialist last year is increasingly handled by the model inferring intent on its own. The technical scarcity is evaporating.

When the scarcity of a core skill disappears, the bottleneck doesn't vanish — it moves. And the new bottleneck isn't "can you build it." It's where do you use it, how do you use it, and how does it connect to the actual workflow.

Most companies haven't registered the shift. They're using2024 thinking to hire 2026 people.

"AI Engineer" hides three completely different jobs

The phrase "AI Engineer" quietly covers three people with completely different skill profiles.

1. The floor-raiser. Makes it possible for non-coders to demo something, and for junior engineers to ship senior-looking code. Their leverage comes from the falling tool barrier itself. Most of the market's "prompt engineers" and "RAG engineers" sit here. They demo blindingly fast — and stall the moment they hit production data, permissions, approvals, and cross-department reality.

2. The ceiling-keeper. A genuinely senior software engineer using AI tools to do harder engineering — architecture, code review, performance tuning, multi-agent orchestration. Their output is still software, held to the same exacting standard as traditional engineering. Rare and valuable — but they don't solve the enterprise-adoption problem, because their job is to make the engineering better, not to fix the process.

3. The process-rebuilder. Digs out the implicit process that's run for fifteen years without anyone writing it down, coordinates across departments to change it, then uses AI to lock the changed process in place. This role has no market label yet.

These three are trained differently, produce different things, and should be hired against completely different criteria. But in the job description, they all collapse into one phrase: AI Engineer.

Here's where it breaks:

• Companies write the JD wanting #2 (someone who can do the hard technical work).
• HR's inbox fills with #1 (people who know a few tools).
• The only person who keeps the project alive is #3 (someone who understands the process).

The mismatch happens at three separate points. Project failure is nearly guaranteed.

What the job actually involves — and how little of it is code

When you map out what this new role actually does day-to-day, it comes to roughly eight things:

1. Design the new, AI-inclusive workflow.
2. Deploy the system that lets the AI run.
3. Continuously maintain the AI's context (every time a business rule changes, this changes with it).
4. Connect internal systems to the AI — CRM, ERP, HR.
5. Build evaluations to check whether the AI is doing the job correctly.
6. Decide which steps must keep a human in the loop.
7. Manage the migration when the AI tooling upgrades.
8. Partner with business-process change management.

Count them. The items that require writing code are #2 and #4 — and maybe half of #5. The remaining five-plus are process design, process change, cross-department coordination, human-machine workflow design, and change management.

That is a consultant's job wearing an engineer's title.

My read: the essence of this role is "the engineer who leans consultant," or "the consultant who leans engineer." Neither pure form can do it. And that's exactly why the big-company AI engineer a client poaches at great expense demos beautifully and then stalls at deployment. It isn't that they lack ability — it's that the back six items were never in their training.

The part you can't hire: organizational capital

Suppose you actually find someone with all three — engineering, business-process fluency, and cross-department coordination. On their first day, they still can't do anything.

Because a large part of what this role needs isn't knowledge. It's organizational capital.

Organizational capital is knowing which veteran actually understands the procurement process; knowing which leaders you clear before you touch a given workflow; knowing which business unit gets along with IT and which two haven't spoken in years; knowing whether a process is written into policy or is a verbal handshake from a decade ago.

None of this is on the wiki. It lives in the company's relationship network, in the informal conversations that happen every day. My rough estimate, from doing this work: in a mid-size company, at most 20% of the process knowledge that actually makes AI work is documented. The other 80% is in employees' heads.

And organizational capital is firm-specific. Five years of it at Company A resets to zero at Company B. This is the opposite of software-engineering skill — a Java engineer who switches jobs keeps 95% of their ability.

My estimate is that something like 70% of the capability mix enterprise AI adoption requires is organizational capital. Which means "hire externally" fails as a strategy at the level of basic logic.

The change-management piece is even more brutal. Getting a five-year-old process changed means asking a business unit to absorb a short-term efficiency hit and a KPI risk. Driving that requires internal credit — years in the building, favors given and owed, relationships with the key players. You cannot hire that.

This is a structurally underrated fact: roughly 70% of an enterprise's AI-adoption capability is non-portable and non-purchasable.

The companies getting it right retrain instead of hire

The companies I've seen actually make AI work aren't hiring new people. They're retraining existing ones.

The clearest public example is Box. Its CEO, Aaron Levie, has been blunt that the AI wave is driving hiring, not cuts — and the role he's staffing has a name that isn't "AI engineer": agent engineer. These are internal people who wire AI agents into the systems the company already runs (Box, Salesforce, Workday). A large part of staffing them is pulling in employees who already know those systems — not importing a team from outside.

Another telling signal: Eli Lilly — one of the largest pharmaceutical companies in the world — is hiring a Lab Automation Software Engineer (Senior and Advisor levels, roughly $141K–$207K) at its San Diego biotech center. There isn't a single "AI" in the title. But read the JD — "own the software integration layer between automation infrastructure and the digital tools that drive it, and shape how emerging AI capabilities get woven in" — and it maps almost exactly onto the eight tasks above. AI is the tool woven in, not the adjective on the door.

Why not call it an "AI Engineer"? Because the company knows it doesn't want "an engineer who can use AI" — it wants "an engineer who can rebuild the lab's processes." AI is the tool in that role, not the adjective.

The title a company chooses reveals how deeply it understands its own problem. A role called "AI Engineer" usually means the company hasn't figured out what problem it's solving — it grabbed a fashionable label and stuck it on. A role called "Lab Automation Software Engineer" means the company already knows what it's doing.

That person is probably already inside your company

If the core of this role is organizational capital + process understanding + hands-on ability, then the supply can only come from inside.

The profile looks roughly like this:

• Has been at the company 3–5 years, and has run at least one cross-department project (proof they can get resources and move people).
• Knows how a specific business process actually runs — where it jams, where it's redundant, which veteran is the key node.
• Is hands-on. Not necessarily a coder — building complex Excel models, writing some SQL, assembling something in Airtable all count.
• Has been tinkering with AI on their own for the last six months — using it unprompted, paying for ChatGPT or Claude out of pocket, building little tools.
• Has enough internal credit that veterans will explain things to them and a business lead will lend them two hours.

Every mid-size company has at least 3–5 of these people. When I do this exercise, the list almost never exceeds five. But they're mostly stuck doing execution-layer work, not core work. Their potential is bottled up.

What they need isn't training on how to tune a large model — the models iterate every three months, so any tech stack you teach is obsolete by the time they've learned it. What they need to learn is how to decompose a process into AI-executable steps, how to design evaluations, and how to decide where a human stays in the loop. That's methodology, not tech stack. It doesn't expire when the model upgrades.

What you give them is time, access, and permission to stop doing their old job.

The real shift: from "configure tools" to "redesign processes"

Connect the layers and the real meaning of this moment emerges. It isn't that "AI Engineer" is the wrong role. It's that the entire paradigm of enterprise AI adoption is shifting — from configuring tools to redesigning processes.

The "configure tools" paradigm: give every employee an AI assistant, shave a little off everyone's workload. One person + one AI = a productivity bump. But the process itself doesn't move — five approval steps are still five, three days is still three.

The "redesign processes" paradigm: go back to the start of the process and re-examine why it looks the way it does — which steps are essential, which are historical residue, which can run in parallel, which can be compressed, which AI can replace, and which must keep a human.

The output of these two differs by more than 10x. But redesigning processes is an order of magnitude harder than configuring tools.

Most companies are still in the "configure tools" paradigm, hiring "configure tools" people — which is why the JDs say LangChain, RAG, vectorization. Those are tool-layer skills. The few companies that have realized they need to shift to "redesign processes" hire completely different people: the ones who can do this inside the organization, not the ones with the trendiest tech stack.

What makes this shift genuinely hard is that it isn't a technical problem — it's an organizational one. Technical problems can be solved by buying. Organizational problems can't.

The bottom line

The talent market is a lagging indicator. Every "AI Engineer" with a name and a definition on the market today was defined by someone one or two years ago. By the time these people are plentiful, the tech stack that defined them is probably already obsolete.

Worse: the market will never produce a standard profile for the "enterprise-process-rebuilding AI engineer," because the role's core capability is welded to a specific company and a specific industry. Someone doing lab automation at a pharma company isn't necessarily useful at a bank. Someone redesigning supply chains in retail isn't necessarily useful at a law firm.

The supply for this role can only come from inside. That's both good news and hard news. Good, because it's a capability your company can grow internally and no competitor can poach. Hard, because there's no ready-made talent market to copy from — you have to identify and develop these people yourself.

So before your next meeting about "how many AI Engineers should we hire," do one thing first: open your directory. Look at the handful of people who've been there three-plus years, who've been quietly tinkering with AI lately, who've run a cross-department project. No more than five.

That person is almost certainly already in there.

The only question left is whether you'll give them the time, the resources, and a chance to stop doing their old job.

Sources: Box's hiring and "agent engineer" comments — Fortune and reporting on Aaron Levie, May 2026. Eli Lilly "Lab Automation Software Engineer" — careers.lilly.com (San Diego biotech center).