L’ex fondatore tecnico di Meta condivide tre cose che ogni CTO deve fare prima di occuparsi di 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 di IA che offre alle organizzazioni un unico luogo in cui distribuire, governare, monitorare e ottimizzare ogni agente in produzione.

Abbiamo parlato con James per scoprire 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 il CEO e cofondatore di Guild.ai, il piano di controllo per gli agenti di 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 in 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 fondamentali per sviluppatori che alimentavano i prodotti di Meta. Il mio team ha creato il primo agente di IA interno di Meta, con 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.

Con 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à editoriali di Yahoo dopo che l'azienda aveva acquisito Luminate, una società di tecnologia interattiva per le immagini da me fondata. Prima ancora, ho guidato team in Oracle, Netscape Communications, Tellme (acquisita da Microsoft) e in diverse mie aziende.

Come l'IA ha contribuito a rimuovere 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 congelava la propria base di codice ogni anno da metà dicembre a gennaio, perché quello è il periodo di maggior traffico per i suoi prodotti. Per anni, al fine di evitare incidenti in produzione durante le settimane più rischiose, nessuno effettuava distribuzioni. Era una misura sicura, ma bloccava anche la produttività dell'intera azienda per oltre un mese.

Il mio team ha creato e reso a codice aperto Diff Risk Score, un sistema basato su LLM che valuta la probabilità che una modifica al codice provochi un arresto della produzione. Invece di considerare ogni modifica altrettanto pericolosa durante il periodo di blocco, il modello effettuava una valutazione basata sul rischio. Assegnava un punteggio di rischio continuo a ogni modifica, ottimizzato per un'elevata capacità di rilevamento: per esempio, segnalava il 10% delle modifiche individuando il 60% di quelle che causavano effettivamente incidenti. Il modello consentiva di distribuire le modifiche a basso rischio anche durante il blocco, ma tratteneva quelle segnalate come rischiose.

Di conseguenza, il blocco non è più una situazione tutto o niente. Inoltre, Diff Risk Score sta consentendo a Meta di iniziare a rimuovere del tutto il blocco del codice: gli ingegneri stanno recuperando settimane del loro calendario che prima erano tempo perso, senza rinunciare alla rete di sicurezza offerta dal blocco.

È un buon esempio della mia filosofia più ampia: 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 trovino da soli il modo di sfruttarla.

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 capacità di applicare quel giudizio su larga scala.

Ora l'IA contribuisce al lavoro nella valutazione dei rischi, così come nella scoperta di strumenti e flussi di lavoro.

Dove gli esseri umani danno il meglio:

• Governance e barriere di controllo sugli agenti stessi: Quando i team integrano modelli di ragionamento e agenti in profondità nell'infrastruttura, si rendono rapidamente conto delle lacune 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 agli esseri umani che utilizzano quell'infrastruttura, ovvero lasciare comunque agli esseri umani la definizione dei limiti di budget, dei confini di accesso e dei requisiti di audit.
• Strategia di adozione: Non si impone l'adozione degli strumenti di IA: l'utilizzo conquistato sul campo è 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 costituiti da un unico elaboratore centrale condiviso da tutti, per poi passare ad armadi rack di server che eseguivano servizi specializzati. Gli agenti stanno seguendo lo stesso percorso.

La vecchia ipotesi consisteva nel creare 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 è costituita da una manciata di strumenti condivisi: è più simile a un ecosistema di agenti specializzati e progettati per uno scopo preciso. Questo impone di ripensare perfino al significato di "architettura" per una base di codice: meno un monolite con plug-in, più un mondo di microservizi, con la differenza 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 risultato coerente. Ho abbandonato questo approccio, sostituendolo con un modello mentale basato sulla forza lavoro. Questo riformula le domande relative alla progettazione dell'organizzazione — chi approva cosa, chi controlla il budget, chi è responsabile quando qualcosa si rompe — come questioni gestionali, 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

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

Quando ero 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 gestire una domanda crescente, cercando letteralmente decine di migliaia di server liberi.

Col senno di poi, tutto questo era evitabile. Se si ipotizza che l'adozione interna possa diventare virale, si integrano i controlli sui costi e i confini di accesso nella piattaforma fin dal primo giorno, anziché ricorrere a un intervento d'emergenza.

I CTO devono riprogettare il confine tra "dove risiede l'IA" e "che cosa può toccare l'IA", spostandolo dall'editor all'infrastruttura, perché è a quel livello che hanno origine i rischi e deve risiedere la governance.

James condivide

I CTO devono riprogettare il confine tra “dove risiede l’IA” e “che cosa può toccare l’IA”, spostandolo dall’editor all’infrastruttura, perché è a quel livello che hanno origine i rischi e deve risiedere la governance.

Perché le organizzazioni devono disporre di un luogo centralizzato in cui creare biforcazioni degli agenti

In quanto ingegnere, ero più bravo a rubare che a programmare. 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 è "inviare una richiesta a un modello"; è consultare un luogo centralizzato per vedere quali agenti esistono già per questa attività e crearne una biforcazione invece di partire da zero. Le organizzazioni devono creare processi che consentano di "rubare" facilmente gli agenti.

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

Ecco i miei consigli:

1. Non imporla — guadagnatevela. L'uso obbligatorio dell'IA per aumentare la produttività mi frustra perché porta a un'adozione superficiale — i migliori strumenti per sviluppatori conquistano il loro utilizzo, e gli sviluppatori sono abbastanza intelligenti da opporsi a chi dice loro quali strumenti apprezzare. I CTO dovrebbero presentare all'organizzazione sfide aziendali di un ordine di grandezza — problemi così grandi che l'IA sia l'unica soluzione realistica. Poi, lasciate che gli ingegneri che li risolvono diventino promotori spontanei. 
2. Smettete di considerare l'IA uno strumento per scrivere codice e iniziate a considerarla un'infrastruttura. Il 2025 è stato l'anno in cui strumenti di codifica come Cursor e Copilot sono diventati di uso comune; ora, i modelli di ragionamento e gli agenti a più passaggi smettono di essere estensioni dell'editor e diventano invece parte dell'infrastruttura delle aziende — inviano codice, eseguono test, aiutano i nuovi ingegneri a iniziare e gestiscono il comportamento in produzione. Se la vostra strategia per l'IA consiste ancora nel chiedervi "quale plug-in per l'IDE dovremmo acquistare?", state risolvendo un problema ormai superato.
3. Governate gli agenti come governereste una forza lavoro, non come governereste un software. Gli agenti alimentati da modelli di ragionamento non sono deterministici: date allo stesso agente due volte lo stesso input e potreste ottenere risultati diversi. Non è un bug da correggere; è la natura fondamentale di questa tecnologia. I CTO gestiscono già quotidianamente 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 i servizi cloud il primo giorno, così come non dareste nulla di tutto questo 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!