Kristin Isaac, CEO e Co-Fondatrice di Strudel – Serie di Interviste

Kristin Isaac, CEO e Co-Fondatrice di Strudel, è un veterano leader tecnologico aziendale che ha ricoperto ruoli senior in LinkedIn, Udemy, ESPN e Disney prima di lanciare Strudel. Ora si concentra sull’eliminazione di uno dei più grandi punti di frizione nelle organizzazioni software: il divario tra il supporto clienti e l’ingegneria. In Strudel, sta costruendo una piattaforma guidata da AI che aiuta i team di supporto tecnico a risolvere problemi complessi più velocemente, collegando le richieste di supporto direttamente all’intelligenza ingegneristica. La sua esperienza nel far crescere team, costruire strategie di mercato e guidare la crescita in organizzazioni globali ha aiutato a plasmare la rapida presa di Strudel e la sua forte posizione nel mercato dell’AI aziendale e degli strumenti per sviluppatori.

Strudel è una piattaforma AI progettata per automatizzare il supporto tecnico avanzato analizzando log, dati di produzione, repository di codice e storia di supporto per identificare le cause radice e raccomandare soluzioni. Il suo obiettivo è ridurre il tempo e lo sforzo ingegneristico necessari per risolvere casi di supporto difficili, in particolare le escalation che di solito consumano risorse tecniche senior. Collegando il supporto direttamente ai problemi tecnici sottostanti, Strudel si posiziona come uno strumento che può rendere le operazioni di supporto aziendale più veloci, efficienti e scalabili.

Ha ricoperto ruoli di leadership in organizzazioni come LinkedIn, Udemy e Disney prima di fondare Strudel nel 2025. Quali esperienze in quei ruoli l’hanno convinta che i team di ingegneria avevano bisogno di una nuova piattaforma di “intelligenza ingegneristica” guidata da AI, e come quell’intuizione ha plasmato la fondazione di Strudel?

Ogni azienda in cui ho lavorato aveva una versione diversa dello stesso problema. A Disney, le poste in gioco erano enormi – se una piattaforma di streaming andava giù durante un importante lancio, non si trattava solo di un impatto sui ricavi, ma di un momento di marca. A LinkedIn, la scala era implacabile. C’erano migliaia di servizi che generavano rumore, e anche i migliori team faticavano a tenere il passo. A Udemy, ho visto un team magro fare cose eroiche con strumenti limitati.

Ciò che collegava tutti e tre, e all’esperienza dei miei co-fondatori, Shai Rubin e Brian Kaufman, che guidavano team di ingegneria, era che gli ingegneri trascorrevano più tempo a ricostruire il contesto che a risolvere effettivamente i problemi. Qualcuno viene pagato alle 2 del mattino, e prima di poter iniziare a diagnosticare, deve setacciare thread di Slack, dashboard, biglietti Jira, log di deploy – solo per capire cosa è cambiato e quando. Stanno essenzialmente giocando a fare i detective prima di poter fare il loro lavoro vero. Questo è uno spreco di persone incredibilmente talentuose.

Continuavo a pensare: deve esserci un modo più intelligente per portare alla luce ciò che conta veramente, quando conta. Questo è veramente il seme di Strudel.

Molte aziende misurano l’impatto finanziario del downtime in termini di ricavi persi o penalità SLA. Nella sua esperienza, quali sono alcuni dei costi meno visibili degli outage che le organizzazioni sottostimano costantemente?

Il numero dei ricavi fa parte della presentazione alla direzione, ma l’impatto immediato sui ricavi è solo una frazione di ciò che l’outage effettivamente costa. Quelli che vedo le organizzazioni costantemente trascurare rientrano in alcune categorie.

Il primo è la fiducia del cliente. Le penalità SLA sono una costruzione giuridica – non catturano il cliente che si disiscrive silenziosamente o il prospetto aziendale che ha visto la pagina di stato al momento sbagliato e ha scelto un concorrente. Quel danno è lento, invisibile e permanente in un modo che un assegno di rimborso semplicemente non è.

Il secondo è l’abbandono e il burnout degli ingegneri. La fatica dell’on-call è reale. Quando i migliori ingegneri vengono ripetutamente coinvolti in incidenti ad alto stress – specialmente quelli che avrebbero potuto essere prevenuti – iniziano a mettere in discussione se questo è il posto giusto per costruire la loro carriera. Sostituire un ingegnere senior costa da uno a due volte il suo stipendio annuale quando si considerano i costi di reclutamento, formazione e conoscenza istituzionale persa. Nessuno lo mette nel post-mortem.

Il terzo è il costo di opportunità. Ogni ora che un team di ingegneria trascorre a combattere incendi è un’ora non spesa a costruire un prodotto. È difficile metterlo su un foglio di calcolo, ma accumulato su mesi, fa esplodere silenziosamente la tua roadmap.

Gli ingegneri sono spesso distolti dal costruire nuove funzionalità per rispondere a incidenti di produzione. Come questo costante lavoro di estinzione degli incendi impatta l’innovazione del prodotto e la roadmap di sviluppo a lungo termine?

Questo crea una tassa sulla capacità del team di ingegneria di costruire. Ogni team ha una quantità finita di banda, e quando una parte significativa di essa continua a essere dirottata verso gli incidenti, l’effetto composto sullo sviluppo del prodotto è severo. Gli impegni della roadmap vengono saltati. Il debito tecnico non viene estinto. Le funzionalità vengono spedite con meno rigore perché c’è pressione per recuperare il tempo perso.

Quello che è particolarmente dannoso è l’imprevedibilità. Un team può pianificare il suo sprint con buone intenzioni, e poi un incidente importante esplode di martedì e tutto il resto diventa secondario. Quel tipo di imprevedibilità sostenuta rende quasi impossibile costruire una cultura di lavoro profondo – che alla fine guida i migliori risultati ingegneristici.

Questo crea anche un ciclo auto-rinforzante. Gli investimenti differiti significano più incidenti, che significano più lavoro di estinzione degli incendi, che significa ancora meno tempo per investire nei problemi sottostanti. In Strudel, una grande parte di ciò che stiamo costruendo è specificamente per i team SRE che vivono questo ogni giorno.

Strudel collega i dati di supporto clienti, log, sistemi di produzione e repository di codice per identificare le cause radice più velocemente. Come l’AI unisce questi diversi segnali tecnici in un modo che gli strumenti di monitoraggio tradizionali non possono?

Gli strumenti di monitoraggio tradizionali sono fondamentalmente sistemi di allarme. Sono grandi nel dire che qualcosa ha superato una soglia – un picco di latenza, una frequenza di errore in aumento, un pod in crash. Quello che non possono fare è ragionare attraverso domini.

Non sanno che il picco della frequenza di errore nel tuo servizio di pagamento è avvenuto quattro minuti dopo un deploy di una dipendenza, e che un biglietto di supporto clienti che menziona problemi di checkout è arrivato più o meno nello stesso momento, e che l’ultima volta che questo pattern si è verificato nei tuoi log è stato sei mesi fa durante una migrazione del database.

Quella correlazione cross-domain è ciò che l’AI consente. Possiamo trattare un biglietto Zendesk, un commit GitHub, una traccia Datadog (DDOG ) e un log CloudWatch come parte di una storia unificata piuttosto che punti di dati isolati. L’AI porta alla luce non solo cosa è rotto, ma anche il probabile perché e dove – e lo basa su prove che un ingegnere umano può effettivamente verificare e agire. Non stiamo chiedendo ai team di fidarsi di una scatola nera. Stiamo dando loro un’ipotesi ben ragionata e un vantaggio.

Descrive Strudel come una piattaforma che fornisce “intelligenza ingegneristica”. Cosa significa questo concetto nella pratica, e come si differenzia dalle piattaforme di osservabilità o AIOps convenzionali?

L’osservabilità è fondamentalmente questione di strumentazione e visibilità – assicurarsi che la telemetria sia presente e che i team possano interrogarla. L’AIOps, nella maggior parte delle sue implementazioni attuali, è questione di ridurre il rumore degli allarmi attraverso la correlazione e la rilevazione delle anomalie basate su ML. Entrambi sono genuinamente preziosi, e ci integrano con loro.

Ma l’intelligenza ingegneristica è un livello sopra. Stiamo prendendo ciò che fa l’AIOps e ampliandolo. Dove l’AIOps ti dice che qualcosa è sbagliato, l’intelligenza ingegneristica aiuta a capire perché è sbagliato, dove è iniziato e cosa fare al riguardo – attingendo a segnali da tutta la tua pila, comprese fonti che gli strumenti AIOps tradizionali non guardano nemmeno, come biglietti di supporto clienti o modifiche al codice. L’obiettivo non è solo ridurre il rumore. È dare al tuo team un’immagine completa e azionabile in modo che possano risolvere il problema più velocemente e tornare a costruire.

Penso alla differenza tra un rilevatore di fumo e un investigatore di incendi. L’osservabilità e l’AIOps sono il rilevatore di fumo – essenziali, ma si fermano all’allarme. L’intelligenza ingegneristica è ciò che viene dopo: ecco cosa è successo, ecco perché, ecco dove è iniziato.

Gli agenti AI sono sempre più utilizzati per automatizzare flussi di lavoro tecnici complessi. Qual è il ruolo che vede gli agenti AI svolgere nella diagnosi e risoluzione degli incidenti software nei prossimi cinque anni?

Credo che la domanda più interessante non sia cosa faranno gli agenti – ma cosa smetteranno di fare gli ingegneri. I migliori ingegneri con cui ho lavorato non sono entrati in questo campo per trascorrere le notti a triare allarmi o a cercare nei log per una modifica di configurazione che qualcuno ha fatto un venerdì pomeriggio. Quello non è il motivo per cui sono diventati bravi nel loro lavoro. Ma è quello che una grande parte del loro tempo viene mangiato.

Nei prossimi cinque anni, credo che gli agenti prendano su di sé molto di quel lavoro di routine – il lavoro di riconoscimento di pattern, l’assemblaggio del contesto, il lavoro di triage ripetitivo. Questo libera le persone per concentrarsi sui problemi complessi, sulle decisioni architettoniche, sulle cose che richiedono effettivamente giudizio umano.

Ciò che mi emoziona è che questo non è solo uno stato futuro – lo stiamo già vedendo accadere, compreso in Strudel. La nostra intera roadmap è orientata verso la rimozione del lavoro amministrativo e di manutenzione dalle piastre degli ingegneri. E cosa stiamo trovando, onestamente, è che questo cambia ciò che è possibile per un team. Puoi costruire di più, muoverti più velocemente e farlo con meno persone – perché le persone che hai sono concentrate sulla strategia e sulla complessità piuttosto che sul lavoro ripetitivo. Sembra un cambiamento significativo in come vengono costruiti e strutturati i team in futuro.

Molti outage originano da piccoli bug o modifiche di configurazione che sfuggono ai test. Come possono i sistemi AI identificare pattern sottili nel codice, log o segnali di infrastruttura abbastanza presto per prevenire incidenti maggiori?

Un AI ben costruito ha un vero vantaggio qui, e non è che sia più intelligente dei suoi ingegneri – è che non dimentica mai e non dorme mai. Un umano potrebbe non collegare un pattern sottile di log oggi a qualcosa che è successo sei mesi fa in una parte completamente diversa del sistema. L’AI può. Sta guardando tutto, tutto il tempo, e ha una memoria molto più lunga e ampia di qualsiasi individuo nel tuo team.

Detto questo, c’è anche qualcos’altro che sento dai clienti molto spesso: la prevenzione è solo buona quanto i dati sottostanti. Se i tuoi log sono incoerenti, incompleti o frammentati in una dozzina di strumenti che non parlano tra loro, l’AI sta lavorando con un’immagine frammentata. Spazzatura dentro, spazzatura fuori – questo è ancora vero. Trascorriamo molto tempo con i clienti aiutandoli a pensare alla qualità dei dati e alla strumentazione perché il miglior AI del mondo non può portare alla luce un segnale che non è stato catturato per primo.

Quindi la risposta è sia: sì, l’AI può cogliere cose più presto e collegare punti che gli umani potrebbero perdere. Ma i team che ottengono il massimo valore da esso sono quelli che hanno anche fatto il lavoro per assicurarsi che i loro dati siano effettivamente degni di essere ragionati.

Le aziende spesso investono molto in strumenti di rilevamento, ma ancora lottano con il tempo medio di risoluzione. Quali sono i più grandi ostacoli che impediscono alle organizzazioni di colmare il divario tra la rilevazione degli incidenti e la risoluzione effettiva della causa radice?

La rilevazione è fondamentalmente un problema risolto a questo punto. La maggior parte dei team ha allarmi. Sanno che qualcosa è sbagliato. Il divario è tutto ciò che accade dopo.

Quando un ingegnere viene pagato, non entra in una situazione chiara con tutto il contesto rilevante assemblato. Entra in un pasticcio. Deve capire cosa è cambiato, quando è cambiato, quale sistema ha toccato, se c’è un impatto sul cliente, se è collegato a qualcosa che è successo la settimana scorsa. Sta attingendo da Slack, dalle dashboard, dai log di deploy, dai biglietti di supporto – facendo quel lavoro di assemblaggio manualmente, sotto pressione, spesso in mezzo alla notte.

Quell’assemblaggio del contesto è l’ostacolo. Non è che gli ingegneri e i team di supporto tecnico non sappiano come risolvere problemi – è che stanno spendendo i primi 30-60 minuti di ogni incidente solo cercando di capire cosa stanno guardando. È lì che vive Strudel. La nostra intera tesi è che se puoi dare a un ingegnere un’immagine coerente, basata sulle prove, di cosa è successo e perché – proprio quando ne ha bisogno – drammaticherai la compressione di quel divario. Il lavoro di risoluzione è ancora loro. Noi li portiamo solo alla linea di partenza molto più velocemente.

Man mano che i sistemi AI iniziano ad analizzare i dati di produzione, codebase e log operativi, quali considerazioni di governance o sicurezza i team di ingegneria dovrebbero tenere presente nell’implementazione di questi strumenti?

La cosa di cui mi preoccupo di più qui è questa: gli umani dovrebbero ancora revisionare il codice che va in produzione.

Ho parlato con molti ingegneri a questo proposito, e una cosa che sento ripetere è che l’AI scrive bug in modo efficiente e astuto. Davvero astuto, in realtà. In un modo che può essere genuinamente difficile da cogliere – anche per ingegneri senior che esaminano il codice con cura. I bug non sono sempre ovvi. Possono sembrare perfettamente ragionevoli a un’occhiata.

Quindi, man mano che l’AI scrive sempre più codice che finisce in produzione, credo che vedremo più di questi problemi sottili e difficili da rilevare scivolare dentro – non perché qualcuno è stato negligente, ma perché la natura dei bug generati dall’AI è diversa. Più difficile da individuare nella revisione. Più difficile da cogliere nei test.

Sinceramente? Questo è uno dei motivi per cui credo che il caso per ciò che fa Strudel diventi solo più forte con il tempo. Se più bug finiscono in produzione, la capacità di trovarli e risolverli più velocemente diventa più importante, non meno. La questione di governance non è solo sui controlli di accesso ai dati e sulle autorizzazioni – sebbene quelle siano importanti e i team dovrebbero essere pensierosi su quali dati stanno dando accesso a qualsiasi sistema AI. È anche sul mantenere gli umani ai punti di controllo giusti, specialmente intorno a qualsiasi cosa tocchi la produzione.

Guardando avanti, pensa che il futuro dell’ingegneria della affidabilità si sposterà verso un’infrastruttura AI-first, dove sistemi autonomi monitorano, diagnosticano e addirittura risolvono problemi prima che gli umani ne siano a conoscenza? Se sì, cosa sembra il flusso di lavoro futuro per gli ingegneri?

Credo che stiamo andando in quella direzione, ma sono pragmatico sul cronogramma. Sistemi completamente autonomi che risolvono incidenti di produzione senza alcuna consapevolezza umana – questo non è dove siamo, e non credo che lo saremo nei prossimi anni. E credo che vada bene.

Ciò che credo è che il ciclo si stringa molto e diventi molto meno doloroso. Il futuro che mi emoziona non è quello in cui gli umani vengono rimossi dall’equazione – è quello in cui gli umani integrati nel processo trascorrono il loro tempo sulle parti che effettivamente richiedono loro. Chiamate di giudizio. Situazioni nuove. Un incidente che non hai mai visto prima. L’AI gestisce il riconoscimento di pattern, l’assemblaggio del contesto, la triage di routine. Gli ingegneri gestiscono le decisioni.

Per gli ingegneri stessi, credo che significhi: meno tempo in turni di notte per cose che non dovevano svegliarli, e più tempo a costruire sistemi che non si rompono per primo posto. Il lavoro di estinzione degli incendi non scompare del tutto. Ma diventa l’eccezione piuttosto che lo stato predefinito di essere un ingegnere in un’azienda che esegue software su larga scala. Questo è un futuro verso il quale vale la pena costruire.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Strudel.