Als Codex herauskam, fragte mich jemand im Team: „Was machen wir, wenn Codex einfach im ersten Anlauf die Anwendungsfälle lösen kann, an denen wir die letzten Monate gebaut haben?“
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 bauen, auf die sie sich verlassen können. Was wir dabei lernen, hilft, unsere Produkte zu formen, und gibt der Forschung konkrete Probleme zum Lösen.
Das ist Fortschritt. Wenn wir uns alle paar Monate überflüssig machen, erfüllt unser FDE-Team seine Aufgabe.
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 zu können scheinen, und dem, was Menschen zuverlässig nutzen können, um ihre Arbeit zu erledigen.
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 bei einem Benchmark gut ab, kann die Arbeit aber nicht mit realen Variablen und Einschränkungen bewältigen.
Wir konzentrieren uns auf die schwierigsten Probleme der Kunden. Wo unsere Modelle die Arbeit heute erledigen können, arbeiten wir mit dem Produktteam und dem Kunden daran, die Lösung wiederholbar zu machen, und wo sie an ihre Grenzen stoßen, arbeiten wir mit Kunden und der Forschung daran, die Lücke zu definieren und Verbesserungen vorzunehmen. Unser Ziel ist, dass jeder Einsatz den nächsten Kunden mit einem besseren Ausgangspunkt lässt – wenn wir den Boden so weit anheben, dass unsere Kunden beim nächsten Mal keine FDEs mehr benötigen, 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, war, 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 Chemikalienverbrauch um bis zu 70% senkt.
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 setzte OpenAIs APIs ein, 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 ihr volles Potenzial möglicherweise nicht ausschöpfen, und Landwirten helfen zu verstehen, welchen Nutzen sie aus der Technologie ziehen.
Die Möglichkeit geht über jede einzelne Interaktion hinaus: relevante Begleitung entlang der gesamten Customer Journey zu bieten, damit Landwirte ihre Geräte besser nutzen und zugleich Effizienz und Nachhaltigkeit verbessern.
Das ist die Art von Herausforderung, die OpenAI-FDEs zu lösen arbeiten: Organisationen zu helfen, von KI-Fähigkeiten zu Systemen zu gelangen, die in komplexen, realen Umgebungen praktischen Wert liefern.
Doch die Probleme sind oft völlig offen, es gibt möglicherweise keine etablierte Grundwahrheit, und es gibt kein Playbook. Jeder will etwas bauen, das noch nie existiert hat. Weniger Menschen wollen das tun, was nötig ist, um dorthin zu gelangen.
Talentierte FDEs zu finden und zugleich die Messlatte für „gut genug“ anzuheben, bedeutete ständiges Experimentieren und Ausprobieren.
Mit dem Ergebnis beginnen
Zu Beginn jeder Sitzung des FDE-Teams zeige ich eine Folie mit einem Kernwert: „Mit dem Ergebnis beginnen, tun, was zum Erfolg nötig ist, dann mit der Skalierung folgen“.
Eine beeindruckende Demo kann eine ganze Weile überzeugen, bevor jemand fragt, ob sie in der realen Welt funktioniert.
Unsere Aufgabe ist es, das Problem des Kunden auf einem Niveau zu lösen, hinter dem wir in der Produktion stehen können.
Mitte 2025 arbeiteten rund 15 FDEs mit einem großen Halbleiterkunden an 10+ Anwendungsfällen. Das Ziel war, ihren Verifikationsprozess KI-nativ zu machen, abgedeckt wurden:
Generierung gerichteter Tests
Root-Cause-Analyse und Debugging
Ein Architektur-Assistent
Verifikation kann in dieser Branche ~70% des Aufwands eines Projekts ausmachen. Die Möglichkeit war enorm, und es gab viele mögliche Ausgangspunkte.
Einige FDEs waren erst wenige Tage zuvor zu OpenAI gestoßen und hatten noch nie in der Halbleiterbranche gearbeitet. Sie embeddeten sich im Verifikationsteam des Kunden, 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.
Neben diesem Lernprozess bauten wir individuelle Harnesses für die einzelnen Anwendungsfälle. Innerhalb der ersten 3-6 Monate erreichten alle davon die Produktion und eine frühe Nutzeradoption. Der Lohn war der Blick auf die Kennzahlen:
~48 % Zeitersparnis durch KI-gestützte gerichtete Testgenerierung.
22 % mediane Leistungssteigerung durch Kernel-Optimierung.
Wochen des Debuggings auf Stunden komprimiert
Als wir das alles präsentierten, fragte der Chief Hardware Officer: „Habt ihr als Chipdesigner gearbeitet, bevor ihr hierher gekommen seid?“
Unsere FDEs tun das nicht müssen die Branche nicht am ersten Tag kennen, aber es ist ihre Verantwortung, sie zu lernen.
Da Coding-Assistants die Softwareentwicklung beschleunigen, wird das Verständnis des Geschäftes der Kunden noch wichtiger. Wir stellen Teams zusammen, die aus einer Mischung aus Generalisten und Domain-Experten bestehen.
Man benötigt ausreichend Wissen, um fundierte Urteile zu fällen, und genug Neugier, um Annahmen über den Status quo in Frage zu stellen.
In den Lebenswissenschaften beispielsweise helfen den FDEs ihre naturwissenschaftlichen Hintergründe dabei, das Vertrauen von Forschern zu gewinnen, die an präklinischen Aufgaben der Arzneimittelforschung wie Target-Validierung und -Priorisierung, Genexpressionsanalyse und Rekonstruktion chemischer Syntheserouten arbeiten. Diese Expertise ermöglicht es ihnen, fundierte Beiträge zur Frage einzubringen, wie sich diese Workflows verbessern ließen.
Erfolg wiederholbar machen
Wir hatten gezeigt, dass diese Workflows Mehrwert liefern konnten, aber jeder erforderte noch zu viel individuelle Integration, um auf ein anderes Team ausgeweitet zu werden. Die nächste Herausforderung bestand darin, diese Ergebnisse zu bewahren und die Software gleichzeitig einfacher bereitzustellen und zu warten.
Bis dahin hatte Codex an Fähigkeiten gewonnen. Ein FDE testete den Neuaufbau seiner Anwendung auf Basis von Codex und arbeitete dann mit dem Team daran, die Anwendungsfälle auf ein gemeinsames Harness mit Codex im Kern zu übertragen.
Individuelle Anwendungen wurden zu Plugins und Skills, die auf gemeinsamen Codex-Primitives 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 rund 90% des individuellen Codes aus jedem Projekt entfernen, und dies veränderte, wie wir diese Workflows erstellten, warteten und skalierten:
Wir konnten von zentralen Verbesserungen an Codex profitieren, was den Umfang des für jeden einzelnen Anwendungsfall erforderlichen Glue-Code reduzierte
Zentrale Funktionen wurden als Skills und Plugins gebündelt, was sie leichter teilbar machte und eine zentrale Steuerung durch das AI CoE ermöglichte. Das bedeutete, dass die Erweiterung von einem Team zum nächsten so einfach sein konnte wie das Einsetzen neuer Connectoren/MCP-Server, der Aufbau neuer Evals (wofür wir ebenfalls einen Skill hatten) und der Start des Betriebs.
In einem Beispiel aus August 2026 dauerte die anfängliche Bereitstellung zwei Monate. Die Erweiterung der Lösung auf ein zweites Team dauerte einen Tag. Die nächsten Teams wurden beim Skalieren schneller integriert – das hat sich fortgesetzt, wobei ein Anwendungsfall im August 2026 für das zweite Team nach einer anfänglichen Bereitstellung von 2 Monaten nur 1 Tag benötigte.
Das ist eine Version davon, 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 gleichzeitig den Mehrwert erhalten, den sie lieferte.
Deshalb ist die Reihenfolge wichtig. LLMs ermöglichen es uns, schnell zu bauen. Nutze diese Geschwindigkeit, um etwas Wertvolles in die Hände der 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-Agents, entstand aus realen Kundeneinsätzen. 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.
Die Inbetriebnahme dieser Deployments in der Produktion lehrte uns, welche Probleme eine individuelle Lösung benötigten und welche Bausteine andere Teams verwenden konnten. Wir brachten diese Bausteine in Presence ein, was es Entwicklern erleichtert, regulierte Workflows zu automatisieren, ohne die zugrunde liegende Infrastruktur neu zu bauen. Jedes Deployment half, das Produkt zu formen, und gab dem nächsten Kunden einen besseren Ausgangspunkt.
Bei Thrive Holdingsarbeiteten OpenAI-FDEs und Forscher Seite an Seite mit Ingenieuren und Buchhaltern, um Tax AI für Cretes Steuerberatungsgesellschaften zu entwickeln. Im Pilotprojekt verarbeitete Tax AI 7,000 Steuererklärungen und steigerte den Durchsatz um etwa 50%.
Eine der größten Herausforderungen war die Automatisierung von Mietobjekt-Deklarationen, für die sechs Wochen Engineering und Prüfung durch Fachleute erforderlich waren, um 90% Präzision und Recall zu erreichen. Die Arbeit schuf wiederverwendbare Muster, die es erleichterten, Tax AI auf andere komplexe Steuervordrucke auszuweiten.
Die Teams wenden denselben Ansatz nun auf Buchhaltung, Wirtschaftsprüfung und IT-Support an – sie bauen Systeme, die sich durch Feedback von Fachleuten und den Einsatz in der realen Welt verbessern.
Intelligenzlücken schließen, sobald sie auftreten
Manchmal erlaubt uns ein besseres Produkt, zu vereinfachen, was wir gebaut haben, 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. Daher beginnen viele unserer wichtigsten 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 das Unternehmen wollte diese auf Sprache ausweiten.
Sprache machte rund 90% ihres Kundenservicevolumens aus. Diese Fälle waren teurer zu bearbeiten als Chat und brachten eine Reihe neuer technischer Herausforderungen mit sich, um Akzente, Tonfall 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 erreichte unser Modell rund 60% bei den wichtigsten Evals, mit denen wir bewerteten, ob es die Aufgabe in der Produktion bewältigen könnte. Wir waren an die Grenzen seiner Fähigkeiten gestoßen. Function Calling und Befehlsbefolgung in Kundenservice-Szenarien mussten verbessert werden.
Wir haben das dem Kunden erklärt und die Forschung in die Arbeit eingebunden. Die FDE arbeitete mit dem Kunden daran, die Plattform zu erstellen und festzulegen, was das Modell leisten sollte. Die Forschung arbeitete daran, die Fähigkeitslücken zu schließen, wobei uns fortlaufende Modell-Snapshots ermöglichten, den Fortschritt an den Anforderungen des Kunden zu messen.
Über sechs Monate hinweg stieg die Leistung bei den wichtigsten Evals von rund 60% auf 80% und dann auf über 90%, womit das für den Produktiveinsatz erforderliche Niveau erreicht wurde.
Das daraus resultierende Sprachmodell unterstützt heute die Bereitstellung dieses Kunden, weitere individuelle Kundenservice-Bereitstellungen sowie verwaltete Bereitstellungen über Presence. Ein Problem im Geschäft eines Kunden 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. Die FDE blieb nah genug dran, um dieses Problem zu formulieren, die Plattform zu erstellen und das Engagement von Anfang bis Ende voranzutreiben. Die Forschung 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 zukünftige Modelle liefern können. Der Ertrag unserer Arbeit reicht über die Stunden hinaus, die wir mit jedem einzelnen Kunden verbringen.
Finden Sie das schwierigere Problem
Ich bin zu OpenAI gekommen, um dazu beizutragen, 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 Occam-Razor-Prinzip gilt—die einfachste Lösung ist die beste. In einem Unternehmen, das durch seine Forschung an der Spitze definiert ist, und in einer Branche, die von Übertreibung geprägt ist, wollen wir Dinge bauen, die zuverlässig funktionieren und auf die Menschen in der Praxis sich verlassen können.
Das Ziel ist, dass jedes Engagement das Verbessert, was danach kommt: ein Produkt, das leichter bereitzustellen ist, 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 zusammenarbeiten. 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 benötigt haben?
Finden Sie das schwierigere Problem.