The hottest engineering job of 2026 was invented in 2005 to work with the CIA.

Palantir built it two decades ago for customers no ordinary consultant could help. Intelligence agencies had enormous, messy problems and data no vendor understood from the outside. So Palantir did something unusual. It took strong engineers, dropped them inside the customer’s actual environment for months at a time, and had them turn a vague problem into working software while sitting next to the people who lived it.

They called the role the forward-deployed engineer. For years it stayed a Palantir thing, a quirk of selling software to the government. Then OpenAI and Anthropic rebuilt the role for the AI era in 2023. This year almost every serious enterprise AI company is hiring one, from the frontier labs to Salesforce, Databricks, and Scale AI.

The role came back for a reason. Understanding that reason tells you a lot about why your own AI effort might be stuck.

What the role actually is

A forward-deployed engineer sits with your team, learns how the work really happens, then builds the thing that fixes it.

That is the whole job. One person who understands your business and writes the software to match, in the same room as the people who own the problem.

It sounds obvious when you say it out loud. Most companies do not have that person. They have a data science team two floors away. They have a vendor on a quarterly call. They have a slide deck that describes the problem in language the engineers never quite trust. The work crosses a wall, and something gets lost every time it does.

The forward-deployed engineer removes the wall by moving to the other side of it.

Why AI projects really fail

Most AI projects do not fail because the model is weak.

The models are extraordinary. They can draft, summarize, classify, and reason at a level that would have looked like science fiction three years ago. When a company’s AI effort stalls, the model is almost never the reason.

They fail because no one translated a real business problem into something the technology could solve. The gap sits between the messy way work actually happens and the clean way a model expects to receive it. Someone has to stand in that gap and do the translation, again and again, as the real edge cases surface and the neat plan meets the ugly reality.

That is the gap the forward-deployed engineer closes. They close it by living in it. They see the exception the process document never mentioned. They watch the person who does the job find the workaround nobody documented. Then they build for the work as it is, not the work as the org chart imagines it.

You probably do not need a bigger model

If your AI effort keeps stalling, the instinct is to reach for more technology. A better model. A new platform. Another pilot.

The more useful move is usually the opposite. You probably do not need a bigger model. You need one person who understands both the work and the tools, sitting with the team that owns the problem.

You can hire that person. You can borrow them from a partner for a few months. You can grow them from inside by taking an engineer who already gets your business and giving them room to sit with a team and build. The title matters far less than the seat. What matters is that someone with real engineering judgment is close enough to the problem to feel it, and trusted enough to ship the fix.

What this means if you run a company

Look at your last AI project that went nowhere. Trace it back.

There is a decent chance the problem was never technical. The idea was sound and the tools were capable. What was missing was a person who sat with the business long enough to understand the actual problem and had the skill to build the actual answer. The effort died in the translation layer, in the handoffs between people who understood the work and people who understood the software.

The companies pulling ahead with AI put a capable builder inside the problem and keep them there. Model size is rarely what separates them from the ones still stuck in pilots.

If your AI effort keeps stalling, ask who on your team actually sits with the business and writes the code. If the answer is no one, you have found the hire you are missing.

Reply and tell me where your AI efforts have gotten stuck. I am seeing the same pattern on almost every engagement, and I want to know if it matches what you are living.

Subscribe now

Last month a marketing lead showed me a tool she built over a weekend. It pulled her campaign data, scored the leads, and emailed her team a summary every morning. She does not write code. She described what she wanted to an AI model, and it built the thing.

Her CEO asked me a fair question afterward. If she can do that, what is the engineering team for?

It is the right question. Most leaders answer it wrong.

What is happening

For twenty years, software had a gate. If you wanted a tool, you filed a request, waited in a queue, and the engineering team built it when they got to it. Engineers were the only people in the building who could turn an idea into working software.

That gate is gone. Your operations lead can automate a workflow. Your finance team can build a model that used to need a developer. Your marketer can ship her morning report. This is real, and it is good. Work that used to die in a backlog now gets done in an afternoon.

Most leaders see this and jump to one of two conclusions. Either the engineering team is now overhead, or everyone should be turned loose to build whatever they want. Both are wrong, and both are expensive.

The mess nobody planned for

Watch what happens when a whole company starts building software with no one owning the result.

The marketer’s tool holds customer data on a service no one vetted. The finance model has a logic error that no one will catch until it drives a bad decision. Ops automated a workflow that breaks the moment an upstream system changes, and the person who built it has moved to another team. Multiply that by fifty tools across the company. You have not gained speed. You have taken on debt you cannot see.

This is AI slop at the scale of a company. The software looks finished. It runs. It solves today’s problem. It also has no owner, no tests, no security review, and no plan for the day it breaks. Fast output is not the same as good software. It never was.

The new job

So the engineering team’s job changes. It stops being the only group that can build. It becomes the group that makes everyone else’s building safe, connected, and durable. That is a bigger job than the old one.

They build the paved road. The engineers create the sanctioned way to build: approved tools, a place to put data that is already secure, starting templates with the guardrails in place. A non-engineer building on that road gets speed without the landmines.

They own the hard part. Most software is easy now. The last twenty percent is not. The gnarly integration, the system that has to stay up at three in the morning, the data model the whole company depends on. That work still needs people who understand it deeply.

They decide what graduates. A prototype and a production system are different animals. Someone has to look at the marketer’s weekend tool and decide whether it stays a personal helper or becomes something the company depends on, with the ownership that choice demands. That judgment is engineering work.

They set the bar for quality. When anyone can generate code, the scarce skill is knowing whether the code is any good. Reviewing it, hardening it, and teaching the rest of the company what good looks like becomes a core function.

From builders to stewards

The value of an engineer used to sit in their hands, in the speed and correctness of their typing. AI took most of that and made it cheap. The value moved up, into judgment. It lives now in deciding what to build, what to leave alone, what is safe to trust, and how the pieces hold together over years.

A strong engineering team in this world has fewer people for every unit of output, and each of those people is worth more. One good engineer who builds the paved road lets a hundred non-engineers move fast without hurting themselves. That beats the same engineer writing one more report by hand.

This is why I keep telling leaders that AI does not replace engineers. It changes what you are paying them for. The company that sees that early gets a workforce that can all build, on a foundation a strong team keeps solid underneath them.

What this means if you run a company

You have two failure modes to avoid.

The first is locking it down. You get scared of the mess, so you kill the tools and route everything back through the old queue. You threw away the biggest productivity gain of the decade to feel in control.

The second is letting it run wild. You tell everyone to build and you cheer the speed, right up until the data leak, the silent error, or the pile of tools no one can maintain.

The job is the road between those two. A place where your whole company can build, on a foundation your engineers own and defend. That is the assignment for your engineering team now, and it is worth more than the old one.

Ask your engineering leaders one thing this week. If everyone here can build software now, what is our team the owner of? If they cannot answer that clearly, that is the work.

If people across your company are building their own software, your engineering team’s job already changed, whether or not anyone said so out loud. I am watching this shift on every client I work with. Reply and tell me what you are seeing.