Evidence at a glance
A Team That Aims to Make Itself Obsolete
In an October 2026 essay, Colin Jarvis, OpenAI’s head of Forward Deployed Engineering, describes how FDE teams work alongside enterprise customers. They start with difficult customer problems, build solutions that can be relied on in real environments, and feed what they learn back to Product and Research. The job is not to produce a model demo, but to make a model work consistently inside an actual workflow.
Jarvis uses Codex to pose an apparent paradox: if a coding tool can one-shot use cases that took months to build, what is left for FDEs to do? His answer is that the team is not meant to preserve bespoke projects indefinitely. If model or product improvements mean customers no longer need FDEs to solve the same class of problem, that is evidence the work is succeeding.
The Deployment Gap Is More Than a Model Shortfall
OpenAI frames the reason for creating FDE as a “deployment gap”: a distance between what models appear capable of and what organizations can reliably use in their work. Sometimes the model itself falls short: strong benchmark performance does not guarantee success amid the variables and constraints of a real task. In other cases, the missing pieces are product capabilities, system integration, or adaptation to an existing workflow. OpenAI’s job descriptions add the practical engineering work around enterprise systems and data, permissions and policies, and iteration after launch.
FDE is therefore neither simply product sales nor a matter of writing a small application for a customer. In OpenAI’s account, the team defines the problem with the customer, builds a solution and evaluations, and tests the result in production. If the model cannot do the job, the team brings a specific capability gap back to Product and Research. The role combines delivery with problem definition, but whether that becomes a useful feedback loop depends on results in the customer’s environment.
In Agriculture, the Hard Part Comes After the Technology
The John Deere example shows that the value of adding a model does not necessarily come from replacing existing technology. See & Spray uses cameras and machine learning to identify weeds and spray them precisely, reducing chemical use by up to 70% compared with treating entire fields. But realizing that benefit depends on farmers configuring the equipment, planning the season, and adjusting their practices as conditions change. Weed detection and targeted spraying alone do not guarantee sustained use.
OpenAI says its APIs support natural-language questions, tailored setup guidance and recommendations, and help farmers identify whether equipment is reaching its potential and understand the value it delivers. This shifts the question from “Can the model answer?” to “Can users take the right actions throughout the product journey?” For technical leaders, the deployment target is not an isolated chat interface, but an adoption chain involving equipment, user decisions, and field conditions. The material gives no quantified results for farm output or adoption, so the chemical-reduction figure should not be attributed to the AI solution itself.
What the Semiconductor Project Shows—and What It Does Not
OpenAI’s semiconductor engagement gets closer to the engineering core of FDE. In mid-2025, about 15 FDEs worked with a large semiconductor customer on more than 10 use cases, including directed test generation, root-cause analysis and debugging, and an architecture assistant. OpenAI says verification can account for roughly 70% of project effort in the industry, so the work was not about adding a single chat feature. It covered tasks embedded in engineering workflows. Some FDEs had joined only days earlier and lacked semiconductor experience, so they embedded with the customer’s verification team, learned the domain, and built evaluations with engineers.
According to figures supplied by OpenAI, the use cases entered production and began to be adopted within three to six months. Directed test generation saved about 48% of the time, kernel optimization produced a 22% median performance improvement, and debugging shrank from weeks to hours. These figures suggest how evaluations built with domain experts can test whether a model does more than appear capable. But the material does not specify test sets, baselines, sample sizes, or metric definitions. The 48% and 22% figures should therefore be treated as results reported for one customer engagement, not as expected gains for other chip teams.
Custom Delivery Becomes a Loop Only When It Is Reusable
The hardest trade-off in the FDE model is that customer problems demand customization, while the team’s long-term value depends on reducing it. OpenAI says validated solutions are moved into a general framework centered on Codex and captured as plugins, skills, and connectors. In the semiconductor engagement, about 90% of custom code was later removed from each project. The first team deployment took two months, while expansion to a second team took one day. These figures illustrate the intended direction of productization: separate customer-specific work from capabilities that later teams can reuse.
But less code does not, by itself, prove that reuse has succeeded. Different enterprises may still have distinct permission boundaries, data structures, evaluation standards, and workflows. The material also does not explain how the plugins and connectors handle permission isolation or how broadly they can be reused across customers. Technical leaders can treat FDE as a loop between production deployment and productization: start with a concrete workflow, build testable evaluations with domain experts, then decide which parts can become shared components and which must remain customer-specific. The key test is not merely whether one deployment launches, but whether the next one becomes faster and more reliable while remaining verifiable against the customer’s own evaluations.