What Is the Endgame for FDE?

The gentleman is not an implement. — Confucius, The Analects, "Wei Zheng"

Look back five years from now, and part of any FDE's working inventory will already be worthless: fluency in a particular framework, the feel of a particular prompting style, the click-paths of a particular product. Tools update too fast — yesterday's new technology is tomorrow's default feature.

But some things don't expire with the version: knowing what to evaluate, how to design acceptance, who should be accountable for the result; knowing that a solution that runs in a demo and a solution that survives on the customer's site are two different things.

Perhaps by then the title "FDE" itself will have become uncommon — folded into product, engineering, industry solutions, or delivery teams, renamed to whatever sounds more fashionable.

But when a customer's system breaks, someone will still have to answer: can this solution actually reach the result — and if it can't, who is accountable?

So whether the profession disappears isn't the first endgame question. Ask two things first: will the experience you accumulate today still be worth anything in five years? And who will be carrying, by then, the responsibility for hauling new technology to a production result? This chapter answers both on three levels — the individual, the role, and the industry.

I. The Individual Level: A Balance Sheet for Experience

The most personal question first: is the experience this line of work builds up worth anything five years from now? Sort what the job gives you into three columns.

Depreciating: tricks for using a specific framework, the feel of a prompting style, the operational details of a particular product — tool-layer experience depreciates fastest. Every round of iteration in models, tools, and workflows revalues this column.

Holding value: evaluation method, acceptance design, accountability management, organizational drive — the meta-capability layer, compounding across industries, and appreciating as cases accumulate.

Appreciating: industry depth plus reusable assets — connectors, templates, eval sets. What makes this column special is that it can be traded: it can travel with the person and become your market price, or stay inside the organization and become part of the platform and your bargaining power.

The career advice in one line: rebalance the depreciating column into the holding-value column on a schedule. Whenever you notice yourself getting fluent in something about to become obsolete, ask one question: what method underneath it should I be extracting? Rebalance diligently, and your shelf life extends indefinitely.

II. Three Paths, and Each One's Bar

These assets won't stay on a résumé. As experience deepens, they carry a person toward three different positions: turning delivery experience into team capability, into product capability, or into a company's capacity for sustained delivery.

The management path: turning experience into team capability. Moving from delivery lead toward bigger management roles, the real turn isn't carrying more projects — it's going from "carrying the result myself" to "building a mechanism that keeps carrying the result." Whether you can grow people, assign responsibility, and handle conflict sets the ceiling of this path.

The product path: turning experience into product capability. Problems that recur in the field, eval structures, and delivery templates can all be deposited into the platform. Retool's FDE team has incubated more than a dozen startups — proof that front-line experience can be the starting point for products and companies.¹ The bar on this path is recognizing what's worth standardizing, and being willing to shift from solving one customer's problem to solving a class of customers' problems.

The startup path: turning experience into a capacity for sustained delivery. The hard part of a vertical studio or a product startup isn't landing the first deal — it's organizing acquisition, solutioning, delivery, support, and productization into a system that can run over and over. This capability is especially scarce while an industry's AI demand is just moving from novelty to real budgets: too early, and you have to educate the market; too late, and the advantage gets swallowed by homogenization.

This is also why end-to-end field experience becomes a training ground for founders: it forces a person to understand, at the same time, why the customer pays, how the solution lands, and who carries the result after delivery.

Nabeel Qureshi, a former Palantir employee, observed that although Google has roughly 50 times Palantir's headcount, the number of companies founded by ex-Palantir employees in each YC batch is usually larger.² The comparison can't separate the training effect from the self-selection of the people involved, but it points at something: people used to carrying things from start to finish in the field find it easier to see problems and businesses that can stand on their own.

III. The Title Changes, the Responsibility Stays

On this there is no consensus — two front-line practitioners give opposite predictions. Jove Zhong (Cresta) believes FDE will remain the backbone for a long time: "when a company has good salespeople, sales is very hard to replace either"; the FDE belongs to the category of "very grounded people with engineering capability who can also use AI well," and that part is hard to hand to AI. Vincent Lu (Ventus AI) believes FDE will drift increasingly toward customer success: "the technical bar keeps getting lower, so how do you out-compete other companies? By providing emotional value, better service, a better understanding of what's needed."³ Both predictions come from people in the field, and they point in two directions — which is exactly this chapter's opening stance confirmed: the answer to the endgame shouldn't be prophecy; what to watch are signals reality can check (see Figure 28-1).

Figure 28-1: The title may change; the responsibility for getting real problems into production and feeding assets back does not disappear.

Will the FDE title still exist in five years? Maybe not. But that doesn't mean this kind of work disappears — it means the work is being redistributed.

Part of the execution gets taken by AI and platforms. Palantir has written deployment, configuration, and troubleshooting into the AI FDE's product capabilities; that's a product claim, but it points clearly in one direction: repetitive, standard execution will depend less and less on being done by hand.⁴

Another part gets taken by productization. When one kind of problem keeps recurring and the solution gradually stabilizes, it moves from being delivered on-site, time after time, to being a default capability on the platform.

Once both ends have absorbed their share, what's left in the middle? Judgment and guarantee — the judgment of "will this solution work in this customer's production environment," and the guarantee of "if it works, I own it; if it doesn't, I backstop it." The eternal need in B2B procurement isn't code — it's risk transfer: what the customer buys has always been "someone to carry this new technology to a result on my behalf." That core doesn't get absorbed — AI can substitute for execution, but it cannot take on the customer's accountability for the result.

IV. The Stronger the Technology, the More the Front Line Persists

Widen the view to the whole industry: between model companies, application companies, and enterprise customers sits the same gap — the capability arriving upstream runs ahead, and the part actually usable downstream lags behind. Filling that gap takes putting new capability into concrete workflows, permissions, and organizations; this is not a defect waiting to be eliminated — it's commercial space that keeps reappearing.

One Chinese practitioner sees the drag of old processes: bosses readily overestimate the side of AI that can do anything, and underestimate the side that gets trapped by existing institutions and ways of working together. He expects the market to converge in the end on two forms — standardized products, or standardized services.⁵

An American practitioner sees the time lag between capability and adoption. Models upgrade generation by generation, but how fast people actually put them to use doesn't necessarily keep up; AI needs people to explore and push it forward, and needs people to absorb the friction of landing it.⁶

The two observations don't contradict. The first explains why new technology gets dragged down by old organizations; the second explains why capability, however strong, doesn't happen by itself. Model companies are like a headquarters product team, while application companies and customer sites keep turning new capability into usable things; each layer does the front-line work for the layer below.⁶

This rhythm isn't unique to AI. The economic historian Carlota Perez described how technological revolutions move from being built and validated by a few early movers to spreading at scale.⁷ The last mile between capability and adoption will persist for the long run — it just keeps moving up: today on the enterprise's front line, tomorrow inside industry processes and organizational collaboration.

V. What Three Kinds of Readers Should Do Now

The answer to the endgame shouldn't be prophecy. What follows are trackable actions and signals: if the judgment is wrong, readers will find out early.

Individuals: which column of the balance sheet to invest in — carry fewer depreciating items, accumulate more holding-value and appreciating items; run a rebalancing review once every three years.

Companies: confirm three things first — is there a clear business problem, is the business side willing to commit people, data, and time, and has one small-scale trial already been run. Until all three are in place, buy a small service first; don't rush to create the role.

Industry observers: watch three signals — how fast the automation boundary of AI-FDE-type products is expanding, whether the share of outcome-based pricing in enterprise contracts is rising, and whether the "FDE" title disappears while the function survives under another name. They will tell you how this chapter's judgments are being confirmed or falsified.

VI. To Close

The answer fits in one sentence: AI projects stall not because they can't be built, but because nobody is accountable for the last mile. The model lives in the cloud and capability keeps growing; the real difficulty sits in "can be put to use, can stay in use, and can be accounted for."

FDE is what this responsibility is called right now. The name will change — into product capability, into a platform function, into some other title; the responsibility won't — as long as what enterprises procure is still "carrying new technology to a production result," some role will always have to own it end to end. This book teaches the full technical detail of that responsibility; and you, having read this book — whether you stand in delivery, product, or organization — are already looking at the problem through that same lens.

The road is laid to here. The rest — go explore and discover it in the field.

---

Footnotes

1. @jamiecuffe's own account of the product line incubated inside Retool ↩

2. "Reflections on Palantir" (Nabeel Qureshi) ↩

3. Tencent Research Institute, AI Lens Roundtable, Episode 6: "FDE Non-Consensus Views and a Field Guide from Silicon Valley Founders" ↩

4. Palantir Foundry, "AI FDE" product documentation ↩

5. Turning Point (破局点), Episode 31: "FDE, Chinese Style" ↩

6. Y Combinator, "The FDE Playbook for AI Startups" (Bob McGrew) ↩ ↩²

7. Carlota Perez, Technological Revolutions and Financial Capital: The Dynamics of Bubbles and Golden Ages ↩