Back to Writing
Translated from Chinese by AI~15 min read

The Million-a-Year FDE May Not Have to Be a Person

Emergent prompted me to unpack three layers of FDE work and consider which could become AI products. It also made me rethink how a one-person business might serve enterprise customers.

When I wrote my Emergent case study a couple of days ago, there was another question hiding in it. I wonder how many readers had that question in the back of their minds too.

I did not pursue it then. It would have taken the piece off track and interrupted the flow, and I felt it was valuable enough to deserve a discussion of its own.

(If you are interested, you can read Behind $100 Million in ARR in Eight Months: How Emergent Uses a Consumer Approach to Win the Business Market first, then come back. You may get more out of this piece that way.)

That article was about how Emergent used a consumer approach to take a slice of the business market.

At its core, it uses a consumer-style product experience to enter the business market with as little friction as possible. Customers build their own business assets on the platform, and their companies gradually get drawn in deeper. The more a company uses it, the more Emergent gains. That is how it sustains growth.

It breaks with the traditional B2B software business model and reshapes the value chain: the individual becomes the entry point, the business supplies the use case, and the company becomes the ultimate beneficiary.

So far, an inspiring story.

But once you understand Emergent's product and business model, might you want to ask a sharper question?

If products evolve in the direction Emergent points toward, could the success of companies like Emergent make the FDE role disappear altogether?

In theory, if it succeeds, that proves this role is not actually needed. The best person to build the application is already inside the company: the person who understands its business best. All you need to give them are tools good enough to build with. Isn't that exactly what Emergent's customers are already doing?

If so, might the FDE—currently the hottest role in enterprise AI deployment—be less necessary than it seems?

Yet on the other side of this, FDE is one of the most expensive and hardest-to-fill jobs today. A million a year, and demand still outstrips supply.

In May this year, OpenAI set up a dedicated Deployment Company and acquired Tomoro, bringing in around 150 FDEs from the outset and securing more than $4 billion in initial investment.

Anthropic is also working with DXC to train Claude-certified FDEs at scale and deploy them across regulated industries such as banking, aviation, insurance, and manufacturing.

The leading model companies all have their eyes on enterprise customers. A view is increasingly taking hold in the industry: winning those customers may depend less on whose model is slightly stronger than on whose FDE moat is deeper and who can put people on the ground faster.

On one side is a scarce role hyped to the skies. On the other is the question I just raised: this role may be getting dismantled, little by little, by the very people it serves and by the evolution of AI products.

I think that tension is worth exploring.

The FDE is the person between the enterprise and AI

First, what does an FDE actually do?

FDE stands for Forward Deployed Engineer. The title sounds like engineering, but the work goes far beyond writing code.

OpenAI's official definition covers working with a customer's engineering and business teams throughout the process: discovering needs, defining the technical scope, designing the system, building it, and launching it into production.

Fundamentally, FDEs exist today because there is a huge gap inside companies:

Business domain knowledge is disconnected from AI capabilities and software engineering skills.

On the business side, people know what they want, but they cannot build agents, write workflows, connect APIs, or design data structures—let alone deploy, test, and evaluate the result.

On the AI side, engineers understand the technology, but often do not know how bank approvals actually work, where hospital care processes get stuck, or which step in an insurance claim wastes the most time.

An FDE bridges a gap between business teams and technical teams, translating business needs into working systems
Diagram in English: business teams bring domain knowledge, experience, and real problems, but lack the skills to build agents, workflows, APIs, data structures, and deployment or evaluation systems. Engineers bring technical skills and implementation experience, but may not know the actual workflow, pain points, valuable data, or success criteria. The FDE connects them through business understanding, AI and engineering skills, product judgment, customer communication, and delivery—turning business language into technical solutions, and technical capability into business value.

So today, we need a rare kind of person in the middle to connect the two: someone who understands both business and technology, can make product judgments, communicate with customers, and deliver.

FDE = translator between business and technology + builder

Why, then, are FDEs so expensive and hard to hire?

Because you are effectively asking one person to combine:

Business understanding + product judgment + software engineering + AI knowledge + customer communication + delivery skills.

Of course people like that are scarce.

Emergent raises a dangerous question

But products like Emergent raise a dangerous question.

Suppose a domain expert can simply say: “This is how our company's sales process works...”

The AI then asks:

“Which step needs approval?
Which system does the data come from?
When should finance be notified?
Who has final authority? ...”

Once the domain expert has answered, the AI designs the system, builds the database, writes the code, connects APIs, tests, deploys, and makes changes.

Why must there still be an FDE in the middle?

The old chain was: a domain expert explains the requirements to an FDE, who then delivers an application through code.

The future might be: a domain expert tells an AI builder what they need, and out comes the application.

The FDE gets bypassed in the value chain.

Before: domain expert to FDE to AI or code to application. Possible future: domain expert to AI builder to application
Before: domain expert → FDE → AI / code → application. Possible future: domain expert → AI builder → application, bypassing the FDE step.

Emergent's significance goes well beyond “people who cannot code can build apps.” From an enterprise AI perspective, it also suggests something else:

The work of translating business needs into software could itself become an AI product.

If that happens, the impact will be enormous.

But I do not think FDEs will disappear

Although that seems like a very logical progression, I lean toward the view that the FDE role will not disappear. It may be broken apart, but it will not vanish.

So far, we have reduced the FDE's work to understanding the business and writing applications.

In practice, the work of a top FDE can be much more complex.

For a large company, the hardest question is usually not: how do we write this app?

It is:

Should this app be built at all?
Which workflow should change?
Which data can we give the model?
Which data must we keep out?
How do we connect the old ERP?
How do we integrate with some data or system from twenty years ago?
How should permissions work?
Who is responsible when the model gets something wrong?
How do we evaluate it?
How do we meet regulatory requirements?
How do we get tens of thousands of employees to actually use it?
How do we demonstrate ROI?

Or even:

Is this workflow itself wrong? Should we redesign the whole thing?

OpenAI's own description of FDE work now extends beyond building applications. It includes helping enterprises redesign critical processes and infrastructure, connecting models to the customer's data, tools, control systems, and business processes.

That is a different level of difficulty from “generate a CRM for me.”

FDE work can be broken into at least three layers

Layer one: application builder.

Turning business requirements into apps, workflows, agents, dashboards, and automation systems.

This is the layer most at risk.

Emergent, Claude Code, Codex, and all kinds of agent-building tools are moving into this layer.

Domain experts will probably be able to do this themselves in the future. I think demand for FDE labor at this layer will fall sharply.

Layer two: translator between business and technology.

Finding the real problem, deciding what should and should not be automated, and defining what a successful outcome would look like.

This layer is interesting.

The FDE used to be the translator: business staff → FDE → engineering system

In the future, it may well become: business staff → AI

But only if the AI is good enough at asking questions.

In other words, Emergent's most sophisticated future capability might not be coding at all.

It might be asking the right questions to draw out the tacit business knowledge inside a domain expert's head.

That is a very large product opportunity.

If AI can keep asking questions like a great FDE:

Why do it this way?
Who is responsible?
What are the exceptions?
What does success look like?
Where does this data come from?
When things conflict, who takes priority?

Then the FDE's second layer of value will also start to erode.

Layer three: enterprise transformation architect.

This is the hardest layer to displace in the near term: organization + systems + data + security + governance + change management.

Many of these problems are less about whether AI knows the answer than about who inside the company has the authority to make the call.

Take a bank.

The model can tell you, “This process could be redesigned.”

But does the risk team agree? What about legal? Security? IT? The business owner? The regulator? The legacy system provider? ...

This is no longer purely a software problem. It is an organizational coordination problem.

I think experienced consultants who have done deep enterprise work will recognize this.

That is why both leading model companies set up new enterprise AI service companies this year to help medium-sized and large businesses with customized deployments.

Once we separate these three layers, the conclusion becomes clearer: FDEs will not disappear; their work will be broken apart or turned into AI products.

The part that translates business needs into applications will be heavily compressed. The part that drives enterprise change across systems, organizations, and governance boundaries will remain for quite some time.

The near-term reality and the longer-term projection can both hold—

Today, FDEs are in extremely short supply and demand is surging. In the future, the stronger AI builders become, the more likely the lower layers of FDE work are to become products.

There is no contradiction.

An FDE does not have to be a “person”

At this point, we can return to the opening question with a somewhat more precise answer:

Emergent will not “eliminate” the FDE. But it may show that an FDE does not necessarily need to be a person.

At its core, FDE is a function.

Today, an exceptionally capable person carries that function: understand the business → clarify requirements → design a solution → build the system → test → deploy.

In the future, that function may become the AI builder itself. The person who understands the business best would then work with it directly.

In the ideal situation, then, domain experts do not replace FDEs; they become—or already are—the FDEs.

They have not suddenly learned software engineering. AI has supplied the software engineering capabilities they lacked. Domain expert + AI = today's FDE.

There are already signs of this shift. Inside Anthropic, people have observed many employees in nontechnical roles using Claude to acquire software capabilities outside their original skill sets, gradually crossing their old professional boundaries.

That is why I even think we could see FDE as a transitional profession.

Many technological revolutions create a particular kind of job in their early stages: someone who translates the new technology for the old world.

Today's enterprises are still organized around traditional software. Agents suddenly arrive, and an FDE is needed to fit them in.

But suppose that ten years from now, enterprises are AI-native. Domain experts already work with agents every day, software is generated dynamically as business needs change, and data and permissions are designed for agents from the outset. The term “Forward Deployed Engineer” would sound rather odd. If AI is already deployed everywhere, what is left to forward-deploy?

A divided market will determine who still needs FDEs

Following this logic, the future market will probably split into three tiers.

MarketLikely future setup
Small businesses / startupsDomain expert + AI builder, with almost no need for an external FDE
Medium-sized companiesInternal domain experts + a small number of AI / platform specialists
Large, complex / regulated enterprisesA small number of highly capable FDEs / enterprise transformation architects remain needed over the long term

Small businesses / startups

They cannot afford to keep a “translator” on staff.

Their reality:

  1. The owner is the person who understands the business best
  2. One person + AI can turn an idea directly into an application
  3. An external FDE is too expensive, too cumbersome, and too slow

So the future setup is:

Domain expert + AI builder, combined in one person or a team of two or three. There is almost no room left for an external FDE.

The core issue is not technical difficulty. It is this:

The business simply does not need a middle layer to translate itself.

Medium-sized companies

They have business complexity, but not enough to justify maintaining a large delivery team.

What they need more is:

  1. People inside the company who understand the business stepping forward
  2. A small number of AI or platform specialists alongside them
  3. Building the capability in-house, rather than depending on external teams stationed there indefinitely

So the future setup is: internal domain experts + a small number of AI / platform specialists.

The FDE is not “eliminated.” Instead, the role is:

Broken apart, internalized, and absorbed into the organization's own capabilities.

Large, complex / heavily regulated enterprises

This is the FDE's last stronghold, and the hardest layer to replace.

The problem here has never been just “build an app.” It also involves:

  1. Old systems tightly entangled with one another
  2. Sensitive data and complex permissions
  3. Security, compliance, and auditing—all essential
  4. Organizational processes affected by every change

In this environment, knowing how to write an agent is not enough. Neither is understanding the business alone.

So the future setup is: a small number of highly capable FDEs and enterprise transformation architects will remain for a long time.

Their value is no longer “translating requirements.” It is:

Designing system-level solutions that can actually be implemented under tight constraints, and driving real organizational change.

To put it in one sentence:

Small businesses do not need an intermediary. Medium-sized companies absorb the intermediary. Large, complex enterprises can afford—and cannot do without—the most capable intermediaries.

So FDEs do not go to zero; the role splits. Of 100 projects that need an FDE today, perhaps 80 will be handled by domain experts and AI themselves in the future. The 20 most complex will go to more advanced FDEs.

The number of FDEs may not grow indefinitely, but each FDE will cover more companies and business areas, with their skills increasingly centered on judgment and architecture.

What this makes me think about my own work

I spent more than ten years in B2B work—business development, marketing, sales, solutions, and product—dealing with enterprise customers all along. Later, when I wanted to build a one-person business, what worried me most was the weight of B2B: long chains, slow decisions, heavy delivery commitments, and the need to coordinate with a whole group of people. It consumes an enormous amount of energy.

The FDE role is a miniature version of the heaviest kind of B2B delivery: one person doing the work of a project team, deeply tied to the customer. High income, but not a model you can easily replicate.

So when I saw Emergent, I saw more than an app-building tool. I saw another path.

One path is to become an FDE and do the AI work for enterprises yourself. It can make money, but for a small team, it will almost inevitably wear you down.

The other is to build a product that lets the person who knows the business best become the FDE.

I find that second path especially worth exploring. It is neither AI consulting nor custom development. It turns an understanding of B2B situations into a set of tools that domain experts can use to solve their own problems.

Put simply: instead of doing the work for business customers yourself, give them a tool simple enough for the person who knows the business best to do it themselves. That is one lesson I take from Emergent.

So, back to the question we started with: will AI do away with FDEs?

There is no standard answer here, but we can begin to form a judgment:

FDE is shifting from a scarce person to a function that can be put into other people's hands. The best future FDE may well be the company's own domain expert, working with a sufficiently capable AI.

That could even be an AI startup idea in its own right.