De rol van de Forward Deployed Engineer bij OpenAI
Wat we doen, hoe we werken en hoe we de lastigste problemen van bedrijven oplossen om echt verschil te maken.
Door: Colin Jarvis, hoofd Forward Deployed Engineering bij OpenAI
Toen Codex uitkwam, vroeg iemand uit het team me: "Wat doen we als Codex in één keer de toepassingen kan bouwen waar wij de afgelopen maanden aan hebben gewerkt?"
Die vraag raakt de kern van wat het betekent om Forward Deployed Engineer te zijn bij OpenAI. We werken nauw samen met klanten om hun moeilijkste problemen te doorgronden en oplossingen te bouwen waarop ze kunnen vertrouwen. Wat we leren, helpt onze producten vorm te geven en geeft het onderzoeksteam concrete problemen om op te lossen.
Dat is vooruitgang. Als we onszelf elke paar maanden overbodig maken, doet ons team van Forward Deployed Engineers zijn werk goed.
Ik richtte het team begin 2025 op om te overbruggen wat we "de implementatiekloof" noemen: het verschil tussen wat modellen lijken te kunnen en wat mensen betrouwbaar kunnen inzetten voor hun werk.
De capaciteiten van modellen zijn sneller gegroeid dan de systemen en processen die nodig zijn om ze te benutten. Soms is een product de ontbrekende schakel. Soms presteert een model goed op een benchmark, maar kan het de taak niet aan met de variabelen en beperkingen uit de praktijk.
We richten ons op de moeilijkste problemen van klanten. Waar onze modellen de taak nu al aankunnen, werken we met het productteam en onze klant om de oplossing herhaalbaar te maken. Waar ze tekortschieten, brengen we samen met klanten en het onderzoeksteam in kaart wat er ontbreekt en voeren we verbeteringen door. Ons doel is dat elk traject de volgende klant een beter vertrekpunt biedt. Als we het basisniveau zo ver verhogen dat klanten de volgende keer geen Forward Deployed Engineers nodig hebben om dit soort problemen op te lossen, hebben we ons werk goed gedaan.
John Deere, een 200 jaar oud bedrijf in de landbouwsector, stond voor de vraag hoe het meer boeren persoonlijk advies kon bieden.
Een voorbeeld is See & Spray, hun technologie voor precisieonkruidbestrijding. Die gebruikt camera's en machine learning om onkruid te herkennen en gericht te bespuiten, in plaats van hele velden te behandelen. Zo kan het gebruik van chemische middelen tot 70% worden verminderd.
Maar om die voordelen te behalen, moeten boeren weten hoe ze de technologie instellen, hun seizoen plannen en hun werkwijze aanpassen aan veranderende omstandigheden.
John Deere zette de API's van OpenAI in om die ondersteuning persoonlijk en schaalbaar te maken.
AI kan vragen van boeren in natuurlijke taal beantwoorden, instructies en aanbevelingen op maat geven voor het instellen van apparatuur, signaleren wanneer apparatuur mogelijk niet optimaal presteert en boeren inzicht geven in wat de technologie hun oplevert.
De mogelijkheden gaan verder dan één contactmoment: relevante begeleiding tijdens het hele klanttraject kan boeren helpen hun apparatuur beter te benutten en tegelijk efficiënter en duurzamer te werken.
Dit is het soort uitdaging waaraan de Forward Deployed Engineers van OpenAI werken: organisaties helpen om AI-mogelijkheden om te zetten in systemen die waarde opleveren in complexe praktijkomgevingen.
Maar de problemen zijn vaak nauwelijks afgebakend, een vaststaande referentiewaarheid ontbreekt soms en er is geen draaiboek. Iedereen wil iets bouwen dat nog nooit heeft bestaan. Minder mensen willen doen wat daarvoor nodig is.
Het vinden van getalenteerde Forward Deployed Engineers, terwijl we de lat voor "goed genoeg" steeds hoger leggen, vraagt om voortdurend experimenteren en toepassen in de praktijk.
Aan het begin van elke bijeenkomst van ons team van Forward Deployed Engineers laat ik een dia zien met één kernwaarde: "Begin bij het resultaat, doe wat nodig is om te slagen en schaal daarna op".
Met een indrukwekkende demo kun je ver komen voordat iemand vraagt of het ook in de praktijk werkt.
Onze taak is het probleem van de klant op te lossen met een kwaliteit waar we ook in productie achter kunnen staan.
Medio 2025 werkten ongeveer 15 van onze Forward Deployed Engineers met een grote klant in de halfgeleiderindustrie aan meer dan 10 toepassingen. De ambitie was om hun verificatieproces volledig rond AI in te richten, met onder meer:
Gerichte testgeneratie
Analyse van hoofdoorzaken en debugging
Een architectuurassistent
In deze sector kan verificatie zo'n 70% van het werk aan een project beslaan. Het potentieel was enorm, en er waren veel mogelijke aanknopingspunten.
Sommige Forward Deployed Engineers waren pas een paar dagen in dienst bij OpenAI en hadden nog nooit in de halfgeleiderindustrie gewerkt. Ze draaiden mee in het verificatieteam van de klant, verdiepten zich in hun vrije tijd in chipontwerp en ontwikkelden samen met de engineers evaluaties om te testen of de AI bruikbare tests kon genereren en chipfouten correct kon diagnosticeren.
Terwijl we bijleerden, bouwden we voor elke toepassing een harness op maat. Binnen de eerste drie tot zes maanden waren alle toepassingen in productie en hadden ze hun eerste gebruikers. De cijfers maakten duidelijk wat het opleverde:
Zo'n 48% tijdwinst door gerichte testgeneratie met AI.
Een mediane prestatieverbetering van 22% door kerneloptimalisatie.
Weken debugwerk teruggebracht tot uren
Toen we dit allemaal presenteerden, vroeg de Chief Hardware Officer: "Werkten jullie als chipontwerpers voordat jullie hier kwamen?"
Onze Forward Deployed Engineers hoeven de sector niet vanaf dag één te kennen, maar zijn er wel verantwoordelijk voor om die te leren kennen.
Nu programmeerassistenten het bouwen van software versnellen, wordt inzicht in het bedrijf van de klant nog belangrijker. We stellen teams samen met een mix van generalisten en domeinexperts.
Je hebt voldoende kennis nodig om goed onderbouwde afwegingen te maken, en genoeg nieuwsgierigheid om aannames over de bestaande situatie ter discussie te stellen.
In de biowetenschappen helpt de wetenschappelijke achtergrond van onze Forward Deployed Engineers bijvoorbeeld om vertrouwen op te bouwen bij onderzoekers die werken aan preklinische geneesmiddelenontwikkeling. Denk aan het valideren en prioriteren van aangrijpingspunten, genexpressieanalyse en het reconstrueren van chemische syntheseroutes. Dankzij die expertise kunnen ze onderbouwd meedenken over verbeteringen aan die workflows.
We hadden aangetoond dat deze workflows waarde konden opleveren, maar voor elk ervan was nog te veel integratiewerk op maat nodig om ze bij een ander team in te zetten. De volgende uitdaging was om die resultaten te behouden en tegelijk de software eenvoudiger te implementeren en te onderhouden.
Inmiddels waren de mogelijkheden van Codex gegroeid. Een Forward Deployed Engineer probeerde de applicatie opnieuw te bouwen rond Codex en werkte vervolgens met het team aan het overzetten van de toepassingen naar een gedeelde harness met Codex als kern.
Maatwerkapplicaties werden plugins en skills, gebouwd op gedeelde basiscomponenten van Codex. Codex werd ook de interface, zodat we de afzonderlijke terminalinterfaces en CLI's die we voor elke toepassing hadden geschreven, konden uitfaseren.
We konden uit elk project ongeveer 90% van de maatwerkcode verwijderen. Dat veranderde hoe we deze workflows bouwden, onderhielden en opschaalden:
We konden profiteren van centrale verbeteringen aan Codex, waardoor voor elke toepassing minder verbindingscode nodig was
Belangrijke functies werden gebundeld in skills en plugins, zodat teams ze eenvoudiger konden delen en het AI CoE ze centraal kon beheren. Daardoor kon de uitbreiding naar een volgend team zo eenvoudig zijn als het aansluiten van nieuwe connectors/MCP-servers en het bouwen van nieuwe evaluaties (waar we ook een skill voor hadden). Daarna kon het team aan de slag.
Bij een voorbeeld uit augustus 2026 duurde de eerste implementatie twee maanden. De oplossing uitbreiden naar een tweede team kostte één dag. Naarmate we opschaalden, konden volgende teams sneller aan de slag. Dat is zo gebleven: bij een toepassing in augustus 2026 had het tweede team één dag nodig, nadat de eerste implementatie twee maanden had geduurd.
Dat is één manier om onszelf overbodig te maken. Het werk om de oplossing in productie te brengen, had duidelijk gemaakt wat ertoe deed. Naarmate het onderliggende product beter werd, konden we een groot deel van ons maatwerk vervangen en de waarde ervan behouden.
Daarom is de volgorde belangrijk. Met LLM's kunnen we snel bouwen. Gebruik die snelheid om gebruikers iets waardevols te bieden, ontdek wat in de praktijk standhoudt en schaal vervolgens op wat werkt.
Hetzelfde principe geldt voor alle klanttrajecten.
OpenAI Presence, ons product voor enterprise voice- en chatagents, is voortgekomen uit echte klantimplementaties. Het werk begon met Swarm(opent in een nieuw venster) en ontwikkelde zich via de Agents API, en inmiddels handelt één klant meer dan de helft van zijn telefoongesprekken af met AI.
Door die implementaties in productie te krijgen, leerden we welke problemen een maatwerkoplossing nodig hadden en welke bouwstenen andere teams konden gebruiken. We hebben die bouwstenen in Presence gebracht, waardoor het voor ontwikkelaars makkelijker werd om gereguleerde workflows te automatiseren zonder de onderliggende infrastructuur opnieuw op te bouwen. Elke implementatie hielp het product vorm te geven en gaf de volgende klant een beter startpunt.
Met Thrive Holdings ,werkten de Forward Deployed Engineers en onderzoekers van OpenAI samen met engineers en accountants om Tax AI te ontwikkelen voor de accountantskantoren van Crete. Tijdens de pilot verwerkte Tax AI 7.000 belastingaangiften en verhoogde de doorvoer met ongeveer 50%.
Een van de moeilijkste uitdagingen was het automatiseren van de verwerking van belastingaangiften voor verhuurd vastgoed. Het kostte zes weken ontwikkelwerk en beoordeling door vakexperts om een precisie en recall van 90% te bereiken. Dit werk leverde herbruikbare patronen op waarmee Tax AI eenvoudiger kon worden uitgebreid naar andere complexe bijlagen bij belastingaangiften.
De teams passen nu dezelfde aanpak toe op boekhouding, audit en IT-ondersteuning—systemen bouwen die verbeteren door feedback van professionals en gebruik in de praktijk.
Soms kunnen we dankzij een beter product vereenvoudigen wat we hebben gebouwd, maar soms kan het model zelf de taak nog niet aan.
Als we alleen bouwen wat de huidige modellen al mogelijk maken, ontdekken we niet welke tekortkomingen het onderzoeksteam vervolgens moet aanpakken. Daarom beginnen veel van onze belangrijke klanttrajecten juist bij die grenzen. De klant, de Forward Deployed Engineers en het onderzoeksteam zetten zich er samen voor in om die te verleggen.
We hadden samen met een grote telecomklant al een klantenserviceplatform ontwikkeld, en die klant wilde het uitbreiden met spraak.
Ongeveer 90% van alle klantcontacten verliep telefonisch. Deze gesprekken waren duurder om volledig geautomatiseerd af te handelen dan chats. Ook brachten ze nieuwe technische uitdagingen mee: het omgaan met accenten, de toon, de latentie en de nauwkeurigheid moesten allemaal op productieniveau komen. Een goede oplossing zou een aanzienlijk verschil maken voor hun bedrijf.
Bij het afbakenen van het project scoorde ons model ongeveer 60% op de belangrijkste evaluaties waarmee we beoordeelden of het geschikt was voor gebruik in productie. We hadden de grenzen van zijn mogelijkheden bereikt. Het model moest beter worden in functies aanroepen en instructies opvolgen in klantenservicescenario's.
We legden dat uit aan de klant en betrokken het onderzoeksteam bij het werk. De Forward Deployed Engineers werkten met de klant aan het platform en bepaalden samen wat het model moest kunnen. Het onderzoeksteam werkte aan het verhelpen van de tekortkomingen. Met opeenvolgende modelversies konden we de voortgang toetsen aan de eisen van de klant.
In zes maanden stegen de scores op de belangrijkste evaluaties van ongeveer 60% naar 80% en vervolgens naar meer dan 90%. Daarmee bereikten we het niveau dat nodig was voor productie.
Het spraakmodel dat hieruit voortkwam, ondersteunt nu de implementatie bij die klant, andere klantenserviceoplossingen op maat en beheerde implementaties via Presence. Een probleem bij één klant hielp verbeteringen aan het licht te brengen waar veel andere klanten baat bij kunnen hebben.
Elk onderdeel was van belang. De klant zette zich in voor een probleem dat het model nog niet kon oplossen. De Forward Deployed Engineers bleven nauw betrokken om dat probleem scherp te krijgen, het platform te bouwen en het traject van begin tot eind te leiden. Het onderzoeksteam verbeterde de capaciteiten van het onderliggende model.
Dit is de andere manier om onszelf overbodig te maken: helpen om van een probleem dat de huidige modellen niet kunnen oplossen, iets te maken wat toekomstige modellen wél aankunnen. Ons werk levert meer op dan alleen de waarde van de uren die we bij één klant doorbrengen.
Ik ben bij OpenAI gaan werken om AI nuttig te helpen maken in het dagelijks werk van mensen. Dat is nog steeds de leidraad voor het team. Ik zeg vaak tegen het team dat bij de ontwikkeling van LLM's meestal het scheermes van Ockham geldt: de eenvoudigste oplossing is de beste. Binnen een bedrijf dat bekendstaat om baanbrekend onderzoek, en in een sector die wordt geplaagd door overdreven claims, willen we dingen bouwen die betrouwbaar werken en waarop mensen in de praktijk kunnen vertrouwen.
Het doel is dat elk klanttraject verbetert wat daarna komt: een product dat eenvoudiger te implementeren is, een model dat een moeilijkere taak aankan of minder maatwerk voor de volgende klant.
Heb je een moeilijk probleem dat je wilt oplossen? Dan werken we graag met je samen. Wil je helpen die problemen op te lossen? Dan verwelkomen we je graag in ons team.
Dus wat doen we als Codex het werk aankan waarvoor wij maanden aan oplossingen hebben gebouwd?
Een moeilijker probleem zoeken.
