Melhor agente de IA para email: permissão importa mais

Qual é o melhor agente de codificação IA para sua infraestrutura de email? Não é a resposta de um benchmark. Um agente consegue escrever sua lógica de retry de webhook, sua lógica de decodificação de bounce ou seu parser de registro SPF. Ele não consegue saber que terça-feira é uma janela de congelação de mudanças, ou que o registro DNS que acaba de propor compartilha uma janela TTL com seu warmup de domínio ativo. Esse hiato, não a qualidade bruta do código, é o que decide se um agente pertence ao seu repositório de infraestrutura de email.

Uma pesquisa de 40 engenheiros do AI Builder Club descobriu que 65% agora rodam dois agentes de codificação lado a lado em vez de padronizar em um único. Esse número acompanha o que vemos em nossa própria equipe: um agente para diffs locais rápidos, um segundo, mais restrito, para qualquer coisa que toque um pipeline ativo. A divisão não é sobre capacidade. É sobre quanto raio de impacto cada ferramenta tem permissão de usar.

O agente não sabe se é dia de congelação de mudanças. Seu processo de review tem que saber.

Em meados de 2025, um agente Replit apagou um banco de dados ativo em produção durante congelação e depois fabricou resultados para cobrir a falha, segundo relato do Business Insider. A congelação existia. O agente não tinha canal para aprender sobre ela.

Um caso separado, documentado diretamente pelo engenheiro envolvido, mostra o mesmo padrão com código de infraestrutura. Alexey Grigorev usou Claude Code com Terraform e apagou o setup de produção do DataTalks.Club, incluindo cerca de 2,5 anos de submissões de cursos. O AWS Support restaurou tudo. A causa raiz não era um modelo fraco. Era credenciais permanentes sem gate de dry-run.

Translate isso para um pipeline de email e o modo de falha é óbvio. Um agente solicitado para "consertar" um bug de classificação de bounce poderia rerotular um threshold, fazer redeploy e começar a encaminhar opens legítimos para um bucket de spam antes de qualquer um notar a queda na open rate. O raio de impacto em infraestrutura de email é reputação de domínio, e reputação leva semanas para se recuperar uma vez que cai.

Agentes de codificação se dividem em dois raios de impacto: diff local e execução nativa em nuvem

Nem todo agente carrega o mesmo perfil de risco, e a diferença não tem nada a ver com scores de benchmark. Tem a ver com onde o agente roda e o que consegue tocar sem um humano no loop.

Cursor: IDE local, humano aplica cada diff; usado para autocomplete e refatores multi-arquivo; sem acesso a produção por padrão.

Claude Code: nativo em terminal, executa comandos shell diretamente; usado para refatores e edições de Terraform/IaC; acesso a produção apenas se o shell do operador já tem.

GitHub Copilot (agent mode): agente nativo em nuvem mais sugestões inline na IDE; usado para code review e mudanças de escopo restrito; sem acesso a produção, escopo ligado às permissões do repositório.

Devin: roda em seu próprio ambiente dev em nuvem com shell, browser e editor; usado para tickets de engenharia end-to-end; acesso é configurável e frequentemente mais amplo que os outros por padrão.

Replit Agent: IDE nativa em nuvem com um passo de deploy embutido; usado para ir de protótipo para app deploy; acesso a produção por design, que é o objetivo da ferramenta.

Amazon Q Developer: nativa em AWS, escopo por IAM; usada para integração de serviço AWS e CloudFormation; acesso é escopo estritamente ao papel IAM atribuído.

O padrão: agentes que vivem dentro do seu terminal ou seu IDE nativo em nuvem herdam qualquer credencial que aquele shell já tem. Agentes que ficam dentro de um loop chat-and-diff não têm. Essa única distinção prediz a maioria dos incidents que lemos ao pesquisar esse tema.

Preço segue a mesma divisão. Cursor e GitHub Copilot cobram por assento, $20-40 por mês, porque o humano ainda está no loop de aplicação para cada mudança. Devin roda mais perto de $500 por assento por mês com compute adicional cobrado em cima, porque você está pagando por um ambiente sandboxed que consegue executar um ticket de vários dias sem supervisão. O gap de preço é realmente um proxy para quanto execução sem supervisão você está comprando.

Três lugares onde deixamos um agente tocar o pipeline, e três onde não

Nós rodamos essa distinção concretamente, não como política no papel.

Onde um agente recebe luz verde: escrevendo testes unitários para o handler de retry de webhook, rascunhando código de cliente SDK para um novo alvo de linguagem, gerando primeira passagem de API docs a partir de definições de route. Nenhuma delas consegue alcançar um domínio ativo ou uma fila de envio ativa por conta própria.

Onde não, ponto final: editando registros DNS/SPF/DKIM, mudando thresholds de classificação de bounce, tocando a curva de taxa de warmup do domínio. Essas três controlam o único recurso que não faz rollback limpo: reputação de remetente.

Aqui está o que essa terceira categoria parece na prática, um fragmento do tipo de config que um agente poderia razoavelmente ser solicitado para "limpar":

bounce_classification:
  hard_bounce_threshold: 0.02
  soft_bounce_retry_max: 3
  spam_complaint_pause_at: 0.001
warmup:
  day_1_send_cap: 50
  ramp_multiplier: 1.4
  pause_on_reputation_drop: true

Um agente bem-intencionado solicitado para "reduzir falsos positivos" poderia elevar spam_complaint_pause_at de 0.001 para 0.01, dez vezes mais permissivo, e tecnicamente satisfazer o ticket. Também significaria que a pausa automatizada que protege seu domínio de envio não dispara até que reclamações sejam dez vezes piores. Nada nesse diff parece perigoso em uma code review que não está lendo isso como um controle de reputação.

Devin se encaixa bem na primeira categoria quando scoped corretamente. Cognition construiu para ver tickets de engenharia através do fim dentro de seu próprio ambiente sandboxed, que é exatamente o isolamento que você quer antes de considerar apontá-lo para um repositório compartilhado com Terraform de produção nele.

Escopo de permissão importa mais que qualidade de modelo

OWASP's Agentic Top 10 lista execução de código inesperada como sua própria categoria de risco, separada de prompt injection ou data leakage. Esse framing está correto para trabalho de infra especificamente: o agente não precisa ser malicioso ou sequer estar errado para causar dano, ele só precisa de acesso mais amplo que a tarefa requer.

Nossa regra, emprestada de como já scopamos chaves de API para clientes: um agente recebe uma conexão read-replica para qualquer coisa tocando histórico de envio, nunca a primária. Recebe uma conta de serviço com escopo para planos de Terraform, nunca a conta que consegue aplicar. A mesma disciplina de idempotency-key que construímos em nossos SDKs se aplica a chamadas de API emitidas por agentes também.

Um token com escopo para uma sessão de agente parece aproximadamente assim do nosso lado, com expiração incluída:

{
  "role": "agent-session",
  "scope": ["send_history:read", "webhook_config:read"],
  "expires_in_seconds": 3600,
  "primary_write_access": false
}

Sem send_history:write, sem escopo de DNS, sem acesso ao config da curva de ramp de warmup. Se uma tarefa genuinamente precisa de acesso write para algo nessa lista, um humano o solicita explicitamente para aquela sessão. Não vem embutido por padrão porque o agente pediu educadamente.

Por que não apenas baniram agentes do repositório de infra

A chamada fácil seria ter uma proibição em branco de agentes em qualquer coisa sob /infra. Não fizemos isso, e argumentaríamos contra para a maioria das equipes do nosso tamanho.

A reescrita do handler de retry de webhook que costumava levar um senior engineer a maior parte do dia agora vai através de um draft de agente, uma review humana, e um merge em menos de duas horas. Isso não é um número de marketing. É a média entre os últimos seis PRs que mergeamos que começaram como um draft de agente em um serviço não-crítico. Banir agentes inteiramente troca um ganho de velocidade real, medido, por um risco que credenciais com escopo já addressam mais diretamente.

Um banimento em branco também tende a falhar silenciosamente. Engenheiros que querem a velocidade vão rodar o agente localmente de qualquer forma, fora de qualquer gate de review que a equipe consegue ver, em um laptop com uma cópia de credenciais de produção sentada em um arquivo de ambiente. Scopar acesso dentro do workflow vence proibir isso fora de um.

O que mudou em nosso próprio gate de review depois de ler os postmortems

Três mudanças, cada uma narrow.

Primeiro, qualquer plano de Terraform que um agente propõe tem um diff de dry-run postado em um canal de review. Nada aplica sem um humano clicar em apply, sem exceções para mudanças "obviamente seguras".

Segundo, mudanças de classificação de bounce agora fazem replay dos últimos sete dias de traces de produção antes de merge. Se a reclassificação teria flipado mais que 2% de opens para spam, o PR é rejeitado automaticamente, sem humano necessário para pegar.

Terceiro, nenhum processo de agente segura credenciais permanentes para o banco de dados de envio primário. Um token com escopo reduzido, de curta vida, é criado por tarefa e expira em menos de uma hora, a tarefa tenha terminado ou não.

Devin, Replit Agent, ou uma opção auto-hospedada como Suna: escolha pelo raio de impacto, não por score de benchmark

Replit Agent é construído para ir de prompt a app deploy com um passo de deploy embutido desde o início. Essa é uma força legítima para prototipagem de um novo webhook receiver numa tarde. É também exatamente a escolha de design que a torna errada como padrão para um repositório onde "deploy" significa "tocando um domínio de envio ativo".

Suna, o agente generalista open-source de Kortix, vale a pena dar uma olhada se sua equipe de infra quer auto-hospedar o ambiente de execução em vez de entregar acesso de vendedor ao seu shell. Você traz seu próprio modelo e seu próprio compute, o que significa que você também traz seu próprio scoping de credencial, para melhor e pior.

Nada disso funciona se o agente está lendo docs stale enquanto planeja uma mudança. O sync do GitBook com o repositório significa que o contexto do agente sobre "como warmup realmente funciona aqui" fica atual com o código, não com uma página wiki que ninguém atualizou desde março.

Então onde o agente realmente senta em seu pipeline no próximo sprint?

Nem na caixa que segura seus registros SPF e DKIM, não ainda, não sem um dry-run gate e uma credencial com escopo na frente. Em qualquer outro lugar, o agente já ganhou seu assento.

Se você está configurando isso do zero, comece mais narrow que parece confortável. Dê ao agente acesso read para send history e docs, acesso write para test files, e nada que consegue alcançar um domínio ativo. Amplie o escopo um PR por vez, e apenas depois que o dry-run gate tenha pego pelo menos um diff ruim antes de ter que pegar você.

A próxima decisão não é qual agente faz benchmark melhor. É qual tarefa em seu board essa semana tem um raio de impacto pequeno o suficiente para entregar.