FDE vs AI engineer: where the two jobs actually diverge
An AI engineer builds the system: retrieval, agents, evaluation, guardrails, latency and cost. They are judged on whether it is accurate, fast and cheap enough, measured against an evaluation set they can run on demand. A forward deployed engineer takes a system that already works by that measure and finds out what happens when a real organisation touches it. They are judged on whether that organisation changed how it works, and whether the change outlived their departure. Both write code against models, and the code often looks similar. The difference is what counts as done. For the AI engineer, done is a number moving on a benchmark. For the forward deployed engineer, done is a person who used to do something one way now doing it another way, voluntarily, when nobody from the vendor is in the building.
| Forward deployed engineer | AI engineer | |
|---|---|---|
| In one sentence | An engineer employed by the product company, working inside the customer’s organisation to make the product solve that customer’s actual problem. | An engineer who builds systems on top of models: retrieval, agents, evaluation, guardrails, latency and cost. |
| Judged on | Whether the customer’s workflow changed, and whether it stayed changed after the engineer left. | Whether the system is accurate, fast and cheap enough to run, measured against an evaluation set. |
| Works inside | The customer’s systems, data and meetings, often on their premises. | The product codebase, the model layer and the evaluation harness. |
| Usually leads to | Leading a deployment team, or product management with unusual field credibility. | Staff or principal engineering on the model platform, or founding an applied-AI product. |
| Time with the customer How much of the week is spent with the people who will use the thing. | High | Low |
| Technical depth How deep the engineering expected of the role goes. | High | High |
| Business depth How well the role is expected to understand the customer’s own trade. | High | Medium |
| Hands on code How much of the job is actually writing and integrating software. | High | High |
| Owns the outcome Whether the role is judged on delivery, or on what the delivery changed. | High | Medium |
These levels describe where each role sits on average, not a rule. Job titles are not standardised across companies, so a given posting can sit well away from its column. Read what a posting says the person will build rather than the heading.
The same code, a different definition of finished
Put both engineers on the same problem and for the first week you would struggle to tell them apart. Both will look at the data, both will write retrieval, both will argue about chunking and about what the evaluation set should contain. The divergence starts at the moment the system is good enough on paper.
The AI engineer, at that point, has a result. The number moved, the regression suite passes, the latency budget holds. There is a next problem waiting, and moving to it is the correct professional behaviour: their employer is buying a product that works for everyone.
The forward deployed engineer, at the same moment, has barely started. Their next question is who, specifically, is going to look at this output on Tuesday morning, and what they will do when it is wrong. That question has no engineering answer. It is answered by sitting next to that person, watching them not trust the system, and finding out that the reason is a column they have been mentally correcting for six years and never told anyone about.
Why the evaluation set is the honest dividing line
If you want one test to tell the roles apart, ask who owns the evaluation set and where its contents came from.
An AI engineer’s evaluation set is a product artefact. It is meant to generalise, it is version-controlled alongside the system, and a case enters it because it represents a class of input the product must handle. It is the instrument by which the team knows whether they are going backwards.
A forward deployed engineer’s evaluation set is an argument with a customer. Its cases come from that customer’s own files, its labels come from the customer’s own experts, and its purpose is not primarily to measure the system. Its purpose is to get a specific group of people to agree, in advance, on what a correct answer looks like. Half the value is extracted before a single case is run, during the arguments about what belongs in it. Those arguments surface the disagreements inside the customer that would otherwise have surfaced three months later as a claim that the system does not work.
Where the difficulty lives
Both jobs are hard, and it is worth being precise about where the difficulty sits, because engineers choosing between them often assume the deployment role is the easier one.
The AI engineer’s difficulty is depth against a moving floor. The techniques that mattered eighteen months ago have been partly absorbed into the models, the tooling is unstable, and a system that was well engineered last year can be beaten by something simpler today. Staying current is a large part of the job, and the work is unforgiving in the way engineering usually is: the system either holds under load or it does not.
The forward deployed engineer’s difficulty is different in kind. The technical problems are rarely the hardest thing in the room. The hardest thing is that the person whose work the system changes did not ask for it, may be measured on the old way of working, and has no obligation to help you. No amount of engineering skill resolves that. It is resolved by understanding what that person is actually optimising for, which requires being interested in their job rather than in your system.
Engineers who find the second kind of difficulty degrading should not take the role. Engineers who find it the most interesting part of the week are unusually valuable, because the supply of people who are strong at both is small.
Moving between the two
The move from AI engineering to forward deployed work is the common one, and it is easier than it looks on paper. The technical foundation transfers whole. What has to be added is not knowledge but a habit: assuming that the stated problem is a translation of the real one, and treating the translation as your job rather than as an annoyance.
The reverse move, from deployment into core AI engineering, is less common but not rare, and the people who make it bring something the core team usually lacks. They have watched systems fail for reasons that never appear in an evaluation harness. An engineer who has seen twenty organisations reject a correct answer builds guardrails differently.
The practical advice for anyone choosing: the distinguishing question is not which technology you prefer. It is whether you would rather spend Tuesday improving a number or spend it finding out why somebody does not believe the number. Both are real engineering. They are not the same week.
Reading a posting for which one it really is
Because the titles are not standardised, the heading tells you less than the responsibilities. Three signals sort most postings reliably.
First, whose systems are named. A posting that talks about the product’s codebase, its evaluation infrastructure and its latency budget is an AI engineering role whatever it is called. One that talks about customer environments, integrations and stakeholders is a deployment role.
Second, whether travel appears. It is the single most reliable tell, and its absence from a posting that otherwise reads as deployment work is worth asking about directly rather than assuming.
Third, what the success measure is. A posting that describes success in terms of model quality is one job. A posting that describes it in terms of accounts, adoption or time to value is the other. When a posting describes both, it is usually a small company where one person does both, which is a legitimate role and worth knowing about in advance.
