OpenAI's FDE Playbook: Make Yourself Unnecessary by Turning AI Demos into Production Systems

What Is an FDE? Not Pre-Sales, Not Just a Programmer

FDE stands for Forward Deployed Engineering. Unlike traditional software engineers who work from requirements documents, or pre-sales engineers who focus on demos, FDEs embed directly in the customer's real business environment. They work alongside domain experts and engineers to identify the hardest, often ill-defined problems, then combine AI models, software engineering, and domain knowledge to build systems that actually run in production.

OpenAI calls the chasm between model benchmarks and reliable business value the Deployment Gap . A model that answers well in a chat window does not equal a system that can handle accents, latency, complex context, and error recovery in a live voice-support line.

Start from the Outcome, Then Scale

OpenAI's guiding principle: work backward from the desired result, do whatever it takes to succeed, then think about scaling . Many teams start by building a chatbot or a flashy demo; FDEs instead ask what success looks like in the customer's workflow and build the evaluation harness first.

Case Study: AI in Semiconductor Verification

In mid-2025, about 15 FDEs partnered with a large semiconductor company to bring AI into chip verification. The project covered directed test generation, root-cause analysis, debugging, and architecture assistance — over ten use cases. Several FDEs had no prior semiconductor background; they learned on the job, co-designed evaluation metrics with the customer's verification engineers, and judged whether AI-generated tests actually found bugs.

Results after 3–6 months in production:

AI-assisted directed test generation saved ~48% of engineering time.

Kernel optimizations delivered ~22% median performance improvement.

Debugging tasks that used to take weeks were compressed to hours.

These numbers come from OpenAI's public case study and are not guaranteed for every engagement, but they illustrate the FDE metric: success is measured by whether the customer's work genuinely improved, not by lines of code written.

Turn One-Off Delivery into Reusable Capabilities

If FDEs only deliver a custom project, the model becomes expensive bespoke development. The second phase is to extract verified solutions into reusable assets. In the semiconductor project, the team initially built custom apps and integration code per use case. As Codex capabilities grew, they migrated everything onto a shared execution framework centered on Codex, converting features into reusable Skills and Plugins and replacing per-use-case UIs with a unified interface.

Outcome: ~90% reduction in custom code per project . Deployment time for the second team dropped from two months to one day .

The engineering lesson: first solve the problem with whatever customization is needed; only when the same pattern recurs should you abstract it into a platform. Premature generalization creates complexity. OpenAI's enterprise voice product Presence followed the same path — common needs discovered in real deployments were folded back into the product so later customers don't rebuild infrastructure.

When the Model Isn't Good Enough: Feed Gaps Back to Research

Sometimes no amount of application-layer engineering can close the gap — the model itself falls short. In a large telecom voice-support project, voice handles ~90% of contact volume but demands lower latency, accent robustness, tone handling, and reliable function calling. Initial model evaluations scored ~60%, below the production threshold.

Instead of papering over the deficiency with more application code, the FDEs precisely defined the capability gaps and brought the research team into the loop. FDEs and the customer built the platform and defined the real-world tasks; researchers targeted function-calling and instruction-following improvements. Every model update was measured against the same business-specific eval set.

Over ~6 months, the key eval score rose from ~60% to 80%, then past 90%, meeting the production bar. This reveals a second core FDE value: translate customer-site problems into concrete, measurable research tasks .

Business-specific evaluations are critical. Generic benchmarks show rough model quality but cannot replace evals that check: Is the answer correct? Does the function call match expectations? Is latency acceptable? FDEs become the bridge connecting real requirements, business evals, and model research.

Why FDE Success Means Making Yourself Unnecessary

Colin Jarvis, OpenAI's Head of Forward Deployed Engineering, puts it bluntly: if every few months you can make yourselves unnecessary, the FDE team is doing it right . This is not a slogan; it's the loop observed across the cases:

When a model can do the task, partner with product to standardize and simplify deployment instead of maintaining custom code.

When the model can't do the task, partner with research to define the gap and drive improvement via real-world evals.

After a customer succeeds, ask: which parts can become a public product, tool, eval suite, or workflow for the next engagement?

Each delivery should make the next one easier. The metric shifts from "how much custom code did we write?" to "are similar problems becoming easier over time?" The role won't vanish — new model capabilities unlock new business opportunities, which surface new problems — but the repetitive work that products and models have absorbed should disappear.

Lessons for Every Engineer in the AI Era

Don't treat code generation as the finish line. AI tools slash implementation cost, but they don't decide what problem to solve or guarantee the system meets real business constraints.

Get into real scenarios early; validate with outcomes. Instead of spending months building a "do-everything" agent, find a real user, define success criteria, build a reliable eval, and iterate.

Turn custom experience into reusable engineering assets. Frameworks, Skills, Plugins, connectors, eval sets, deployment pipelines — each project should leave artifacts that become the starting point for the next one.

Distinguish application-engineering problems from model-capability problems. Some gaps close with better data, tooling, workflows, or system design; others need a better model. Misidentifying the boundary wastes effort stacking code in the wrong layer.

Domain knowledge gains value as implementation gets cheaper. Judging what's worth building, verifying correctness, and navigating complex constraints become the high-leverage activities.

Summary: Go Solve the Next Harder Problem

OpenAI's article superficially explains the FDE role but fundamentally asks where engineering value lies when AI writes code fast. The answer: not in who writes the most code, but in who understands the real problem, designs a reliable solution, and turns one win into a repeatable capability. FDEs operationalize this at the customer site — owning the business context, building the system, answering for production results, and feeding insights back to product and research. It's a working model that connects business, engineering, and AI research.

Jarvis's closing line is the takeaway for every engineer: Go find the next harder problem.

References

What FDE means at OpenAI – https://openai.com/index/forward-deployed-engineering-means

Work at the Frontier: Forward Deployed Engineering at OpenAI – https://forum.openai.com/public/events/work-at-the-frontier-forward-deployed-engineering-at-openai-vmimj73oz5