FDE: The New Frontier in AI-Driven Engineering Roles

Over the past month, I met four friends preparing to switch careers—a front-end developer, a solutions architect, a product manager, and a traditional algorithm engineer—each with different backgrounds, ages, and cities, yet all asking the same question: Is FDE [2] worth pursuing?

FDE stands for Forward Deployed Engineer [2]. Two years ago, it was still an insider jargon within the Palantir community; today, it has quietly become a common opening line for recruiters, a frequently listed position in job postings, and one of the top candidates for “the most valuable job in the AI era” on social media. In May 2026, OpenAI directly established a Deployment Company [3] under this name, with an initial investment of $4 billion, explicitly stating its intent to send engineers into clients’ on-site environments and integrate them into clients’ workflows. Anthropic’s Applied AI team is also simultaneously hiring FDEs across four time zones. This term transitioned from insider jargon to a widely recognized keyword in just over a year.

My previous article, "To the Super Individual" [4], explored how the "human engine"—curiosity, self-learning, self-motivation, and hands-on ability—is activated within a complete closed-loop system. But humans are not suspended in void; they must be grounded within a specific job coordinate system. If super individuals are the "raw material" of production relations in the AI era, then FDE is the most visible job format that the market has grown this year.

In my view, FDE does not belong in the consulting box or the outsourcing box—it is closest to the super individual, with the only difference being that FDE is an organized super individual existing in the gap between “model company × client.”

Did you know—where does the term “Forward Deployed” come from? It originally stemmed from the U.S. military term “Forward Deployed Forces,” referring to troops stationed overseas or at the front lines to enable rapid response, in contrast to rear units remaining at home bases. In the late 2000s, Palantir adopted this term into the software industry to describe the practice of sending engineers away from headquarters to live on-site with clients—even naming internal teams using military phonetics: Delta and Echo. Now, OpenAI and Anthropic have taken it back—not by coincidence—because the essence of sending engineers to the front lines has never changed.

The three specific questions addressed in this article are the ones I was recently asked by four friends:

- Is FDE just a consulting firm dressed in AI clothing? Where does its boundary lie with traditional consulting?

Is FDE a more advanced form of software outsourcing? How does it differ from what I'm currently doing as a contractor?

Am I suitable for an FDE role? Which types of people will thrive in this position, and which will be worn down by it?

My stance is cautiously optimistic: FDE is genuinely taking root, but it is far from a transition outlet for everyone. Clarifying it is more important than making it sensational.

If only one event could mark the moment FDE re-entered the spotlight, the author would choose May 11, 2026—the day OpenAI announced the formation of Deployment Company [5], with COO Brad Lightcap leaving his previous business division to take on a special projects role reporting directly to Sam Altman, fully dedicated to this initiative. In the same week, OpenAI acquired the UK-based AI consulting firm Tomoro, bringing in 150 Forward Deployed Engineers and Deployment Specialists all at once into the new company.

Notably, OpenAI’s careers page is currently listing over a dozen FDE roles across San Francisco, New York, and Washington, along with industry-specific verticals such as Life Sciences, Semiconductor, and Gov. Even the position of FDE recruiter [6] is itself open for hiring. Analysts estimate this team will expand to 2,000–4,000 people within three years. This is not the scale of a research group—it’s a full-fledged army.

Anthropic is essentially making a mirrored move. The Forward Deployed Engineer role under the Applied AI team [7] is being advertised simultaneously in Boston, New York, Seattle, San Francisco, Washington, and London, requiring 25%–50% on-site client travel. A recently cited example is the fintech company FIS, which explicitly stated in its announcement: “Anthropic’s Applied AI team and forward-deployed engineers have been embedded within FIS to co-design the Financial Crimes AI Agent and transfer knowledge to FIS so it can independently scale additional agents in the future.”

This is the real nature of the FDE role. It’s not a pre-sales architect, not an SDR, and not an evangelist coming in to train customers. It’s an engineer who brings models and embeds themselves directly into the customer’s codebase. Brad Lightcap puts it even more plainly: “Our customers tell us they need the ability to go from pilot to production. Deployment Company means placing our engineers directly into their teams and giving them the resources to deliver.”

Drawing this as a diagram will make the three-party relationship very clear:

Pay attention to the two most informative lines in this diagram: the feedback flows from FDE in both directions. Toward customers, FDE does not sell the model as SaaS; instead, it integrates customer data, permissions, compliance, and internal systems into a unified pipeline capable of running models. Toward model companies, FDE brings back real customer pain points and failure samples to product and research teams, influencing the roadmap—a recurring erroneous tool-calling pattern may become the next built-in abstraction in the SDK.

This is why FDE has been simultaneously revived by two leading model companies in this round—it’s not as simple as “we’re also going to emulate Palantir and do consulting.” It’s a signal-gathering mechanism for model companies: the most intense customer pain points on the front lines can only be captured by having their own people on the ground; demands filtered through partners always come through a layer of distortion. Anthropic is taking a hybrid approach: running FDE in-house while also building joint deployment networks with consulting firms and private equity giants. One leans toward in-house execution, the other toward ecosystem collaboration—but at their core, they’re identical: model companies are no longer just API providers; they’re sending engineers directly into their customers’ products.

The next two questions are the most common comparisons: Where is the boundary between FDE and traditional consulting (like McKinsey or Accenture)? And is it the same as the software outsourcing we’re familiar with?

Many people’s first reaction upon hearing FDE’s job description is: “Isn’t this just a new version of McKinsey or Accenture?”

I understand this association. Appearing in a suit, visiting client sites, drawing on whiteboards in client meeting rooms, and aligning with C-level executives—on the surface, FDEs do resemble management consultants. But once you look one layer deeper, the core nature of their work is entirely different: consultants sell process boundaries, while FDEs sell model boundaries.

Placing these two side by side in a table makes the differences immediately apparent.

The row most worth pausing on in this table is "Asset Depreciation."

The most profitable logic of traditional consulting is asset reuse—a solution created for one bank can be slightly modified and sold again to the next; a digital playbook for the retail industry can be repeatedly applied to thirty clients. This has been the underlying economic model behind the growth of Accenture, Deloitte, and McKinsey Digital over the past three decades.

FDE does not have this type of asset. Model capabilities are evolving rapidly—today requires carefully crafted prompt chains, but the next version may accomplish the same with a single sentence. The "methodology accumulation" in consulting will quickly lose value against this pace. Therefore, FDE cannot rely on asset reuse; each closed-loop execution must be performed anew—reassessing model boundaries, reselecting tool stacks, and reassembling product forms. It may seem inefficient, but it is the only way to keep up with the speed of model advancement.

Did you know—what is Product Overhang? In my previous article, “To the Super Individual” [4], I explained this term: the model’s capabilities have surpassed the current product form, but there is no product entry point, permission, or context to realize them. The value of the FDE role is essentially turning those suspended Overhangs from customer scenarios into concrete, operational products. Customers aren’t buying API call quotas—they’re buying the capability that “someone can truly implement this pile of Overhang within my business.”

This also explains the discrepancy in the “Project Structure” row. The standard structure for consulting projects is SOW (Statement of Work) + WBS (Work Breakdown Structure) + Phase Gate Approvals: clearly defining in the contract what will be delivered, when it will be delivered, and the criteria for acceptance. This structure assumes that the objectives are already clearly defined before the contract is signed.

FDE’s projects don’t follow this approach. The most common thing clients say is: “I know AI should be able to help me with something, but I don’t know what.” The goal itself is part of the project. So FDE doesn’t take SOWs—they take missions: a relatively ambiguous direction—and then gradually clarify that direction through iterative cycles. Eventually, in one of those cycles, they transform the accumulated model insights into a tangible product.

The line "deliverables" is also worth expanding. After FDE leaves, what remains in the client’s system is a working function—perhaps small, perhaps ugly, perhaps with little to no user interface—but it is genuinely being called, modified, and criticized every day. The deliverables of consulting are PPTs and change management reports; even if code was written or ERP systems configured during the project, what ultimately stays in the hands of the client’s executives is still a methodology document.

The "moat" row is the most subtle. FDE’s moat is the real-time intuition for the boundaries of model capabilities—how many real customer scenarios you’ve run this month determines how well you know what Claude 4.7 can do and what must wait for Claude 5. This intuition can’t be written into a PowerPoint or stored in a knowledge base; it can only reside in the minds of engineers who’ve worked hands-on in the past 90 days.

So next time someone says, “Isn’t FDE just the new Accenture?” you can respond: Accenture’s engineers go to redesign their clients’ processes, while FDE goes to rediscover the boundaries of models. The assets of the former can last a decade, while the assets of the latter need to be rebuilt every 90 days.

If "FDE is the new Accenture" is the first layer of misunderstanding, then "FDE is expensive software outsourcing" is the second. This layer is more misleading, because the surface-level evidence appears overwhelmingly convincing: FDE does go to client sites to write code, does customize features according to client business needs, and does adhere to client working hours. At first glance, it seems indistinguishable from outsourced engineers.

But just looking at the feedback loop makes the difference unmistakable.

The most critical difference in this diagram isn’t how simple the top part is, but rather the additional feedback loop extending toward the model company in the bottom part. This loop isn’t decorative—it’s the very reason the FDE role exists. Breaking down this distinction reveals at least four key comparisons.

The delivered deliverables are different. Outsourcing works with a SOW—a clearly defined requirements list established before contract signing: which features to build, what tech stack to use, what acceptance criteria to meet, and how penalties will be applied for breach. FDE works with a mission—the client isn’t even sure what they want, only that “AI should be able to help me with something.” A SOW is based on certainty; a mission is based on exploration. The two represent entirely different approaches to initiating a project.

The scope is different. Outsourcing handles partial deliverables—a module, a website, a data pipeline—then packages up and moves on to the next client. FDE handles end-to-end projects—from identifying business pain points, through model selection and product design, to post-launch user retention and churn.

The billing model is different. This is the most counterintuitive point. A model company sends an FDE to the client’s site, and what they ultimately care about isn’t just how much consulting fee they earn from this project—but how many tokens this client will consume going forward, whether they’ll become a retention customer, and whether they’ll expand into additional business lines. The FDE’s true KPI is the long-term token consumption curve, not the number on the project sign-off sheet.

The feedback goes to a different destination. This is the deepest of the four groups. In outsourced projects, client feedback stops at the outsourcing company and does not influence future products the outsourcing company sells to others. In contrast, FDE feedback flows back into the model company’s roadmap—every issue encountered by clients in real-world scenarios, every failed prompt, and every tool invocation bug becomes input for the next version of training data, tool design, and product features. In other words, each FDE-deployed client serves as a natural design partner for the model company.

This is the real reason model companies are willing to pay high salaries to hire FDEs. They’re not just selling a service—they’re collecting real-world product signal data at their customers’ sites. These signals can’t be purchased, captured, or uncovered through surveys—they can only be brought back by a specific engineer who has personally hit walls several times within a specific customer workflow.

Did you know—what’s the total compensation for FDE roles at OpenAI and Anthropic? According to publicly available data on Levels.fyi for Anthropic software engineers [8], the median total compensation for senior SDEs has already reached $710K. The FDE role carries higher risk—it must navigate uncertainty in model capabilities, client business needs, and product form factors—so industry benchmarks [9] indicate that mid- to senior-level FDE compensation at leading AI labs typically ranges from $350K to $550K, with Staff-level and above reaching $630K+. This pay isn’t for “contracted hours”; it’s compensation for bearing the combined risk of product, client, and model. > Recall 2006, when I first started my career at a state-owned enterprise undergoing digital transformation. At the time, our group hired Accenture consultants on-site, paying them 3,500 RMB per day for several years—they were dubbed “golden collars” by the media back then. Later, I joined SAP Germany, which essentially coined the term “consultant” in this industry, making SAP consultants the very symbol of the “golden collar.” From this perspective, FDE salaries will likely continue rising over the next 24–36 months, with demand steadily increasing.

Outsourcing is labor arbitrage; FDE is a frontline sensor. Confusing the two will lead clients to mistakenly believe they can hire FDEs using an SOW, and candidates will approach FDE roles with an outsourcing mindset. Both sides will hit a wall quickly.

Many people mistakenly believe that the term FDE was invented by OpenAI. It was not. It has two historical roots: one from Palantir and another from the new generation of model companies after 2023. Viewing these two roots side by side makes it clearer what the FDE role truly entails.

First, let's look at a timeline.

The first root is Palantir.

Palantir was founded in 2003 by Peter Thiel, Alex Karp, Joe Lonsdale, and others, with its earliest clients being U.S. intelligence agencies. Karp himself had no computer science background—he pursued his doctorate in philosophy under Jürgen Habermas in Frankfurt and was later brought on as CEO by Thiel after returning to the U.S. The FDE role emerged precisely from this unconventional combination of a non-typical CEO and highly classified clients: as 36Kr’s retrospective [10] bluntly noted, Palantir was heavily criticized by intelligence agencies early on because engineers lacked access to real-world business scenarios, and requirements became distorted through multiple layers of translation. Eventually, Palantir secured an arrangement allowing its engineers to work directly on client sites alongside intelligence analysts. This model was later systematized by Shyam Sankar, forming the雏形 of the FDE role.

By 2009, FDE had expanded into the commercial sector. When JPMorgan deployed Palantir’s Metropolis platform, 120 FDEs were embedded to monitor for insider threats. From this point on, FDE evolved beyond merely “sending engineers on site” into a structured approach of customer embedding—integrating Foundry/Gotham directly into clients’ business workflows, rather than simply delivering a license and moving on.

Palantir’s FDE hiring has an unconventional criterion—no CS degree required. This could fit in a “Did you know?” section.

Did you know—Palantir FDE does not require a CS degree? According to Palantir’s hiring criteria compiled by SkillScouter [11] and Palantir’s official careers page [12], Palantir explicitly welcomes candidates from non-CS backgrounds; recent FDE hires have come from fields such as mechanical engineering, economics, and philosophy. What truly matters are two things: the ability to act with incomplete information, and the ability to communicate directly with C-level clients. A CS degree is a bonus, not a requirement. Karp himself is the earliest example of this standard—a philosophy major who leads an FDE team composed of physicists, mathematicians, and philosophers.

The second root is a next-generation model company established after 2023.

After ChatGPT was released at the end of 2022, OpenAI quickly realized one thing: simply posting model APIs on documentation and expecting customers to integrate them themselves simply wasn’t working. Customers weren’t unwilling to use them—they didn’t know how to use them. They had business problems but no product form. As a result, companies like OpenAI, Anthropic, Cohere, Scale, Glean, Sierra, Hebbia, and Decagon began hiring FDEs at scale.

This wave of FDE is learning directly from Palantir’s playbook—sending engineers to client sites to end-to-end deploy a workflow. But the product载体 has changed completely: In the Palantir era, FDEs focused on data integration and UI customization; today’s FDEs work on prompt design, agent orchestration, tool invocation, and workflow embedding.

In Pragmatic Engineer’s article on FDE [13], this new version is described as “embedded with enterprises to make Claude solve real, specific, high-value problems”—a phrasing nearly identical to Palantir’s from years ago, with “data” replaced by “model.”

Looking at these two roots together, you can see a clear set of commonalities and differences.

Commonality: Customers aren’t buying software—they’re buying “engineers plus a toolkit that solves my problem.” This was unusual in the past thirty years of enterprise software history. SAP, Oracle, and Salesforce sold software itself—the engineers existed as auxiliary resources to make the software accessible to customers. Palantir flipped this: the tools exist as levers to enable FDEs to solve problems for customers. The new generation of model companies inherits this inverted relationship—OpenAI doesn’t sell a GPT-4 license; it sells “our FDEs using GPT-4 to automate your customer service.”

Difference: The Palantir era emphasized OPS integration—focusing on data integration, ontology modeling, and permission governance. The new generation emphasizes model capability deployment—focusing on prompt design, agent orchestration, and retention optimization. The former is like an advanced system integrator; the latter is like an extension of a product engineer.

One final interesting fact: Many early Palantir FDEs later became entrepreneurs or joined next-generation model companies. A long list of former Palantir employees can be found in the early teams of Anthropic, OpenAI, Sierra, and Hebbia. This is no coincidence—the FDE role inherently forces individuals to manage product risk, customer risk, and engineering risk simultaneously, essentially serving as entrepreneurship training. I prefer to view Palantir as an invisible startup incubator: it doesn’t just produce engineers, but a cohort of people who know how to drive something from zero to one amid incomplete information. Two roots converged after 2023.

The convergence of the two roots primarily occurs overseas. In China, the term FDE has only recently emerged, but the work it represents did not arise out of nowhere. To understand FDE in China, one must first recognize its two local predecessors, then examine the three key differences between it and the U.S. version of FDE.

Two local predecessors

The first predecessor was the solution architect role at cloud service providers. Over the past decade, Alibaba Cloud, Tencent Cloud, and Huawei Cloud have cultivated entire teams of Solution Architects (SAs) who present architectures to customers, develop proof-of-concepts, design migration plans, and support deployment to go-live. Huawei even has a dedicated “Delivery Engineer” track responsible for implementing projects at customer data centers. This system already covers about 80% of FDE work, but its focus remains on pre-sales and deployment—end-to-end product iteration is not the SA’s responsibility; changes to requirements require formal change processes, and switching models depends on headquarters’ scheduling.

The second predecessor is a new role emerging from AI startups: MiniMax is listing "AI Pre-Sales Solutions Expert" on Boss Zhipin, and similar positions are also posted by model companies such as Moonshot AI, Zhipu AI, Tongyi, and Hunyuan. Although the job titles vary slightly, the job descriptions are highly consistent: understanding customer scenarios, creating demos, tuning prompts, running RAG, drafting delivery plans, and coordinating with customer engineering teams to go live. This wave of roles truly represents the domestic FDE.

Three differences in soil and water

On-premises deployment and data compliance overwhelm pure model API calling models. Domestic B2B customers in China have far higher requirements than the U.S. market for data staying within their premises, control over model weights, and auditable traceability. In an FDE project, the workload of simply calling APIs to run prompts may account for only 30%, while the remaining 70% involves deploying the model to the customer’s data center, implementing authentication, integrating with the data middleware, and completing compliance filings.

Model capabilities are still catching up to SOTA, leaving room for differentiation primarily at the engineering level. In the U.S., OpenAI and Anthropic can win customers with raw model performance alone; in China, models from Tongyi, Doubao, Kimi, GLM, and DeepSeek show less variation in capability, so customers increasingly evaluate based on engineering factors such as agent orchestration, RAG retrieval quality, tool integration, and workflow design. Chinese FDEs are competing not on “how powerful our model is,” but on “whether we can actually make this business work.”

B-end customers' willingness to pay and pricing rhythm differ from those in the U.S. The Palantir model—deploying FDEs first, then charging high-unit subscription fees—is difficult to replicate directly. Domestic clients’ budgets follow annual procurement cycles, with payments tending toward project-based models; the FDE business model is often a hybrid of subscription, private licensing, and project delivery.

A unique positioning: Internal FDE

Many large tech companies' internal AI teams are now using the FDE model to serve internal clients. Alibaba Cloud's PAI has assigned engineers to work directly within Taobao, and Tencent's HunYuan has established similar mechanisms to collaborate with WeChat and advertising teams. JD.com lists roles such as "Industry Implementation Engineers," "AI Application Engineers," and "Intelligent Business Experts"—all essentially internal FDEs, end-to-end deploying model capabilities directly to business units. This gives leaders at large companies a new approach: placing a few internal FDEs on-site with business teams to quickly deliver a working demo and deliver ROI data directly to business stakeholders—this can break down departmental silos faster than ten alignment meetings.

In my previous article, “To the Super Individual” [4], I discussed the five engines of a super individual: strong curiosity, strong spirit of exploration and innovation, strong self-learning ability, strong self-motivation, and strong hands-on ability. These five traits are the entry ticket to FDE roles, but not the whole picture. Beyond these five engines, FDE positions require a distinct set of specific additional qualities, and certain personality types are clearly unsuited. I’ve seen too many talented engineers struggle after transitioning into FDE roles—not due to lack of ability, but because of mismatched personality and work preferences.

Five traits suitable for FDE

Don’t shy away from sales and communication. A typical day for an FDE isn’t coding behind closed doors—it’s directly engaging with clients’ CTOs, business leads, procurement teams, compliance officers, and IT staff. The usual rhythm: a client CTO interrupts you mid-demo; the FDE’s response isn’t “I’ll go back and revise it and come back next week,” but rather immediately opening the IDE to modify the prompt and rerun it right in front of them. “The client is here, and I’m making changes” is the norm for an FDE.

Embrace the gray area. FDEs don’t receive clear PRDs—they get a statement like, “We want to do something with AI.” Even the client isn’t sure what they want, and it’s the FDE’s job to help shape that vague expectation into something concrete. If you can only act when requirements are clear, being an FDE will leave you anxious every day.

Strong engineering skills are required, but not 10x performance. FDE doesn’t need you to be the person with the cleanest code or deepest algorithms in the company—it needs you to deliver end-to-end: a frontend that can render a clickable page, a backend that can run a working service, and a model that connects to business data sources. In the FDE world, “good enough” isn’t a flaw—it’s a virtue.

Thrives on feedback. FDE roles involve frequent moments where work is sent back by clients: today’s demo might be rejected tomorrow with “This isn’t what I wanted”; a solution aligned with stakeholders last week may need to be redone this week because a new executive has taken over. The right person for an FDE role treats this feedback as fuel, takes end-to-end ownership, and doesn’t blame the “requirements team” for unclear instructions.

Sensitive to model boundaries. This is the most technical and least obvious criterion. FDEs must know which tasks are suitable for LLMs and which are not, and how to implement fallbacks—this sensitivity cannot be learned from papers but only through repeated failures. Only by accumulating failure cases do FDEs develop muscle memory for model boundaries: when to use RAG, when to apply rules, and when to always provide a human fallback.

Four types of people unsuitable for FDE

A pure tech enthusiast who wants to hide behind code. FDEs spend about 50% of their time not writing code, but in client meetings, internal coordination, product discussions, and contract progression. If your joy comes from coding uninterrupted for four hours straight, an FDE role will leave you chronically mentally exhausted.

People who need OKRs to get started. FDE’s goals are rooted in the customer, not on your performance sheet. Progress is determined by the customer’s project milestones, changes in model capabilities, and your own judgment of the use case. Those accustomed to “needing OKRs to know what to do” will struggle to find their anchor.

People who value promotion over work. FDEs don’t have an advantage in large company promotion systems—metrics like customer satisfaction, project acquisition, and reuse rate carry less weight in level reviews compared to lines of code or deployment frequency. If promotion is your top motivation, FDE is not the right choice.

People who resist business contexts. FDEs must understand their clients’ P&L, ROI, procurement processes, and compliance requirements. If you naturally dislike discussing money, contracts, or business logic, an FDE role may make you feel like you’re compromising your technical ideals.

Self-Check Checklist

Seven questions, each corresponding to a real-world scenario for FDE. If you answer "yes" to five or more, seriously consider FDE; if three or fewer, proceed with caution.

Would you be willing to shift 50% of your daily time from coding to client meetings, replying to messages, and phone calls?

2. When a customer tells you, "This doesn't work, but I can't explain why," is your first reaction curiosity or impatience?

3. No one has given you a PRD—can you work with Claude Code to build a working prototype that you can show to clients within a week?

4. For the same delivery, the client requested eight revisions—can you still maintain your judgment rather than mechanically following instructions?

5. When the model gives an incorrect answer, is your first reaction to design a fallback, or to complain that the model is inadequate?

6. Are you willing to sign contracts, write reports, handle client acceptance, and coordinate with legal on compliance terms?

7. Can you embrace rapid prototyping and rapid failure?

Five traits, four counter-personas, seven self-assessment questions—all ultimately point to the same question: Are you willing to refine your product sense, engineering strength, and business judgment simultaneously within a single workflow?

In my previous article, I discussed the "human engine"—curiosity, exploratory spirit, self-learning ability, self-motivation, and hands-on skills—and how they can be fully activated within large corporations. This article addresses another topic: the evolution of job roles. FDE is the first new job role in the AI industrial revolution to have a defined name, a salary range, a formal job description, and validation through customer payments. It is not synonymous with the concept of a "super individual," but rather the first concrete milestone to emerge from this wave of transformation.

FDE is not the end. My view is that FDE is merely the first form to emerge with a name within this new division of labor. Soon, we’ll see Forward Deployed PMs, Forward Deployed Designers, Forward Deployed Researchers—all roles deeply coupled with customer contexts, requiring teams to grow products in ambiguous spaces—to develop their own “forward deployed” variants. The job titles may change, but the underlying logic remains the same: model capabilities lead the way, product forms follow closely behind, and job structures are redefined according to the workflow.

Leave one sentence for each of the three types of readers.

For engineers: FDE doesn’t require you to be the best coder in the company, but it does require you to be willing to shift half your time from code to customers. If your answer is “yes,” the market window has just opened—top domestic model companies, cloud providers, and internal AI teams at large enterprises are accelerating their hiring. If your answer is “no,” that’s perfectly fine—new roles will emerge within this evolving division for you too.

To HR and OD: Be wary of “discrepancy between title and reality.” Your company may already have a group of FDEs working under titles like “Solution Specialist,” “Industry Architect,” or “AI Application Engineer.” Identify them, reclassify them, and provide a career path that aligns with their actual responsibilities—this is more efficient than hiring new talent from scratch.

To managers: The FDE model isn’t just for external use—it can also be applied internally. Instead of creating a new AI department and holding ten cross-team alignment meetings, consider placing a few “internal FDEs” directly within business teams to end-to-end integrate model capabilities into business workflows. Departmental silos aren’t broken down by organizational design—they’re dissolved by a working demo.

The career transformation in the AI era has already begun, and FDE is the first signal flare, telling us that the pace of model capability evolution has accelerated to the point of creating entirely new roles. The author leaves readers with a specific question—If three new positions appear on your company’s organizational chart three years from now, what do you think they’ll be? Figuring out this question is more valuable than reading this article itself.

👦🏻 Author: Henry (DeerFlow Team) [1]