I team di ingegneri stanno producendo più codice che mai con agenti IA. Ma quando questo codice raggiungerà la produzione, si scontreranno con un muro.
Il problema non è necessariamente il codice generato dall’intelligenza artificiale stessa. Gli strumenti di monitoraggio tradizionali spesso hanno difficoltà a fornire i dati dettagliati a livello funzionale di cui gli agenti di intelligenza artificiale hanno bisogno per comprendere come si comporta effettivamente il codice in ambienti di produzione complessi. Senza questo contesto, gli agenti non possono rilevare problemi o produrre soluzioni che tengano conto della realtà della produzione.
Questa è una sfida per l’inizio uff Il rilascio di mercoledì del sensore del codice di runtime mira a risolvere il problema. L’omonimo sensore dell’azienda funziona con il codice di produzione per tracciare automaticamente il comportamento di ciascuna funzione, offrendo agli sviluppatori informazioni dettagliate su ciò che sta realmente accadendo durante l’implementazione.
"Ogni team software creato su larga scala deve affrontare la stessa sfida fondamentale: creare prodotti di alta qualità che funzionino bene nel mondo reale." Il CEO e fondatore di Hud, Roee Adler, ha dichiarato a VentureBeat in un’intervista esclusiva. "Nella nuova era dello sviluppo accelerato dall’intelligenza artificiale, non sapere come si comporta il codice in produzione diventa una parte ancora più grande della sfida."
Ciò con cui lottano gli sviluppatori di software
I punti critici che gli sviluppatori devono affrontare sono abbastanza coerenti tra le organizzazioni di ingegneria. Moshik Eilon, leader tecnologico del gruppo Monday.com, gestisce 130 ingegneri e descrive una frustrazione familiare nei confronti degli strumenti di monitoraggio tradizionali.
"Quando ricevi un avviso, in genere stai verificando la presenza di un endpoint con un tasso di errore o una latenza elevata e desideri eseguire il drill-down per visualizzare le dipendenze downstream." Eilon ha detto a VentureBeat. "Nella maggior parte dei casi si tratta dell’applicazione vera e propria e poi è una scatola nera. In pratica ottieni solo l’80% di latenza downstream."
Il passaggio successivo di solito prevede un lavoro investigativo manuale su più strumenti. Controlla i registri. Timestamp associati. Prova a riconfigurare ciò che fa l’applicazione. Per i nuovi problemi all’interno di una codebase di grandi dimensioni, i team spesso non dispongono dei dati esatti di cui hanno bisogno.
Daniel Marashlian, CTO e co-fondatore di Drata, ha visto i suoi ingegneri dedicare, secondo le sue parole, ore alla progettazione. "tassa sulle indagini" "Stavano mappando un avviso generico a un proprietario di codice specifico, quindi esaminando i registri per ricostruire lo stato dell’applicazione." Marashlian ha detto a VentureBeat. "Volevamo eliminare questo problema in modo che il nostro team potesse concentrarsi interamente sulla correzione piuttosto che sulla scoperta."
L’architettura di Drata complica ulteriormente questa sfida. L’azienda si integra con numerosi servizi esterni per garantire la conformità automatica, creando indagini complesse quando sorgono problemi. Gli ingegneri monitorano il comportamento attraverso una codebase molto ampia, abbracciando moduli di rischio, conformità, integrazione e reporting.
Marashlian ha identificato tre problemi specifici che hanno portato Drata a investire in sensori di runtime. Il primo problema era il costo del cambio di contesto.
"Poiché i nostri dati sono dispersi, i nostri ingegneri hanno dovuto fungere da ponte umano tra strumenti disconnessi." ha detto.
Ha notato che il secondo problema è la stanchezza al risveglio. "Quando si dispone di un sistema distribuito complesso, i canali di allerta pubblici diventano un flusso costante di rumore di fondo, che il nostro team descrive come l’effetto “ding, ding, ding” che alla fine viene ignorato." Maraşlıyan ha detto:
Il terzo fattore chiave è stata la necessità di integrazione con la strategia AI dell’azienda.
"Un agente AI può scrivere codice, ma se non riesce a vedere le variabili di runtime o la causa principale, non può correggere il difetto di produzione." Maraşlıyan ha detto:
Perché gli APM tradizionali non riescono a risolvere facilmente il problema?
Le organizzazioni fanno affidamento da tempo su una classe di strumenti e servizi noti come Application Performance Monitoring (APM).
A causa del ritmo attuale dello sviluppo dell’intelligenza artificiale delle agenzie e dei moderni flussi di lavoro di sviluppo, sia Monday.com che Drata non sono stati in grado di ottenere la visibilità necessaria dai loro strumenti APM esistenti.
"Se volessi ottenere tali informazioni da Datadog o CoreLogix, dovrei ottenere tonnellate di log o tonnellate di intervalli e pagherei un sacco di soldi." disse Eilon.
Eilon ha notato che Monday.com utilizza frequenze di campionamento molto basse a causa di vincoli di costo. Ciò significava che spesso perdevano i dati necessari per eseguire il debug dei problemi.
Anche gli strumenti tradizionali di monitoraggio delle prestazioni delle applicazioni richiedono congetture; Il che a volte è un problema perché uno sviluppatore non sa ciò che non sa.
"L’osservabilità tradizionale richiede di prevedere ciò di cui avrai bisogno per eseguire il debug." Maraşlıyan ha detto: "Ma quando sorge un nuovo problema, soprattutto all’interno di un codice base ampio e complesso, spesso mancano esattamente i dati necessari."
Drata ha valutato diverse soluzioni nelle categorie ingegneria dell’affidabilità del sito AI e risposta automatizzata agli incidenti e non è riuscita a trovare quella necessaria.
"La maggior parte degli strumenti che abbiamo valutato erano eccellenti nella gestione del processo di incidente, nell’instradamento delle notifiche, nel riepilogo dei thread Slack o nella correlazione dei grafici." ha detto. "Tuttavia, nella maggior parte dei casi il codice stesso era inadeguato. Potrebbero dirci che “il servizio A è inattivo”, ma non potrebbero dirci esattamente il motivo."
Un’altra caratteristica comune in alcuni strumenti, inclusi i monitoraggi degli errori come Sentry, è la capacità di rilevare eccezioni. La sfida, secondo Adler, è che notare le eccezioni è positivo, ma non le collega all’impatto sul business né fornisce il contesto di esecuzione di cui gli agenti AI hanno bisogno per suggerire soluzioni.
In che modo i sensori di runtime funzionano diversamente?
I sensori di runtime spingono l’intelligenza al limite dove viene eseguito il codice. Il sensore dell’HUD funziona come un SDK che si integra con una singola riga di codice. Vede l’esecuzione di ciascuna funzione ma invia solo una piccola quantità di dati a meno che qualcosa non vada storto.
Quando si verificano errori o rallentamenti, il sensore raccoglie automaticamente dati forensi approfonditi, inclusi parametri HTTP, query e risposte al database e l’intero contesto di esecuzione. Il sistema stabilisce le prestazioni di base nel corso della giornata e può avvisare di rallentamenti drammatici e valori anomali che il monitoraggio basato su percentili non riesce.
"Ora otteniamo tutte queste informazioni per tutte le funzioni, indipendentemente dal livello in cui si trovano, anche per i pacchetti sottostanti." disse Eilon. "A volte potresti avere un problema molto profondo e lo vediamo ancora abbastanza rapidamente."
La piattaforma fornisce i dati attraverso quattro canali:
-
applicazione web per il monitoraggio e l’analisi centralizzati
-
Estensioni dell’IDE Espone le metriche di produzione per VS Code, JetBrains e Cursor direttamente nel punto in cui viene scritto il codice
-
server MCP Fornire dati strutturati agli agenti di codifica AI
-
sistema di allarme identifica i problemi senza la necessità di configurazione manuale
L’integrazione del server MCP è fondamentale per lo sviluppo basato sull’intelligenza artificiale. Gli ingegneri di Monday.com ora interrogano il comportamento di produzione direttamente da Cursor.
"Posso porre una domanda al cursore: Ehi, perché questo endpoint è lento?" disse Eilon. "Ottengo tutte le metriche dettagliate quando Hud utilizza MCP e questa funzione è più lenta del 30% da questa distribuzione. Quindi posso anche trovare la causa principale."
Ciò modifica il flusso di lavoro di risposta agli incidenti. Invece di iniziare da Datadog e approfondire i livelli, gli ingegneri iniziano chiedendo a un rappresentante dell’IA di diagnosticare il problema. L’agente ha accesso immediato ai dati di produzione a livello funzionale.
Dai punti salienti del voodoo alle correzioni minime
Il passaggio dalla capacità teorica all’impatto pratico diventa chiaro nel modo in cui i team di ingegneri utilizzano effettivamente i sensori di runtime. Il lavoro investigativo che prima richiedeva ore o giorni ora viene risolto in pochi minuti.
"Sono abituato ad avere queste cose voodoo in cui la CPU aumenta e non sai da dove viene." disse Eilon. "Ho avuto un incidente del genere qualche anno fa e ho dovuto sviluppare il mio strumento che prendesse il profilo della CPU e il dump della memoria. Ora ho tutti i dati di funzionamento e ho scoperto che gli ingegneri l’hanno capito molto rapidamente."
L’effetto misurato in Drata è drammatico. L’azienda ha creato un comando /triage integrato che consente agli ingegneri di lavorare con gli assistenti IA per rilevare immediatamente le cause principali. Il lavoro di triage manuale è diminuito da circa 3 ore al giorno a meno di 10 minuti. Il tempo medio di risoluzione è aumentato di circa il 70%.
La squadra anche ogni giorno "Stai attento" segnalazione di bug con vittoria rapida. Gli sviluppatori possono risolvere questi problemi in pochi minuti perché la causa principale è già stata individuata. I tecnici dell’assistenza ora eseguono la diagnostica forense che in precedenza richiedeva uno sviluppatore senior. Aumento del throughput dei ticket senza espandere il team L2.
Dove si adatta questa tecnologia
I sensori di runtime hanno un impatto diverso rispetto agli APM tradizionali, che eccellono nel monitoraggio a livello di servizio ma hanno difficoltà con dati granulari ed economici a livello di funzione. Differiscono dai tracker degli errori, che rilevano le eccezioni senza contesto aziendale.
I requisiti tecnici per supportare gli agenti di codifica dell’intelligenza artificiale differiscono dall’osservabilità dal lato umano. Gli agenti hanno bisogno di dati strutturati a livello funzionale su cui poter ragionare. Non possono analizzare e correlare i log grezzi come fanno gli umani. L’osservabilità tradizionale presuppone inoltre che sia possibile prevedere ciò di cui è necessario eseguire il debug e strumenti di conseguenza. Questo approccio contrasta con il codice generato dall’intelligenza artificiale, in cui gli ingegneri potrebbero non avere una conoscenza approfondita di ogni funzione.
"Penso che stiamo entrando in una nuova era di codice generato dall’intelligenza artificiale, e questo enigma, questo enigma di un nuovo stack, sta emergendo," Ecco cosa ha detto Adler: "Non penso che lo stack di osservabilità del cloud computing si adatterà esattamente a come sarà il futuro."
Cosa significa questo per le imprese?
Per le organizzazioni che già utilizzano assistenti di codifica AI come GitHub Copilot o Cursor, l’intelligence di runtime fornisce un livello di sicurezza per le distribuzioni di produzione. La tecnologia rende possibile ciò che dice Monday.com "indagine dell’agente" invece di saltare gli strumenti manuali.
Il significato più ampio riguarda la fiducia. "Con il codice generato dall’intelligenza artificiale, stiamo ottenendo molto più codice generato dall’intelligenza artificiale e gli ingegneri stanno iniziando a non conoscere tutto il codice." disse Eilon.
I sensori di runtime colmano questa lacuna di conoscenza fornendo il contesto di produzione direttamente nell’IDE in cui viene scritto il codice.
Per le organizzazioni che desiderano ampliare la generazione di codice AI oltre i progetti pilota, l’intelligenza di runtime risolve un problema fondamentale. Gli agenti AI generano codice in base a presupposti sul comportamento del sistema. Gli ambienti di produzione sono complessi e sorprendenti. I dati comportamentali a livello di funzione raccolti automaticamente dalla produzione forniscono agli agenti il contesto di cui hanno bisogno per creare codice affidabile su larga scala.
Le organizzazioni dovrebbero valutare se il loro attuale stack di osservabilità può fornire in modo economicamente vantaggioso il livello di dettaglio richiesto dagli agenti di intelligenza artificiale. Se il raggiungimento della visibilità a livello di funzione richiede un aumento significativo dei costi di acquisizione o della strumentazione manuale, i sensori di runtime possono offrire un’architettura più sostenibile per i flussi di lavoro di sviluppo accelerati dall’intelligenza artificiale attualmente emergenti nel settore.
