OpenAI FDE Lead Discusses How the Team Brings AI into Enterprise Production Environments

Just days after joining, you're "forced" to learn how to design chips? The code you worked hard on for months, and the moment AI gets an upgrade, it deletes 90% of it for you? The weirdest part is that in this role, the better you do, the faster you might "lose your job"?

This is the real experience of being an FDE engineer at OpenAI, currently the world's top AI company.

If OpenAI's researchers are the people building nuclear weapons in the lab, then the FDE team is the "special forces" who carry those weapons to the front lines and teach enterprises, hand in hand, how to win the war. They have only one mission: solve the customer's toughest business problems and get AI truly deployed into production environments.

In a newly published blog post, lead Colin Jarvis shared how the OpenAI FDE team works, along with a group photo of the entire team.

This job is far less glamorous than it sounds, and is even full of a "masochistic" flavor. To sum it up, they mainly have to get through a few hurdles.

Hurdle one: You have to be a "crash-course" industry expert

In mid-2025, about 15 OpenAI FDE engineers were sent to work with a large semiconductor customer. The goal was to use AI to help verify chips. How troublesome is chip verification? It can account for nearly 70% of the entire chipmaking workload.

But these engineers had only been on the job a few days, and forget about making chips—they probably hadn't even figured out the door to the semiconductor industry yet. What to do? Grit your teeth and push on. They dove straight into the customer's team, learned chip design alongside them, and crammed knowledge in their spare time.

Why go to such lengths? For example, if you don't know how to fix a car, how can you judge whether the repair plan AI gives is right or wrong? When AI writes a piece of test code or reports a fault, you have to know whether it's actually useful in the real business.

As a result, after three to six months, they helped the customer save about 48% of directed test time, raised median performance by 22%, and compressed debugging work that originally took weeks into a few hours. The customer's hardware boss even asked in shock: "Did you used to do chip design?"

Hurdle two: Reject "vanity projects" and fight to the death for real results

In ordinary software development, building a demo, getting it running, and being able to show it off basically counts as delivering. But on the FDE team, that doesn't even reach the passing line.

If it were just about going through the motions, engineers could easily ship a "castrated version" and call it done. But the FDE approach is: no, we have to solve it at the root. They break down the customer's needs, run back to OpenAI's research team, and demand that they "upgrade the brain" of the model and improve its instruction-following and function-calling capabilities.

After grinding for half a year, they managed to pull the score from 60 to above 90, reaching the standard for real deployment. What does this show? FDEs are not just users of AI; they are the "overseers" pushing AI to evolve.

In the semiconductor project mentioned earlier, the team spent several months writing a large amount of customized code and tools for different scenarios.

Then, after a while, OpenAI's own coding model Codex got an upgrade! It became smarter! At this point, an FDE engineer made a crazy decision: he rebuilt the framework with the upgraded Codex and turned all those complex customized applications into general-purpose plugins.

The result: about 90% of the customized code in each project was deleted!

Does it hurt? Maybe a little. But what did it buy? Deploying a solution used to take two months; now rolling it out to the next team takes just one day.

This is the core value of being an engineer at OpenAI: your value is absolutely not how many lines of code you wrote, but what problem you solved, and whether you can keep the next person from having to suffer through everything you suffered.

This is also reflected in their AI project with a tax company. At first, handling complex rental property tax forms was extremely painful, and the team spent six weeks getting accuracy to 90%. But once the method was solidified, handling similar complex forms later became easy for AI.

After Codex was released, someone on the FDE team did ask lead Colin Jarvis this.

Colin's answer was very bold. He said: "Then go find a harder problem."

Below is the full translation of the blog post:

What FDE means at OpenAI

What we do, how we work, and how we solve enterprises' toughest problems and deliver real impact.

When Codex was released, someone on the team asked me: "If Codex can handle in one go all those use cases we spent months painstakingly building, then what should we do?"

This question happens to touch the core meaning of FDE at OpenAI. We work side by side with customers, figure out their hardest problems, and build solutions they can rely on. The understanding we gain from this both shapes the direction of the product and gives the research team concrete problems to attack.

This is progress. If we make ourselves redundant every few months, it means the FDE team is doing its job right.

I formed this team in early 2025 to bridge what we call the "deployment gap"—the distance between what models appear to be able to do and what people can reliably use them to accomplish at work.

Figure 1 | The "deployment gap": the shortfall between the value model capabilities can create and the current trajectory of business value

Model capabilities evolve faster than the systems and processes needed to actually put them to use. Sometimes what's missing is a product; sometimes a model performs well on benchmarks but can't do the job when placed under real-world variables and constraints.

We focus on our customers' hardest problems. For the parts the model can handle today, we work with product teams and customers to turn the solution into something reusable; for the parts the model still can't manage, we work with customers and research teams to define the gap and drive improvements. We want every project to leave the next customer starting from a better position—if the floor is raised high enough that the next time a customer encounters this kind of problem, they no longer need an FDE to step in, then we've done our job well.

John Deere, an agricultural company with a two-hundred-year history, faced the challenge of scaling personalized advice for farmers.

One example is the precision weeding technology See & Spray: using cameras and machine learning to identify weeds and apply herbicide only to the weeds rather than spraying the entire field, it can reduce chemical usage by up to 70%.

But to realize these benefits, farmers first need to know how to configure the equipment, how to plan the entire growing season, and how to adjust their approach when conditions change.

John Deere calls OpenAI's API to make this kind of support both personalized and scalable.

The opportunity goes beyond a single interaction: carrying useful guidance through every step of the customer journey, so farmers can get more out of their equipment while improving efficiency and sustainability.

This is exactly the problem OpenAI's FDEs are meant to solve: helping organizations move from "having AI capabilities" to "having systems that deliver real value in complex real-world environments."

But these kinds of problems often have no boundaries, may have no ready-made standard answers, and come with no operating manual. Everyone wants to build something that has never existed before, but far fewer are willing to pay the price for it.

Finding talented FDEs while continuously raising the bar for what counts as "good enough" means constant trial and error, and constant investment.

Start from outcomes

Every time the FDE team meets, I put up a slide with just one core value: "Start from outcomes, do whatever it takes to succeed, then talk about scaling."

Figure 2 | The core values the author presents at team meetings: start from outcomes, do whatever it takes to succeed, then scale

A stunning demo can carry you for a long time—until someone asks, "Does it actually work in the real world?"

Our job is to solve the customer's problem to a standard where we dare to vouch for it in production.

In mid-2025, we sent about 15 FDEs to work with a large semiconductor customer on more than a dozen use cases. The goal was to make their verification process AI-native, covering:

In this industry, verification can account for 70% of a project's workload. The space is huge, and there are many places to start.

Some FDEs had joined OpenAI just days earlier and had never worked in semiconductors. They dove straight into the customer's verification team, studied chip design in their spare time, and worked with customer engineers to build evals, testing whether AI could generate useful tests and correctly diagnose chip failures.

Learning as we went, we built custom harnesses for each use case. Within the first 3 to 6 months, all of these use cases went into production and were used by early users. The returns showed up in the numbers:

During the retrospective, the customer's chief hardware officer asked: "Did you do chip design before you came here?"

Our FDEs don't need to understand the industry on day one, but learning it is their own responsibility.

As coding assistants make software development faster and faster, understanding the customer's business has become more important. Our team is a mixed formation of generalists and domain experts.

You need enough knowledge to make sound judgments, and enough curiosity to question the default assumptions about the status quo.

Take life sciences as an example: our FDEs' research backgrounds let them earn the trust of researchers—people doing preclinical drug discovery work such as target validation and prioritization, gene expression analysis, and redesigning chemical synthesis routes. This expertise allows them to make well-grounded judgments about "how these processes should change."

Make success replicable

We've proven that these processes can create value, but each one still requires too much custom integration to replicate for another team. The next challenge is: while preserving these results, make the software easier to deploy and easier to maintain.

Figure 3 | FDEs turn a hard problem into replicable capability: hard problem → zero-to-one solution → reusable packaging

By then, Codex's capabilities had grown. One FDE tried rebuilding their application around it, then worked with the team to migrate these use cases onto a unified harness centered on Codex.

Custom applications became plugins and skills built on Codex's general-purpose primitives. Codex also became the unified entry point, and the terminal interfaces and CLIs we had written separately for each use case were retired.

About 90% of the custom code in each project was removed, and the way we build, maintain, and roll out these processes changed with it:

l Centralized improvements to Codex flow through directly, and the glue code each use case needs shrinks accordingly.

l Key capabilities are packaged as skills and plugins, making them easier to share across teams and easier for the AI CoE (AI Center of Excellence) to centrally govern. This means that scaling from one team to the next may only require swapping in a new connector/MCP server and rebuilding a set of evaluations (for which we likewise built corresponding skills), and it can run.

l In one example from August 2026, the first deployment took two months, while extending the solution to a second team took only one day. As scale grew, subsequent teams onboarded faster and faster—and this trend has continued: in the same August 2026 use case, the first deployment took two months and the second team took one day.

Figure 4 | Before-and-after comparison of the architecture overhaul: before (left) was a multi-agent architecture; after (right) is an architecture with Codex as the hub

This is one way to "make yourself redundant." The work done to reach production established what really matters. As the underlying product grows stronger, we can replace most of our custom implementations while retaining the value they created.

This is why order matters. LLMs let us build fast. Use that speed to first put something valuable in users' hands, see clearly what holds up in practice, and then scale the parts that truly work.

This principle applies to all projects.

OpenAI Presence, a product for enterprise voice and chat agents, grew out of real customer deployments. This line began with Swarm, evolved through the Agents API, and today one customer already has more than half of its incoming calls handled by AI.

Taking these deployments to production showed us clearly which problems need custom solutions and which building blocks other teams can use directly. We folded these building blocks into Presence so developers can automate regulated processes without rebuilding the underlying infrastructure. Each deployment both shapes the product and gives the next customer a better starting point.

In collaboration with Thrive Holdings, OpenAI's FDEs and researchers worked alongside engineers and accountants to build Tax AI for accounting firms in Crete. During the pilot, Tax AI processed 7,000 tax returns, increasing throughput by about 50%.

One of the hardest challenges was automating rental property filings: reaching 90% precision and recall took six weeks of engineering development and practitioner review. This work produced reusable patterns that make it easier to extend Tax AI to other complex tax forms.

Now the team is applying this approach to bookkeeping, auditing, and IT support—building systems that keep getting better through practitioner feedback and real-world use.

Figure 5 | Processing more tax forms with the same headcount: Tax AI's throughput index is about 1.5 times the pre-overhaul level

Fill intelligence gaps as soon as they appear

Sometimes a better product lets us simplify what we built ourselves, but sometimes the model itself still can't do the job.

If we only do what today's models can already do, we won't discover the intelligence gaps that the research team needs to fill next.

That is why many of our important projects start precisely at these limits: customers, FDEs, and the research team commit together to crack them.

We had previously built a customer service platform with a large telecom customer, and they wanted to extend it to voice.

Voice accounts for about 90% of their customer service volume. These calls are harder to resolve in self-service than text-based customer service, cost more to handle, and bring a series of new technical challenges in accents, tone, latency, and accuracy reaching production-grade standards. Done well, the impact on their business is significant.

During the project evaluation phase, on the key evaluations used to judge whether the model could handle a production environment, our model scored about 60%. This was already at the ceiling of its capabilities: function calling and instruction following in customer service scenarios both needed improvement.

We made this clear to the customer and brought in the research team. FDEs worked with the customer to build the platform and define what the model needed to do; the research team was responsible for closing the capability gaps, and new model snapshots let us test progress against the customer's requirements.

Over six months, the key evaluation score rose from about 60% to 80%, and then to over 90%, reaching the standard required for a production environment.

Figure 6 | Real-time progress in voice reasoning: Audio Big Bench accuracy rose from 65.6% in December 2024 to 92.29% in May 2026

The resulting voice model now powers this customer's deployment, other custom customer service deployments, and managed deployments offered through Presence. A problem encountered in one customer's business helped us find improvements that can serve many other customers.

Every link is essential. The customer was willing to invest in a problem the model could not yet solve; FDEs stayed close to the front line, defining the problem clearly, building the platform, and driving the project from start to finish; the research team improved the underlying model capabilities.

This is another way to "make yourself redundant": helping turn a problem today's model cannot solve into a capability future models can deliver. The return on our work far exceeds the hours invested in a single customer.

Go find harder problems

I joined OpenAI because I wanted AI to be genuinely useful in people's daily work.

This still guides the team today. I often tell the team that Occam's razor applies to most situations in LLM development—the simplest solution is the best. At a company that defines itself by the most frontier research, in an industry tainted by exaggerated rhetoric, what we want to build is something that runs reliably and that frontline people dare to depend on.

The goal is for every project to improve the next one: a better-deployed product, a model that can handle harder tasks, or less custom work for the next customer.

If you have a hard problem you want to solve, we are willing to work on it with you; if you want to help solve these problems, we welcome you to join us.

So when Codex can take over the work we spent months building, what should we do?

Go find harder problems.

Markets carry risk, and investment requires caution. This article does not constitute personal investment advice and does not take into account the specific investment objectives, financial situation, or needs of individual users. Users should consider whether any opinions, views, or conclusions in this article are suitable for their particular circumstances. Invest at your own risk.