FDE: AI's Hottest Role or Just Rebranded On-Site Engineering?
This article analyzes the Forward Deployed Engineer (FDE) role, tracing its origins at Palantir and adoption by OpenAI, while examining debates over whether FDEs are essential for AI deployment or merely rebranded implementation engineers, concluding that their value hinges on feeding field experience back into core products.
Introduction: The Rise of FDE
Over the past year, the acronym FDE (Forward Deployed Engineer) has moved from niche circles onto hiring pages and industry reports. The Pragmatic Engineer noted in August 2025 that venture firm a16z called it "the hottest job in tech." OpenAI built an FDE team from two people to over a dozen across eight cities in early 2025; fintech company Ramp embedded about 15 FDEs in squads. In September 2026, Google Cloud and Accenture announced a joint unit to train up to 1,000 FDEs for direct customer deployment. Domestically, Shanghai's government and industry bodies launched FDE training programs in December 2025 and February 2026.
1. FDE Boundaries: How It Differs from On-Site and Pre-Sales Roles
The role was systematized at Palantir, where it is called Delta (Forward Deployed Software Engineer). Palantir contrasts it with standard R&D: "One capability serving many customers" (Dev) versus "One customer needing many capabilities" (Delta). Palantir describes the FDE mandate bluntly: "FDE responsibilities resemble a startup CTO — small teams, end-to-end ownership of high-stakes project execution."
This role is not new. According to The Pragmatic Engineer, Palantir employed more FDEs than regular software engineers until around 2016, when the Foundry platform launch moved many FDEs back into product teams to inject field experience into the core product.
Work intensity is often overlooked. Palantir expects ~25% on-site time; medical AI company Commure estimates up to 50%; industrial AI firm Matta explicitly requires "figuring out the solution on the shop floor." Seven-year Palantir FDE Anjor Kanekar described daily scenes on Airbus final-assembly lines.
OpenAI structures the work in three phases:
Early scoping — spend days on-site, sit beside users, map workflows, identify highest-value areas, prototype with synthetic data.
Validation — answer "Is this scoped problem truly the highest value for the customer?" Build eval sets with users, expand labels, watch metrics climb. Validate first, deliver later.
Delivery — several days per week on-site, use real data, build back at home office, demo iteratively, goal is a minimum end-to-end working unit.
Boundaries with adjacent roles are frequently blurred. Per OpenAI's split, Solutions Architects (SA) lean advisory, rarely write code on customer infrastructure, deliver only MVPs or PoCs on sanitized data; FDEs are hands-on, coding directly on customer machines and toolchains, and push product roadmap changes. Compared to Sales Engineers (SE) and Agent Engineers (AE), the key differentiator is FDE output must flow back into the core product .
Stripping away Palantir's narrow definition, the role broadly comprises four elements: deep immersion in business context (not hearsay); insight-driven resource coordination; rapid delivery capability; and accountability for outcomes. The first three are skills; the fourth is a stance. Subsequent debates center on this fourth element.
2. Supporters: AI Turns "Cross-Role" from Impossible to Possible
Support for FDEs rests on three logical layers:
Layer 1: Organizational barriers are the real blocker. Eight-year Palantir veteran Nabeel Qureshi recalls FDEs spend most time on "data integration" — negotiating access from data owners, cleaning dirty data, making it universally accessible. The difficulty is never technical; it's cross-department negotiation, approval chains, and "not my job" mindsets. The Pragmatic Engineer argues startups are agile and engineers willing to hustle, while large enterprises are bogged down by bureaucracy. Deploying a fully authorized engineer with a "how to make it work" mindset yields faster progress than the customer's internal efforts.
Layer 2: Feedback loops into product. OpenAI case: on a call-center voice automation project, FDEs found the model fell short of production thresholds, took data and eval sets back to research to improve the model; the customer became the first to deploy that capability in production, and OpenAI's Realtime API improved as a result. Palantir's Foundry grew the same way. A Hacker News comment summarized: "Pain itself becomes the moat."
Layer 3: AI changes the cost structure. Previously, "business expert, engineering expert, decision-maker" had to align; now one person with AI can cover all three. An HN practitioner leading an FDE team put it cautiously: it remains an engineering role; "their value lies in being simultaneously embedded in the customer's company and ours — the eyes and ears we place inside the customer."
Supporters' strongest evidence is concrete outcome stories. OpenAI FDEs flew to Iowa to help a 200-year-old farm-equipment maker scale "personalized grower interventions." Previously done by manual phone calls, with a hard deadline before the next planting season; the project delivered on schedule.
3. Skeptics: Three Hats of Criticism
Hat 1: This work existed decades ago. Semiconductors have long had Field Application Engineers (FAE) — chips must prove they run before customers commit engineering time; FAEs are the adaptation and feedback linchpin. Mainframe and ERP implementation teams were standard even earlier. A widely cited HN analogy: "Sell a million-dollar machine, the real money is the service contract — send a fresh grad to sit beside you and parrot your engineering team's words back." The sharpest comment: "'Forward Deployed' is a Palantir coinage; aside from making on-site engineers sound respectable, there is nothing new." In East Asia, the equivalent is SI (System Integration), long not treated as a serious career track: every client stack differs, you must know a little of everything but master nothing, client-specific experience doesn't transfer, and it barely counts as capital when job-hopping.
Hat 2: Copying the form, not the function. This critique comes from Palantir alumni. Ted Mabrey's widely circulated piece "Sorry, that isn't an FDE" argues most companies adopting FDE are "tribute bands": they redraw org charts, internalize what used to be outsourced to SIs, but don't truly bind incentives to customer outcomes. Form copied, function missed. He spoke with former FDEs who joined such firms; they described it as "like being in prison." His argument hinges on productization . FDEs write quick, dirty code on-site, carrying technical debt and stopgap solutions — by design. The model only works if the product team generalizes these one-offs into reusable capabilities. Palantir's prerequisites: product ambition large enough that "what needs building is effectively infinite," and a strategy of "choosing the right customers, not all customers." Palantir disclosed its top 20 customers generate over $1.1B ARR.
Hat 3: Not enough roles, but courses are booming. Heat data shows tension. While labeled "hottest role," public FDE openings number only in the hundreds. Compensation is all over the map: some cite Palantir's $215k, others point to top labs' $785k; job-board medians sit between $197k–$294k. A 3–4x spread under one title signals the definition hasn't converged. The supply side moves faster: overseas, consultancies and cloud vendors batch-train; domestically, training, certification, delivery systems, and even "FDE concept stocks" have appeared. Amid genuine substance, there are many "spent $20k for nothing" warnings. A simple observation: when training supply visibly outpaces role demand, the biggest earners are rarely the practitioners. A deeper limit is scenario scarcity. Palantir-style FDEs are hard to replicate because they require a "10x value" scenario — only problems of that magnitude justify a high-comp, high-intensity, deeply customized engineering role. Such scenarios are inherently rare. FDE is not a role you can replicate by headcount; it's a role forced into existence by a sufficiently large problem.
4. The One Thing Both Sides Agree On
Laying out both arguments, the smallest divergence is: FDE value depends not on where they sit, but on whether field experience crystallizes into product capability.
If it crystallizes, it's an R&D front-line antenna; if not, it's premium outsourcing. This also explains why many believe credible FDEs can only grow inside a company: only your own business and product are worth — and able — to be repeatedly crystallized; generic training courses cannot solve the prerequisite "crystallize into which product?" question.
Viewed this way, FDE is not just a role but a playbook: on-demand training, upfront research, scenario workshops — all the same motion: first embed in real scenarios, then use engineering to deliver results. As for whether AI has lowered ToB difficulty, the answer may be no. Who owns it, who signs off, where the director's KPI sits — these are identical to five years ago.
5. Open Questions Without Answers Yet
If a company doesn't center on its own product, does hiring FDEs doom it to outsourcing from day one? Or is "service as product" itself a viable path?
What most enterprises truly lack — one FDE, or an internally empowered decision-maker?
Where is the opportunity? Large-company projects are locked by budgets, procurement, and internal politics; external gaps are narrow. Is the opportunity only in SMEs and one-person companies (OPC)?
Will FDE be a transitional phase in this AI deployment wave, disappearing once agents become reliable enough? Or is the gap permanent, ensuring the role's longevity?
A simple litmus test for anyone claiming to do FDE — person, team, or course:
Ask three questions:
Who is the customer?
Which specific scenarios were solved?
What methods were used?
If any answer is missing, the rest can be ignored. If all three are answered, then it's worth deeper inquiry.
This debate will likely never reach a unified conclusion, because "one customer, many capabilities" and "one capability, many customers" fundamentally serve different business models.
But if you're on this path, the questions above are worth clarifying first.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Continuous Delivery 2.0
Tech and case studies on organizational management, team management, and engineering efficiency
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
