Moshe Sambol, VP di Soluzioni per i Clienti di Lightrun – Serie di Interviste

Moshe Sambol, VP di Soluzioni per i Clienti di Lightrun – porta più di due decenni di esperienza che spazia dall’ingegneria del software, all’architettura, all’infrastruttura cloud e alla leadership tecnica rivolta ai clienti. Prima di unirsi a Lightrun nel 2022, ha trascorso quasi un decennio a Google, dove ha ricoperto diverse posizioni di leadership, tra cui Cloud Customer Engineering Manager, aiutando le organizzazioni ad adottare e scalare le tecnologie di Google Cloud. All’inizio della sua carriera, Sambol ha ricoperto ruoli di ingegneria e sviluppo presso Oracle, Sun Microsystems, BMC Software e JPMorgan Chase. A Lightrun, ha inizialmente guidato l’ingegneria delle soluzioni a livello globale prima di diventare VP di Soluzioni per i Clienti, dove si concentra sull’aiutare i clienti ad adottare la tecnologia Runtime Insights dell’azienda e tradurre le sue capacità in guadagni di produttività aziendale e di sviluppo misurabili.

Lightrun è una piattaforma di ingegneria della affidabilità nativa AI progettata per dare ai developer e agli agenti AI una visibilità diretta su come si comporta il software durante l’esecuzione. La sua tecnologia può catturare dinamicamente log, snapshot, metriche, tracce, valori di variabili ed esecuzione del contesto da applicazioni live senza richiedere modifiche al codice o ridistribuzioni. L’azienda sta estendendo sempre più questa intelligenza di runtime allo sviluppo del software assistito da AI attraverso Lightrun MCP, che utilizza il Model Context Protocol per fornire assistenti di codifica e strumenti agenti con il contesto dell’applicazione live anziché affidarsi solo al codice sorgente statico. Ciò consente ai sistemi AI di indagare problemi di produzione, convalidare ipotesi contro il comportamento di esecuzione effettivo e supportare l’analisi della causa radice incorporando controlli aziendali come l’accesso basato su ruolo e la redazione dei dati sensibili.

La tua carriera ha abbracciato lo sviluppo software pratico e l’architettura, l’ingegneria dei clienti cloud di Google, l’ingegneria delle soluzioni globali e ora le soluzioni per i clienti di Lightrun. Come ha plasmato la tua comprensione di cosa separa una dimostrazione impressionante di un agente AI da un sistema che può essere affidato in produzione?

C’è una grande differenza tra mostrare cosa può fare un agente AI e dimostrare che può essere affidato in un ambiente aziendale. Ciò è dovuto al fatto che gli agenti sono solo una parte di un sistema pronto per la produzione. La struttura che li circonda è altrettanto importante. Deve applicare l’accesso con i privilegi minimi, monitorare l’attività, preservare una traccia di audit, prevenire azioni inaccettabilmente rischiose e coinvolgere un essere umano quando necessario.

I sistemi agenti sono intrinsecamente diversi dal software tradizionale, poiché gli sviluppatori non prescrivono esattamente come funzionerà il sistema. Impostiamo un obiettivo, forniamo strumenti e indicazioni, e il modello determina come procedere. Quella flessibilità è potente, ma rende anche più difficile prevedere il comportamento del sistema.

Per le aziende, specialmente quelle in settori regolamentati, i flussi di lavoro di produzione che di solito funzionano o richiedono un tempo imprevedibile per il completamento sono un non-inizio. Gli ambienti di produzione contengono dati sensibili, codice sorgente e proprietà intellettuale, quindi le organizzazioni devono essere in grado di impedire agli agenti di esporre quelle informazioni o di intraprendere percorsi creativi ma inaccettabili per raggiungere i loro obiettivi. Ciò sta diventando sempre più importante, poiché ogni settimana porta un nuovo esempio di un sistema AI che, nel suo tentativo di raggiungere un obiettivo, si ritrova vulnerabile o causa un exploit di sicurezza.

La maggior parte dei leader con cui parlo valuta ancora gli agenti nel modo in cui valuterebbero un nuovo dipendente: in base alle capacità, al giudizio e alla produzione. La vera domanda non è se l’agente sia abbastanza intelligente. È se il sistema che lo circonda possa intercettare e contenere i momenti in cui non lo è.

Molti aziende inizialmente credevano che costruire un agente AI fosse in larga misura una questione di scrivere una promessa efficace. Cosa hanno frainteso le organizzazioni sui requisiti di ingegneria, architettura e operativi dietro gli agenti pronti per la produzione?

Credo che il più grande malinteso fosse una credenza quasi ingenua nel potere dell’AI per risolvere qualsiasi sfida, una volta data una promessa ben scritta, un contesto rilevante e strumenti adatti. I team hanno collegato il loro LLM al codice, alla documentazione, ai biglietti e alla telemetria storica, e poi si aspettavano che ragionasse in modo accurato sulla decisione giusta.

Quello che non hanno costruito è stato un modello di verifica per ogni passaggio del ragionamento dell’AI. Una delle grandi forze dell’AI è che utilizza il ragionamento probabilistico, trovando e prendendo una delle molte possibili rotte per raggiungere una destinazione. In ambienti di produzione complessi e interconnessi, quella stessa forza introduce un rischio serio: una singola decisione può scatenare regressioni a valle, fallimenti silenziosi o altri comportamenti inattesi che minacciano la resilienza operativa di un sistema in esecuzione.

Questo è dove diventa essenziale il pilotaggio deterministico. Il ragionamento dell’agente può rimanere probabilistico, ma i punti di controllo attorno alle sue azioni non possono esserlo. Per un agente che partecipa a un flusso di lavoro di ingegneria, ciò richiede un passaggio di verifica che controlli la sua ipotetica prossima azione contro la realtà di produzione, un cancello deterministico anziché un altro guess probabilistico. Deve vedere quale sarà la conseguenza di quella decisione e approvarla solo una volta che ha determinato che l’azione è sicura.

Guardando la prima ondata di agenti aziendali sviluppati internamente, quali sono gli errori architettonici più comuni che sta vedendo e quali problemi possono essere corretti in modo incrementale anziché richiedere una completa ricostruzione?

La preoccupazione fondamentale a cui continuo a tornare è la convalida. Gli agenti possono diventare una scatola nera: raccolgono informazioni da una serie di fonti e poi prendono decisioni che appaiono ragionevoli in principio ma che potrebbero non essere adeguate per le realtà di un ambiente di produzione complesso e sporco.

Ciò punta a un cambiamento più fondamentale e si tratta di qualcosa di cui parliamo costantemente a Lightrun mentre aiutiamo i clienti a costruire automazioni agentiche per le loro organizzazioni di ingegneria. I team devono ricostruire il flusso agente stesso e mettere cancelli sulle azioni dell’agente, per assicurarsi che l’uso degli strumenti sia soggetto a supervisione, audit e revisione. Fornire all’agente stesso un forte feedback loop – compresa l’osservabilità del runtime live – focalizza il suo contesto su ciò che sta realmente accadendo in questo momento. Quell’accesso è ciò che consente all’agente di convalidare le proprie decisioni di progettazione, l’analisi della causa radice e le raccomandazioni di mitigazione degli errori contro la realtà di produzione anziché contro assunzioni basate sull’analisi statica del codice o sulla telemetria vecchia.

Una ricostruzione drammatica non è l’unica opzione. Ciò che può essere fatto in modo incrementale, e non è rivoluzionario ma è essenziale, è investire nelle competenze che guidano il comportamento dell’agente. Competenze progettate e valutate con cura spingono l’agente nella direzione di un flusso di lavoro deterministico. I team non devono riarchitettare l’intero sistema per ottenere quel beneficio. Devono trattare la progettazione delle competenze con la stessa rigida logica che darebbero a qualsiasi altra logica di produzione.

Perché alcuni agenti si eseguono bene durante i test controllati ma iniziano a produrre risultati incoerenti, incompleti o fuorvianti quando esposti a utenti reali, dati in cambiamento, strumenti esterni e ambienti di produzione complessi?

I test controllati rimuovono la maggior parte della variabilità che definirà la realtà di produzione che l’AI deve affrontare. I dati sono curati, il comportamento degli strumenti è prevedibile, le autorizzazioni sono note e copriamo un percorso che abbiamo anticipato. Quando si rilascia un agente per interagire con utenti reali e i loro effetti nei sistemi live, non stiamo paragonando cose simili.

Gli utenti introducono richieste ambigue ed eseguono azioni concorrenti, lo stato del sistema è in costante flusso, l’agente spesso deve lavorare con dati parziali e gli strumenti esterni portano la loro latenza e modalità di failover in aggiunta a ciò. Poiché il modello è probabilistico, ogni nuova variabile crea un altro posto in cui il flusso di lavoro può divergere o comporre un errore precedente.

La parte pericolosa è che l’agente può continuare ad apparire come se stesse funzionando correttamente mentre produce risposte errate ma plausibili, costruite su dati parziali o su assunzioni radicate in informazioni obsolete. È per questo che gli agenti di produzione necessitano di una valutazione continua che continua ad eseguirsi dopo il lancio, di un gestione esplicita dei dati mancanti e dei failover degli strumenti e della verifica live di una decisione prima di completare un’azione ad alto impatto.

Lightrun pone un’enfasi significativa nel dare ai sistemi AI l’accesso al contesto di runtime. Quali informazioni fornisce il contesto di runtime che le registrazioni, le metriche e le tracce convenzionali potrebbero perdere e perché queste informazioni sono particolarmente importanti per diagnosticare i fallimenti degli agenti?

L’osservabilità convenzionale mostra i sintomi esterni del comportamento del sistema, spesso aggregati, campionati o filtrati attraverso dashboard e avvisi che scattano su soglie. Sono solitamente dipendenti dalle decisioni prese dagli sviluppatori al momento in cui il codice è stato scritto: quali informazioni saranno di interesse in futuro? Cosa vale la pena registrare o misurare? Il contesto di runtime decoppia la visibilità da questo bisogno di sapere in anticipo cosa potrebbe essere di interesse e fornisce dati granulari che mostrano cosa sta succedendo sotto il cofano e come ci siamo arrivati.

Il vero divario è tra dati statici e dinamici. Le registrazioni, le metriche e le tracce convenzionali sono statiche e producono un resoconto storico di cosa è successo. Il contesto di runtime di Lightrun è dinamico. Fornisce all’agente la capacità di inserire nuova strumentazione nel codice in esecuzione, su richiesta, e osservare esattamente i valori delle variabili, gli argomenti delle funzioni, lo stato degli oggetti, lo stack di chiamate o le condizioni di ramo come si verificano.

Questa distinzione è particolarmente importante per diagnosticare i fallimenti nel codice generato dall’agente, poiché questi sono frequentemente silenziosi. Un agente può scegliere lo strumento sbagliato, passare l’argomento sbagliato o agire su un’assunzione obsoleta e completare comunque il suo compito senza scatenare alcun errore. Un fallimento del genere non si verificherà nella telemetria statica, perché nessuno sapeva in anticipo di strumentare per esso. Un comportamento inatteso richiede un’indagine dinamica diretta sul sistema in esecuzione, inserendo nuova strumentazione esattamente dove il modello del mondo dell’agente si è discostato dalla realtà, anziché affidarsi a ciò che era già stato registrato.

È questo che rende il contesto di runtime dinamico il livello di verifica naturale per le decisioni generate dall’AI nell’ingegneria.

Come può il Model Context Protocol (MCP) e simili strati di integrazione consentire agli agenti di codifica di apprendere dal comportamento di esecuzione reale senza concedere loro un accesso eccessivo o non sicuro ai sistemi di produzione?

MCP e altri accessi controllati a strumenti esterni (ad esempio, wrapper CLI) consentono a un agente di chiamare una specifica capacità ambita anziché avere un accesso ampio al sistema e fidarsi di comportarsi. Un agente connesso a un server MCP per il contesto di runtime può richiedere prove a sola lettura, il valore di una variabile, un percorso di chiamata, se una soglia è stata superata, senza toccare l’accesso in scrittura, senza la capacità di ridistribuire nulla e senza aver bisogno di credenziali permanenti per l’ambiente sottostante.

Quando si ridisegna un agente di prima generazione, come dovrebbero approcciare le aziende le autorizzazioni degli strumenti, la memoria, il recupero dei dati, la valutazione, la supervisione umana e le procedure di fallback come parti di un’architettura coesa anziché funzionalità separate?

Non si possono aggiungere questi pezzi in modo indipendente perché ognuno cambia gli altri. I migliori posti in cui iniziare sono la struttura, l’arnese che controlla il ciclo dell’agente e l’orchestrazione del flusso di lavoro generale che lega insieme più agenti e altri attori. Per un flusso di lavoro di analisi della causa radice, ad esempio, i team dovrebbero decidere quali prove sono richieste, quali sistemi l’agente può ispezionare, se può pubblicare una conclusione o solo abbozzarla, quando un essere umano deve approvare il prossimo passo e cosa succede se le prove di runtime non sono disponibili.

Una volta che quel contratto è chiaro, l’arnese e la struttura forniscono i meccanismi con cui applicare quelle linee guida. I gateway MCP possono essere sfruttati per limitare l’accesso dell’agente a capacità specifiche rilevanti per il suo scopo. Gli strumenti possono essere concessi con i privilegi minimi. La memoria può essere supervisionata, con i dati sensibili redatti in modo deterministico. Il recupero può essere progettato attorno alle prove di cui il flusso di lavoro ha bisogno.

La valutazione, la supervisione e il fallback chiudono il cerchio. Il sistema dovrebbe misurare se le conclusioni sono corrette e supportate, coinvolgere un essere umano quando il rischio o l’incertezza supera una soglia definita e fermarsi o tornare a una raccomandazione a sola lettura quando non può raccogliere abbastanza prove. Un registro di audit condiviso dovrebbe collegare il trigger, le autorizzazioni, le prove, le chiamate degli strumenti, le approvazioni, l’azione e l’esito. È questo che rende questi componenti un’architettura di produzione anziché sei funzionalità separate.

Quali salvaguardie dovrebbero circondare gli agenti che possono ispezionare applicazioni live o partecipare ai flussi di lavoro di ingegneria della affidabilità del sito, in particolare in ambienti regolamentati in cui il controllo degli accessi, la privacy, la tracciabilità e la stabilità operativa sono critici?

Questo è stato uno dei quesiti di design centrali quando abbiamo costruito Lightrun AI SRE. Un AI SRE opera vicino a alcuni dei sistemi più sensibili di un’organizzazione, quindi l’abbiamo progettato come un attore operativo privilegiato, non come un assistente di chat. Una decisione importante è stata quella di separare il piano di ispezione dal piano di azione. L’AI SRE raccoglie prove attraverso integrazioni a sola lettura e strumentazione di runtime sandbox di Lightrun, con accesso limitato da identità, tenant, servizio ed ambiente. Può ispezionare l’esecuzione live e generare prove mancanti, ma il livello di ispezione del runtime non può modificare lo stato dell’applicazione.

In un ambiente regolamentato, quella frontiera deve essere supportata da RBAC, SSO, isolamento del tenant, redazione dei dati personali, controlli di conservazione e un registro di audit che mostra quali strumenti e prove hanno supportato ogni conclusione. Abbiamo anche bisogno di limiti operativi su quanti dati possono essere raccolti, con quale frequenza il runtime può essere interrogato e quali azioni richiedono l’approvazione. Se le prove sono mancanti o una conclusione non può essere verificata, l’AI SRE dovrebbe dirlo e passare la decisione a un essere umano anziché agire come se sapesse più di quanto non sappia. L’obiettivo è l’autonomia controllata: utile abbastanza per accelerare un’indagine, ma contenuta abbastanza da rimanere sicura per il sistema live.

Man mano che le aziende superano gli agenti sperimentali, quali misure dovrebbero determinare se un agente è veramente pronto per la produzione e come si prevede che la relazione tra agenti AI e ingegneri umani evolverà nei prossimi anni?

Giudicherei la prontezza per la produzione in base a quanto spesso le azioni di un agente AI producono i risultati desiderati, le sue conclusioni reggono contro ciò che era effettivamente vero in produzione, le conclusioni non supportate vengono catturate prima dell’azione e se fallisce in modo visibile e sicuro quando le prove non ci sono. Per gli agenti di ingegneria, l’accuratezza degli esiti verificati, la copertura delle prove, il tempo per confermare la causa radice, il tasso di fallback di successo e i risultati post-azione sono le metriche chiave su cui dovremmo concentrarci.

Nei prossimi anni, mi aspetto che gli agenti assumano più raccolta di prove e prima indagine, nonché la supervisione dei flussi di lavoro agentic e l’apprendimento continuo dall’esperienza e dal feedback, mentre gli ingegneri definiscono le politiche, risolvono l’ambiguità, approvano azioni ad alto rischio e guidano i sistemi agentic migliorati. La fiducia si espanderà flusso di lavoro per flusso di lavoro. Gli agenti che possono tracciare le loro conclusioni fino alle prove live e disclosi chiaramente cosa non possono verificare guadagneranno maggiore autonomia. Quelli che non possono farlo rimarranno limitati a compiti a basso rischio e a bassa posta, indipendentemente da quanto fluente suonino.

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