Chapter 1: What an FDE Is, and Is Not

Adapted public course. Concepts, procedures and examples are adapted from the internal textbook. Case sizes, timings, improvement figures and target thresholds are illustrative, not site delivery results or universal standards. Verify tools, platforms and skills in your environment. Prompts do not grant permissions and retry counts do not authorize recovery. Preserve work and verify targets, sharing and external-state effects first.

Lesson explanation

1.1 A Typical Scene: Monday Morning at the Customer Site

It is nine on Monday morning. You are not at your company’s desk but in a meeting room at the customer’s data center. The head of operations sits opposite you, with three business workflows he drew yesterday on the whiteboard. Monthly reconciliation occupies three analysts for four full days, he says, and he wants AI to bring those four days down to half a day. He has not asked for a demonstration. His question is: “When can we start using it?”

What is your role in this scene?

Traditional job categories make the answer ambiguous. You look like presales because you face the customer, a developer because you will write code, and a project manager because you must answer “when.” Yet the industry already has a clear definition for the person in this setting: Forward Deployed Engineer (FDE). This textbook’s AI Forward Deployed Engineer · AFDE describes the complete form of that role in the AI era.

Broken down to first principles, the definition has four inseparable elements:

1. Embed at the customer site: Forward Deployed. “Forward” describes location, not seniority. You are deployed to the front line nearest the customer, rather than directing operations from the rear. Your context is the customer’s actual constraints, not your company’s internal schedule: what the data looks like, where the process stalls, and who makes decisions.
2. Write production code on customer infrastructure. This means deploying code to the customer’s private cloud, internal network, or even isolated network, where it serves real business traffic and failures carry real costs. A demo in your own company’s repository does not fulfill this requirement.
3. Own the entire process end to end. OpenAI’s FDE job description states the scope directly: engineers must “own discovery, technical scoping, system design, build, and production rollout.” From discovering the problem and defining its scope through system design, construction, and production launch, you own the journey.
4. Answer for customer outcomes. Accountability is for neither hours worked nor a feature checklist, nor even runnable code, but customer business results. In the opening scene, the deliverable is not “a reconciliation script”; it is “analysts spend only half a day each month.”

Together, these four elements define an FDE. Remove any one and the role becomes something else, as Section 1.4 explores.

First, however, a natural question: Where did this role come from, and why did it proliferate after 2024?

1.2 Origins and Evolution: From Palantir Delta to a Standard AI-Company Role

FDE is not an invention of the AI era. The role originated in Palantir’s Delta team in the 2010s: engineers deployed forward to customer sites to deliver software in customer environments. Palantir’s official blog recounts that, even before 2016, FDEs — then titled Forward Deployed Software Engineers — at one point outnumbered traditional development engineers. Most of the company’s engineers were delivering outcomes at customer sites rather than writing products at headquarters.

The role did not take its current shape in one act of design. Four layers of responsibility accumulated, each building on the preceding layer rather than replacing it:

Accumulated layer	Question answered	Typical work
1. Field engineering discipline	How does code survive in the customer’s environment?	Deployment, permissions, networks, and operations: DevOps capability is the entry ticket
2. Data integration	How do we bring in customer data?	Connect dispersed, heterogeneous customer sources of questionable quality
3. Custom solutions	What happens where the product falls short?	Build custom systems in the gap between product capabilities and customer needs
4. Customer enablement	How does the customer keep operating after you leave?	Train customer teams, preserve reusable assets, and hand over operations

These accumulated layers explain the role’s “onion structure”: from outside it looks like coding, one layer inward it is integration, another inward it is solution design, and at the core it is enabling customers to operate for themselves. The methods in the rest of this book — blueprints, acceptance, constraints, and evaluation — attach to these layers.

Why did this old role suddenly become an industry buzzword after 2024? AI companies encountered the same obstacle: the last mile between model capability and customer workflows. A model can already perform strongly on evaluation sets, but integrating it into an organization’s actual business raises questions whose answers are at the customer site: Where is the data? Who will use it? What happens when it is wrong? What should be measured after adoption? Those answers are not in the laboratory. From 2024 onward, companies including OpenAI, Anthropic, and Ramp therefore began establishing FDE positions at scale; see OpenAI’s and Anthropic’s public job descriptions. Unlike the analytics platforms of the Palantir era, this generation of FDEs deploys AI systems. That raises the demands on evaluation, risk, and measurement of real-world use — the reason this book combines the industry FDE baseline with AI-assisted engineering methods.

1.3 Five Core Responsibilities

A role definition explains who you are; responsibilities explain what you do each day. Public industry descriptions, most fully Palantir’s definition of the Forward Deployed Software Engineer, can be distilled into five core responsibilities:

#	Responsibility	Meaning	Typical artifacts
1	Architectural decisions	Decide the system’s shape within customer constraints	Deployment plan, integration architecture, architecture decision records (ADRs)
2	Accelerate customer operations with data and AI	Connect model capabilities to everyday business	Data pipelines, AI workflows, automated processes
3	Build custom applications	Fill gaps between the product and customer needs	Custom applications, integration middleware
4	Engage stakeholders at different levels	Connect the languages of technical teams, business teams, and executives	Communication cadences by level, executive readouts
5	Own high-stakes projects end to end	Be accountable from discovery through launch	Production systems in use and adoption data

Consider each in turn.

Responsibility one: architectural decisions. FDEs often make decisions where there is no company-standard answer. Every customer’s compliance requirements, legacy systems, and network topology differ; headquarters’ product manuals cannot cover them all. You are the person on site with the complete technical picture. Deployment architecture, data boundaries, and build-versus-buy choices can determine whether the project succeeds. Part Four, “Blueprint and Architecture,” develops this responsibility.

Responsibility two: accelerate customer operations with data and AI. This is the main arena for the FDE in the AI era. It means embedding model capability into everyday operational flows, beyond merely training a model: where data originates, how it is processed, where the model intervenes, and how people review its work. Part Seven, “Evaluation Systems,” and Part Nine, “Customer Delivery,” jointly cover this responsibility.

Responsibility three: build custom applications. Where the company’s product does not cover a customer scenario, the FDE closes the gap through engineering: custom applications and system integration. This is one dividing line between “Forward Deployed” and “Solution.” Solutions engineers (SA) typically demonstrate product capability; FDEs write production code on customer infrastructure to fill the gaps. AI-assisted coding greatly amplifies this responsibility’s leverage: AI-assisted coding can reduce some implementation effort, but the magnitude must be established with project evidence. The book’s methods apply throughout that work.

Responsibility four: engage stakeholders at different levels. A customer is a group of people with different interests and languages. Technical teams discuss interfaces and security, business stakeholders efficiency and cost, executives strategy and risk. The FDE is the on-site “protocol translator,” conveying engineering progress upward as business value and translating business needs downward into system constraints. Addressing the wrong level — technical detail for executives, strategic vision for engineers — is a common root cause of failed field delivery. Chapter 28 examines this directly.

Responsibility five: own high-stakes projects end to end. Pay attention to “own”: participation is not ownership. Customer projects often combine tight schedules, ambiguity, and highly visible failure. The FDE takes responsibility for discovering the real problem, defining scope, designing, building, launching, and measuring adoption. The first four responsibilities describe capabilities; the fifth establishes accountability. It is the final distinction between an FDE and an expert helping out on site.

1.4 What an FDE Is Not

Drawing exclusions can define a role more effectively than describing its attributes. Three adjacent roles cause the most confusion:

Adjacent role	Its definition	Boundary with FDE
Presales / SA	Demonstrate product capabilities and support closing sales	The SA’s arena is the demo environment, without writing customer production code; a gulf separates a working demo from a usable system
Technical support	Respond to tickets and resolve product-use problems	Support answers for tickets; FDEs answer for outcomes. Support explains how to use something; an FDE decides whether it should be used that way
Traditional consulting	Produce analysis, reports, and recommendations	Consulting delivers documents; an FDE delivers a production system running on customer infrastructure. The classic industry distinction is that consulting teams can proceed over multiple years with multiple staffing tiers, while a small FDE team goes directly to the field and delivers outcomes through production software

All three boundaries use the same test, returning to Section 1.1: Do you write customer production code, own the end-to-end process, and answer for customer outcomes? If any answer is no, you are not doing FDE work, whatever title appears on your business card.

This test also supports self-assessment. When something feels wrong in a customer project — repeated demos, waiting on somebody else’s schedule, defending “features delivered” while the customer’s business remains unchanged — check the role before doubting the methodology. You may be doing presales, support, or consulting under the FDE name.

[Self-Check] FDE Role Checklist

Check each item. Any that does not hold deserves a pause for reflection:

• Can I state the customer outcome for this project and how it will be measured?
• Does my code run on customer infrastructure and serve real business traffic?
• Do I have decision authority, or an explicit escalation path, at every stage from discovery to production launch?
• Am I making architectural decisions, or only implementing someone else’s plan?
• Do I have a communication cadence with the customer’s technical team, business stakeholders, and executives?
• Am I delivering a production system, or demonstrations, reports, or recommendations?
• Am I the first person the customer contacts when the project has a problem?
• Can I distinguish “the feature is live” from “the customer uses it and the business benefits”?

If most answers are yes, you already occupy the FDE position. The next questions concern precise boundaries with adjacent roles in Chapter 2, and where its core value moves as AI makes code cheaper in Chapter 3.

[Exercise] Test a Real Role Against the Four Elements

Task: Choose a familiar position, either your current job or a role you have worked with: presales engineer, implementation consultant, embedded developer, solutions architect, or another. Test each of Section 1.1’s four elements: embedded at the customer site? Writing production code on customer infrastructure? Owning the entire process end to end? Accountable for customer outcomes? Answer “yes,” “no,” or “partly” for each, with reasons.

Guidance: Pay particular attention to two gray areas: (1) writing code that runs in a demo environment — code without production; (2) participating end to end while someone else guarantees the result — process without accountability. These are precisely where FDE is most easily confused with presales and support.

Reference direction for instructors: Four yes answers describe a complete FDE. “Writes production code but does not own the process” often describes outsourced developers embedded on site. “Embedded on site but does not write code” commonly describes presales and implementation consultants. “Accountable for results but not on site” is closer to a product engineer delivering remotely. The point is not classification itself but seeing the gap: which elements separate the present role from FDE, and what are the costs and benefits of adding them?

---

Sources for the industry facts in this chapter: Palantir’s official blog provides the Forward Deployed Software Engineer definition, responsibilities, and account that FDEs at one point outnumbered traditional engineers before 2016. OpenAI’s public job description supplies “own discovery, technical scoping, system design, build, and production rollout.” For the adoption of FDE roles by OpenAI, Anthropic, Ramp, and others in 2024-2026, see The Pragmatic Engineer’s August 2025 interview with OpenAI’s FDE leader and the companies’ recruitment pages. This chapter uses no numerical claims from outside those sources.

---

Independent exercise

Use fictional or authorized deidentified material. Answer independently before revealing the reference. Save chapter-01.md with versions, decisions, evidence and gaps.

Write five responsibilities for the fictional Qinghe ticket project. Assign decisions to the customer, FDE, product and operations, and reject one unauthorized request.

Required chapter artifact: FDE role-boundary table

The submission for this independent exercise must contain the evidence below. The existing prompts supply content but do not replace these acceptance items.

• O1: The FDE role-boundary table states the scope and owner of both customer outcome ownership and end-to-end delivery
• O2: The FDE role-boundary table contains at least one exclusion, one handoff and one acceptance condition
• O3: The artifact records all three tests against one real job description with cited evidence

Reveal reference feedback (answer first)

Reference feedback

The FDE turns the classification problem into a verifiable scope, coordinates implementation and evaluation, and prepares handover. The customer approves business rules and data access; operations approves production changes. Do not upload raw tickets to a personal model account without authorization.

Self-review and next steps

Check whether your decision is explicit, evidence reproducible and unknowns honestly recorded. The reference illustrates one defensible approach, not a unique answer. Seek peer review for alternatives with equivalent evidence. Mark unsupported parts unfinished and revisit the corresponding step.