FDE: The Engineer Who Puts AI to Work

An FDE is the engineer willing to get in the trenches with the customer and turn “AI seems to work” into “the business is actually using it—and someone owns the failures.”

Over the past two years, calling a capable model and building a convincing demo has become relatively easy.

The real trouble starts afterward. Models give wrong answers. Systems lag. Knowledge bases are incomplete. Legacy systems refuse to cooperate. Business teams cannot always explain their own rules, while legal and security teams have long lists of concerns.

After listening to the “Superlinear” interview with Jove, who leads Cresta’s FDE team, I kept returning to one question: as model capability becomes easier to access, who closes the gap between a demo and a working business system?

FDE—Forward Deployed Engineer—is one answer.

Jove was leading a team of about 30 people at the time, with plans to grow it to 100. The headcount is less interesting than the reason the team exists. These engineers need to write code, understand the business, earn the customer’s trust, and ultimately take responsibility for the result.

What does an FDE actually deliver?

Imagine a hotel wants voice AI to answer customer service calls.

The owner probably does not care which model sits underneath it. They care whether the AI understands the guest, whether it makes promises it cannot keep, whether it hands the call to a person at the right moment, and whether it damages the brand.

A conventional engineer might begin with interfaces and architecture. A consultant might start with research and a proposal. A sales engineer needs to prove the product is worth buying. The FDE goes further: connecting business rules, model capability, the knowledge base, and existing systems, then watching how the whole thing performs in the real world.

The interview compares an FDE to the technical lead of a small company. That feels accurate. They decide where AI belongs and where it needs to stop. They also build the system, test it, launch it, and fix what goes wrong.

Code is only part of the job. What the FDE really delivers is a result the customer is willing to trust.

The job is a loop

Customers rarely arrive with a perfectly written requirements document. They are more likely to say, “We want to use AI too,” “Can we reduce the customer service workload?” or “Could we build an intelligent front desk?”

The FDE does not start by writing a prompt. They start by clarifying the problem: Which outcome needs to improve? Where does the current process hurt most? If the AI fails, what is the worst thing that could happen?

The work then moves through four stages.

First, get the business problem clear

Many companies do not have one agreed answer for how a business process should work. The FDE needs to find the person who can make the decision, then clarify the rules, risks, and definition of success. Sometimes the conversation reveals that the first thing to fix is not the model at all. It is the process nobody can explain consistently.

Then build the agent properly

Model choice is only the beginning. The FDE also has to deal with retrieval, tool calls, latency, permissions, human handoffs, fallbacks, testing, and evaluation. Voice adds pauses, background noise, accents, and even the rhythm of someone reading out a phone number.

These details rarely appear in a demo, but they decide whether the system can go live.

Stay accountable after launch

AI is probabilistic. One configuration will not remain correct forever. Models, prices, and interfaces change; so does the customer’s business.

The FDE watches real usage, contains the impact when something goes wrong, explains what happened, fixes it, and verifies the result again. Passing acceptance testing does not mean the work is finished.

Bring field knowledge back into the product

If every customer starts with a fresh custom build, the company eventually becomes a consultancy whose growth depends on adding more people.

A strong FDE team turns recurring problems into interfaces, templates, test sets, documentation, and platform capabilities. The next deployment gets faster, and the product keeps growing through contact with real customers.

This part matters. One foot is in the customer’s operation; the other remains in the product.

How is this different from outsourcing?

Much of the work does resemble outsourcing: go to the customer’s site, understand the requirements, write code, integrate systems, and deliver a working deployment.

The difference is not that one side uses more sophisticated technology. It is what happens to the problem after the project ends.

Traditional outsourcing usually works against a contract. The project ships, the customer accepts it, and the team wraps up. If a similar requirement appears at another customer, it can become another contract. An FDE owns two outcomes at once: whether this customer gets the business result, and whether the solution becomes part of the product so the next customer can reuse it.

That is why some companies place FDEs inside product engineering rather than customer service or project delivery.

Where a role sits in the organization slowly shapes its decisions. If the only goals are billable hours and project acceptance, endless customization becomes easy to tolerate. If the FDE also owns the product, they keep asking: Is this a one-off exception, or a missing piece of the product itself?

A new title does not automatically separate an FDE from outsourced delivery. The real dividing line is whether problems from the customer site flow back into the product, and whether each deployment reduces the amount of manual work required next time.

Why is this role so hard to hire for?

AI coding has not removed the engineering bar.

Someone without solid engineering fundamentals will struggle to judge whether AI-generated code is safe, whether the tests are sufficient, or whether the system is reliable rather than merely lucky. Knowing how to use Claude Code, Cursor, or Codex is becoming more like knowing how to use search and an editor. It is difficult to treat that skill alone as an advantage.

Technical ability is still not enough.

Customers will not hand over a core operation because the model specifications look impressive. An FDE needs to hear the concern the customer has not said aloud. They need to know when to ask another question, when to admit they do not know, and how to say no when the customer is asking for something unsafe.

In the interview, Jove describes an ideal candidate as someone with at least three years of engineering experience, hands-on work with real AI agents, an understanding of testing and evaluation, and some exposure to customers, consulting, startups, or early-stage engineering teams.

Even a failed startup may not count against them. Anyone who has lived through the distance between “we can build it” and “we made it work” usually has a better feel for how many unplanned problems appear along the way.

People who earn customer trust tend to share a few habits:

• They understand what the other person is worried about before showing what they know.
• Their technical judgment is strong, but they do not fight the customer simply to prove they are right.
• They are comfortable naming what they do not know, then finding the answer quickly.
• When something fails, they deal with the impact first instead of blaming the model or the prompt.

Which parts of FDE work will AI replace?

More of the configuration, testing, and diagnosis that FDEs handle manually today will be automated by platforms and agents. That is the outcome FDEs should be working toward: turn something done once by hand into something the system can do the next time.

But when the simpler problems disappear, the business environment will keep becoming more complex.

Today the challenge may be voice support, knowledge bases, and latency. Tomorrow it may be permissions, audits, and ownership boundaries between multiple agents. As models execute more, people have to make harder decisions.

I do not yet see a path to fully automating accountability.

Customers still need someone to coordinate conflicting interests, make trade-offs, and stand up when the outcome is poor. The specific skills of an FDE will change. The value of staying close to the real result is harder to remove.

Could FDE become a more demanding form of outsourcing in China?

This may be a more useful question than whether FDE is the next hot role.

Labor costs are high in North America. Software subscriptions and enterprise procurement are relatively mature, so the value of reducing waiting time and manual work is easier to calculate. China has different labor costs, procurement habits, on-premises requirements, and payment cycles.

If customers only pay by the project while demanding large amounts of one-off customization, FDE may become a fashionable new title for harder outsourced delivery and on-site implementation.

I would use three questions to assess an FDE opportunity in China:

• Does the customer have a real budget and a person who owns the outcome?
• Can the business impact after launch be measured?
• Can what this project builds be reused by the next customer?

If none of the three has a clear answer, growing the team will only scale the delivery cost faster.

Whether the FDE model works in China ultimately depends on whether the company can resist endless customization, and whether customers are genuinely willing to pay for outcomes. The title travels easily. The business conditions underneath it do not.

What I really care about is ownership

What stayed with me after the interview was not the arrival of another job title.

In the past, knowing a particular language, framework, or database could earn someone a clear place in the organization. AI is making those individual skills less scarce. The people who become more valuable are often the ones who can cross technical, business, and human boundaries and push an uncertain problem all the way to a result.

That does not mean everyone should become an FDE.

But engineers, product managers, and founders can all borrow its perspective. Ask “Do I know this tool?” a little less often. Ask instead: “When this goes wrong, who will notice, who will fix it, and who will own the result?”

The reason a new role deserves to exist may be hiding inside that line of ownership.