The viral FDE—how is it different from an on-site engineer?

"FDE is hot, but under the same name, two completely different things are being mixed together.

In 2026, an English acronym suddenly went viral in China's enterprise AI circle.

According to Maimai data, FDE-related job postings surged 21-fold year-over-year in the first half of 2026, and among companies posting FDE roles, 37.3% were AI-native companies. The "2026 FDE Talent Supply and Demand Trends Insight Report" released by Liepin Big Data Research Institute shows that over the past year, FDE-related positions had an average annual salary of 408,000 yuan, a median salary of 366,000 yuan, and hiring demand in June grew 237.21% month-over-month. ByteDance's "Doubao AI Large Model FDE" offers a monthly salary of 35,000 to 70,000 yuan with 15 months of pay per year, while Ant Digital Technologies' B2B FDE pays 40,000 to 60,000 yuan per month. The Ministry of Industry and Information Technology issued a document proposing to "encourage service providers to build Forward Deployed Engineer (FDE) teams, rooted at user sites, to ensure scenario implementation."

With popularity at this level, controversy followed.

"In China, FDE is just a new name for on-site workhorses." Someone quipped on social media that implementation engineers simply change their title and want their day rate to jump from 1,500 to 15,000. Huo Jia, Vice President of Alibaba Cloud Intelligence Group, said at the Yunqi Conference: "I don't want to talk about FDE anymore—anything I say now could be picked apart."

So what exactly is an FDE? Is there any essential difference between it and the pre-sales solutions consultants, on-site engineers, and implementation consultants that have long existed in the Chinese market? Or is it just the same group of people repackaged with an English name?

To answer this question, we need to start with the origin of the FDE.

From the Pentagon to Silicon Valley

FDE's 20 Years

FDE stands for Forward Deployed Engineer. "Forward Deployed" was originally a military term, meaning to push troops to the front line rather than keeping them tucked away in rear headquarters.

Palantir was founded in 2003, and its initial clients were US intelligence agencies. These clients had a peculiar problem: the requirements themselves were classified, and the business logic was extremely complex—the traditional path of "product manager gathers requirements → engineers develop → client accepts" simply didn't work. Palantir's response was to send engineers directly to client sites, embed them in client teams, and understand problems, discover requirements, build solutions, and deliver end-to-end from within.

Screenshot of a Palantir Foundry workspace

This model gave rise to a unique role division within Palantir. The company calls FDEs "Delta," with the formal job title Forward Deployed Software Engineer (FDSE), complementing the "Dev" role responsible for core platform development. A frequently cited summary of the difference between the two roles: Dev is "one capability, serving multiple clients"; Delta is "one client, drawing on multiple capabilities." Before around 2016, Palantir had more FDEs than regular software engineers. By software company standards, this ratio is extremely rare, showing that the embedded model was the core of its business from the very beginning.

Palantir describes this approach as "reverse backpropagation by humans" in software development: engineers stay close to the problems clients are working on, then bring field discoveries back to the core R&D team. It was precisely 20 years of FDEs on-site that distilled the industry logic of defense, finance, and other sectors into reusable modules, enabling Palantir to achieve profitability in 2023 and complete the leap from project-based work to productization.

In the past two years, as Palantir's valuation has risen, the FDE concept has spread from Silicon Valley to China, quickly becoming the hottest job concept in AI implementation. Data from global recruiting platform Indeed shows that the number of open FDE positions in the US grew from 643 in April 2025 to 5,330 in April 2026, a year-over-year increase of 729%, far exceeding the roughly 45% growth rate for AI engineers overall. OpenAI, Anthropic, Stripe, and Google Cloud are all hiring this type of engineer.

Builds, Embeds, Owns

Three Verbs That Draw the Line

Palantir itself has summarized the difference between FDEs and on-site engineers with three verbs: Builds, Embeds, Owns. These three dimensions form the core yardstick for judging real versus fake FDEs.

Builds—able to write production code with their own hands. A consultant's deliverables are documents: requirement specifications, flowcharts, PowerPoint decks. An FDE's deliverable is a working system. Rather than writing down requirements and handing them to someone else to implement, the FDE directly turns them into ontology definitions, data pipelines, and executable actions. No document handoffs in between, no second-hand interpretation, no "I thought you meant this."

Embeds—stationed on-site. Consultants typically engage in phases: they leave after the research, leave after the proposal. An FDE embeds in the client's daily work four to five days a week, sitting next to dispatchers watching how they make decisions, standing in the workshop watching how the production line runs. Only on-site can you capture the tacit knowledge that can't be articulated but is critically important. On-site delivery engineers are only responsible for implementation and execution—whatever customization the client asks for, they do, temporarily patching code and adjusting environments when problems arise, just to get delivery approved in the moment. An FDE, by contrast, writes code at the client site and personally delivers the system to production.

Owns—accountable for production outcomes, not for deliverables. This is the most fundamental difference. On-site engineers are typically accountable for "launch and operations within the agreed scope," while an FDE is also accountable for the results the system produces in actual business, and must bring field discoveries back to the product team.

Three verbs—remove any one of them, and the role degrades into something else. Remove Builds, and it becomes a pre-sales consultant; remove Embeds, and it becomes remote technical support; remove Owns, and it becomes outsourcing.

But what best distinguishes real from fake FDEs is the difference from implementation consultants. SAP implementation consultants configure SAP modules; Salesforce implementation consultants configure Salesforce processes—the categorical framework is predefined, and implementation consultants make parameter adjustments within that framework. An FDE doesn't configure an existing framework, but builds the categorical framework itself from scratch. Palantir's ontology has no predefined entity types, no ready-made "supply chain template" waiting for you to fill in parameters. The FDE must step into the business scenario, judge "what matters in this world," and then implement it.

Ontology: Why the FDE Must

Be Stationed at the Client Site

If the FDE is Palantir's "hands," then ontology is Palantir's "brain."

The Palantir Ontology is the operational system and organizational operations layer at the core of Palantir's architecture. It connects enterprise digital assets into real-world business objects and relationships, and places decision logic, controlled Actions, and security rules into the same runnable decision-making world. This system contains two inseparable parts: the Ontology both describes "what the world currently looks like" and defines "who can change it into what, under what conditions."

From a technical structure perspective, the core elements of the Ontology include Object, Property, Link, Function, Action, and Security. It doesn't store the business data itself, but defines what entities exist in the business world, what those entities look like, how they connect to each other, and what can be done to them.

These two things are one. The construction of the ontology must be done by FDEs on-site. The reason is simple: things that genuinely exist in an enterprise are visible to humans, but invisible to software. The same client is called "XX Co., Ltd." in the CRM, "XX Shares" in the ERP, and "XX Group" in the warehouse system. Each system calls it its own name, and the moment you try to consolidate, the cracks show.

A Tencent Cloud developer community article, "Palantir Study 05 | What Is Ontology: Describing the World and Changing It," mentions a typical scenario Palantir has publicly discussed: a customer built a full data model, linking Supplier, Material, Plant, and Customer Order into one graph—everything that should be there seemed to be there. But when a planner opened a material shortage event, they still couldn't directly answer: which customer orders does this shortage affect, who can approve a transfer, and how does an approval flow into execution. Data being findable does not mean decisions can be executed. The problem lies in the translation loss between business understanding and system implementation. The entire reason FDEs exist is to fill that gap.

And this must be done by the FDE on-site. Business decision-makers' knowledge is tacit. Ask a veteran scheduler "what do you need to look at when scheduling," and they most likely can't articulate it. But sit next to them and watch them work for a day, and you'll find that the few metrics their eyes scan and the few relationships they mentally calculate are exactly the core categories the ontology should model. These judgments are buried in the muscle memory of daily operations—they can't be dug out through a few requirements-gathering meetings.

Colin Jarvis, head of OpenAI's FDE program, has a blunt summary of the role: the FDE's job is to "eat pain and excrete product"—digest pain, produce product. The team's north star metric is: "You must leave with product."

Same Title, Two Realities

After FDE entered China, it quickly diverged. Under the same name, two completely different things are mixed together: half is productized forward deployed engineering, and half is the old on-site staffing model in a new skin.

First, look at the proven cases in the US. Palantir's General Mills supply chain project: this food company connects with 4,000 suppliers and over 200 plants in North America, processing about 1.2 million orders per year. The FDE team integrated 200 master data and operational data tables to build the supply chain decision system ELF. It checks about 3,000 orders daily and provides about 400 adjustment suggestions, of which over 70% are accepted by staff. General Mills says the system saves about $40,000 per day, roughly $14 million per year. The system must simultaneously understand orders, transport capacity, production capacity, costs, and business constraints, and also know which suggestions can be executed and which decisions must be left to humans. A consultant can propose optimization directions, a traditional implementation engineer can wire up the databases, but the FDE must turn vague problems into production systems, then judge whether the system works using adoption rates and business metrics.

Yet some domestic FDEs are doing something else entirely.

According to media reports, FDEs are still on customer sites repeatedly tweaking details and supporting acceptance testing. On-site staffing and travel costs all come out of their own pocket; one customer remark like "change this a bit more" or "that part still isn't meeting expectations" pushes acceptance further back. Costs are being incurred every day.

One practitioner described their actual work: in interviews, they discussed Agent architecture and Prompt engineering, but at the customer site—a manufacturing plant—the real job was going into the workshop, recording each machine's "nickname" amid the roar of machinery, and personally sticking QR codes onto equipment for positioning.

The common problem in these cases: FDEs are treated as "senior pre-sales" or "AI project managers," without sufficient engineering authority or participation in business decisions. FDEs become PPT-making machines, losing the core value of "writing code on the front line."

The deeper problem is the business model. In the US, enterprise software and subscription models are more mature, so FDE costs can be amortized into recurring revenue. But domestically, many projects are billed by person-days or on-site duration; under this model, FDEs easily become senior implementation staff or even outsourcing. On-site staffing is a work arrangement, outsourcing is a resource organization relationship, and FDE is a delivery model oriented toward business outcomes—the three are fundamentally different, but in China's project-based environment they are easily conflated.

That said, leading domestic companies are already trying to chart differentiated paths.

MiningLamp Technology's mid-2026 interim results announcement showed that about 30% of the company's delivery staff transitioned to FDEs in the first half of the year, establishing AI efficiency evaluation standards across 172 reported delivery scenarios, achieving an overall efficiency improvement of 56.1%, accumulating 359 reusable Skills, and cutting new-hire training cycles in half. The company also disclosed it will drive the Teamsoft team to transform into FDEs serving central and state-owned enterprises.

MiningLamp CEO Wu Minghui pointed out that in the big data era, FDEs did data governance, helping customers build data middle platforms; in the AI era, FDEs have more to do—helping customers' business staff build their own AI agents, connecting the agents to the middle platform, not only sharing context but also sharing skills and sharing memory.

iSoftStone has built a closed-loop capability of "consulting defines scenarios—FDE implements—scenario assets accumulate—scaled reuse" through "FDE front-line delivery + AI platform support," creating benchmark projects in more than ten industries including finance, manufacturing, aviation, steel, agriculture and livestock, transportation and logistics, and retail. The company has built an iSoftStone FDE industry solutions team of over 500 people.

Seeyon established an AI-FDE co-creation service model, with "AI technology + industry business + value delivery" trinity teams going deep into customer sites to jointly complete requirements co-creation, solution design, scenario validation, and ongoing operations with customers.

The common feature of these attempts: no longer treating FDEs as "on-site labor," but trying to distill on-site experience into reusable product capabilities.

Who Is Doing FDE:

Salary, Origins, and Transition Barriers

Based on current market data, the answer is "partly yes, partly no."

A report from Liepin Big Data Research Institute shows that over the past year, the average annual salary for FDE-related positions reached 408,000 yuan, with a median of 366,000 yuan; positions paying over 500,000 yuan accounted for 28.25%, far above the 16.11% for IT and internet technical roles. But the median salary is about 366,000 yuan, and positions above 500,000 yuan account for less than 30%. In other words, "million-yuan annual salary" is an exception for top positions, top companies, and top cities, not the industry average. A post-90s practitioner at an AI company in Shanghai said that lower-level FDEs earn a monthly salary of 20,000 to 30,000 yuan, while higher-level ones are paid mainly in annual packages, mostly above 400,000 yuan.

By city distribution, FDE positions are highly concentrated. Among newly posted positions over the past year, Shanghai accounted for 23.33%, Beijing 22.50%, Shenzhen 14.31%, and Hangzhou ranked fourth at 8.19%—these four cities together accounted for 68.33%.

As for transition origins, the main force doing FDE work in China today indeed comes from software engineering and solutions backgrounds.

But what's truly scarce is not "people who can code" or "people who understand the business," but people who have both. An AI product team lead who has been doing enterprise AI deployment since 2023 told industry observers: across the entire team, only 2 or 3 people truly qualify as excellent FDEs. It's not newcomers complaining that talent is hard to find—it's someone who has been doing enterprise AI deployment for years, with a sizable team and a product at the top of a niche track, admitting that this role is genuinely hard.

For on-site engineers to transition to FDE, programming skills alone aren't enough. Palantir's FDEs don't work solo; they use an Echo-Delta two-person collaboration model—Delta is the engineer who writes code, and Echo is a domain expert from the customer's industry who can extract front-line requirements in "the language of the field." This means someone transitioning to FDE must either possess both capabilities themselves or learn to take on the responsibilities of one of these roles within team collaboration.

The Core Yardstick: Can It Distill into Product Capability

To judge whether FDE will keep growing into a key force or end up "a mess on the floor," there is one core yardstick: whether it distills experience into reusable product capability.

Palantir's approach is institutionalized. They built a "gravel road to highway" mechanism—FDEs lay down a "gravel road" (custom solution) at a single customer site, and the product team then generalizes it into a "highway" (standard feature) serving more customers, with the original FDE participating in the generalization discussions throughout. This mechanism ensures that FDEs' on-site experience doesn't remain trapped in a single customer's custom project, but becomes an incremental capability for the entire platform.

If a company's FDEs only write one-off code at customer sites, and the next delivery starts from scratch, the work is still custom development—just with a more expensive name.

Currently in the Chinese market, both models coexist. MiningLamp Technology is trying to transform its existing delivery team by writing experience into Skills and Agents, so that the next delivery relies less on people. But more companies are still using FDEs as "freebies"—showing them to customers once, telling them "we have this capability," just to help the company close deals smoothly.

Industry standards are also not yet settled. BeyondSoft's statement on its investor interaction platform represents a cautious judgment: FDE is one of the key deployment models that the domestic and international AI application industry is focusing on, but it is still in the stage of industry exploration and practice.

Back to the controversy at the beginning: is FDE old wine in a new bottle, or a genuine professional restructuring?

FDE is not old wine in a new bottle, but it can easily be made into old wine in a new bottle.

The difference lies not in the job title, but in three things: whether one can write production-grade code on-site at the customer, whether one can distill reusable ontological capabilities from projects, and whether one can be accountable for business outcomes rather than just deliverables. Those who achieve these three things are true FDEs. Those who don't are just resident engineers with an English name.

Palantir's FDEs spent nearly two decades turning the most complex data scenarios of the U.S. Department of Defense and the CIA into a reusable product system. Chinese enterprises' AI adoption has only just begun. Whether FDE can succeed in China depends not on how long the job title stays popular, but on whether Chinese enterprises' AI delivery model can truly shift from "selling person-days" to "accumulating product capabilities."

If it fails, FDE will ultimately end up like many once-hot concepts, leaving a mess behind. If it succeeds, it could become a key turning point for Chinese enterprise AI moving from a "project-based" model to "productization."

The answer to this question lies not in FDE itself, but in the hands of those who use it.

Text: Haidao / DataYuan

Editor: Ningshi Shenkong / DataYuan

This article was uploaded and published by a The Paper (Pengpai News) account author or organization, and represents only the views of that author or organization, not the views or positions of The Paper, which merely provides an information publishing platform. To apply for a Pengpai account, please visit http://renzheng.thepaper.cn from a computer.

Report This