What FDE means at OpenAI
OpenAI's Forward Deployed Engineering team, founded in early 2025, operates at the gap between model capability and production reliability. Colin Jarvis frames FDE as a feedback loop: embed with customers on their hardest problems, learn what models can't do in the real world, feed those gaps back to research, and scale what works through product. The central claim is that this process makes FDE teams obsolete by design—if you're still needed six months later, you've failed to raise the floor for the next customer.
Transcript
Justy So OpenAI just published this whole thing about Forward Deployed Engineering, and Cody, I'm guessing you're going to tell me this is just consulting with a research spin.
Cody Not consulting—it's worse than that. It's the exact pattern every lab does when they realize benchmark wins don't ship. You build a services team, they solve real problems, you extract patterns, you close the gap. That's the playbook. What bugs me is Jarvis keeps framing it like they invented something when what they're actually doing is very old: field engineering, customer success ops, pre-sales technical depth.
Justy Yeah, but—
Cody Let me finish. The semiconductor example: fifteen FDEs, ten-plus use cases, three to six months to production, forty-eight percent time savings on test generation. That's real. The problem is you can't scale that. The second you try to replicate it at another semiconductor company, you're back to hiring domain experts and doing the same work all over again.
Justy Okay, but that's actually not what happened. They did the hard work first, learned what worked in production, and then rebuilt it around Codex as a common harness. And when they did that—they removed ninety percent of the custom code. The second team took one day to onboard instead of two months.
Cody Right.
Justy That's the story that matters. They didn't just consult and leave. They took the patterns they learned, made them repeatable, and the product improved enough to make the custom integration cheap. That's the scaling move.
Cody Okay, I hear you. But that only works if Codex actually got dramatically better between the initial deployment and the refactor. If Codex had plateaued, the ninety percent code reduction doesn't happen. You're still hand-building for each customer.
Justy Right, and that's exactly why this model of work is so interesting. FDE is not a consulting play—it's a forcing function on product. You have to improve the underlying model fast enough to make the custom work obsolete, or the whole thing breaks. Jarvis basically says that out loud: if they're still needed on the same class of problem six months later, they failed.
Cody That's a good frame. I'll give you that.
Justy The John Deere example is smaller but cleaner. Farmers need guidance on equipment setup, seasonal planning, knowing when their gear isn't working right. That's not a benchmark problem—it's a customer-success problem. OpenAI built it, deployed it, and now they can hand it off to product because the use case is stable enough.
Cody I'm not going to argue that the work is real. The semiconductor metrics are solid, the scaling story from two months to one day is a huge gap to close, and if they actually extracted reusable patterns that generalize, that's a genuine product win. What I'm skeptical about is whether this scales beyond the customers where the underlying model is already pretty good at the task.
Justy Explain that.
Cody Semiconductor verification, tax returns, customer-service voice—these are all domains where Claude or GPT is already doing most of the work. The FDE job is to stitch the pieces together, add domain knowledge, build the eval, make it production-ready. But what if the model is at forty percent on a task? You can't pattern your way out of that. You need the model to get better first, or you're just building a more expensive consulting engagement.
Justy That's fair. But I think the article is actually claiming both things are happening at once. Some engagements are scaling because the product is ready. Some are at the frontier and feeding research. The whole point is you don't know which one you're in until you embed with the customer and learn.
Cody That's true. And if that feedback loop is real—if Research is actually prioritizing based on what FDE learns in the field—that's genuinely different from consulting. But the scaling examples are solid enough that I think the core claim holds: if you do this right, the underlying product gets better because you're learning at the edge of what's actually possible in the real world.
Justy Exactly. And the part that gets me is the 'make yourself obsolete' framing. Most services organizations want to make themselves indispensable. OpenAI is explicitly saying the goal is to not need FDEs on this class of problem anymore. That's a weird and honest business model.
Cody It only works if you can keep finding harder problems. If you solve the customer's problem and then the model plateaus, you're stuck. You need a constant stream of new capability to keep moving forward.
Justy Which is the bet, right? That model capability keeps moving faster than the infrastructure to use it. If that's true, FDE stays busy. If it's false, this whole thing becomes an expensive way to build consulting.
Cody Sixty-forty it's true. The model capability is moving fast, infrastructure is lagging, and there's real money in closing that gap. But the moment the capability ceiling hits a wall or the infrastructure catches up, the whole model breaks.
Justy Fair. But for right now, in Q four twenty twenty-six, I think this is one of the smarter things OpenAI is doing. It's not sexy, it's not a new model, it's not a benchmark—it's just embedding engineers with customers and learning what actually works. And then using that to make the product better. That's it.
Cody Yeah. I'll take that.