Il CEO di Hud, Roee Adler, afferma che l'intelligenza runtime definirà la prossima era delle operazioni software.

      L'intelligenza artificiale ha accelerato drasticamente lo sviluppo del software, con agenti di codifica ora capaci di produrre grandi volumi di codice pronto per la produzione in pochi minuti. Tuttavia, mentre scrivere software è diventato più veloce, garantire che il software si comporti correttamente in produzione rimane una delle sfide più grandi dell'ingegneria.

      Per decenni, le piattaforme di osservabilità hanno aiutato i team a monitorare l'infrastruttura attraverso log, metriche e tracce. Ma secondo Roee Adler, CEO di Hud, la rapida ascesa dello sviluppo assistito dall'IA sta esponendo i limiti dei sistemi originariamente progettati per operatori umani piuttosto che per agenti di codifica autonomi.

      Il software viene scritto per un'era diversa

      Adler crede che il cambiamento non riguardi semplicemente l'adozione di strumenti di IA. Invece, si tratta di riconoscere che lo sviluppo del software stesso sta subendo una trasformazione fondamentale. Come spiega, “Il cambiamento fondamentale è che il software non è più scritto principalmente da esseri umani utilizzando i processi ingegneristici che abbiamo affinato nel corso dei decenni; è scritto da agenti di codifica che sono una specie completamente diversa.” Quegli agenti, dice, sono “veloci, impazienti, aggressivi,” ma mancano anche del contesto di produzione necessario per prendere decisioni sicure in ambienti complessi.

      Piuttosto che rallentare l'adozione dell'IA, Adler crede che l'industria dovrebbe costruire l'infrastruttura che consenta agli agenti di codifica di diventare collaboratori affidabili. A suo avviso, l'obiettivo non è sostituire gli ingegneri, ma dotare l'IA di una comprensione sufficiente del mondo reale per operare con fiducia in produzione.

      Lo sviluppo più veloce ha creato un nuovo collo di bottiglia

      Sebbene l'IA stia aumentando drasticamente la quantità di codice che gli sviluppatori possono produrre, Adler sostiene che le organizzazioni non stanno vedendo la stessa accelerazione nella consegna complessiva del software.

      Il problema, dice, non è che i team di ingegneria si trovino improvvisamente di fronte a nuovi punti ciechi operativi. Invece, i processi di revisione e validazione esistenti non erano progettati per il ritmo dello sviluppo generato dall'IA. Man mano che più codice raggiunge la produzione, la fiducia diventa più difficile da mantenere. Adler osserva che mentre gli ingegneri individuali stanno diventando più produttivi, “il collo di bottiglia si è spostato al cancello, che cercava di prevenire che cambiamenti sbagliati rompessero il sistema.”

      Crede che le organizzazioni di ingegneria ora si trovino di fronte a due domande urgenti: come rivedere un volume sempre crescente di codice generato dall'IA garantendo che l'intento commerciale venga preservato, e come preservare la conoscenza istituzionale man mano che sempre meno ingegneri comprendono ogni angolo di codebase sempre più generati dall'IA.

      Perché l'osservabilità è insufficiente per l'IA

      I team di ingegneria investono già pesantemente in log, metriche, tracce e piattaforme di monitoraggio delle prestazioni delle applicazioni. Quei sistemi rimangono preziosi per identificare quando i servizi diventano non sani, ma Adler sostiene che non sono stati progettati per fornire il tipo di prove di cui i sistemi di IA hanno bisogno.

      Come dice, “Sono costruiti per far emergere che qualcosa non va, non perché.” Mentre log, metriche e tracce possono aiutare gli ingegneri a indagare sugli incidenti, “Agenti che iterano su log è ciò che abbiamo oggi, e non è sufficiente.” Invece, Adler crede che l'IA richieda “un contesto strutturato a livello di funzione che descriva ciò che viene effettivamente eseguito,” dando ai modelli visibilità diretta su come il codice si comporta in condizioni di produzione reali piuttosto che chiedere loro di dedurre il comportamento da telemetria frammentata.

      Quella filosofia forma la base di ciò che Hud chiama intelligenza in tempo di esecuzione.

      Perché il contesto è più importante di più dati

      L'osservabilità tradizionale produce spesso enormi volumi di telemetria, lasciando agli ingegneri il compito di ricostruire i fallimenti dopo il fatto. Adler sostiene che semplicemente raccogliere più informazioni non risolve il problema se i dettagli critici rimangono sepolti.

      Come spiega, “Più telemetria è un fieno più grande, e l'ago è l'unica cosa per cui sei venuto.” Quando si verificano incidenti in produzione, gli ingegneri non hanno bisogno di terabyte di log. Invece, hanno bisogno del flusso di esecuzione esatto, dei parametri interessati, dei percorsi di codice, del comportamento delle dipendenze e del contesto forense circostante che spiega perché si è verificato un fallimento.

      L'approccio di Hud si concentra sulla cattura automatica di quel contesto forense mentre si verificano gli incidenti, piuttosto che richiedere agli ingegneri di prevedere quali log, dashboard o strumentazione avranno bisogno in anticipo. Adler sostiene che questo cambiamento è sempre più importante perché la configurazione manuale lascia inevitabilmente lacune di copertura. “Qualsiasi cosa che dipende dalla configurazione viene applicata in modo disuguale,” dice, aggiungendo che le organizzazioni spesso perdono i fallimenti che non hanno mai previsto.

      Intelligenza in tempo di esecuzione come nuovo strato architettonico

      Sebbene molti fornitori di osservabilità stiano aggiungendo assistenti IA ai prodotti esistenti, Adler non vede l'intelligenza in tempo di esecuzione come una funzionalità incrementale.

      Invece, sostiene che “Uno strato diverso, non una funzionalità che aggiungi.” Semplicemente posizionare l'IA sopra la telemetria campionata significa che il modello eredita ogni limitazione dei dati sottostanti. L'intelligenza in tempo di esecuzione, al contrario, cambia quali informazioni vengono catturate fin dall'inizio, producendo un contesto consapevole della produzione specificamente strutturato per il ragionamento dell'IA piuttosto che per l'indagine umana.

      Quella distinzione spiega anche l'enfasi di Hud sulla cattura del contesto di esecuzione senza campionamento. Secondo Adler, il campionamento funziona bene per dashboard e tendenze a lungo termine, ma diventa problematico durante la risposta agli incidenti perché l'evento raro che ha innescato l'interruzione potrebbe essere esattamente ciò che viene scartato. Poiché l'IA ragiona solo in base alle informazioni che riceve, la mancanza di dati di produzione non rallenta semplicemente le indagini; può portare i modelli verso conclusioni errate.

      Il futuro è rivedere l'IA, non fare il debug

      Guardando al futuro, Adler si aspetta che gli ingegneri trascorrano molto meno tempo a indagare manualmente sugli incidenti in produzione e significativamente più tempo a convalidare le correzioni generate dall'IA.

      Punta a organizzazioni che stanno già vedendo riduzioni drammatiche nel tempo di indagine una volta che le informazioni sulla causa principale vengono catturate automaticamente piuttosto che ricostruite manualmente. Ma sottolinea che la manutenzione autonoma del software dipende dal dare all'IA accesso diretto alla verità di produzione piuttosto che a supposizioni.

      Quella stessa filosofia si estende ai deployment autonomi. Adler crede che le organizzazioni alla fine si fideranno degli agenti di codifica per apportare modifiche in produzione in modo indipendente, ma solo dopo che quei sistemi dimostreranno costantemente un ragionamento trasparente e opereranno all'interno di chiari confini di sicurezza. Come dice, “La fiducia si basa su prove e reversibilità, non fede.” L'IA dovrebbe ragionare in base al comportamento reale della produzione, spiegare le sue conclusioni e consentire agli esseri umani di verificare rapidamente o invertire le sue decisioni.

      In definitiva, Adler crede che la sfida definente dell'era del software IA non sia scrivere codice più velocemente, ma comprendere come quel codice si comporta una volta distribuito. Come conclude, “Man mano che l'IA scrive sempre più del nostro software, la risorsa scarsa non è più scrivere codice; è sapere come quel codice si comporta nel mondo reale. Chiunque detenga quella comprensione e possa metterla davanti a persone e agenti è colui che spedisce con fiducia e sfrutta davvero il potere della rivoluzione del codice gener