Skip to content
FDE Handbook
M0Lesson 2 · FDE vs. Adjacent RolesM0-L2.3

FDE vs Software Engineer and AI Engineer

In one sentence: A software or AI engineer builds and improves the company’s own product for many users; an FDE starts from one customer’s problem, builds what that customer needs on top of the product, and owns whether it works there.

What it is

Section titled “What it is”

Software engineers (SWEs) and AI engineers work on the product itself. Their starting point is the roadmap; their users are mostly people they will never meet; their environment is the company’s own stack. An AI engineer specializes in the model-facing parts: prompts, retrieval, tool calling, evaluation, fine-tuning.

An FDE uses many of the same skills, which is why Modules 1–4 of this handbook look like a software and AI engineering curriculum. What changes is the context: the starting point is one customer’s problem, the users are specific people in one organization, and the environment is someone else’s systems, data, security rules and legacy code.

Why an FDE needs this

Section titled “Why an FDE needs this”

“Why FDE and not software engineering?” is one of the most common interview questions, and many candidates answer it badly (“I like talking to people”). A clear comparison lets you answer in terms of responsibility and environment.

Key concepts

Section titled “Key concepts”
Software / AI engineerFDE
Starting pointProduct roadmapOne customer’s problem
UsersMany, mostly anonymousNamed people in one organization
EnvironmentThe company’s own stack, which the team controlsThe customer’s systems, permissions and legacy, which nobody on the team controls
SuccessFeature quality and adoption across the user baseThis customer’s outcome
Where the code livesThe main product repositoryProduct contributions plus customer-specific integrations
Typical feedback loopMetrics and user research at scaleDirect conversations, daily

Shared skills, different weighting

Section titled “Shared skills, different weighting”

Both roles need to read and write production code, design systems and evaluate AI behavior. The FDE additionally needs to work inside constraints they cannot change (a customer’s identity provider, a database they can only read, a security review with a six-week queue) and to run discovery and adoption, which product engineers rarely own.

Movement in both directions

Section titled “Movement in both directions”

Engineers move from SWE to FDE for closer contact with customer impact and faster feedback, and from FDE to SWE or product roles for deeper ownership of a single system. Both moves are common; neither is a demotion.

Common misconceptions

Section titled “Common misconceptions”
  • “FDE code is throwaway.” FDE code runs in production at the customer and is held to the same standards; customer-specific is not the same as low quality.
  • “Strong SWE skills are enough to be a good FDE.” They are necessary, not sufficient. Most FDE failures are discovery or adoption failures, not coding failures.
  • “FDE is a step down from SWE.” It is a different trade-off: less depth in one system, more breadth and more direct accountability for outcomes.

Typical interview questions

Section titled “Typical interview questions”
Why FDE and not a product engineering role?

Talk about what you want to be accountable for: a working outcome for a real customer, including the parts outside the code. Mention the environment you want to work in (other people’s systems, real constraints) and one example where you already did this kind of work.

What is harder about writing code in a customer's environment than in your own company's?

You don’t control the environment: access takes time, data is messier than expected, security rules limit what you can deploy, and you may have to integrate with systems nobody fully understands. You also have to leave the code in a state someone else can run.

Learn more

Section titled “Learn more”
Section titled “Related”