What FDE means at OpenAI

What FDE means at OpenAI | OpenAI October 22, 2026

What FDE means at OpenAI

What we do, how we work, and how we solve enterprise’s toughest problems to deliver real impact. By: Colin Jarvis, Head of Forward Deployed Engineering at OpenAI When Codex came out, someone on the team asked me, “What do we do when Codex can just one-shot the use cases we spent the last few months building?” That question gets to the heart of what FDE means at OpenAI. We work alongside customers to understand their hardest problems and build solutions they can depend on. What we learn helps shape our products and gives Research concrete problems to solve. That is progress. If we make ourselves obsolete every couple of months, our FDE team is doing its job. I founded the team in early 2025 to close what we call “the deployment gap”: the distance between what models appear capable of and what people can reliably use to do their work. Model capabilities have moved faster than the systems and processes needed to put them to use. Sometimes the missing piece is a product. Sometimes a model performs well on a benchmark but cannot do the job with real-life variables and constraints. We focus on customers’ hardest problems. Where our models can do the job today, we work with Product and our customer to make the solution repeatable and, where they fall short, we work with customers and Research to define the gap and make improvements. Our goal is for each engagement to leave the next customer with a better starting point—if we raise the floor to the point our customers don’t need FDEs to solve this class of problem the next time, we have done our job well. The challenge for John Deere, a 200 year-old agriculture business, was how to scale personalized advice for farmers. One example is See & Spray, its precision weed-control technology, which uses cameras and machine learning to identify and spray weeds rather than treating entire fields to reduce chemical use by up to 70%. But realizing those benefits depends on farmers knowing how to configure the technology, plan their season, and adjust their practices as conditions change. John Deere deployed OpenAI’s APIs to help make that support personalized and scalable. AI can answer farmers’ questions in natural language, provide tailored setup guidance and recommendations, identify when equipment may not be delivering its full potential, and help farmers understand the value they’re getting from the technology. The opportunity extends beyond any single interaction: to deliver relevant guidance throughout the customer journey, helping farmers make better use of their equipment while improving efficiency and sustainability. This is the kind of challenge OpenAI FDEs work to solve: helping organizations move from AI capabilities to systems that deliver practical value in complex, real-world environments. But the problems are often wide open, there may be no established ground truth, and there is no playbook. Everyone wants to build something that has never existed. Fewer people want to do what it takes to get there. Finding talented FDEs while raising the baseline for “good enough” has meant constant experimentation and application.

Start with the outcome

At the start of every FDE team session, I put up a slide with one core value: “Start with the outcome, do what it takes to succeed, then follow with scale”. An impressive demo can go a long way before anyone asks whether it works in the real world. Our job is to solve the customer’s problem to a standard we can stand behind in production. In mid-2025, we had around 15 FDEs working with a large semiconductor customer on 10+ use cases. The ambition was to make their verification process AI-native, covering:

• Directed test generation
• Root cause analysis and debugging
• An architecture assistant

Verification can account for \~70% of a project’s effort in this industry. The opportunity was enormous, and there were many possible places to start. Some FDEs had joined OpenAI just days earlier and had never worked in semiconductors. They embedded with the customer’s verification team, studied chip design in their spare time, and built evals with the engineers to test whether the AI could generate useful tests and correctly diagnose chip failures. Alongside that learning, we built custom harnesses for the individual use cases. Over the first 3-6 months, all of them reached production and early user adoption. The payoff was seeing the metrics:

• \~48% time saved through AI-based directed test generation.
• 22% median performance improvement through kernel optimisation.
• Weeks of debugging compressed into hours

When we played this all back the Chief Hardware Officer asked, “Did you guys work as chip designers before coming here?” Our FDEs don’t need to know the industry on day one but it is their responsibility to learn it. As coding assistants make software faster to build, understanding the customer’s business becomes even more important. We build teams with a mix of generalists and domain experts. You need enough knowledge to make sound judgments, and enough curiosity to question assumptions about the status quo. In life sciences, for example, our FDEs’ scientific backgrounds help them earn trust with researchers working on pre-clinical drug discovery tasks such as target validation and prioritization, gene-expression analysis, and chemical synthesis-route reconstruction. That expertise lets them contribute informed judgment about how those workflows could improve.

M ake success repeatable

We had shown that these workflows could deliver value, but each still required too much custom integration to extend to another team. The next challenge was to preserve those results while making the software easier to deploy and maintain. By then, Codex had grown in capability. One FDE tested rebuilding their application around it, then worked with the team to move the use cases onto a common harness with Codex at its core. Custom applications became plugins and skills built on common Codex primitives. Codex also became the interface, allowing us to retire the separate terminal UIs and CLIs we had written for individual use cases. We were able to remove roughly 90% of the custom code from each project, and this changed how we built, maintained and scaled these workflows:

• We could benefit from centralized improvements to Codex, reducing the amount of glue code required for each individual use case
• Key...