L’ex fondatore tecnologico di Meta condivide tre cose che ogni direttore tecnico deve fare prima di occuparsi dell’IA

James Everingham ha guidato l'ingegneria in alcune delle aziende più avanzate al mondo, tra cui Meta. Attualmente è CEO e cofondatore di Guild.ai, un piano di controllo per gli agenti IA che offre alle organizzazioni un unico luogo in cui distribuire, governare, monitorare e ottimizzare ogni agente in produzione.

Abbiamo incontrato James per capire come l'IA stia cambiando i flussi di lavoro dell'ingegneria e cosa debbano cambiare i team di ingegneria prima che l'IA possa essere integrata efficacemente. Ecco cosa ci ha raccontato.

Da Meta a una startup di IA

Sono CEO e cofondatore di Guild.ai, il piano di controllo per gli agenti IA che offre alle organizzazioni un unico luogo in cui distribuire, governare, monitorare e ottimizzare ogni agente in produzione. Abbiamo raccolto 44 milioni di dollari: un round di Serie A guidato da Google Ventures, con la partecipazione di NFX, Acrew, Scribble Ventures, Khosla Ventures e Webb Investment Network. Siamo un team di circa 35 persone con sede a San Francisco.

Prima di questo incarico, ero vicepresidente dell'ingegneria presso Meta DevInfra, dove costruivo e gestivo gli strumenti, i servizi e le piattaforme di base per sviluppatori che alimentano i prodotti di Meta. Il mio team ha creato il primo agente IA interno di Meta, generando un impatto immediato sul modo in cui gli ingegneri di Meta utilizzavano gli strumenti di IA. Durante il mio periodo in Meta, ho anche contribuito a creare Diem e sono stato responsabile dell'ingegneria di Instagram.

Nel corso di una carriera di 40 anni come manager, imprenditore e sviluppatore tecnologico, ho guidato numerosi team di ingegneria di livello mondiale. In Yahoo, ero vicepresidente dell'ingegneria per le proprietà multimediali di Yahoo dopo l'acquisizione di Luminate, un'azienda di tecnologia per immagini interattive che avevo fondato. Prima ancora, ho guidato team presso Oracle, Netscape Communications, Tellme (acquisita da Microsoft) e diverse mie aziende.

Come l'IA ha contribuito a eliminare il blocco annuale del codice di Meta

Quando lavoravo in Meta, abbiamo utilizzato un modello di rischio basato sull'IA per eliminare il blocco annuale del codice.

In precedenza, Meta bloccava la propria base di codice ogni anno da metà dicembre fino a gennaio, perché quello è il periodo di maggiore traffico per i suoi prodotti. Per anni, al fine di evitare incidenti in produzione durante le settimane più rischiose, nessuno distribuiva modifiche. Era una misura sicura, ma rallentava anche la produttività dell'intera azienda per oltre un mese.

Il mio team ha sviluppato e reso open source Diff Risk Score, un sistema basato su un LLM che valuta la probabilità che una differenza di codice provochi un arresto della produzione. Invece di considerare ogni modifica ugualmente pericolosa durante il periodo di blocco, il modello eseguiva un triage del rischio. Assegnava un punteggio di rischio continuo a ogni differenza, ottimizzato per un'elevata copertura: ad esempio, segnalava il 10% delle differenze individuando il 60% delle modifiche che causavano effettivamente incidenti. Il modello consentiva di distribuire le differenze a basso rischio anche durante il blocco, trattenendo invece quelle segnalate come rischiose.

Di conseguenza, il blocco non è più una misura assoluta. Inoltre, Diff Risk Score sta consentendo a Meta di iniziare a eliminare completamente il blocco del codice: gli ingegneri stanno recuperando settimane del loro calendario che prima erano tempo perso, senza rinunciare alla rete di sicurezza fornita dal blocco.

Questo è un buon esempio della mia filosofia generale: non imponete agli ingegneri un mandato sull'IA calato dall'alto, date loro un'infrastruttura — una piattaforma centralizzata, un segnale di rischio, un piano di controllo — e lasciate che siano loro a individuare autonomamente i vantaggi.

Perché gli esseri umani devono essere in grado di spiegare il codice prima che venga messo in produzione

Se non sai spiegarlo, non puoi distribuirlo.

Utilizzo intensamente gli strumenti di IA per accelerare il lavoro, ma consiglio agli ingegneri di richiedere sempre una convalida prima che qualsiasi elemento raggiunga la produzione. L'IA non sostituisce il giudizio ingegneristico: offre agli ingegneri una maggiore leva per applicare tale giudizio su larga scala.

Oggi l'IA contribuisce al lavoro nella valutazione del rischio, oltre che nella scoperta di strumenti e flussi di lavoro.

Dove gli esseri umani eccellono:

• Governance e barriere di protezione relative agli agenti stessi: Quando i team integrano modelli di ragionamento e agenti in profondità nell'infrastruttura, si accorgono rapidamente delle carenze nella governance: gli agenti si moltiplicano più velocemente di quanto chiunque avesse previsto e i budget evaporano da un giorno all'altro. È necessario applicare agli agenti non deterministici lo stesso livello di governance che si applicherebbe alle persone che utilizzano quell'infrastruttura, ovvero gli esseri umani devono continuare a stabilire limiti di budget, confini di accesso e requisiti di audit.
• Strategia di adozione: Non si impone l'adozione degli strumenti di IA: l'utilizzo conquistato è migliore di quello imposto, poiché gli obblighi producono un'adozione superficiale. Decidere come integrare l'IA nel flusso di lavoro di un team è una decisione interamente umana, legata alla leadership e alla cultura: lo strumento può dimostrare il proprio valore, ma la decisione di adottarlo non può essere automatizzata.

Perché i team di ingegneria devono ripensare la propria architettura

I primi sistemi informatici erano basati su un unico computer centrale condiviso da tutti, per poi passare a rack di server che eseguivano servizi specializzati. Gli agenti stanno seguendo lo stesso percorso.

La vecchia ipotesi prevedeva di costruire una manciata di agenti generalisti e centralizzarne l'utilizzo, proprio come si centralizzava la potenza di calcolo. Ma le aziende si rendono conto che la loro realtà non consiste in una manciata di strumenti condivisi: è più simile a un ecosistema di agenti specializzati e creati per scopi specifici. Questo impone di ripensare persino il significato di "architettura" per una base di codice: meno un monolite con componenti aggiuntivi, più un mondo di microservizi, solo che i servizi sono agenti anziché punti terminali.

L'istinto nella maggior parte delle organizzazioni è trattare un agente come qualsiasi altro componente software: scrivere le specifiche, distribuirlo e aspettarsi un output coerente. Ho abbandonato questo approccio, sostituendolo con un modello mentale basato sulla forza lavoro. Questo riformula le domande relative alla progettazione organizzativa — chi approva cosa, chi gestisce il budget, chi è responsabile quando qualcosa si rompe — come questioni manageriali, non di distribuzione. È un modo diverso di strutturare il rapporto di un team con i propri strumenti.

Perché la governance deve essere in atto prima che l'adozione dell'IA decolli

Nei miei ruoli precedenti, avrei voluto che avessimo costruito il livello di governance prima che l'adozione decollasse, non dopo.

Quando lavoravo in Meta, gli ingegneri hanno iniziato a creare e pubblicare i propri agenti sulla piattaforma interna; gli agenti si sono moltiplicati rapidamente e il team dell'infrastruttura si è trovato improvvisamente a lottare per stare al passo con la domanda, cercando letteralmente decine di migliaia di server liberi.

Col senno di poi, tutto questo si sarebbe potuto evitare. Se si presume che l'adozione possa diventare virale internamente, è necessario integrare i controlli sui costi e i confini di accesso nella piattaforma fin dal primo giorno, anziché gestirli come un intervento di emergenza.

I CTO devono riprogettare il confine tra "dove risiede l'IA" e "ciò che l'IA può toccare", spostandolo dall'editor all'infrastruttura, perché è a quel livello che si origina il rischio e deve risiedere la governance.

James Condivide

I CTO devono riprogettare il confine tra “dove risiede l’IA” e “ciò che l’IA può toccare” — spostandolo dall’editor all’infrastruttura, perché è a quel livello che si origina il rischio e deve risiedere la governance.

Perché le organizzazioni devono avere un luogo centralizzato in cui sia possibile creare derivazioni degli agenti

In quanto ingegnere, ero più bravo a fare il ladro che il programmatore. Trovavo qualcosa che soddisfaceva parzialmente le mie esigenze, lo adattavo al mio scopo specifico e imparavo strada facendo.

Il primo passo del flusso di lavoro non è "chiedere qualcosa a un modello": è consultare un luogo centralizzato per vedere quali agenti esistono già per quella determinata attività e crearne una derivazione invece di partire da zero. Le organizzazioni devono creare processi che consentano di appropriarsi facilmente degli agenti.

Tre consigli per i CTO che integrano l'IA nelle organizzazioni tecniche

Ecco i miei consigli:

1. Non imporlo: guadagnatelo. L'uso obbligatorio dell'IA per aumentare la produttività mi lascia frustrato perché porta a un'adozione superficiale: i migliori strumenti per sviluppatori conquistano l'uso sul campo, e gli sviluppatori sono abbastanza intelligenti da opporsi quando viene detto loro quali strumenti apprezzare. I CTO dovrebbero sottoporre all'organizzazione sfide aziendali di ordine di grandezza: problemi così grandi che l'IA sia l'unica soluzione realistica. Poi, lasciate che gli ingegneri che li risolvono diventino evangelisti spontanei. 
2. Smettete di considerare l'IA uno strumento di scrittura e iniziate a considerarla un'infrastruttura. Il 2025 è stato l'anno in cui strumenti di programmazione come Cursor e Copilot sono diventati di uso comune; ora, i modelli di ragionamento e gli agenti multi-passaggio smettono di essere estensioni dell'editor e diventano invece parte dell'infrastruttura delle aziende: inviano codice, eseguono test, aiutano i nuovi ingegneri a inserirsi e gestiscono il comportamento in produzione. Se la vostra strategia per l'IA consiste ancora nel chiedervi "quale estensione per l'IDE dovremmo acquistare?", state risolvendo un problema ormai superato.
3. Gestite gli agenti come gestireste una forza lavoro, non come gestireste un'applicazione. Gli agenti basati su modelli di ragionamento sono non deterministici: date due volte allo stesso agente lo stesso input e potreste ottenere risultati diversi. Non è un bug da correggere: è la natura fondamentale di questa tecnologia. I CTO gestiscono già ogni giorno sistemi non deterministici con i dipendenti. Dovete applicare agli agenti alcune delle stesse misure di sicurezza che applicate alla vostra forza lavoro. Non date a un agente accesso illimitato alla produzione, credenziali root o un budget illimitato per il cloud il primo giorno, così come non dareste nessuna di queste cose a un neoassunto.

Segui gli aggiornamenti

Puoi seguire il lavoro di James Everingham su X e LinkedIn.

Presto arriveranno altre interviste a esperti su The CTO Club!