Tech's Fastest-Growing Role: The Forward Deployed Software Engineer
Most enterprise AI projects do not fail for technical reasons. The demo works, the model answers correctly, the presentation lands. Then the work meets real data, a real process and real users, and it stops. Nobody is positioned to close that distance: the sales engineer does not write code, the product team does not know the customer's operation, the consultant produces slides.
There is a role defined precisely to fill that gap, and over the past year it has become the fastest-growing position in tech: the Forward Deployed Software Engineer (FDSE).
What the role is
An FDSE is a software engineer embedded inside the customer. Rather than shipping features from headquarters to an abstract user base, they scope one customer's problem, build the solution and take it to production. The phrase "forward deployed" is borrowed from military language: stationed at the front rather than at headquarters.
Palantir defined the role around 2009. Deploying platforms like Foundry and Gotham into complex government and enterprise environments required engineers who could both write code and sit with the customer. Today the same role appears under different names: Forward Deployed Engineer at OpenAI, Applied AI Engineer at Anthropic, Deployment Strategist or similar elsewhere.
Three things distinguish it. An FDSE writes and owns production-grade code. They carry no sales quota. And they understand the customer's operation at a depth usually reserved for product managers and consultants.
Why it took off now
The numbers show how quickly it spread. According to Indeed data reported by Business Insider, FDE postings went from 643 in April 2025 to 5,330 in April 2026, a 729% year-over-year increase.
The reason is straightforward. In AI products the distance between demo and production is far wider than in conventional software. A customer can install and run a SaaS product alone. They cannot stand up an AI system alone, because output quality depends on their data, their processes and their edge cases. The integration work is both complex and domain-specific.
So the list of companies adopting the role grew fast: data and AI platforms (Palantir, Databricks, Snowflake), frontier labs (OpenAI, Anthropic), vertical AI startups, and even traditional consultancies such as EY and PwC. Box CEO Aaron Levie describes it as one of the most important roles in enterprise AI adoption.
Compensation reflects that demand. Median total compensation for a Palantir FDSE sits around $215K, with senior levels at frontier labs reaching considerably higher bands.
Two separate implications
This development means different things depending on which side of the table you sit on.
For engineers. Because the role is defined by proximity to the customer, it tends to require geographic proximity too. New York overtaking San Francisco as the largest FDE hub comes down to regulated industries concentrating there. That means it is often not a fully remote position. Regional deployments, projects run by European companies across nearby markets, and local enterprise customers are where the equation changes.
For companies. This matters more. The same gap exists in enterprise AI projects everywhere, it simply has not been named. The pilot works, then adoption stalls. Model choice or budget usually takes the blame; the real cause is more often that nobody at the table understands the customer's process well enough to build for it.
Build the capability in-house or bring it in
That is the practical question, and it turns on a few factors.
Building in-house makes sense when AI sits at the centre of your business and you keep generating new use cases. The difficulty is the profile itself: strong engineering and the ability to hold a room with a customer rarely coexist in one person. Even when you find it, global companies are hiring the same profile at much higher bands.
Bringing it in works better when the need is bounded to a set of projects. What deserves scrutiny is whether the other side actually works this way. The difference between a supplier selling day rates and an engineering partner owning the outcome shows up in the first two weeks, not in the contract.
Three questions usually separate them. Who produces the scope, you or them? Who is accountable for the work running in production? Is the time they spend learning your process billed to you, or treated as part of the job?
How we see it
Internative has worked this way since 2017, well before the title became popular. A studio building custom software has little choice: you cannot build the right system without understanding the operation it serves.
What the FDSE conversation usefully does is give a clear name to something long understood: software creates value when it is used, not when it is delivered. Closing that distance is engineering work, and somebody has to own it.
If an AI project of yours has stalled at the pilot stage, or you want to close that gap from the start on a new build, talk to our team.