Als Codex herauskam, fragte mich jemand im Team: „Was machen wir, wenn Codex die Anwendungsfälle, an denen wir die letzten Monate gebaut haben, einfach in einem Durchgang lösen kann?“
Diese Frage trifft den Kern dessen, was FDE bei OpenAI bedeutet. Wir arbeiten Seite an Seite mit Kunden, um ihre schwierigsten Probleme zu verstehen und Lösungen zu entwickeln, auf die sie sich verlassen können. Was wir dabei lernen, hilft, unsere Produkte zu gestalten, und gibt der Research konkrete Probleme zum Lösen.
Das ist Fortschritt. Wenn wir uns alle paar Monate überflüssig machen, macht unser FDE-Team seine Arbeit richtig.
Ich habe das Team Anfang 2025 gegründet, um das zu schließen, was wir nennen „die Deployment-Lücke“: den Abstand zwischen dem, was Modelle fähig zu sein scheinen, und dem, was Menschen zuverlässig für ihre Arbeit nutzen können.
Die Fähigkeiten der Modelle haben sich schneller entwickelt als die Systeme und Prozesse, die nötig sind, um sie einzusetzen. Manchmal fehlt ein Produkt. Manchmal schneidet ein Modell in einem Benchmark gut ab, kann die Arbeit aber unter realen Bedingungen und Einschränkungen nicht leisten.
Wir konzentrieren uns auf die schwierigsten Probleme unserer Kunden. Wo unsere Modelle die Arbeit heute schon erledigen können, arbeiten wir mit dem Product-Team und dem Kunden daran, die Lösung wiederholbar zu machen; wo sie nicht ausreichen, arbeiten wir mit Kunden und Research daran, die Lücke zu definieren und Verbesserungen vorzunehmen. Unser Ziel ist, dass jedes Engagement den nächsten Kunden mit einem besseren Ausgangspunkt zurücklässt – wenn wir die Untergrenze so weit heben, dass unsere Kunden das nächste Mal keine FDEs mehr brauchen, um diese Klasse von Problemen zu lösen, haben wir unsere Arbeit gut gemacht.
Die Herausforderung für John Deere, ein 200 Jahre altes Agrarunternehmen, bestand darin, personalisierte Beratung für Landwirte zu skalieren.
Ein Beispiel ist See & Spray, seine Präzisions-Unkrautbekämpfungstechnologie, die Kameras und maschinelles Lernen nutzt, um Unkraut zu erkennen und gezielt zu besprühen, statt ganze Felder zu behandeln, und so den Chemieeinsatz um bis zu 70% reduziert.
Doch diese Vorteile zu realisieren hängt davon ab, dass Landwirte wissen, wie sie die Technologie konfigurieren, ihre Saison planen und ihre Praktiken an veränderte Bedingungen anpassen.
John Deere hat OpenAIs APIs eingesetzt, um diese Unterstützung personalisiert und skalierbar zu machen.
KI kann Fragen von Landwirten in natürlicher Sprache beantworten, maßgeschneiderte Einrichtungsanleitungen und Empfehlungen geben, erkennen, wann Geräte möglicherweise nicht ihr volles Potenzial ausschöpfen, und Landwirten helfen zu verstehen, welchen Nutzen sie aus der Technologie ziehen.
Die Möglichkeit reicht über eine einzelne Interaktion hinaus: relevante Begleitung entlang der gesamten Customer Journey, die Landwirten hilft, ihre Geräte besser zu nutzen und gleichzeitig Effizienz und Nachhaltigkeit zu verbessern.
Das ist die Art von Herausforderung, an deren Lösung OpenAI-FDEs arbeiten: Organisationen dabei zu helfen, von KI-Fähigkeiten zu Systemen zu gelangen, die in komplexen, realen Umgebungen praktischen Nutzen liefern.
Aber die Probleme sind oft völlig offen, es gibt möglicherweise keine etablierte Ground Truth, und es gibt kein Playbook. Alle wollen etwas bauen, das noch nie existiert hat. Weniger Menschen wollen tun, was nötig ist, um dorthin zu gelangen.
Talentierte FDEs zu finden und gleichzeitig die Messlatte für „gut genug“ zu erhöhen, hat ständiges Experimentieren und Ausprobieren bedeutet.
Beginne mit dem Ergebnis
Zu Beginn jeder Sitzung des FDE-Teams zeige ich eine Folie mit einem zentralen Wert: „Beginne mit dem Ergebnis, tue, was zum Erfolg nötig ist, und folge dann mit Skalierung.“
Ein beeindruckender Demo kann viel bewirken, bevor jemand fragt, ob es in der realen Welt funktioniert.
Unsere Aufgabe ist es, das Problem des Kunden auf einem Standard zu lösen, zu dem wir uns im Produktivbetrieb bekennen können.
Mitte 2025 hatten wir rund 15 FDEs, die mit einem großen Halbleiterkunden an 10+ Anwendungsfällen arbeiteten. Das Ziel war, ihren Verifizierungsprozess KI-nativ zu gestalten, unter anderem:
Generierung gerichteter Tests
Root Cause Analysis und Debugging
Ein Architektur-Assistent
Die Verifikation macht in dieser Branche etwa 70% des Aufwands eines Projekts aus. Die Gelegenheit war enorm, und es gab viele mögliche Ausgangspunkte.
Einige FDEs waren erst wenige Tage zuvor zu OpenAI gestoßen und hatten noch nie mit Halbleitern gearbeitet. Sie arbeiteten im Verifikationsteam des Kunden mit, studierten Chipdesign in ihrer Freizeit und entwickelten gemeinsam mit den Ingenieuren Evals, um zu testen, ob die KI nützliche Tests generieren und Chipfehler korrekt diagnostizieren konnte.
Parallel zu diesem Lernprozess bauten wir maßgeschneiderte Harnesses für die einzelnen Anwendungsfälle. In den ersten 3-6 Monaten gingen alle davon in Produktion und wurden von ersten Nutzern übernommen. Der Lohn war der Blick auf die Kennzahlen:
~48% Zeitersparnis durch KI-basierte gerichtete Testgenerierung.
22% mediane Leistungsverbesserung durch Kernel-Optimierung.
Wochen des Debuggings, komprimiert auf Stunden
Als wir uns das Ganze zurückgespielt haben, fragte der Chief Hardware Officer: „Habt ihr vor eurem Kommen hier als Chip-Designer gearbeitet?“
Unsere FDEs müssen die Branche nicht am ersten Tag kennen, aber es ist ihre Verantwortung, sie zu lernen.
Da Coding-Assistenten die Softwareentwicklung beschleunigen, wird das Verständnis des Geschäfts der Kundinnen und Kunden noch wichtiger. Wir stellen Teams zusammen, die aus einer Mischung aus Generalisten und Domänenexpertinnen und -experten bestehen.
Man braucht genug Wissen, um fundierte Urteile zu fällen, und genug Neugier, um Annahmen über den Status quo in Frage zu stellen.
In den Life Sciences zum Beispiel helfen die wissenschaftlichen Hintergründe unserer FDEs dabei, das Vertrauen von Forschenden zu gewinnen, die an präklinischen Aufgaben der Arzneimittelforschung arbeiten, wie Zielvalidierung und -priorisierung, Genexpressionsanalyse und die Rekonstruktion chemischer Syntheserouten. Diese Expertise ermöglicht es ihnen, fundierte Einschätzungen dazu beizutragen, wie diese Workflows verbessert werden könnten.
Erfolg wiederholbar machen
Wir hatten gezeigt, dass diese Workflows Mehrwert liefern können, aber jeder erforderte noch zu viel individuelle Integration, um ihn auf ein anderes Team auszuweiten. Die nächste Herausforderung bestand darin, diese Ergebnisse zu bewahren und gleichzeitig die Software einfacher bereitzustellen und zu warten.
Bis dahin hatte Codex an Fähigkeiten gewonnen. Ein FDE testete, ihre Anwendung darauf aufzubauen, und arbeitete dann mit dem Team daran, die Anwendungsfälle auf einen gemeinsamen Harness mit Codex als Kern zu übertragen.
Individuelle Anwendungen wurden zu Plugins und Skills, die auf gemeinsamen Codex-Primitiven aufbauten. Codex wurde auch zur Schnittstelle, sodass wir die separaten Terminal-UIs und CLIs, die wir für einzelne Anwendungsfälle geschrieben hatten, ausmustern konnten.
Wir konnten etwa 90% des individuellen Codes aus jedem Projekt entfernen, und dies veränderte, wie wir diese Workflows erstellten, pflegten und skalierten:
Wir konnten von zentralen Verbesserungen an Codex profitieren, wodurch sich der Umfang an Glue-Code verringerte, der für jeden einzelnen Anwendungsfall erforderlich war
Zentrale Funktionen wurden als Skills und Plugins gebündelt, wodurch sie sich leichter untereinander teilen und vom AI CoE zentral steuern ließen. Das bedeutete, dass die Erweiterung von einem Team zum nächsten so einfach sein konnte wie das Einsetzen neuer Konnektoren/MCP-Server, das Erstellen neuer Evals (wofür wir ebenfalls einen Skill hatten) und das An-den-Start-Gehen.
In einem Beispiel aus August 2026 dauerte die erste Bereitstellung zwei Monate. Die Erweiterung der Lösung auf ein zweites Team dauerte einen Tag. Die nächsten Teams kamen bei der Skalierung schneller an Bord – das hat sich fortgesetzt, mit einem Anwendungsfall im August 2026, bei dem das zweite Team 1 Tag brauchte, nachdem die erste Bereitstellung 2 Monate gedauert hatte.
Das ist eine Variante, uns selbst überflüssig zu machen. Die Arbeit, die wir bis zur Produktionsreife geleistet hatten, legte fest, was zählte. Als sich das zugrunde liegende Produkt verbesserte, konnten wir einen Großteil unserer individuellen Implementierung ersetzen und den Mehrwert, den sie lieferte, erhalten.
Deshalb ist die Reihenfolge wichtig. LLMs ermöglichen es uns, schnell zu bauen. Nutze diese Geschwindigkeit, um etwas Wertvolles in die Hände der Nutzerinnen und Nutzer zu bringen, lerne, was sich in der Praxis bewährt, und skaliere dann, was funktioniert.
Dasselbe Prinzip gilt für alle Mandate.
OpenAI Presence, unser Produkt für Enterprise-Sprach- und Chat-Agenten, entstand aus echten Kundenbereitstellungen. Die Arbeit begann mit Swarm(öffnet in einem neuen Fenster) und entwickelte sich über die Agents APIweiter, und heute bearbeitet ein Kunde inzwischen mehr als die Hälfte seiner Anrufe mit KI.
Diese Bereitstellungen in die Produktion zu bringen, zeigte uns, welche Probleme eine individuelle Lösung brauchten und welche Bausteine andere Teams nutzen konnten. Wir haben diese Bausteine in Presence eingebracht, sodass Entwicklerinnen und Entwickler regulierte Workflows einfacher automatisieren können, ohne die zugrunde liegende Infrastruktur neu aufzubauen. Jede Bereitstellung half, das Produkt zu formen, und gab dem nächsten Kunden einen besseren Ausgangspunkt.
Mit Thrive Holdingsarbeiteten OpenAI-FDEs und Forschende Seite an Seite mit Ingenieuren und Buchhaltern daran, Tax AI für Crestes Steuerberatungsunternehmen zu entwickeln. Während des Pilotprojekts verarbeitete Tax AI 7,000 Steuererklärungen und steigerte den Durchsatz um etwa 50%.
Eine der größten Herausforderungen war die Automatisierung von Mietimmobilien-Erklärungen, die sechs Wochen Engineering- und Praktiker-Überprüfung erforderte, um 90% Präzision und Recall zu erreichen. Die Arbeit schuf wiederverwendbare Muster, die es erleichterten, Tax AI auf andere komplexe Steuerformulare auszuweiten.
Die Teams wenden denselben Ansatz nun auf Buchhaltung, Prüfung und IT-Support an – und bauen Systeme, die sich durch Feedback von Praktikern und den Einsatz in der realen Welt verbessern.
Die Intelligenzlücken schließen, sobald sie auftreten
Manchmal ermöglicht uns ein besseres Produkt, das, was wir gebaut haben, zu vereinfachen, aber manchmal kann das Modell selbst die Aufgabe noch nicht erfüllen.
Wenn wir nur das bauen, was die heutigen Modelle bereits ermöglichen, werden wir die Intelligenzlücken nicht aufdecken, die Research als nächstes schließen muss. Deshalb beginnen viele unserer wichtigen Projekte genau an diesen Grenzen, mit der gemeinsamen Verpflichtung von Kunde, FDE und Research, diese gemeinsam zu bewältigen.
Wir hatten bereits eine Kundenservice-Plattform mit einem großen Telekommunikationskunden entwickelt, und diese wollte sie auf Sprache ausweiten.
Sprache machte rund 90% ihres Kundenservice-Volumens aus. Diese Fälle waren teurer zu bearbeiten als Chat und brachten eine Reihe neuer technischer Herausforderungen mit sich, um Akzente, Tonlage sowie Latenz/Genauigkeit auf Produktionsniveau zu bringen. Das richtig hinzubekommen, würde einen erheblichen Unterschied für ihr Geschäft machen.
Während der Scoping-Phase erzielte unser Modell bei den wichtigsten Evals, mit denen wir bewerteten, ob es die Aufgabe im Produktivbetrieb bewältigen konnte, rund 60%. Wir waren an die Grenzen seiner Fähigkeiten gestoßen. Function Calling und Befehlsbefolgung in Kundenservice-Szenarien mussten sich verbessern.
Wir haben das dem Kunden erklärt und die Research-Abteilung in die Arbeit eingebunden. Das FDE-Team arbeitete mit dem Kunden zusammen, um die Plattform aufzubauen und festzulegen, was das Modell leisten musste. Die Research-Abteilung arbeitete daran, die Fähigkeitslücken zu schließen, wobei uns fortlaufende Modell-Snapshots ermöglichten, die Fortschritte an den Anforderungen des Kunden zu messen.
Über sechs Monate stieg die Leistung bei den wichtigsten Evals von rund 60% auf 80% und dann auf über 90%, womit das für den Produktivbetrieb erforderliche Niveau erreicht wurde.
Das daraus entstandene Sprachmodell unterstützt nun die Bereitstellung dieses Kunden, weitere individuelle Kundenservice-Bereitstellungen sowie verwaltete Bereitstellungen über Presence. Ein Problem, das im Geschäft eines Kunden auftrat, half dabei, Verbesserungen zu identifizieren, die vielen anderen zugutekommen konnten.
Jeder Teil war wichtig. Der Kunde verpflichtete sich, an einem Problem zu arbeiten, das das Modell noch nicht lösen konnte. Das FDE-Team blieb nah genug dran, um dieses Problem einzugrenzen, die Plattform aufzubauen und das Engagement von Anfang bis Ende voranzutreiben. Die Research-Abteilung verbesserte die zugrunde liegenden Modellfähigkeiten.
Dies ist die andere Variante, uns selbst überflüssig zu machen: zu helfen, ein Problem, das heutige Modelle nicht lösen können, in eine Fähigkeit umzuwandeln, die künftige Modelle liefern können. Der Ertrag unserer Arbeit reicht über die Stunden hinaus, die wir mit einem einzelnen Kunden verbringen.
Sucht euch das schwierigere Problem
Ich bin zu OpenAI gekommen, um zu helfen, KI in der alltäglichen Arbeit der Menschen nützlich zu machen. Das leitet das Team bis heute. Ich sage dem Team oft, dass in den meisten Fällen der LLM-Entwicklung das Occamsche Rasiermesser gilt – die einfachste Lösung ist die beste. In einem Unternehmen, das durch seine Spitzenforschung definiert ist, und in einer Branche, die von Übertreibungen geprägt ist, wollen wir Dinge bauen, die zuverlässig funktionieren und auf die Leute in der Praxis sich verlassen können.
Das Ziel jedes Engagements ist es, das Weitere zu verbessern: ein Produkt, das sich leichter bereitstellen lässt, ein Modell, das eine schwierigere Aufgabe bewältigen kann, oder weniger individuelle Arbeit für den nächsten Kunden.
Wenn Sie ein schwieriges Problem haben, das Sie lösen möchten, würden wir gerne mit Ihnen arbeiten. Wenn Sie mithelfen möchten, diese Probleme zu lösen, würden wir uns freuen, wenn Sie zu uns kommen.
Was tun wir also, wenn Codex die Arbeit bewältigen kann, für deren Aufbau wir Monate gebraucht haben?
Sucht euch das schwierigere Problem.