O pior conselho que vejo sendo dado a times pequenos de dev é "comece a automatizar tudo". Times de cinco pessoas não têm banda para construir cinco agentes. Mal têm banda para construir um. Erre na escolha do primeiro agente e você gasta três semanas em algo que o time usa duas vezes e abandona.
A pergunta que vale a pena responder: em um time de 2 a 10 desenvolvedores, qual é o primeiro agente que você constrói? A resposta depende do que mais dói. Mas existe uma ordem real, e existe uma automação sedutora que eu absolutamente não construiria primeiro. Deixa eu passar por ela.
Os Seis Candidatos
Essas são as seis que sempre aparecem na proposta. Eu ranqueio em dois eixos: esforço para construir, e valor depois de existir. As que ficam no canto superior direito saem do papel. As que ficam no canto inferior esquerdo viram papo de corredor e nunca são entregues. Nenhuma delas precisa de ordem de compra para começar: SonarQube Community Build, um Sentry self-hosted e GitHub Actions em plano gratuito cobrem a lista inteira, com uma ressalva de licença na primeira que eu explico mais abaixo.
O Sedutor Que Eu Pularia: Assistente de Onboarding
O agente de onboarding parece ótimo. Novo contratado entra, o agente explica a codebase, responde perguntas de arquitetura, sugere as primeiras tarefas. É a automação que anima todo mundo. É o pior lugar para começar.
Por quê. O agente de onboarding precisa saber tudo. Cada serviço, cada convenção, cada padrão depreciado, cada razão pela qual uma decisão estranha foi tomada três anos atrás. Se a base de conhecimento estiver errada ou incompleta, o novo contratado aprende coisas erradas e você tem que desaprender depois. Se a base de conhecimento estiver completa, você já fez 80 por cento do trabalho de onboarding, e um README faria a maior parte do serviço.
Em um time pequeno você contrata talvez 2 ou 3 pessoas por ano. O agente dispara 2 ou 3 vezes. Toda outra automação dessa lista dispara a cada PR ou a cada merge. Você está gastando semanas de esforço de engenharia em um agente que roda um punhado de vezes por ano e que dá resultado errado se a base de conhecimento não estiver perfeita. Pule. Construa quando você for um time de 30, não de 8.
Comece Aqui: Ponte SonarQube para Copilot
Esse merece um post próprio. Versão curta: o Sonar sinaliza problemas em código assistido por IA, e os desenvolvedores ignoram o dashboard porque agir em cima custa trocas de contexto. O agente lê o relatório do Sonar, gera um prompt de Copilot pronto para colar, e deixa no PR. O desenvolvedor cola, revisa, commita.
Por que esse primeiro. Ele dispara em todo PR. A entrada é uma API estruturada. A saída é texto, sem risco de execução. Um único desenvolvedor consegue construir em um fim de semana. Cada membro do time vê valor já na primeira semana. Essa é a vitória mais fácil que eu conheço, e os times ainda não constroem.
A ressalva que ninguém coloca no pitch: análise de pull request exige SonarQube Developer Edition ou superior. O Community Build rejeita sonar.pullrequest.key, então o gatilho por PR não é gratuito. A versão gratuita desse agente roda em cima de análise de branch: escaneie a main, leia as issues que apareceram desde a última análise, comente no commit de merge. Você perde o feedback antes do merge e mantém todo o resto. O plugin comunitário de branches (mc1arke/sonarqube-community-branch-plugin) traz o gatilho por PR de volta no Community Build, de forma não oficial e sem suporte da SonarSource. Decida isso antes de reservar o fim de semana.
Segundo: Detector de Drift de Docs
Esse roda no merge para a main. O agente olha quais arquivos mudaram no PR e verifica se a documentação relacionada foi atualizada. Se não foi, ele posta um comentário ou abre um PR de atualização de docs com um rascunho.
Por que segundo. Drift de documentação é universal. Ninguém atualiza docs por vontade própria, todo mundo atualiza docs sob pressão pouco antes de uma release ou de um onboarding. Um agente que sinaliza o drift no momento em que acontece significa que você corrige em 10 minutos, em vez de auditar 200 páginas seis meses depois.
Cicatriz de times com quem já trabalhei: docs ficam desatualizadas porque a atualização é um PR separado e acaba sendo despriorizada. A correção é amarrar a atualização de docs à mudança de código em vez de deixar para depois. O agente faz isso: ele abre o PR de docs vinculado ao PR de código, mesmo sprint, mesmo revisor.
Terceiro: Bot de Briefing de Standup
Às 9h, o agente puxa: commits do dia anterior por desenvolvedor, PRs abertos ou mergeados, mudanças de status no Jira, menções de bloqueios no Slack. Ele posta um briefing por pessoa no canal do time. O humano ainda faz a standup. O bot só substitui o exercício de memória do tipo "deixa eu dar uma olhada no meu git log rapidinho".
Por que terceiro. É de baixo risco, baixo esforço e alto sinal. Tech leads amam porque os impedimentos aparecem sem precisar que as pessoas voluntariamente tragam. As pessoas do time amam porque o demo do dia anterior já vem escrito.
Quarto: Triagem de Bugs
Dispara em novos eventos do Sentry ou em issues recém-abertas no GitHub. O agente classifica a severidade, busca incidentes passados parecidos no vector store, atribui um responsável com base em ownership de arquivo via git blame, e manda uma mensagem no Slack para a pessoa certa.
Por que quarto, não primeiro. Triagem de bugs exige duas coisas que os agentes anteriores não exigem: uma memória já populada (vector store de bugs passados), e uma lógica de classificação afinada para o seu time. Entregue depois que os dois primeiros estiverem rodando, não na primeira semana. Até lá você já tem rodadas suficientes da ponte do Sonar e do detector de docs para entender como construir um agente mais stateful.
Quinto: Assistente de Revisão de PR
Primeira passada na revisão de PR antes do humano chegar. Verifica convenções, risco, cobertura, probabilidade de regressão com base em bugs passados em arquivos relacionados.
Por que quinto. Revisão de PR é uma tarefa de julgamento. Os primeiros 80 por cento são mecânicos e o agente acerta. Os últimos 20 por cento são contexto sobre o time, sobre o roadmap, sobre as coisas que quebraram no último trimestre. Se o agente não estiver calibrado nas revisões passadas do seu time, ele vai gerar ruído. Você precisa de histórico de revisões suficiente do seu próprio time para calibrar, o que significa meses de rodadas, não semanas, e você não vai saber o número até olhar o ruído que ele produz.
A Regra de Decisão
Quando eu avalio um agente candidato para um time pequeno, eu faço três perguntas em ordem. Se qualquer resposta for ruim, eu pulo, por mais empolgante que seja o pitch.
- Com que frequência ele dispara? Se a resposta for menos de uma vez por dia, ele não é o seu primeiro agente.
- Ele precisa de memória ou de qualidade de classificação já no dia um? Se sim, ele não é o seu primeiro agente. Agentes anteriores populam a memória da qual os agentes posteriores dependem.
- Se ele produzir uma saída errada, qual é o raio de explosão? Texto em um comentário de PR tudo bem. Código executado em produção, não. Comece onde o raio de explosão é o menor.
Aplique essas regras aos seis candidatos e você chega na ordem que eu desenhei. Aplique a qualquer outra coisa que alguém te pitchar e você vai saber se vale as próximas três semanas do seu time.
O Que Acontece Depois do Primeiro Agente
O primeiro agente é o mais difícil. Não porque o código é difícil, mas porque você tem que escolher a estrutura, a história de deploy, a abordagem de observabilidade, o layout de memória. O segundo agente é 5x mais rápido porque você reaproveita tudo isso. Chegando no terceiro, você já tem uma pequena plataforma interna e o time começa a propor os próprios agentes.
Esse é o verdadeiro objetivo de começar pela ponte do SonarQube. Não é a ponte em si. É a base compartilhada que torna os próximos cinco agentes triviais de entregar.
Um agente que o time usa todo dia vence cinco agentes que o time usa uma vez e esquece. Escolha aquele que dispara com frequência, que falha com segurança, que devolve valor óbvio já na primeira semana.
Referências
- SonarQube Web API: https://docs.sonarsource.com/sonarqube/latest/extension-guide/web-api/
- GitHub Actions: https://docs.github.com/en/actions
- Sentry API: https://docs.sentry.io/api/