Um endpoint tinha picos de latência esporádicos. A resposta demorava cinco vezes mais que o normal as vezes e ninguém tinha tempo de parar pra entender o problema.
Ele não quebrava, não acordava ninguém de madrugada, não gerava incidente. Só respondia devagar de vez em quando e isso prejudicava a experiência de poucos clientes, por isso nunca virava prioridade.
Você conhece esse endpoint. Todo sistema tem o dele.
Até que eu decidi pedir para o agente de IA investigar. Era uma tarefa que demandaria conhecimentos de observabilidade, banco de dados e código. Sem agentes de IA, ia precisar envolver umas três pessoas.
Com o agente, eu resolvi em uma tarde e ainda ensinei a ele como repetir o processo pra depurar as próximas requisições lentas.
O span que segurava o tempo
Abri o agente e dei a ele o MCP da ferramenta de observabilidade. A partir dali ele não estava mais lendo o que eu colava no chat, estava consultando a ferramenta.
Ele puxou os traces daquele endpoint, ordenou pelos mais lentos e a conta apareceu rápido: um span consumia quase todo o tempo da requisição, e dentro dele estava uma query SQL.
Isso é o passo que qualquer um faz. Se a história parasse aqui, o agente teria economizado quinze minutos meus e nada mais.
O que o trace não guardava
A query que aparece no span vem parametrizada. Você vê a forma, não vê os valores. E é com os valores reais que ela ficou lenta, não com valores de exemplo.
Foi aqui que a coisa mudou de patamar. O agente tinha, ao mesmo tempo, três coisas na mão: as properties daquele trace, o MCP do data lake para buscar o que faltava, e o código do repositório.
Com o código ele descobriu qual trecho monta aquela query e quais parâmetros entram nela. Com as properties do trace ele soube quais eram os identificadores daquela requisição específica. Com o data lake ele foi buscar os dados que nem o trace nem o código guardavam.
E reconstruiu a query real. Não uma parecida, a que estava lenta.
Repara que nenhuma dessas três fontes resolve sozinha. O trace sabe quando, o data lake sabe o quê, o código sabe como. A investigação inteira mora na interseção, e é exatamente por isso que ela costumava precisar de três pessoas.
A pergunta que só o banco responde
Com a query real montada, o agente escreveu o EXPLAIN ANALYZE.
O EXPLAIN sozinho mostra o plano que o banco pretende executar: qual índice ele acha que vai usar, em que ordem vai juntar as tabelas, quantas linhas ele estima em cada etapa. O ANALYZE faz o banco rodar de verdade e devolver o plano com os números reais ao lado dos estimados. É a diferença entre a intuição do banco e o que aconteceu, e quase todo gargalo de query mora nessa diferença: onde ele estimou cem linhas e vieram duzentas mil.
E aí o agente parou.
Primeiro gate: quem roda sou eu
Parou de propósito, e é o primeiro dos dois momentos em que essa história depende de mim.
EXPLAIN ANALYZE executa a query. Rodar contra um banco frio devolve um plano que não descreve o problema, então a resposta útil só vem de um banco quente, com os dados e a estatística de produção, ou de uma réplica que valha por um. E decidir se aquela query pode rodar ali, agora, com aquele volume, não é uma pergunta técnica. É uma pergunta de responsabilidade, e a responsabilidade é minha.
Então o desenho é esse, e ele se repete: o agente prepara, você decide. Ele chega até a borda do que é decisão sua e para na borda, com o trabalho pronto.
Rodei. Peguei o plano de execução em JSON e devolvi para ele.
Do plano ao PR
Um plano de execução em JSON é uma árvore com dezenas de nós, cada um com custo estimado, custo real, linhas estimadas, linhas reais e tempo. Ler isso a olho é possível e é chato, e é onde a maioria das investigações morre de tédio.
O agente achou os nós que estouravam. Mas o que ele fez depois é o ponto: ele voltou para o código.
Porque saber onde o banco sofreu não diz o que consertar. O mesmo gargalo aceita correções muito diferentes, e escolher entre elas é uma decisão de projeto. Pode ser um ajuste em como a query é gerada. Pode ser um índice que não existe. Pode ser uma desnormalização, guardar o dado já calculado em vez de recalcular. Pode ser uma mudança de modelo, e aí o problema nunca foi a query. Quem só vê o plano chuta entre essas quatro. Quem vê o plano e o código pode escolher.
Ele escolheu, escreveu a mudança e abriu o PR. E a descrição do PR não era um resumo do diff: era o link para o trace lento que originou tudo, a explicação de por que aquela mudança ataca a causa e não o sintoma, e como testar.
Segundo gate: quando isso vai pro ar
O segundo momento em que a história depende de mim.
Eu reviso, eu decido se aceito aquela proposta de correção, e eu decido quando aquilo vai para produção. Um fix de performance que muda um índice ou um modelo de dados tem hora certa para subir, e essa hora é uma escolha de quem responde pelo sistema.
Repara na conta: numa investigação que cruzou observabilidade, banco de dados e código, o humano apareceu exatamente duas vezes. Nas duas foi para decidir, nunca para operar.
A skill que ficou da tarde
No fim do dia eu pedi mais uma coisa: que ele escrevesse o processo que tinha acabado de executar. Não um relatório do que aconteceu, mas as instruções para fazer de novo. Isso é uma skill: uma pasta com o passo a passo, os scripts e o contexto que o agente carrega quando a tarefa aparece.
O nome disso na documentação da Anthropic é conhecimento procedural capturado, e a orientação deles é literalmente essa: enquanto você trabalha numa tarefa com o agente, peça que ele consolide as abordagens que deram certo em contexto e código reutilizáveis. Uma skill não é documentação sobre o agente. É a experiência daquela sessão, escrita num formato que a próxima sessão consegue ler.
E o que ele escreveu não foi só o caminho rápido. Foram os dois gates junto: montar o EXPLAIN ANALYZE e parar, esperar o plano voltar, abrir o PR e parar de novo. O lugar onde ele tem que me esperar virou parte do procedimento.
No dia seguinte apareceu outra requisição lenta. Rodei a skill. Não expliquei quais MCPs, nem em que ordem, nem que os parâmetros precisavam vir do trace e não de um exemplo. O prompt foi literalmente:
/analyze-slow-trace <link-para-o-trace>A fila que sumiu
No desenho antigo, aquelas três disciplinas eram três pessoas, e nenhuma delas com o problema inteiro na cabeça ao mesmo tempo.
A fila nunca cobrou só o tempo de execução. Ela cobrava fricção organizacional, porque cada handoff era uma pessoa com a própria agenda.
Cobrava a taxa de “ler a mente”, porque explicar um problema pela metade para quem não estava lá é onde a informação vaza.
Cobrava coordenação, que é o trabalho de fazer as pessoas certas olharem para a mesma coisa no mesmo dia.
E cobrava negociação, porque o meu incidente disputava espaço com o incidente dos outros.
Nada disso aparece no ticket. Tudo isso aparece no calendário.
O que sumiu foi a fila, e as pessoas continuam lá. Os dois gates são a prova: as duas decisões que importavam foram tomadas por uma pessoa.
A conta que chega depois
Só que a fila não evaporou. Ela andou.
Quando uma pessoa faz o trabalho que antes precisava de três, o código passa a sair mais rápido do que o time consegue revisar. Uma sessão do agente de uma tarde vira um PR. Quatro agentes viram quatro PRs, e do outro lado tem um revisor com o mesmo número de horas que tinha antes.
Fazer sozinho não é aprovar sozinho. No caso aqui em cima os dois momentos que continuaram atrás de um humano foram justamente os dois de aprovação, e não por acaso.
Essa conta tem endereço nesta série: ela é o superpoder 4, a Rapidez, e a armadilha que vem junto.
As duas coisas
Rodar contra um banco quente. Publicar em produção.
Foram essas as duas, e as duas são decisão. Tudo o que estava no meio, que é o que sempre consumiu a tarde, o agente fez porque conseguia ver as três fontes ao mesmo tempo.
E você? Qual foi a última vez que passou horas pra depurar uma requisição lenta?Quantas pessoas você envolveu?
Me conta o que você vai ensinar o seu agente a fazer.
A palestra completa, com os cinco superpoderes, está em vbmendes.dev/palestras/rogadx-2026.