Recently, FDE has suddenly become a popular abbreviation in the AI industry.
In May, OpenAI announced the establishment of a company dedicated to helping enterprises deploy AI and plans to acquire AI consulting company Tomoro, with approximately 150 engineers and deployment experts set to join. The new company has received over $4 billion in initial investment, with participants including McKinsey, Bain, and Capgemini. Following OpenAI's announcement, domestic cloud computing, ERP, and software service enterprises have also been actively discussing FDE.
By late August, MiningLamp Technology disclosed in its interim results that roughly 30% of its delivery staff had transitioned to FDE roles, with plans to push Pulian Software toward the same model. COSCO Shipping Holdings is preparing to develop its own FDEs, while iSoftStone, Kingdee, and Seeyon have all embedded FDE into their product delivery frameworks.
Opening recruitment software reveals that companies such as Alibaba, ByteDance, Ant Group, Minimax, and SenseTime have all posted job openings for Frontend Developers (FDE) to attract top talent.
A concept that has existed at Palantir for over 20 years, why did it only gain widespread popularity with the emergence of large models?
This position is often translated as "Frontline Deployment Engineer" or "Frontier Deployment Engineer". The name may be new, but the work scenario is familiar: entering the customer's site, understanding their needs, accessing data, modifying the system, and then accompanying the customer to get the project up and running. Management consultants, solution architects, and on-site developers have also done similar work in the past.
Whether FDE is a new profession or not is not that important. What matters to companies is whether they can transform on-site delivery that relies on individual experience into reusable software capabilities.
Capital Markets Buy Into Roles, Not Titles
Palantir views FDE as a product development methodology, where engineers get close to the problems customers are dealing with and then bring findings from the field back to the core development team, a process the company describes as "human backpropagation" in software development. According to Palantir's official documentation, this approach has been in place since the company's early days.
In recent years, as Palantir's valuation has risen, outsiders have begun to reinterpret the company's growth using FDE. What FDE can explain is why a software company that requires engineers to be deeply embedded with customers can still maintain high profit margins in its software business.
General Mills' supply chain project provides an example. The food company connects 4,000 suppliers and more than 200 factories in North America, handling around 1.2 million orders annually. According to a client case study released by Palantir, the two parties accessed 200 master data and operational data tables to establish the supply chain decision system ELF. It checks around 3,000 orders daily, providing approximately 400 adjustment suggestions, with over 70% accepted by staff; General Mills claims the system saves around $40,000 daily.
The system must simultaneously understand orders, transportation capacity, production capacity, costs, and business constraints, as well as know what recommendations can be executed and what decisions must be left to humans. Consultants can propose optimization directions, traditional implementation engineers can connect databases, while FDE needs to turn ambiguous problems into production systems and then use adoption rates and business metrics to determine the system's effectiveness.
There are no clear-cut divisions between the three types of positions, with the main difference lying in the endpoint of their responsibilities. Consultants typically deliver advice, on-site engineers are responsible for the launch and maintenance of agreed-upon projects, while FDEs also need to take site issues back to the supplier's core products. If one only writes one-time code at the client's site and starts from scratch for the next delivery, this work is still considered customized development.
Domestic Companies Bet on Delivery Efficiency
The differences in strategies employed by domestic players are also quite apparent.
Mingluo Technology is attempting to transform its existing delivery teams. Approximately 30% of the company's delivery personnel were converted into FDEs in the first half of the year, and it plans to drive the transformation of the PuLian software team into FDEs focused on central state-owned enterprises. In the past, project experience was retained by consultants or implementation personnel; now, the company is trying to codify this experience into Skills and Agents, reducing the reliance on individuals for future deliveries.
Ruitong Power proposes "AI Factory+ industry experience+FDE", which covers everything from consulting, model deployment, and intelligent body development to continuous operation. Zhiyuan Interactive, on the other hand, defines FDE as deeply entering the site to complete data governance and customized function development, and then feeding back business pain points to internal teams. The former comes from a large IT service provider, while the latter comes from a collaborative management software manufacturer, both of which aim to add a product feedback loop to traditional delivery.
This also hints at a risk: FDE is becoming a broad business label. Anyone can rename their pre-sales, implementation, and outsourcing teams to FDE. To determine if it's a new model, consider asking three questions: Do engineers write production code, are they responsible for actual adoption, and does the experience of individual customers go into standard products? Without the last item, even the most luxurious job title cannot change the project-based business.
Companies Refuse to Hand Over Master Keys
The closer FDE is to real business, the harder it is to avoid permission contradictions.
Engineers can quickly create prototypes based on a sanitized order form, but to get the system involved in daily production and shipping adjustments, they also need to understand supplier tiers, customer priorities, breach costs, and exceptional approval processes. The most valuable information often lies not in the database, but in the habits of business personnel handling exceptions.
A similar scenario has already emerged domestically. In August 2026, Yangguang Zhineng and Kingdee launched a unified intelligent platform project, starting with the audit of contracts, invoices, and bidding documents. According to Kingdee's disclosed plan, an external team will enter the scene to sort out audit rules, samples, and knowledge, establishing an "AI preliminary review, human re-examination" process. Although there are no publicly available results to prove that efficiency has been improved, it demonstrates the content that FDE needs to access: invoices are just the surface level, while the real goal is to write into the system the redline clauses, approval responsibilities, and historical judgments.
Companies should not open up their entire system just because the other party is called FDE. External teams only need the minimum information required to complete specific tasks: development and production environments should be isolated, sensitive fields should be classified, accounts should be authorized by project, code merges should be approved internally, operations should be logged, and permissions should be revoked after the project is completed.
Technology can only restrict what members can see, but it cannot address the issue of why companies are willing to let them see it. External teams may have access to cost structures, customer relationships, and undisclosed operating rules, and non-disclosure agreements cannot completely eliminate the risk of knowledge spillover. On the other hand, if companies only provide heavily filtered materials, FDE may get stuck in the demonstration stage, resulting in the creation of an application that looks smart but is actually unable to take over business operations.
The in-depth FDE project must first address the issue of trust. Mature enterprises must retain internal data owners, business owners, and security teams. External FDE can only enter authorized areas, and the decision to open which doors, how to interpret business rules, and whether the system can go online remains with the enterprise internally.
Internal FDE vs External FDE: Which Will Remain
The client is also building its own FDE team. In addition to the numerous job postings for internal FDE teams at major companies mentioned earlier, China COSCO Shipping stated that it will focus on FDE talent development to build an internal AI research and development team that combines business and technology. For large enterprises with complex shipping networks, this choice is not hard to understand. External engineers may be familiar with models and platforms, but internal personnel are more aware of which data interfaces cannot be mixed, which approval processes cannot be bypassed, and why a seemingly inefficient process has been retained.
Internal and external FDEs will both cooperate and compete. New models and the first batch of high-risk scenarios require external experience; once scenarios move into day-to-day operations, internal teams must take over control, evaluation, and modification capabilities. When vendors are reluctant to hand over these responsibilities, customers worry about being locked in; but if companies pull all work in-house, they risk losing the cross-project technical perspective.
To determine whether a partnership is healthy, one unconventional indicator can be observed: whether the external manpower required for subsequent projects is decreasing. If the first system requires ten people to be stationed on site, the second system still starts from data cleaning, and the third system still relies on the same batch of people to put out fires, then FDE has not formed software leverage, but is only doing project business based on man-days.
The Best FDE Projects Should Allow FDE to Exit
External FDEs have seen more models fail and have a better understanding of what capabilities products may acquire next. This perspective can help companies avoid doing a few demonstration projects that have no production value. However, they cannot make decisions for companies on which errors are acceptable, which departments should relinquish power, and who should be responsible after automation fails. AI transformation involves adjustments to budgets, responsibilities, and benefits, and code can only handle part of it.
We believe that external FDEs will exist in the long term because models and tools are still evolving. However, in a specific business, FDEs should not become permanent positions. After a project matures, daily operations should return to the internal team, common demands should be incorporated into standard products, and lower-level data conversion and fault diagnosis will gradually be taken over by AI. Palantir has launched an "AI FDE" that can operate Foundry, manage code repositories, and modify data conversions, and the work of human FDEs will shift more towards business judgment, permission coordination, and exception handling.
A Foreign Development Team (FDE) project can be considered truly completed when it meets three key outcomes: the system remains in use after the external engineers have left, the internal team is able to make independent modifications, and the vendor can service the next client without having to start from scratch.
If on-site teams are getting larger, cooperation periods are getting longer, and clients cannot operate without these people, then the AI industry is just giving traditional outsourcing a more expensive name.