Economize o Tempo Chato

Oito posts neste blog sobre IA no ciclo de desenvolvimento. O ciclo é real e o valor é real. Mas meça onde os desenvolvedores realmente gastam tempo desperdiçado, e a resposta raramente é "escrever funcionalidades". A resposta é o trabalho que cerca escrever funcionalidades: fazer triagem de um alerta às 03:00, ler três terabytes de logs depois que um deploy deu errado, rolar Grafana tentando entender por que o p95 subiu, caçar a regressão de performance que comeu um trimestre.

Esse trabalho é o tempo chato. É também onde a divisão de trabalho sobre a qual este blog vem escrevendo paga melhor. O modelo coleta, lê, correlaciona, e rascunha um plano concreto. O desenvolvedor valida e decide. Mesma física do ciclo de desenvolvimento. Outra área de superfície, com um conjunto bem maior de minutos chatos para economizar.

Eu trabalho num domínio regulado onde código errado tem consequências. Resposta a incidente errada com consequências é até mais rápida do que código errado subindo com consequências. Isso inclina o argumento ainda mais. Qualquer coisa que coloque olhos humanos sobre a hipótese certa mais cedo vale a pena montar.

Três fluxos

1. Triagem de incidentes.

Um alerta dispara. Hoje o desenvolvedor de plantão abre cinco abas: logs, métricas, o deploy mais recente, o issue tracker, o runbook. Os primeiros trinta minutos são coletar e correlacionar. A hora seguinte é decidir.

O fluxo com IA: o alerta dispara um agente que lê o alerta, os logs relacionados, os deploys recentes, o runbook relevante, os PRs recentes, o histórico de teste dos arquivos afetados. Ele abre uma issue (ou responde ao incidente do PagerDuty) com um resumo triado, uma lista ranqueada de suspeitos, e um plano de "o que eu investigaria primeiro". O desenvolvedor acorda com um ticket triado, não com uma tela em branco.

A categoria já tem nome. Opções open-source neste espaço em 2026 incluem o k8sgpt, um projeto CNCF Sandbox que escaneia clusters Kubernetes e explica os achados via um LLM, e o HolmesGPT da Robusta, um agente open-source de incident response que lê logs, alertas, runbooks e métricas para produzir um diagnóstico ranqueado. Quando o alerta flui via GitHub Issues, a Claude Code Action oficial cuida do passo de triagem dentro de um workflow.

2. Melhorias em produção.

Um agente agendado lê a base de código, as métricas de performance, os traces recentes, o relatório de dead code. Ele identifica os hotspots de verdade, não os teóricos. Ele escreve um PR com o fix, os novos testes, e um corpo curto de "porque". O desenvolvedor revisa e dá merge, ou rejeita com um comentário.

Exemplos concretos: derrubar uma consulta N+1 que o agente encontrou correlacionando um trace lento com um query log, adicionar cache num endpoint quente, lazy-load no componente pesado que bloqueia o LCP, deletar o caminho de código morto que ninguém chama.

Isso funciona porque o agente tem os mesmos sinais que um engenheiro sênior tem depois de uma manhã lenta de segunda escavando, só que ele escava toda noite, no agendamento, e a saída é um PR que você revisa, não um Jira que você empurra com a barriga.

3. Reconhecimento de padrões em métricas.

Um agente assiste a dashboards (Grafana, Datadog, Honeycomb, o APM da sua escolha) num ritmo. Quando o p95 sobe, quando a taxa de erro cresce devagar, quando um padrão de profundidade de fila muda, ele correlaciona a mudança com a linha do tempo dos deploys, as feature flags, os commits, as dependências. Ele posta um resumo curto de "o que mudou e o que parece suspeito" no canal Slack certo.

O desenvolvedor passa de "rolar o Grafana, depois git log, depois kubectl get" para "ler o resumo, decidir se é de verdade". Mesmo tempo chato, foi-se.

Onde o agente mora

Duas superfícies, e a certa depende do que o agente precisa ler.

GitHub Actions. Orientado a eventos, escopo do repositório, fácil de montar. A Claude Code Action escuta eventos de issue, revisões de PR, menções a @claude, ou crons agendados. O uso de tokens é medido. O padrão publicado de Auto-Triage Issues mostra redução de 62% em uso de tokens depois de centenas de execuções, uma vez que o prompt é ajustado. Encaixe ideal para triagem de issues, triagem de PRs, scans agendados de melhoria de produção, e qualquer fluxo cujo gatilho é um evento de repositório ou um cron. A action roda nos runners do GitHub, então ela não consegue ver dentro do seu cluster.

Agente in-cluster. Quando o agente precisa ler o que está acontecendo dentro do cluster (queries no Prometheus, logs no Loki, traces, serviços que não saem para fora), ele tem que morar lá dentro. O padrão é um Job ou Deployment do Kubernetes rodando o agente com uma service account de escopo restrito, dando exatamente as permissões de leitura que ele precisa. O framework open-source canônico para isso é o kagent, projeto CNCF Sandbox originalmente da Solo.io. Os agentes são definidos como CRDs do Kubernetes, versionados no Git, revisados em PRs, e implantados com as mesmas ferramentas que o time de plataforma já usa. Neutro do lado do LLM e das ferramentas, com traces OpenTelemetry e métricas Prometheus embutidos. Encaixe ideal para triagem de incidente que precisa de estado interno, scans de performance que precisam de acesso vivo ao APM, e reconhecimento de padrões em métricas que precisa do Prometheus direto.

Chamada honesta. GitHub Actions é o ponto de partida certo. É um YAML, sem conversa com o time de plataforma. Você gradua para in-cluster quando o agente precisa de contexto que a action não alcança.

O não-negociável: operador no loop

Em fevereiro de 2026 um desenvolvedor documentou publicamente um experimento de 30 dias em que um agente autônomo tinha as deploy keys de produção. O agente causou uma queda de 13 horas ao deletar um ambiente inteiro de produção tentando corrigir um erro de config. Leia o relato do incidente se você está considerando autonomia. É um argumento mais rápido do que qualquer seção de spec.

A lição não é "IA é perigosa". A lição é a mesma que este blog vem escrevendo há nove posts: o modelo é dono da execução, o desenvolvedor é dono da decisão. Para ops isso significa que o agente faz triagem, rascunha, propõe. Ele não age em produção sem um passo de aprovação humana.

A fundação, de novo

Nada disso funciona sem a fundação por baixo. Para o ciclo de desenvolvimento, a fundação era specs e contexto compartilhado. Para ops, a fundação é observabilidade: logs pesquisáveis, métricas reais, traces existindo, alertas ajustados, runbooks escritos. O agente lê o que está escrito. Se o alerta está errado, o agente faz triagem da coisa errada. Se o runbook não existe, o agente chuta.

Construa a observabilidade primeiro, depois ponha o agente em cima. O agente é a camada de alavancagem, não a fundação que faltava.

Fechando

O ciclo de desenvolvimento é um lugar onde a IA economiza tempo. Ops é o outro, e é maior, porque é onde os desenvolvedores mais desperdiçam. Três fluxos economizam os minutos mais chatos: triagem de incidentes, melhorias em produção, reconhecimento de padrões em métricas. Duas superfícies os rodam: GitHub Actions para começar, in-cluster quando você gradua. Uma regra mantém tudo seguro: o desenvolvedor valida o plano concreto, o agente nunca executa em produção sozinho.

O ciclo de desenvolvimento foram oito posts de fundação. É para isso que a fundação serviu.