0to1 .site
The FDE Handbook Chapter 3 Part One · Role and Boundaries 6 min read

Is FDE Just Outsourcing in a New Coat, or a Passing Trend?

📌 Summary

One FDE consultant admitted it outright: "FDE is old wine in a new bottle." He breaks the business d…

The thing that hath been, it is that which shall be; and that which is done is that which shall be done: and there is no new thing under the sun. — Ecclesiastes 1:9

One FDE consultant admitted it outright: "FDE is old wine in a new bottle." He breaks the business down into "a technical consultant plus an on-site SaaS engineer" — "some of the hype is real, some of it isn't."1

Coming from a practitioner, that might seem to settle the chapter right there. But it's only half right. This chapter draws the specific line: which symptoms are just hype, and which underlying need won't disappear once the buzz fades. Meeting the skepticism head-on is the only way to get the question straight.

I. Four Layers: What's Left When the Project Ends

Judging whether a team is really doing FDE work doesn't start with the job title. Start with what's left after the project ends2. This breaks into four layers:

  • Nothing but a system left with the customer: that's outsourcing. Once the system ships, the relationship ends.
  • Some experience carried back, but not reusable next time: that's project-based delivery. The experience becomes closing documentation, useful reference material for the next pitch.
  • Experience turned into a Skill, a template, or a product capability: that's FDE. Field experience gets organized into something reusable.
  • That accumulation visibly lowers the cost of the next customer: that's FDE at scale. The team starts benefiting continuously from its past projects.

These four layers line up with Chapter 2's second test — where the experience goes — but push one question further: once the experience is back, does it actually make the next customer faster? Chapter 21 covers how customization declines; Chapter 22 covers how experience gets back into the product. Neither gets unpacked here (see Figure 3-1).

Judging FDE isn't about whether someone was on-site — it's about which layers of capability survive after the project ends

Figure 3-1: Judging FDE isn't about whether someone was on-site — it's about which layers of capability survive after the project ends.

On developer forums, the "is FDE just consulting in a new coat" debate keeps resurfacing. One practitioner put it more sharply: a lot of "FDE training" amounts to "selling the information gap around AI to anxious small-business owners with money to spend"3.

Practitioners admit there's an old side to it, while the media and training market keep repackaging it as something new. So where, exactly, is the bubble?

II. Three Concrete Symptoms of Hype

Separating out the common patterns, the hype shows up in three concrete ways:

First, title inflation. Renaming an existing implementation or presales role to FDE is the easiest way to chase the trend. The most common version: repackaging "can write code with an AI coding tool" as FDE. One user on a Chinese developer forum put it this way: "Vibe-coding in Claude Code doesn't make you an FDE by itself — that just solves the development problem."4

Second, the training grift. Courses sell jargon and tool mechanics to anxious career-switchers, pitched as "switch now or it's too late." This isn't unique to FDE — any hot new title attracts this kind of training. What makes FDE different is that its core is real delivery accountability, and that can't be learned from a course alone — it has to be built in real situations (Chapter 25 unpacks this).

Third, organizational drag. Some companies create the role to follow the trend, without building a feedback mechanism or measuring by results. FDE ends up as nothing more than expensive on-site labor. This is exactly the situation practitioners describe as "an expensive professional services organization hiding inside a software company"5.

All three share one thing: they land at the weak end of all three tests from Chapter 2 — no production code, no feedback loop, billed by the day. The hype isn't in the word "FDE." It's in how people use it.

III. The Real Half

Now the other half. Telling a bubble apart from a durable need can't rest on how much buzz there is — it has to rest on whether the conditions underneath will disappear.

"Prompt Engineer" makes a useful contrast. After ChatGPT drove generative AI into the mainstream, the title ran hot, then cooled fast. The reason: prompting techniques depended on whatever the model happened to be weak at that moment. Every generation the model improved, a chunk of those techniques lost their value. Prompt engineering was a skill the tools themselves were bound to erode.

FDE isn't facing a skill that can be mastered in isolation — it's facing an ongoing relationship: the customer has a real production environment, and a vendor has to deliver a system into it. In that relationship, someone always has to own connecting the system, keeping it running, and keeping the customer actually using it. A stronger model doesn't automatically sort out the customer's permissions, workflows, and internal politics. The deeper an agent reaches into the business, the more complicated system integration can get, not less6.

There's financial evidence too. An engineer who spent years at Palantir recalled that the company's 2023 gross margin ran around 80%, versus roughly 32% for a traditional consulting giant like Accenture7. If FDE were just relabeled on-site outsourcing, its profit structure should look like a consulting firm's. Instead it looks more like a software company's. Where does the difference come from? From field experience being repeatedly folded back into the product — exactly the fourth layer above. Chapter 22 explains the mechanism behind it.

IV. Conclusion: Half Right, Half Wrong

This chapter's conclusion splits into two halves, each holding on its own:

  • The need is real. Getting AI safely into a customer's production environment is a durable need. Production environments are complex, and trust between organizations has to be built — neither condition disappears anytime soon.
  • The role won't always be called FDE. FDE, an upskilled consulting team, or a customer's own internal team can all end up carrying this work. The market will change titles, and the buzz will fade. The problem stays.

How long the concept itself stays fashionable, which parts of the work AI ends up replacing, and whether the title itself eventually disappears — those questions belong to Chapters 5 and 28.

One question about timing is still left standing: if this isn't a passing trend, why did it blow up specifically in 2026? Chapter 4 lays out what happened in the first half of that year.


Footnotes

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

  2. Tencent Research Institute, "FDE Model: Industry Observations and Practice"; Si Erxun, "The FDE Delivery Paradigm Revolution"

  3. "Anyone Out There Actually Doing FDE Work?" (linux.do thread)

  4. linux.do thread, post #2580046

  5. @deployengineer (Bhaulik Patel), essay series

  6. a16z, Box CEO on AI agents and why enterprises can't keep up

  7. "Reflections on Palantir" (Nabeel Qureshi)