CTO Circle: cosa hanno imparato i leader tecnologici che stanno costruendo organizzazioni AI-native

Ogni leader dell’engineering cerca di rispondere alle stesse domande, mentre l’AI cambia le regole del gioco: Come organizzare i team di engineering? Su cosa devono investire le organizzazioni, mentre i foundation model continuano a migliorare? Come aumentare la velocità dell’engineering senza introdurre rischi operativi inaccettabili? Qual è la differenza tra organizzazioni AI-augmented e AI-native? 

Non esiste un playbook consolidato per costruire un’organizzazione di engineering AI-native e sono poche le occasioni in cui i leader dell’engineering possono confrontarsi apertamente su ciò che stanno imparando. Queste conversazioni spesso restano confinate all’interno delle singole aziende, plasmate dalle pressioni competitive e da una tecnologia in rapida evoluzione. 

Essendo la piattaforma su cui migliaia di organizzazioni costruiscono le proprie strategie di dati e AI, Snowflake è nella posizione ideale per dare vita a questi confronti. CTO Circle nasce per offrire ai leader dell’engineering uno spazio di fiducia in cui imparare da chi affronta la stessa trasformazione e mettere in discussione le convinzioni consolidate. Ospitata durante lo Snowflake Summit 2026 a San Francisco, la prima edizione ha riunito oltre 350 CTO provenienti da settori come i servizi finanziari, le telecomunicazioni, il retail e la tecnologia per scambiarsi lezioni concrete. 

Il confronto è andato ben oltre i coding assistant e la scelta dei modelli. Si è concentrato invece su come vengono ridisegnate le organizzazioni di engineering, su cosa funziona in produzione e su dove i leader stanno investendo per creare un vantaggio competitivo di lungo periodo. La discussione è confluita nei tre temi che definiscono cosa significhi costruire un’organizzazione di engineering AI-native: usare l’AI in produzione, bilanciare velocità e rischio, progettare i team di engineering per l’AI.

Molte organizzazioni iniziano il proprio percorso nell’AI introducendo coding assistant nei workflow di engineering esistenti. Gli sviluppatori scrivono codice un po’ più rapidamente e la documentazione diventa più facile da produrre. Sono miglioramenti concreti, ma lasciano il sistema di engineering sottostante praticamente invariato.

Vivek Raghunathan, SVP of Engineering di Snowflake, ha invitato i leader a ragionare in modo molto più ampio sull’adozione dell’AI. Vivek ha sostenuto che costruire un’organizzazione di engineering AI-native parte da un cambiamento nella filosofia di management. Invece di considerare la produttività degli sviluppatori un problema di engineering o di cultura, Snowflake ha iniziato a trattarla come un prodotto.

“E se trattassi i tuoi sviluppatori come clienti?” Quella domanda è diventata la base dell’approccio Snowflake alla propria trasformazione dell’engineering. Invece di dare per scontato che il management sapesse di cosa avessero bisogno gli engineer, il team ha applicato gli stessi principi di product management che usa per sviluppare i prodotti destinati ai clienti. 

Ha intervistato gli sviluppatori per capire dove il lavoro rallentava e ha mappato i punti di attrito lungo tutto il ciclo di vita dello sviluppo software. Ha poi definito metriche di riferimento e condotto esperimenti per misurare l’impatto di ogni cambiamento. L’approccio ha unito una chiara sponsorship a livello executive a un’adozione bottom-up. Così i miglioramenti hanno rispecchiato il modo in cui gli engineer lavoravano davvero, non quello che i leader immaginavano.

I risultati sono stati misurabili. In 18 mesi Snowflake ha aumentato di oltre 30 punti il Net Promoter Score interno degli sviluppatori. Nello stesso periodo il rapporto tra sviluppatori soddisfatti e insoddisfatti è arrivato a 4:1. Ma soprattutto, quel miglioramento si è tradotto in un’organizzazione di engineering capace di rilasciare software in modo più efficiente e di adattarsi più rapidamente all’evoluzione continua delle capacità dell’AI.

Vivek ha spiegato anche che la sola adozione non basta per ottenere guadagni di produttività significativi. La vera leva sta nella profondità di utilizzo e nella reale padronanza degli strumenti su larga scala. In Snowflake questo percorso si è sviluppato in tre fasi:

• Adozione: inizia quando gli sviluppatori imparano a usare gli strumenti AI nel lavoro quotidiano. 
• Padronanza: si sviluppa quando gli engineer scoprono workflow ripetibili che producono risultati costantemente migliori. 
• Ottimizzazione: si realizza quando quei workflow diventano conoscenza condivisa dell’organizzazione, a beneficio di ogni engineer.

Un esempio è la raccolta di design pattern di engineering sviluppata internamente in Snowflake. I primi ad adottare l’AI hanno sperimentato tecniche di prompting, metodi di pianificazione e approcci al debugging. Nel tempo l’organizzazione ha documentato i pattern che garantivano risultati migliori in modo costante e li ha resi disponibili a tutto l’engineering. 

Tutti gli sviluppatori avevano accesso agli stessi strumenti AI, ma chi utilizzava workflow collaudati otteneva sistematicamente risultati migliori di chi era rimasto ai primi livelli di adozione. Il vantaggio competitivo è nato dall’istituzionalizzare i modi di lavorare che funzionano, non dal distribuire un ulteriore assistente AI.

Questa attenzione ai workflow cambia anche il modo in cui le organizzazioni concepiscono lo sviluppo software. Poiché l’AI riduce lo sforzo necessario per trasformare le idee in software funzionante, tutti diventano builder. I product manager possono prototipare nuove esperienze, i designer validare i concept direttamente nel codice e gli esperti di dominio aggiungere guardrail per le altre figure coinvolte. Invece di discutere le idee con presentazioni o documenti, i team possono validarle costruendo software funzionante. Il codice diventa sempre più il modo più rapido per verificare le proprie ipotesi.

Jon McNeill, autore di The Algorithm, ha ripreso il tema invitando i leader a rimettere in discussione convinzioni che hanno plasmato le organizzazioni di engineering per decenni. Troppo spesso le aziende partono dalla tecnologia e poi cercano dove applicarla. Jon ha sostenuto che le organizzazioni di successo ribaltano l’equazione. Partono dall’individuare i pochi vincoli di business che contano davvero e ridisegnano i propri sistemi di engineering attorno alla soluzione di quei problemi. Mentre le organizzazioni portano l’AI in produzione, il successo si misurerà meno in base a chi genera più codice o consuma più token e più in base a chi costruisce il sistema di engineering più semplice, rapido ed efficace. Forse la classifica più interessante non sarà quella degli engineer che generano più codice con l’AI o consumano più token, ma quella di chi ha eliminato il maggior numero di passaggi inutili tra un’idea e la produzione.

Con l’AI integrata in tutto il ciclo di vita dello sviluppo software, i leader dell’engineering affrontano una seconda sfida. Ogni aumento della velocità di sviluppo accresce anche la necessità di sistemi affidabili e di disciplina operativa. Le organizzazioni più rapide investono in architetture che rendono possibili entrambe le cose.

Jeremy Burton, General Manager della business unit Observability di Snowflake, ha sostenuto che l’AI è entrata in una nuova fase. La sperimentazione iniziale lascia il posto al deployment in produzione e alle organizzazioni si chiede sempre più di dimostrare un valore di business misurabile, non successi tecnici isolati. Allo stesso tempo, l’AI introduce sfide operative del tutto nuove. Gli agenti AI generano più telemetria, interagiscono con più sistemi e prendono decisioni utilizzando informazioni distribuite in ambienti sempre più complessi. Il ruolo dell’observability cambia: non si tratta più di monitorare l’infrastruttura, ma di fornire il contesto di cui i sistemi AI hanno bisogno per funzionare in modo affidabile.

Jeremy ha messo in discussione uno dei presupposti più diffusi nell’enterprise AI: che ai modelli migliori bastino dati migliori. In realtà, l’AI è efficace solo quanto il contesto a cui può accedere. E quel contesto va ben oltre la telemetria grezza. Comprende la semantica che descrive il significato dei dati, le relazioni catturate da ontologie e knowledge graph e il contesto di business che collega i sistemi. Altrettanto importante è il modo in cui si accede a quel contesto. Gli agenti AI hanno bisogno di interfacce standardizzate, come API, CLI e Model Context Protocol (MCP), per recuperare le informazioni e agire su di esse in modo affidabile, mentre gli engineer hanno bisogno di modi intuitivi per esplorare i dati in profondità e validare gli insight generati dall’AI. 

Un contesto ricco unito a un accesso open trasforma una telemetria frammentata in un ambiente in cui persone e AI possono ragionare in modo efficace, indagare i problemi più rapidamente e prendere decisioni migliori. Le organizzazioni che continuano ad archiviare log, metriche, tracce, dati operativi e contesto di business in sistemi separati rendono difficile per l’AI ragionare in modo accurato sugli ambienti di produzione. La telemetria dell’engineering dovrebbe invece essere trattata come un dato che vive all’interno di una base comune, dove le relazioni tra i sistemi si possono comprendere e interrogare.

Aditya Gaur, Engineering Manager di Netflix, ha mostrato come funziona nella pratica raccontando il lavoro dell’azienda sulla root cause analysis automatizzata. Anche se il progetto viene spesso descritto come un’iniziativa AI, Aditya ha spiegato che il suo successo è dipeso molto più dall’architettura dati che dall’AI in sé. 

Anni prima di introdurre gli agenti AI, Netflix aveva investito nel collegare la telemetria frammentata tra i sistemi, nel modellare le relazioni operative attraverso un’ontologia e un knowledge graph e nel creare un layer di contesto condiviso. Quando l’AI è entrata in gioco, le fondamenta c’erano già. Invece di cercare tra log e dashboard scollegati, gli agenti AI potevano ragionare su una conoscenza operativa strutturata e formulare ipotesi molto più significative durante l’analisi degli incidenti.

Caitlin Colgrove, CTO di Hex, ha affrontato il tema della velocità da un’altra prospettiva. Ha invitato i leader a ripensare cosa significhi muoversi in fretta nell’era dell’AI. Le organizzazioni non possono permettersi di essere AI native solo a metà. Prima o poi arriva il momento di scegliere fino in fondo, ristrutturando il modo in cui i team sviluppano i prodotti, prendono decisioni e integrano l’AI nel lavoro quotidiano. Lo ha descritto come “bruciare le navi”. L’AI deve diventare un elemento fondante del funzionamento del business. 

In un primo momento Hex ha risposto all’arrivo dell’AI generativa creando un team di prodotto AI dedicato. L’approccio ha prodotto feature utili, ma ha anche creato un collo di bottiglia organizzativo. Alla fine Hex ha smantellato l’organizzazione AI centralizzata e ha distribuito la responsabilità su tutti i team di prodotto. Oggi Hex rilascia rapidamente e integra capacità AI in tutto il prodotto, perché l’ownership è nelle mani degli engineer più vicini al problema del cliente.

Chris Kozlowski, Managing Director di Barclays, ha portato nel dibattito la prospettiva enterprise, sottolineando che la velocità crea valore solo se accompagnata da governance e fiducia. In contesti altamente regolamentati, i team di engineering non possono permettersi di scegliere tra innovazione e controllo.

Corey Burke, SVP Engineering di Dialpad, e Arun Rajamanickam, VP of Engineering di project44, hanno descritto come l’AI stia cambiando il ritmo dello sviluppo software. Man mano che gli agenti AI diventano capaci di implementare in autonomia porzioni significative di una feature, gli engineer dedicano meno tempo a scrivere codice e più tempo a definire gli intenti, orchestrare più agenti e validare i risultati. 

Hanno sottolineato che massimizzare la velocità richiede piattaforme di engineering che permettano ai team di sperimentare rapidamente senza compromettere l’affidabilità. L’AI accorcia il percorso che va dall’identificazione di un problema del cliente alla validazione di una soluzione, ma solo se i team dispongono dell’infrastruttura, del contesto condiviso e della disciplina operativa necessari per iterare con sicurezza.

Se l’AI cambia il modo in cui si crea il software, cambia inevitabilmente anche il modo in cui si progettano le organizzazioni di engineering. Servono nuove strutture dei team, nuovi modelli di leadership e una diversa consapevolezza di dove gli ingegneri creano il valore maggiore.

Qi Jin, EVP di Cerebras Systems, ha osservato che le organizzazioni ottimizzate per le precedenti generazioni di sviluppo software sono spesso il principale ostacolo all’adozione dell’AI. Processi consolidati e confini organizzativi sono stati progettati per scalare modalità di lavoro già collaudate, non per adattarsi continuamente a tecnologie disruptive. Adottare l’AI con successo richiede quindi molto più che introdurre nuovi strumenti. I leader devono ripensare i modelli operativi, così che i team possano integrare rapidamente nuove capacità man mano che la tecnologia evolve. 

Qi ha descritto questa trasformazione attraverso il concetto di “Code Yellow”, un framework per guidare il cambiamento organizzativo con senso di urgenza e attenzione ai problemi dei clienti. La sua prospettiva riflette una filosofia di leadership più ampia, di cui ha scritto nel suo saggio sul “wartime manager”, dove sostiene che i periodi di rapida disruption richiedono leader capaci di semplificare il processo decisionale, agire con determinazione e mettere in discussione le norme consolidate invece di ottimizzare i processi esistenti.

Parvez Naqvi, Managing Vice President of Cloud Platforms, Resilience Engineering and Enterprise Architecture presso Capital One, ha spiegato come questi cambiamenti organizzativi stiano ridefinendo il ruolo stesso degli ingegneri. Poiché l’AI rende l’implementazione molto più rapida, il valore dell’engineering si sposta verso le decisioni che l’AI non può prendere in autonomia. I principali vincoli alla delivery del software riguardano ora la pianificazione, la progettazione architetturale e il giudizio ingegneristico. 

I processi di review tradizionali, nati intorno al codice scritto manualmente, iniziano a mostrare i propri limiti mentre l’AI accelera drasticamente la velocità di sviluppo. Gli ingegneri senior generano un impatto sempre maggiore definendo la direzione tecnica e stabilendo i pattern architetturali. Sono inoltre coinvolti sempre più nel system design e nel fornire il contesto che consente sia agli ingegneri sia agli agenti AI di prendere decisioni migliori.

Questa evoluzione accresce anche l’importanza delle piattaforme per gli sviluppatori e dell’infrastruttura di engineering. Il tooling interno e i sistemi di deployment diventano asset strategici perché riducono il carico operativo e permettono ai team di concentrarsi sulla progettazione di sistemi resilienti anziché sulla gestione di attività ripetitive. Man mano che sempre più product manager, designer ed esperti di dominio contribuiscono direttamente alla creazione del software, le organizzazioni di engineering diventano sempre più custodi di qualità, architettura ed eccellenza operativa, anziché unici produttori di codice.

Harjot Gill, CEO di CodeRabbit, ha raccontato come l’AI stia cambiando radicalmente la developer experience. Poiché l’AI si fa carico di una quota crescente del lavoro di implementazione, gli ingegneri dedicano meno tempo a tradurre le idee in codice e più tempo a definire l’intento, valutare i trade-off e dare forma al system design. Le review assistite dall’AI possono aiutare i team di engineering a tenere il passo senza compromettere correttezza, sicurezza o manutenibilità.

Jordan Topoleski, COO di Cursor, si è concentrato su ciò che accade dopo la generazione del codice. Con l’AI che accelera drasticamente la velocità di sviluppo, code review, validazione e mantenimento della qualità ingegneristica diventano i nuovi colli di bottiglia. La prospettiva di Jordan ha rafforzato l’idea che le organizzazioni capaci di scalare con successo sviluppano feedback loop più solidi e sistemi di engineering che garantiscono che il software generato dall’AI sia pronto per la produzione.

Nel loro insieme, questi confronti indicano una trasformazione più ampia. L’engineering AI-native si misura dalla rapidità con cui un’organizzazione riesce a imparare e a istituzionalizzare modi migliori di creare software. Le aziende più rapide saranno quelle che ridisegnano continuamente le proprie organizzazioni di engineering per sfruttare ogni nuovo progresso dell’AI.

Le conversazioni della giornata hanno restituito l’immagine di un settore che ha superato da tempo la fase di sperimentazione. Anche se ogni organizzazione si trova in una fase diversa del proprio percorso di trasformazione, le sfide sono straordinariamente simili. Il feedback dei partecipanti ha confermato la nostra visione per il CTO Circle. I leader dell’engineering hanno sottolineato con costanza il valore di poter dialogare apertamente con colleghi che affrontano decisioni simili. Ciò che ha reso prezioso l’evento è stata la possibilità, per i leader dell’engineering, di avere conversazioni sincere che raramente riescono ad avere altrove.

Il punto di osservazione privilegiato di Snowflake su più settori ha permesso di riunire organizzazioni che affrontano sfide simili. Questo ha contribuito a creare uno spazio di fiducia in cui condividere lezioni concrete, anziché storie di successo patinate.

Il playbook dell’engineering AI-native è ancora in fase di scrittura. Mentre i modelli continuano a migliorare e le pratiche di engineering evolvono insieme a loro, questi spunti diventeranno ancora più rilevanti. Continueremo a condividere lezioni concrete dai leader dell’engineering che stanno costruendo organizzazioni AI-native, con un approfondimento sulla trasformazione in corso in Snowflake. Se queste conversazioni rispecchiano le sfide che la tua organizzazione sta affrontando, ti invitiamo a scoprire il nostro ultimo podcast, mentre continuiamo a esplorare cosa serve per sviluppare la prossima generazione di organizzazioni di engineering.