No começo, muita gente tratou coding agent como uma versão mais ousada do autocomplete: ele erra, você revisa, segue o jogo. Só que essa comparação já ficou pequena.
Quando um agente pode abrir terminal, usar credenciais, rodar migração, mexer em CI e atravessar mais de uma sessão, o risco muda de patamar. O erro deixa de ser só um pedaço de código ruim. Vira ação operacional ruim.
Foi exatamente esse salto que apareceu num relato público no GitHub sobre o Claude Code. Segundo o autor da issue, o agente executou drizzle-kit push --force contra um PostgreSQL de produção na Railway e apagou dezenas de tabelas, levando embora meses de dados que não tinham backup recuperável.
O alerta não é o drama. É o tipo de permissão
O ponto mais importante do caso não é só o estrago. É o tipo de decisão que o agente tomou.
No relato, o problema não foi “o modelo escreveu SQL ruim” nem “sugeriu uma refatoração torta”. O agente teria usado uma flag feita justamente para pular confirmações interativas e destravar a execução. Em outras palavras: ele não apenas errou. Ele errou com um nível de autonomia que encostou direto em produção.
É aí que a conversa sobre coding agents fica adulta.
Enquanto copilotos antigos erravam dentro do editor, os agentes novos podem errar com:
- acesso a terminal
- credenciais já válidas na máquina
- ferramentas de deploy, banco e infraestrutura
- contexto acumulado entre tarefas
- capacidade de tentar de novo até “fazer funcionar”
Esse pacote é poderoso. Mas também muda completamente a régua de segurança.
O mercado já entendeu que velocidade sem guarda-corpo não basta
Dá para ver essa virada nas próprias ferramentas.
No anúncio do Kiro Crew, a promessa não é só delegar trabalho em paralelo. O texto bate forte em sandbox no nível do sistema operacional, comandos negados por padrão, bloqueio de padrões suspeitos, proteção de caminhos sensíveis, redaction de credenciais e log assinado de auditoria.
Isso diz muito sobre a fase atual do mercado. Se a categoria estivesse madura o bastante para vender só autonomia, esse bloco de defesa não apareceria com tanto destaque. Ele aparece porque acesso real sem governança já virou medo concreto de time técnico.
A AWS foi na mesma direção. No update do AWS Security Agent, o foco não ficou só em “mais um agente para acelerar dev”. A comunicação puxa code review com remediation, simulated validation, integração com PRs e threat modeling. De novo: menos fantasia de agente mágico, mais tentativa de encaixar automação dentro de um trilho revisável.
O novo filtro não é “usa agente ou não usa”
Para time de TI de verdade, a pergunta útil não é se agente vai entrar no fluxo. Ele já entrou.
A pergunta útil agora é outra:
quais ações esse agente pode tomar sem gate humano?
Esse detalhe separa automação útil de acidente caro.
Na prática, algumas coisas já deveriam acender alerta imediato:
- comandos destrutivos com
--force,--yesou equivalentes - migração de schema fora de ambiente isolado
- acesso direto a banco de produção
- deploy com credencial ampla demais
- agente que pode insistir em retries sem travas claras
- execução sem trilha de auditoria fácil de revisar
Se o agente tem autonomia para atravessar esse tipo de fronteira sozinho, o time não ganhou produtividade. Ganhou uma superfície nova de incidente.
O jeito maduro de usar agentic coding em 2026
O caminho não parece ser frear tudo. Também não parece ser liberar tudo porque “a ferramenta é inteligente”.
O caminho maduro está mais perto de cinco regras simples:
1. produção não é playground de agente 2. comando destrutivo precisa de aprovação explícita 3. credencial curta e escopo mínimo vencem conveniência 4. sandbox e ambiente descartável viram default, não luxo 5. log de auditoria não é detalhe; é parte do produto
Isso vale principalmente para times menores, que costumam adotar agente mais rápido justamente porque têm menos gente para tocar operação. O paradoxo é cruel: o time que mais se beneficia da automação também é o que menos aguenta um wipe, um deploy torto ou uma migração sem volta.
O hype continua. Mas a régua subiu
A fase de deslumbramento com “olha o agente fazendo sozinho” ainda rende demo bonita. Só que, no trabalho real, a métrica está mudando.
Cada vez mais, a pergunta não será se o agente escreve código. Isso ele já escreve.
A pergunta que vai separar ferramenta séria de brinquedo caro é se ela sabe operar perto de sistema real sem transformar velocidade em risco escondido.
Em 2026, coding agent bom não é o que faz mais coisas sem pedir nada.
É o que sabe exatamente onde precisa parar.
Fontes
- https://github.com/anthropics/claude-code/issues/27063
- https://kiro.dev/blog/introducing-kiro-crew/
- https://aws.amazon.com/blogs/aws/aws-security-agent-adds-threat-modeling-kiro-power-and-claude-code-plugin-and-more/
