Rider porta il profiling dentro il flusso degli agenti AI: perché conta più del chatbot

Quando un agente AI lavora sul codice, il rischio è sempre lo stesso: sa leggere una funzione, seguire un call graph e proporre una modifica, ma spesso ragiona su ciò che il software dovrebbe fare più che su ciò che sta realmente facendo durante l’esecuzione.

Con Rider 2026.2.3 JetBrains sposta un pezzo del problema: il Monitoring tool window raccoglie dati runtime mentre l’applicazione gira e, da quegli snapshot, un agente può essere invitato ad analizzare dove viene speso il tempo, seguire hot path nel codice e restituire osservazioni in chat tramite la skill dottrace-analyze.

La novità non è “Rider ha messo l’AI nel profiler”. La parte interessante è un’altra: l’agente non deve più inferire un collo di bottiglia soltanto dal sorgente; può ricevere una rappresentazione strutturata di ciò che è successo davvero a runtime.

Il salto utile non è aggiungere un chatbot all’IDE. È ridurre la distanza fra il codice che l’agente vede e il comportamento che il programma ha realmente mostrato.

Il profiling smette di essere un mondo separato

Il profiling tradizionale ha un flusso abbastanza chiaro: esegui l’applicazione, raccogli dati, apri lo snapshot, leggi call tree e hot path, formuli un’ipotesi, torni al codice. Funziona, ma richiede che chi sta investigando sappia attraversare manualmente più rappresentazioni dello stesso problema.

JetBrains ora consente di partire direttamente dal Monitoring tool window con l’azione Analyze with AI. L’IDE prepara una richiesta basata sull’ultima sessione; l’utente può controllare il prompt e poi inviarlo all’agente. Per snapshot meno recenti, la stessa azione è disponibile dal menu contestuale della scheda Recent snapshots nel tool window di dotTrace.

Questo dettaglio è importante perché delimita bene ciò che sta succedendo: non è un agente che profila autonomamente qualunque processo a sua insaputa. È un flusso esplicito in cui esiste già uno snapshot, l’utente decide di analizzarlo e il contesto di performance viene passato all’agente.

La differenza fra leggere codice e leggere comportamento

Dal sorgente posso vedere un ciclo annidato, una serializzazione sospetta o una catena di chiamate poco elegante. Ma il codice da solo non mi dice necessariamente dove l’applicazione stia davvero consumando tempo in quella sessione.

La telemetria runtime cambia la qualità dell’evidenza. Se il profiler mostra che il tempo si concentra in un hot path preciso, l’agente parte da un segnale osservato. Può poi risalire dal comportamento al codice, invece di partire dal codice e immaginare il comportamento.

È una distinzione che nei sistemi agentici conta parecchio. Un modello può essere bravissimo a produrre una spiegazione plausibile. Ma un sistema operativo deve essere progettato per sostituire plausibilità con evidenza quando quell’evidenza esiste.

È lo stesso motivo per cui considero centrale il principio discusso nell’articolo su artefatti verificabili negli agenti: ciò che il modello racconta va sempre messo in relazione con uno stato osservabile del sistema.

dottrace-analyze è interessante perché restringe il contesto

Il problema non è soltanto dare più dati al modello. Dare tutto spesso significa peggiorare la decisione: più rumore, più token e più possibilità di concentrarsi sulla cosa sbagliata.

Nel flusso descritto da JetBrains, la skill dottrace-analyze serve a tradurre lo snapshot in un contesto che l’agente possa usare per mostrare dove è stato speso il tempo, seguire gli hot path e produrre insight sulla performance.

Questo è molto più interessante di un prompt generico tipo “ottimizza questo metodo”. Il sistema parte da dati raccolti da uno strumento specializzato e li consegna a un agente attraverso un’interfaccia dedicata. Il profiler resta il profiler; il modello diventa il livello che aiuta a interpretarne il risultato.

La direzione è coerente anche con il problema del tool retrieval per agenti: la qualità non dipende dall’avere accesso a più strumenti, ma dal mettere a disposizione lo strumento e l’informazione corretti nel momento in cui servono.

Non è “l’AI che fa performance engineering al posto tuo”

È facile trasformare questa funzione in una promessa più grande di quella realmente documentata. Rider 2026.2.3 non dimostra che un agente possa fare performance engineering in autonomia né che sia in grado di distinguere sempre causalità, correlazione e rumore in uno snapshot.

JetBrains documenta un flusso più concreto: Monitoring raccoglie i dati runtime, l’utente avvia Analyze with AI, controlla la richiesta e l’agente usa la skill dedicata per investigare il profilo.

Quindi la responsabilità architetturale resta distribuita:

• dotTrace raccoglie e struttura i dati di performance;
• Rider definisce il punto di ingresso e il contesto;
• la skill rende quei dati utilizzabili dall’agente;
• il modello interpreta e collega i segnali al codice;
• lo sviluppatore decide quali ipotesi meritano una modifica e una nuova misura.

È una divisione del lavoro molto più sana del “lascia fare tutto al modello”, perché mantiene strumenti deterministici e telemetria come fonte dell’evidenza.

La parte più forte è il ciclo misura → interpreta → modifica → misura

La performance non si ottimizza con una singola intuizione. Si lavora per cicli: osservi, formuli un’ipotesi, modifichi, misuri di nuovo. Se l’agente viene inserito dentro questo ciclo con accesso alla telemetria, può diventare utile senza dover essere infallibile.

Può aiutare a individuare velocemente un percorso caldo, collegarlo a una porzione di codice, proporre una spiegazione e magari suggerire quale modifica vale la pena testare. Ma il secondo snapshot resta decisivo: è quello che dice se la modifica ha migliorato realmente il comportamento.

In altre parole, l’agente può comprimere il tempo fra misura e ipotesi. Non dovrebbe sostituire la misura.

Un agente utile non deve avere sempre ragione. Deve essere inserito in un ciclo in cui gli errori di interpretazione vengono smascherati rapidamente dai dati.

È un pezzo di quella che chiamo architettura cognitiva dell’harness

Il tema si collega direttamente a quanto emerso nei benchmark sulle interazioni fra modello e harness. Lo stesso modello può comportarsi in modo molto diverso a seconda di come il sistema gli presenta strumenti, errori, stato e contesto.

Qui Rider sta facendo esattamente quel lavoro di harness: prende un artefatto tecnico specialistico — lo snapshot di profiling — e lo rende accessibile all’agente attraverso un percorso definito. Non cambia il modello. Cambia la qualità dell’ambiente in cui il modello prende decisioni.

È il punto che avevo discusso parlando di coppia modello-harness negli agenti AI: il comportamento non appartiene soltanto al modello, ma al sistema che gli costruisce attorno un action space e un observation space sensati.

Le limitazioni contano più del marketing

La funzione, al momento del rilascio 2026.2.3, è disponibile soltanto su Windows. JetBrains richiede inoltre dotUltimate oppure All Products Pack, insieme al plugin AI Assistant installato.

Non è quindi una capability universale di Rider né qualcosa che compare automaticamente su qualunque installazione. E soprattutto non elimina i limiti classici dell’analisi di performance: uno snapshot resta legato al workload, ai dati, alla macchina e al percorso di esecuzione che lo ha prodotto.

Un agente può interpretare bene lo snapshot sbagliato e portarti comunque nella direzione sbagliata. Se il test non rappresenta il traffico reale, se il warm-up altera i numeri o se il problema è intermittente, il collo di bottiglia osservato potrebbe non essere quello che conta in produzione.

Il fatto che il contesto arrivi da dotTrace aumenta la qualità dell’evidenza, non rende l’evidenza automaticamente rappresentativa.

Per chi sviluppa .NET il segnale è più grande della singola feature

Rider 2026.2.3 è un update minore, ma questa integrazione mostra bene dove stanno andando gli strumenti di sviluppo: non verso un unico assistente onnisciente, ma verso agenti che ricevono contesti specialistici prodotti da strumenti già maturi.

Il debugger può fornire stato. Il profiler può fornire hot path. Il test runner può fornire failure. Il compilatore può fornire diagnosi. L’IDE può mettere insieme questi segnali e trasformarli in osservazioni che il modello riesce a usare.

Questa architettura mi convince molto più dell’idea di sostituire gli strumenti tradizionali con l’AI. Gli strumenti specialistici continuano a produrre dati affidabili; l’agente li attraversa, li collega e riduce il lavoro manuale necessario per passare da un segnale tecnico alla porzione di codice pertinente.

Il prossimo vero benchmark non è “quanto bene risponde?”

Per valutare una funzione del genere non mi interessa sapere soltanto se la risposta sembra intelligente. Vorrei misurare altro: quanto tempo serve per arrivare a un’ipotesi corretta, quante false piste vengono proposte, quante modifiche producono un miglioramento misurabile e quante regressioni vengono introdotte.

Il benchmark serio dovrebbe quindi partire da sessioni di profiling reali con colli di bottiglia noti, passare per l’analisi dell’agente e terminare con una seconda misura dopo la modifica.

Solo a quel punto possiamo dire se l’integrazione sta riducendo davvero il costo del performance engineering oppure se sta semplicemente rendendo più elegante la spiegazione di uno snapshot.

L’AI diventa più utile quando vede meno fantasia e più realtà

La cosa che trovo interessante in questa release è precisamente il suo limite. JetBrains non sta cercando di far “intuire” al modello le performance. Gli sta passando dati raccolti da uno strumento che esiste da anni per misurarle.

È un approccio molto più pragmatico: usare l’LLM dove ha senso — interpretazione, collegamento, sintesi, proposta — e mantenere profiling, raccolta dati e verifica nel dominio di strumenti tecnici specializzati.

Quando gli agenti iniziano a ricevere telemetria, snapshot, errori strutturati e artefatti verificabili, smettono lentamente di essere chatbot dentro l’IDE. Diventano un livello di orchestrazione sopra strumenti che conoscono già la realtà del sistema meglio di loro.