Profiling com agentes de IA no JetBrains Rider: como o dottrace-analyze elimina suposições e encontra gargalos reais
O profiling com agentes de IA chegou ao JetBrains Rider para resolver um problema antigo: o agente que culpa o código errado. Imagine que sua aplicação congela por dez segundos em produção e você pergunta ao agente o que está errado.
O que ele realmente faz? Por muito tempo, a resposta honesta era esta: ele vasculha o código-fonte, encontra algo suspeito e apresenta isso com confiança, como se fosse o gargalo real.
Isso não é falta de inteligência do agente, mas uma limitação estrutural: sem dados de runtime, qualquer hipótese é só uma suposição.
O JetBrains Rider 2026.2 EAP 8 introduz uma skill experimental chamada dottrace-analyze, que muda esse cenário de forma fundamental. Neste artigo, vamos ver como ela funciona, o que os benchmarks da JetBrains mostram e quanto isso custa.
O problema das análises de agentes de IA sem profiling
Agentes de IA que trabalham com otimização de performance geralmente operam da mesma forma. Eles leem arquivos de código-fonte, identificam padrões que historicamente causam lentidão e listam sugestões baseadas em heurísticas.
Essa abordagem tem um limite claro. Afinal, o código pode parecer eficiente e ainda assim ser lento em cenários reais de uso.
Por outro lado, um trecho pode parecer ineficiente e não ter nenhuma relação com o problema investigado. Ou seja, a leitura do código sozinha não separa o que parece lento do que de fato é lento.
Um snapshot de profiling, por sua vez, captura o que o programa realmente fez, algo que agentes de IA não deduzem lendo código. Ele mostra exatamente onde a CPU gastou tempo, quais métodos consumiram mais e qual caminho de chamada levou até eles.
Sem acesso a esse snapshot, o agente não tem outra opção além de eleger um suspeito. Às vezes ele acerta por coincidência, mas em travamentos reais e complexos quase sempre erra.
É justamente essa lacuna que o profiling com agentes de IA tenta fechar. Em vez de adivinhar, o agente passa a partir de uma medição.
O que é a skill dottrace-analyze
A skill dottrace-analyze é uma capacidade experimental do AI Assistant do JetBrains Rider. Na prática, ela habilita o profiling com agentes de IA ao conectar o assistente ao dotTrace, o profiler de performance da JetBrains para .NET.
O funcionamento é direto. Primeiro, o desenvolvedor captura um snapshot .dtp com o dotTrace, seja pelo profiler embutido no Rider, pela versão standalone ou pela ferramenta de linha de comando.
Em seguida, ele referencia o diretório desse snapshot em um prompt no AI Assistant. A partir daí, o agente deixa de começar pela leitura do código e começa pela leitura das evidências de runtime.
A skill carrega o SDK do dotTrace e lê os dados de profiling. Depois disso, entrega ao agente um conjunto estruturado de informações: onde o tempo foi gasto, quais métodos dominam a CPU e quais caminhos de chamada levam até os pontos quentes.
Profiling com agentes de IA no AI Assistant
No Rider 2026.2, as skills são unidades reutilizáveis que ampliam o que um agente consegue fazer. Você as configura na página de ajustes Tools, AI Assistant, Skills, onde também pode instalar novas skills.
Segundo a documentação de skills do Rider, a dottrace-analyze analisa um snapshot .dtp existente e identifica os pontos quentes mais relevantes da aplicação .NET.
Portanto, o profiling com agentes de IA não é um recurso isolado. Ele faz parte de uma estratégia maior da JetBrains de dar aos agentes acesso às mesmas ferramentas que um desenvolvedor usa no dia a dia.
Se você quer entender melhor esse conceito, o artigo sobre o que são skills explica como elas estendem o comportamento de um agente.
O que o agente produz com acesso ao snapshot
No profiling com agentes de IA, o agente analisa o snapshot .dtp e constrói um relatório focado, com quatro componentes principais.
- Resumo dos gargalos: uma visão curta dos gargalos dominantes identificados no perfil.
- Pontos quentes: os métodos, as localizações no código-fonte e os caminhos de chamada que concentram o tempo de CPU.
- Causa raiz: uma explicação em linguagem de desenvolvedor, e não apenas o nome de um método isolado.
- Próximos passos: recomendações concretas sobre o que investigar a seguir.
Para investigações longas ou colaborativas, o agente também gera um relatório HTML que o time pode compartilhar.
Estudo de caso com o freeze do Avalonia
Um dos cenários de teste da JetBrains foi uma versão antiga do Avalonia UI Framework que travava durante o encerramento da aplicação. Esse problema chegou a afetar o próprio Rider dois anos antes.
A metodologia foi deliberada. A equipe testou uma versão do Avalonia anterior à correção publicada no pull request AvaloniaUI/Avalonia#16633.
Usar um bug já resolvido foi essencial, porque oferecia uma resposta de referência para julgar cada diagnóstico.
O mesmo agente rodou dez vezes contra esse problema com a skill ativa e dez vezes sem ela. Em seguida, um LLM-as-judge avaliou cada diagnóstico em relação à causa raiz conhecida, em uma escala de 0 a 10.
Sem a skill, o agente obteve média de 1,6 nas dez execuções. Ele vasculhou o código de renderização, listou sugestões genéricas e nunca chegou ao problema real.
Com a skill ativa, por outro lado, a pontuação foi 10 de 10 em todas as dez execuções, sem exceção. Esse é o tipo de resultado que mostra o valor do profiling com agentes de IA em problemas difíceis.
O que o snapshot revelou
O travamento não estava em nenhum lugar óbvio do código.
Na verdade, o caminho quente passava pelo layout de texto na thread de UI e pelo processamento Unicode BiDi. Uma operação de acesso caractere a caractere, barata isoladamente, era executada tantas vezes que consumia cerca de 88% da CPU na região quente.
Esse tipo de problema é difícil de achar apenas lendo código, e é aí que o profiling com agentes de IA se destaca. Afinal, o custo só aparece quando você consegue ver onde o tempo realmente foi gasto.
Benchmark de profiling com agentes de IA em 80 execuções
Depois do cenário do Avalonia, a equipe ampliou a avaliação para oito cenários de investigação de performance em .NET. No total, foram 80 execuções comparando o mesmo agente com e sem acesso ao profiler.
Os resultados gerais mostram um salto consistente:
| Métrica | Sem a skill | Com a skill |
|---|---|---|
| Pontuação média de precisão | 4,71 | 8,15 |
| Execuções com nota 8 ou mais | 29 de 80 | 59 de 80 |
| Execuções com nota 10 | 20 de 80 | 48 de 80 |
Em outras palavras, o número de execuções com nota alta praticamente dobrou. Além disso, as execuções com acerto perfeito da causa raiz mais que dobraram.
Onde a skill agrega mais valor
O padrão dos resultados por cenário revela algo importante. Nos casos em que a resposta vive nos dados de runtime, como os dois cenários do Avalonia e o cenário Cyclops, a linha de base ficou entre 1 e 2,4 pontos.
Com a skill, esses cenários subiram para a faixa de 8,8 a 10, justamente onde ler o código não basta.
Três cenários, porém, já apresentavam bons resultados sem o profiler. São eles game-of-life, checkers-copy e checkers-update, com médias entre 8,8 e 10 na linha de base.
Nos dois cenários de checkers, a skill causou até uma pequena queda de alguns décimos na pontuação. A equipe da JetBrains foi transparente sobre isso: a skill não é universalmente benéfica.
Quando o código-fonte sozinho basta para identificar o problema, invocar o fluxo completo do profiler gasta tokens e tempo sem necessidade. Ou seja, o profiling com agentes de IA é uma ferramenta para problemas de runtime, e não um passo obrigatório em toda análise.
Como as trajetórias dos agentes mudaram
Além das pontuações, a equipe rastreou as trajetórias dos agentes de IA com e sem profiling. Em outras palavras, registrou a sequência real de ferramentas e arquivos usados.
Na avaliação de encerramento do Avalonia, sem a skill, o agente executou 19 chamadas de ferramentas. Foram duas buscas em subagentes, 13 leituras de arquivos, dois globs e dois greps, sem nenhuma medição.
Nas dez execuções, o agente explorou os caminhos de shutdown, o dispatcher e padrões de bloqueio.
No fim, ele se fixava em Win32DispatcherImpl.cs como suspeito. Assim, construía uma teoria coerente, mas errada, baseada na subtração entre Now e dueTime em UpdateTimer.
Com a skill ativa, o agente executou apenas 10 chamadas: uma para a skill, cinco ao profiler, um grep, um glob e duas leituras de arquivo. O modelo mental mudou para medir primeiro e ler depois.
A sequência também foi outra. Primeiro, o agente invocou a dottrace-analyze e leu o snapshot, que mostrava uma captura de 7,3 segundos com um núcleo de CPU ocupado por cerca de 5,5 segundos.
Em seguida, ele localizou List<T>.Remove como o método com maior tempo próprio, chamado via Classes.RemoveListener. Depois, fez um grep específico, leu Classes.cs e confirmou a remoção O(n²) de listeners como causa raiz.
Para visualizar o problema, pense em um código parecido com este:
// Remover itens de uma List<T> em laço custa O(n) por remoção
// Com n listeners, o encerramento inteiro vira O(n²)
foreach (var listener in listenersToRemove)
{
listeners.Remove(listener);
}
Cada chamada a Remove percorre a lista para achar o item e desloca os elementos seguintes. Por isso, com milhares de listeners, um encerramento aparentemente simples consome segundos de CPU.
As dez execuções com a skill chegaram ao mesmo resultado correto. Enquanto isso, as dez sem ela convergiram para a mesma área errada.
O custo do profiling com agentes de IA
A equipe mediu o custo com o mesmo rigor da precisão, já que uma skill cara demais não seria viável como produto.
No lote de 80 execuções, o custo médio por execução subiu de aproximadamente USD 1,91 sem a skill para cerca de USD 2,61 com ela. Já o custo total do lote foi de cerca de USD 153 sem a skill e USD 209 com ela.
No cenário específico do encerramento do Avalonia, porém, o comportamento foi inverso. Sem a skill, o agente vagava atrás de um culpado que nunca encontrava, lendo arquivo após arquivo.
Nesse caso, ele gastava em média USD 3,74 por execução e 373 segundos de tempo de execução. Com a skill, o agente ia direto para a evidência e chegava à resposta por USD 2,58 e 206 segundos, em média.
A síntese da equipe é honesta: o profiling com agentes de IA muda onde o dinheiro é gasto. Ela investe mais na leitura de evidências e menos na exploração de becos sem saída.
Dependendo do cenário, o custo total pode ser maior ou menor. Em ambos os casos, contudo, você paga por uma resposta fundamentada no que a aplicação realmente fez.
Como usar o dottrace-analyze no Rider
O fluxo de trabalho foi projetado para ser simples. O primeiro passo é capturar um snapshot .dtp com o dotTrace, usando uma das três opções disponíveis.
- Pelo profiler embutido no próprio Rider.
- Pelo dotTrace Standalone.
- Pela ferramenta de linha de comando do dotTrace.
Capturando o snapshot pela linha de comando
A opção de linha de comando é útil para levar o profiling com agentes de IA a servidores e pipelines. Segundo a documentação do dotTrace, você pode instalá-la como ferramenta global do .NET:
# Instala a ferramenta de linha de comando do dotTrace
dotnet tool install --global JetBrains.dotTrace.GlobalTools
# Conecta ao processo em execução (PID 1234) e salva o snapshot
dottrace attach 1234 --save-to=./snapshots/snapshot.dtp
O comando attach usa o tipo de profiling Sampling por padrão, que gera arquivos .dtp. Esse é justamente o formato que a skill lê, então o arquivo já sai pronto para a análise.
Pedindo o profiling ao agente de IA
Com o snapshot em disco, abra a janela do AI Assistant no Rider e faça uma pergunta ao agente referenciando o diretório do snapshot. Por exemplo:
Analyze the dotTrace snapshot in ./snapshots and explain why the app freezes on shutdown.
O agente localiza o arquivo, invoca a skill dottrace-analyze e inicia a análise. Em seguida, o resultado volta como um relatório focado diretamente na conversa.
Se várias pessoas trabalham na mesma questão, peça também o relatório HTML para abrir no navegador.
Disponibilidade e licenciamento
A skill dottrace-analyze chegou no Rider 2026.2 EAP 8, publicado em 25 de junho de 2026. Durante o Early Access Program, você pode testar o fluxo gratuitamente na versão EAP.
Para uso regular fora do EAP, a parte de profiling depende do dotTrace. O plugin dotTrace e dotMemory do Rider faz parte das assinaturas dotUltimate e All Products Pack.
Uma assinatura apenas do Rider, portanto, não inclui o profiling com agentes de IA.
A JetBrains também deixa claro que esse profiling com agentes de IA ainda é uma implementação inicial e experimental. O objetivo do EAP é coletar feedback real antes da versão estável, principalmente sobre a qualidade e a confiabilidade dos relatórios.
O princípio por trás do profiling com agentes de IA
O anúncio da JetBrains evidencia uma distinção fundamental entre dois tipos de análise. Sem o snapshot, o melhor que um agente oferece é algo como "aqui estão alguns padrões de código que podem ser lentos".
Com o snapshot, por outro lado, o agente pode afirmar que 88% do tempo foi gasto em um ponto específico e explicar o motivo. Essa diferença muda completamente a confiança no diagnóstico.
Performance tem uma exigência que a maioria das tarefas de codificação não tem. A resposta precisa corresponder ao que o programa realmente fez, e não ao que ele parece poder fazer.
As execuções bem-sucedidas nos benchmarks tinham todas a mesma forma. Elas nomeavam o método, explicavam o caminho de chamada, quantificavam a região quente e separavam a causa raiz dos sintomas.
Além disso, elas propunham uma correção que seguia diretamente do perfil. Essa é a forma de uma investigação conduzida por um especialista, possível apenas quando o agente parte das mesmas evidências.
A mesma lógica aparece em outras ferramentas. O Binlog MCP Server da Microsoft, por exemplo, entrega aos agentes os logs binários do build em vez de deixá-los adivinhar a causa de uma falha.
Conclusão
A skill dottrace-analyze representa uma mudança de paradigma no modo como agentes lidam com investigações de performance em .NET. Ao ancorar a análise em dados de runtime, o profiling com agentes de IA transforma um agente que adivinha em um agente que mede.
Os benchmarks da JetBrains são honestos, inclusive nos casos sem melhora. Ainda assim, quando a causa raiz vive nos dados de execução, o snapshot separa diagnóstico de especulação.
Para equipes .NET que já usam o dotTrace, o profiling com agentes de IA no Rider 2026.2 é uma extensão natural do fluxo existente. Por isso, vale testar a skill no EAP 8 e enviar feedback para moldar a evolução do recurso antes da versão estável.
FAQ
O que é a skill dottrace-analyze?
É uma funcionalidade experimental do AI Assistant no JetBrains Rider. Ela permite que o agente leia snapshots de profiling do dotTrace antes de analisar o código-fonte.
Quais são os requisitos de licença para usar esse recurso?
Durante o EAP do Rider 2026.2, você pode testar o recurso gratuitamente. Para uso regular, é necessária uma assinatura dotUltimate ou All Products Pack, já que uma assinatura apenas do Rider não inclui o dotTrace.
A skill dottrace-analyze sempre melhora o diagnóstico?
Não necessariamente. Quando o problema é identificável apenas pela leitura do código, a skill pode não agregar valor e ainda elevar o custo da execução.
Qual formato de snapshot é compatível com a skill?
A skill trabalha com arquivos .dtp, o formato do dotTrace para o profiling do tipo Sampling. Você pode capturá-los pelo profiler do Rider, pelo dotTrace Standalone ou pela linha de comando.
A skill está pronta para uso em produção?
Ainda não, porque se trata de uma implementação inicial dentro do Early Access Program do Rider 2026.2. A JetBrains está coletando feedback antes de um possível lançamento no canal estável.
O custo de tokens aumenta com o uso da skill?
Depende do cenário. No benchmark de 80 execuções, o custo médio subiu cerca de USD 0,70 por execução, mas no encerramento do Avalonia a skill reduziu tanto o tempo quanto o custo.
Como o benchmark foi conduzido?
A JetBrains testou o mesmo agente com e sem a skill em oito cenários de performance em .NET, totalizando 80 execuções. Um LLM-as-judge avaliou cada diagnóstico com base na causa raiz de referência conhecida.