OpenAI details how its FDE team works: 90% of custom code gave way to Codex skills

OpenAI has published a breakdown of how its forward deployed engineers (FDE) work. The company formed the team in early 2025 to address a specific problem: on paper the model can do a lot, but people can't yet rely on it in their daily workflows. That is the "deployment gap." Results across four projects: 3–6 months to production in semiconductors, +50% throughput for tax accountants, a voice model that went from 60% to 90%+ on key evals, and about 90% of custom code discarded once Codex arrived.

The team's motto: start with the result, do whatever it takes to get it, scale later. Igor Akimov, author of the AI Product channel, notes that vendors keep talking in unison about superintelligent models, yet there are too few real deployments in specific verticals. In his assessment, tokens are currently being burned mostly by startups on someone else's dime. FDEs work precisely where that gap has to be closed by hand.

Chips, taxes and telecom: four cases with numbers

• Semiconductor engineering, mid-2025. About 15 FDEs worked on 10+ use cases: test generation, root-cause analysis of failures, and an architecture assistant. Verification takes up about 70% of project effort in the industry. Some of the engineers joined OpenAI just days before the start and knew nothing about chips. They sat with the customer's engineers, learned the domain and built the metrics together. Within 3–6 months, all use cases reached production. The results: about 48% time savings on test generation, a median 22% performance gain on kernel optimization, and debugging that used to take weeks now taking hours.
• Move to Codex. As Codex matured, the team moved all use cases onto a shared harness with Codex at the center. Custom applications became plugins and skills, and the team's own CLIs and interfaces were thrown out. Each project dropped about 90% of its custom code. In one case, the first deployment took 2 months, and expanding to a second team took 1 day.
• Tax AI for Thrive Holdings accounting firms. The pilot processed 7 000 tax returns, and throughput rose by roughly 50%. Real estate transactions proved the hardest: it took 6 weeks of engineering and review by practitioners to reach 90% precision and recall.
• Voice for telecom. Voice accounts for about 90% of support requests. The model scored about 60% on key evals, which is not enough for production. The team brought in Research: within 6 months it raised the result to 80%, then to 90%+. That voice model now also runs for other customers.

Custom code lasts half a year

The most interesting part from an engineering standpoint is the Codex story. The projects were built on homegrown applications, CLIs and interfaces, with a different set of scaffolding for each customer. Once the platform learned to handle orchestration itself, all of that became plugins and skills. The gap between 2 months for a first deployment and 1 day for an expansion shows where the cost accumulates. The less unique code a project contains, the cheaper every subsequent customer or team becomes.

There is also an architectural shift. According to Akimov, OpenAI moved away from a multi-agent design to a single agent with skills. That is exactly what Anthropic had recommended. The two largest labs are converging on the same pattern: one agent plus a set of pluggable skills.

The takeaway for token economics is straightforward. As a layer of homegrown logic grows around the model, so do maintenance costs, along with the risk that the platform will ship the same thing out of the box six months later. The team adopted this as a working principle: the FDE success criterion is to make themselves unnecessary every couple of months. When Codex began building in a single pass what engineers used to build over months, the question "what do we do now?" got a simple answer: find a harder problem.

What integrators should take away

There are three durable assets: domain knowledge; datasets and metrics built together with the client's experts; and an understanding of where the model falls short. The tax case confirms this: the 90% precision and recall on real estate transactions came not from features but from six weeks of review by practitioners. The voice case shows the same thing from the other side: going from 60% to 90%+ required bringing in Research. For product managers and integrators, this suggests several practical steps:

• start with evals and metrics agreed with the customer's experts, not with the interface;
• build on platform primitives (skills, plugins) rather than homegrown CLIs;
• stick with one agent with skills until multi-agent setups prove their necessity on metrics;
• plan on rewriting the harness every few months.

To developers who fear that Codex will take their jobs, this breakdown offers an answer: the value is shifting toward framing problems and measuring quality. That is exactly what the people did who, a week before the chip project started, knew nothing about chips.