Cosa significa FDE in OpenAI

Quando è stato lanciato Codex, qualcuno nel team mi ha chiesto: "Cosa facciamo quando Codex può risolvere in un solo colpo i casi d'uso su cui abbiamo lavorato negli ultimi mesi?"

Questa domanda va al cuore di cosa significa FDE in OpenAI. Lavoriamo a fianco dei clienti per comprendere i loro problemi più difficili e costruire soluzioni su cui possono fare affidamento. Ciò che impariamo aiuta a plasmare i nostri prodotti e fornisce alla Ricerca problemi concreti da risolvere.

Questo è progresso. Se riusciamo a renderci obsoleti ogni pochi mesi, il nostro team FDE sta facendo il suo lavoro.

La nascita del team FDE

Ho fondato il team all'inizio del 2025 per colmare ciò che chiamiamo "il divario di distribuzione": la distanza tra ciò che i modelli sembrano capaci di fare e ciò che le persone possono utilizzare in modo affidabile per il loro lavoro.

Le capacità dei modelli si sono evolute più velocemente dei sistemi e dei processi necessari per metterli in pratica. A volte manca un prodotto. A volte un modello si comporta bene in una benchmark ma non riesce a svolgere il lavoro con le variabili e i vincoli della vita reale.

Ci concentriamo sui problemi più difficili dei clienti. Laddove i nostri modelli possono fare il lavoro oggi, lavoriamo con il Prodotto e il cliente per rendere la soluzione ripetibile e, laddove non riescano, lavoriamo con i clienti e la Ricerca per definire il divario e fare miglioramenti. Il nostro obiettivo è che ogni interazione lasci il cliente successivo con un punto di partenza migliore: se riusciamo a sollevare il livello base al punto che i nostri clienti non hanno più bisogno degli FDE per risolvere questa classe di problemi la prossima volta, abbiamo fatto un buon lavoro.

Esempi concreti

La sfida per John Deere, un'azienda agricola di 200 anni, era come scalare i consigli personalizzati per i contadini.

Un esempio è See & Spray, la sua tecnologia di controllo delle erbacce di precisione, che utilizza telecamere e machine learning per identificare e spruzzare le erbacce invece di trattare interi campi, riducendo l'uso di prodotti chimici fino al 70%. Ma realizzare questi benefici dipende dal fatto che i contadini sappiano come configurare la tecnologia, pianificare la loro stagione e adattare le loro pratiche man mano che le condizioni cambiano.

John Deere ha distribuito le API di OpenAI per aiutare a rendere quel supporto personalizzato e scalabile.

L'IA può rispondere alle domande dei contadini in linguaggio naturale, fornire guide di configurazione e raccomandazioni su misura, identificare quando l'attrezzatura potrebbe non dare il meglio di sé e aiutare i contadini a comprendere il valore che stanno ottenendo dalla tecnologia.

L'opportunità va oltre qualsiasi singola interazione: fornire guide rilevanti durante tutto il percorso del cliente, aiutando i contadini a fare un uso migliore delle loro attrezzature migliorando al contempo l'efficienza e la sostenibilità.

Questo è il tipo di sfida che gli FDE di OpenAI lavorano per risolvere: aiutare le organizzazioni a passare dalle capacità dell'IA a sistemi che forniscono un valore pratico in ambienti complessi e reali.

La sfida dei semiconduttori

Nella metà del 2025, avevamo circa 15 FDE che lavoravano con un grande cliente nel settore dei semiconduttori su 10+ casi d'uso. L'ambizione era rendere il loro processo di verifica nativo dell'IA, coprendo:

• Generazione di test diretti
• Analisi delle cause radice e debug
• Un assistente di architettura

La verifica può rappresentare fino al 70% dello sforzo di un progetto in questo settore. L'opportunità era enorme e c'erano molti posti da cui partire.

Alcuni FDE avevano appena iniziato a lavorare in OpenAI e non avevano mai lavorato nei semiconduttori. Si sono integrati con il team di verifica del cliente, hanno studiato il design dei chip nel loro tempo libero e hanno costruito valutazioni con gli ingegneri per testare se l'IA potesse generare test utili e diagnosticare correttamente i guasti dei chip.

Insieme a questo apprendimento, abbiamo costruito harness personalizzate per i singoli casi d'uso. Nei primi 3-6 mesi, tutti hanno raggiunto la produzione e l'adozione iniziale da parte degli utenti. Il risultato è stato vedere le metriche:

• ~48% di tempo risparmiato grazie alla generazione di test diretti basati su IA.
• Miglioramento delle prestazioni medie del 22% grazie all'ottimizzazione del kernel.
• Settimane di debug comprese in ore.

Quando abbiamo presentato tutto questo al Chief Hardware Officer, ha chiesto: "Avete lavorato come progettisti di chip prima di venire qui?"

I nostri FDE non devono conoscere il settore il primo giorno, ma è loro responsabilità impararlo.

Il valore della curiosità

Mentre gli assistenti di codifica rendono il software più veloce da costruire, comprendere l'attività del cliente diventa ancora più importante. Costruiamo team con una miscela di generalisti ed esperti di dominio.

È necessario avere abbastanza conoscenze per fare giudizi solidi e abbastanza curiosità per mettere in discussione le assunzioni sullo status quo.

Ad esempio, nelle scienze della vita, i background scientifici dei nostri FDE li aiutano a guadagnare la fiducia dei ricercatori che lavorano su compiti di scoperta di farmaci pre-clinici come la validazione e la prioritizzazione dei target, l'analisi dell'espressione genica e la ricostruzione delle vie di sintesi chimica. Questa esperienza consente loro di contribuire con un giudizio informato su come potrebbero migliorare questi flussi di lavoro.

Rendere il successo ripetibile

Avevamo dimostrato che questi flussi di lavoro potevano fornire valore, ma ognuno di essi richiedeva ancora troppa integrazione personalizzata per estendersi a un'altra squadra. La sfida successiva era preservare quei risultati rendendo il software più facile da distribuire e mantenere.

In quel momento, Codex era cresciuto in capacità. Un FDE ha testato la ricostruzione della loro applicazione intorno a esso, poi ha lavorato con il team per spostare i casi d'uso su un harness comune con Codex al suo centro.

Le applicazioni personalizzate sono diventate plugin e competenze costruite su primitive Codex comuni. Codex è diventato anche l'interfaccia, permettendoci di ritirare le interfacce utente terminali e CLI separate che avevamo scritto per i singoli casi d'uso.

Siamo riusciti a rimuovere circa il 90% del codice personalizzato da ogni progetto e questo ha cambiato il modo in cui costruivamo, mantenevamo e scalavamo questi flussi di lavoro:

• Abbiamo potuto beneficiare di miglioramenti centralizzati a Codex, riducendo la quantità di codice di colla richiesto per ogni singolo caso d'uso.
• Le funzionalità chiave sono state raggruppate come competenze e plugin, rendendole più facili da condividere tra di noi e da controllare centralmente dall'AI CoE. Questo significava che l'estensione da una squadra all'altra poteva essere semplice come scambiare nuovi connettori/servitori MCP, costruire nuove valutazioni (per le quali avevamo anche una competenza) e partire.
• In un esempio di agosto 2026, il primo deployment ha richiesto due mesi. L'estensione della soluzione a una seconda squadra ha richiesto un giorno. Le squadre successive sono state integrate più velocemente man mano che scalavamo: questo è continuato, con un caso d'uso ad agosto 2026 che ha richiesto 1 giorno per la seconda squadra dopo che il primo deployment ha richiesto 2 mesi.