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 firm Tomoro, with approximately 150 engineers and deployment experts set to join. The new company has secured 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 the end of August, Mingluo Technology disclosed in its mid-term performance report that about 30% of its delivery personnel had transformed into Full-Stack Developers and Engineers (FDE), and it would drive the transformation of PuLiang Software's FDE model; China COSCO Shipping is preparing to cultivate its own FDE, while Ruitong Hummer, Kingdee, and Zhiyuan Interactive have incorporated FDE into their product delivery systems.
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 become widely popular 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 constitutes a new profession is, in the end, beside the point. What enterprises are actually betting on is something else: whether on-site delivery, which has long depended on individual experience, can be transformed into a software capability that can be continuously reused.
Capital markets don't buy job 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 margins on 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-making system ELF. It checks around 3,000 orders daily, providing approximately 400 adjustment suggestions, with over 70% being 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 suggestions 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 is only writing one-time code at the client's site, with the next delivery starting from scratch, 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 a single customer's experience get incorporated into the standard product. Without the last point, 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 with just 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 approvals. 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 Zhivi and Kingdee launched a unified intelligent platform project, starting with the review 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, and establish 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, what really needs to be written into the system are 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 answer the question of why companies are willing to let them see it. External teams may have access to cost structures, customer relationships, and unpublished operating rules, and non-disclosure agreements cannot completely eliminate the risk of knowledge spillover. On the other hand, if companies only provide layered and filtered materials, FDE may get stuck in the demonstration stage, resulting in an application that looks smart but is actually unable to take over business operations.
The DeepFDE project must first address the issue of trust. Mature enterprises must retain internal data officers, business officers, and security teams. External FDEs 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 cultivating FDE talent 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 have a deeper understanding of which data interfaces cannot be mixed, which approval processes cannot be bypassed, and why certain seemingly inefficient processes have been retained.
Internal and external FDEs will cooperate and also compete. New models and the first batch of high-risk scenarios require external experience; after scenarios enter daily operations, internal teams must take over authority, evaluation, and modification capabilities. Suppliers are reluctant to hand over, and customers worry about being locked in; enterprises that bring all work back in-house may also lose cross-project technical vision.
To determine whether a partnership is healthy, one unconventional indicator can be observed: whether the external manpower required for subsequent projects decreases. If the first system requires ten on-site personnel, 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, and it is merely a project-based business that charges by man-days.
The Best FDE Projects Should Allow for FDE Exit
External full-stack developers 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 low-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 Environment (FDE) project can be considered truly completed based on three outcomes: the system remains in use after external engineers have left, the internal team is able to make independent modifications, and the supplier does not have to start from scratch when serving the next client.
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.