# Chapter 3: The FDE in the AI Era: What Changes and What Does Not

## Lesson objectives

- **O1** Can compare changing model capability, stable delivery ownership and evaluation feedback loop against the same dimensions (artifact: AI-era responsibility change table)
  - Evidence: The AI-era responsibility change table fills three parallel columns for changing model capability, stable delivery ownership and evaluation feedback loop using the same dimensions
- **O2** Can construct a AI-era responsibility change table whose columns use the same questions and evidence standard (artifact: AI-era responsibility change table)
  - Evidence: Every column in the AI-era responsibility change table includes one reviewable fact and one open question
- **O3** Can distinguish AI-changed delivery leverage from outcome accountability that remains human (artifact: AI-era responsibility change table)
  - Evidence: The artifact records one capability change, one stable responsibility and how each claim is checked

## Learning paths

- **Novice**: Chapter transfer task: Can distinguish AI-changed delivery leverage from outcome accountability that remains human. Use the diagram's comparison relationship to complete the first evidence item in the AI-era responsibility change table, then check each owner and decision rule.
- **Experienced**: Apply this task to a current project before reading the explanation: Can distinguish AI-changed delivery leverage from outcome accountability that remains human. Submit the AI-era responsibility change table, then check the relationship type, missing evidence and authority boundary.

## Teaching diagram

- **Required artifact**: AI-era responsibility change table
- **Diagram kind**: change-continuity
- **Relationship semantics**: The three columns are parallel comparisons against shared dimensions; their order conveys neither process sequence nor maturity.
- **Core concepts**: changing model capability · stable delivery ownership · evaluation feedback loop

![Chapter 3 teaching diagram for the AI-era responsibility change table](/learning/diagrams/en/chapter-03.svg)

Read the AI-era responsibility change table across shared dimensions, compare differences, and only then make a choice.

The diagram places changing model capability, stable delivery ownership and evaluation feedback loop in three parallel columns crossed by a shared comparison line. The columns have no sequence or rank; read each row against the same dimension before recording a choice and reservation.

> **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

Chapter 2 ended with a question: as coding agents sharply reduce the cost of producing code, how do the boundaries between FDE and adjacent roles move? Which parts expand, and which erode?

This chapter answers directly: Code is getting cheaper, but three things defining this role are not: data integration, customer understanding, and accountability for outcomes. The leverage changes; the fulcrum remains.

### 3.1 A "Dirty Secret": The Hottest Job Has No Shared Definition

In a public talk, Meurer, who leads Agent Engineering at Sierra and worked as a Palantir FDE from 2016 to 2021, offered a candid assessment. The "dirty secret" about FDE, in her telling, is that the job "doesn't exist," yet it is also "the hottest job in AI."

This is one authoritative individual's perspective, not an industry consensus. Still, the apparent contradiction deserves consideration. "Doesn't exist" means there is no stable, shared job definition that can simply be copied: positions called FDE in different companies may involve very different work. "Hottest" means that demand for this kind of person is growing rapidly and materially.

Why might a job that does not exist be the hottest one? Widespread coding agents supply half the answer. As the ability to write code becomes less scarce, companies discover that what they actually lack is engineers who connect model capability to real customer business and take responsibility for results. They write a wide variety of job descriptions, some called FDE and others bearing different names. Section 3.4 discusses this "role convergence."

The other half of the answer lies in what has not become cheaper.

### 3.2 Three Things That Have Not Become Cheaper: Data, Understanding, and Accountability

Coding agents have collapsed the cost of turning an idea into running code. Along with that, mastery of syntax and framework details, code-output speed, and the evidential value of a demonstration prototype have declined. When anyone can generate a respectable PoC in a few hours, making a demo no longer provides a professional moat. Chapter 2's boundaries shift accordingly: the gulf between demonstration and production has not narrowed. Easier demonstrations can make it appear wider.

Yet none of these three things at the customer site has become cheaper:

| What has not become cheaper | Why an agent cannot resolve it | Coverage in this book |
|---|---|---|
| Data integration | Customer data is dispersed, heterogeneous, and of questionable quality, as in layer 2 of Section 1.2. This is organizational reality, not a coding problem. Even a strong model needs usable inputs, and AI systems are more sensitive to data quality | Part Four: Blueprint and Architecture |
| Customer understanding | Where the real problem lies, who decides, who uses the system after launch, and who pays for mistakes: this context lives in the customer's organization, not model weights | Part Nine: Customer Delivery |
| Accountability for outcomes | Customers pay for results, and a person must answer for them. Agents can generate code but cannot stand behind it on your behalf | Throughout the book |

The third deserves special emphasis. In the same talk, Meurer identifies what she sees as the industry's one continuity point: every FDE is accountable to the customer. Stacks, tools, and titles change, but having a person in the field accountable for customer outcomes persists from the Palantir era to the AI era. Again, this is a single authoritative viewpoint, labeled here as elsewhere in this chapter.

This explains the book's recurring principle: AI provides leverage; you are the fulcrum. Greater leverage requires a more stable fulcrum. The stronger code generation becomes, the higher the relative value of data integration, customer understanding, and outcome accountability. An FDE's core value resides in the fulcrum.

### 3.3 An Expanding Delivery Reach: From Prototypes to End-to-End Solutions

Those three things describe continuity. The change is equally significant: coding agents substantially extend an FDE's delivery reach.

Traditionally, writing a solution line by line consumed much of an FDE's time, limiting what one person could cover. Meurer describes the new way of working as more than meeting customers or building prototypes: FDEs can "actually build end-to-end solutions with coding agents."

That description fits Chapter 1's four elements. End-to-end ownership, the fifth responsibility, was previously a question of willingness; now it is also a question of feasibility. An FDE working with a coding agent can cover the discovery, scoping, design, construction, and rollout previously requiring a small team. Chapter 1 described that expanded capacity. Here is its other side: as capability expands, so does accountability. The more you build, the more you must inspect, evaluate, and operate.

Here also lies a crucial new lesson for FDEs in the AI era. AI system outputs are probabilistic, beyond the reach of traditional software tests' deterministic assertions alone. Construction has become cheaper; validation has not. How to make model output measurable and regression-testable occupies all of Part Seven, "Evaluation Systems," Chapters 21-23. How to take a built system into production in a customer's environment and ensure it is actually used is Part Nine, "Customer Delivery," Chapters 27-29. This chapter establishes the framework; the methods follow later.

Consider a teaching scenario. An agent finishes the ticket assistant's interface early, freeing half a day. If the engineer immediately takes on three more features while nobody knows who receives misrouted tickets, the expanded delivery reach is superficial. A better use is to review failed examples with the shift supervisor, let actual operators try the system, and agree who takes over after a routing mistake. Back at the desk, add disputed examples to the evaluation set and record the takeover path in the delivery notes. Time saved on code becomes verifiable quality and clear responsibility instead of more features awaiting acceptance. The boundary remains: engineers may organize evidence and propose actions, but faster coding does not authorize them to accept new risks or business commitments for the customer.

The judgments so far fit into one table:

| | What changes and expands | What remains and becomes more visible |
|---|---|---|
| Code | Generation costs collapse; delivery reach expands | The requirement to serve production traffic on customer infrastructure |
| Prototypes | Available in hours, with weaker evidential value | The gulf between a working demo and a usable system |
| Validation | Requires new capabilities: evaluation systems | A person must sign off and take responsibility before launch |
| Role | More varied titles and moving boundaries | Data integration, customer understanding, outcome accountability |

### 3.4 Role Convergence: One Trend, Two Readings

Return now to Section 3.1's question: Why are companies' job descriptions so varied?

Meurer argues that related roles are converging toward FDE: product engineering, agent engineering, AI engineering, solutions engineering, and customer engineering. In her words, "everything is trending that way." When she introduced the term agent engineering in July 2024, she positioned it as a subset of FDE work. Again, convergence is her individual authoritative perspective, not an industry consensus. Chapter 2 showed that the industry still distinguishes these roles at least in name: OpenAI explicitly separates SA and FDE into two positions.

Two readings are useful.

Reading one: opportunity -- the capabilities you practice transfer across roles. If this trend holds, the book's capabilities -- end-to-end delivery, data integration, evaluation, and customer collaboration -- will span recruitment needs across five titles. Your career options broaden rather than narrow.

Reading two: realism -- titles are inflating, so return to the criteria. Convergence and title inflation are two sides of the same coin. As FDE becomes a buzzword, more business cards will carry it while the work may remain presales, support, or consulting. Return to Chapter 1's three questions: Do you write customer production code? Own the end-to-end process? Answer for customer outcomes? Assess opportunities and positions by those answers, never by title alone.

That is a recurring practice in this textbook: external voices, even authoritative ones, provide perspectives; judgment always returns to first-principles criteria. Meurer's talk is an important perspective cited here, but it receives no exemption.

A handover must also test whether the recipient can operate independently: ask the customer owner to reproduce a failure from the records, locate the takeover entry point, and explain when to stop automated handling. If only the developer can explain the procedure verbally, saved coding time has not yet become sustainable delivery capability. The output of this step is a reviewable takeover record, not more features.

### [Exercise] Audit Your Role for Change and Continuity

Task: Use Section 3.2's framework to examine your current work. List three things coding agents have made cheaper over the past year, then three things that have not become cheaper. Which column is receiving more of your time?

Guidance: Look for one danger signal. If all the time saved goes into generating more code, with none going to data integration, customer understanding, or acceptance of outcomes, your leverage has grown but your fulcrum has not kept pace. This is the AI-era form of the role drift described in Chapter 2.

Reference direction for instructors: A healthy shift reduces the share of time spent building while increasing the share spent evaluating and collaborating with customers. An unhealthy shift raises code output per unit time while leaving acceptance and accountability unchanged. The first expands delivery reach; the second enters the entropy spiral, explored in Parts Three and Six.

### 3.5 The Book's Roadmap: After Understanding the Role

Part One now closes its loop. Chapter 1 defines the role -- who you are and who you answer to. Chapter 2 draws boundaries -- who you are not. This chapter examines trends -- what changes, what remains, and how to judge. One sentence runs through all three: Move from "someone who writes code" to "someone who makes decisions for customer outcomes."

With that identity established, the next part returns to everyday work: how to work with AI as a partner. Part Two, Chapters 4-6, reshapes cognition: what AI coding is and is not, why it is a "super intern" while you remain the decision-maker, and three traps to watch for. The map then continues through Part Three's core methodology and six-step workflow; Part Four's blueprints and architecture; Part Five's skill system; Part Six's process constraints; Part Seven's evaluation systems; Part Eight's quality and risk governance; Part Nine's customer delivery; Parts Ten and Eleven's team collaboration and continuous evolution; and Part Twelve's practical exercises.

The book's entire structure expands the table of change and continuity: methods, skills, and processes provide leverage for what changes; evaluation, quality, customer delivery, and accountability provide the fulcrum for what remains.

---

> Sources for the industry facts in this chapter: The FDE "dirty secret" claim, the continuity of customer accountability, the description of building end-to-end solutions with coding agents, and the claimed convergence of five engineering roles all come from a public talk by Meurer, Sierra's Agent Engineering leader and a Palantir FDE from 2016 to 2021. Her introduction of agent engineering in July 2024 as a subset of FDE comes from her public discussion at that time. These are all one authoritative individual's views, not industry consensus, and are labeled throughout. OpenAI's separation of SA and FDE comes from The Pragmatic Engineer's August 2025 interview with its FDE leader, cited in Chapter 1. This chapter cites no additional industry statistics; unsourced scenarios and time allocations are teaching assumptions.

---

> Part One is complete. You now know who you are (Chapter 1), who you are not (Chapter 2), and what changes and remains in the AI era (Chapter 3). Move to Part Two: Cognitive Reshaping. Return to daily work and examine your actual relationship with AI: what AI coding is and is not, why AI is a super intern, and the three traps you must watch for.

---

## Independent exercise

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

For interviews, scaffolding, rule approval, evaluation and release approval, identify AI assistance and decisions requiring a human.

<!-- chapter-artifact-requirement -->
### Required chapter artifact: AI-era responsibility change 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 AI-era responsibility change table fills three parallel columns for changing model capability, stable delivery ownership and evaluation feedback loop using the same dimensions
- O2: Every column in the AI-era responsibility change table includes one reviewable fact and one open question
- O3: The artifact records one capability change, one stable responsibility and how each claim is checked

<details>
<summary>Reveal reference feedback (answer first)</summary>

## Reference feedback

AI may summarize authorized interviews and draft code or evaluation scripts. Humans approve rules, access, evaluation conclusions and release. Measure time and rework over a defined window; generation speed does not establish customer impact.

### 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.

</details>

## Sources and boundaries

Registered sources support only the external claims used here. The AI-era responsibility change table, example numbers and exercise scenario are internal instructional design and require project-specific validation.

- [Forward Deployed Engineer role — San Francisco](https://openai.com/careers/forward-deployed-engineer-(fde)-sf-san-francisco/) — OpenAI, 2026-09-28. This OpenAI role covers discovery, scoping, design, build, rollout, adoption and field feedback; it is not an industry-wide standard.
- [FDE origins, role distinctions and OpenAI work phases](https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers) — The Pragmatic Engineer, 2026-09-17. This interview reports FDE origins, OpenAI SA/FDE distinctions, three customer-project phases and team knowledge-sharing cadences; it is secondary interview evidence, not an industry standard.
- [Transformers generation strategies](https://huggingface.co/docs/transformers/generation_strategies) — Hugging Face, 2026-09-17. Greedy, sampling and beam search use different next-token selection strategies, and decoding choices affect output.
- [The Dirty Secret of Forward Deployed Engineering](https://www.ai.engineer/talks/Byv311hdoHE-dirty-secret-forward-deployed-engineering) — AI Engineer, 2026-09-17. Natalie Meurer argues, as an individual practitioner perspective, that FDE lacks a single stable job boundary while retaining accountability for customer outcomes; the talk also documents her related Palantir and Sierra experience.