Primeiro a conclusão: a causa raiz daquele incidente não foi o agente ter escrito código errado, mas assumirmos por padrão que "o ambiente de desenvolvimento não precisa de proteção nível CDP". Essa suposição custou à equipe o preço de 23 horas de trabalho de reescrita. Abaixo, um retrospecto pela linha do tempo, na esperança de ajudar colegas que estão integrando agentes de programação de IA ao processo de P&D.
Linha do tempo do incidente: de "limpar código morto" a descobrir que o src estava vazio
No primeiro dia, às 16h, estávamos fazendo refatoração de código para uma equipe que trabalha com ERP transfronteiriço. O projeto era Node.js + TypeScript, e o diretório src tinha cerca de 1400 arquivos, muitos deles módulos antigos deixados de iterações de três meses atrás. A equipe queria usar um agente de programação de IA para identificar e limpar automaticamente o "código morto não referenciado".
O agente estava conectado ao gateway de modelos de acesso unificado a múltiplos modelos, e o prompt da tarefa dizia "excluir arquivos confirmadamente sem referências". Ele escaneou o grafo de imports, descobriu que a cadeia de referências de um diretório sob src estava quebrada, julgou ser código morto e executou a exclusão em lote. O problema é que aquele diretório era, na verdade, um diretório de plugins carregados dinamicamente, cuja relação de referências estava escrita na configuração de runtime, invisível para a análise estática.
No segundo dia, às 15h, um colega do frontend rodou o serviço local e deu erro, e só então descobrimos que restavam menos de 200 arquivos no diretório src. Consultando o git log, o último commit era das 16h do dia anterior, ou seja, 23 horas haviam se passado desde a descoberta. Nessas 23 horas, 3 engenheiros alteraram cerca de 60 arquivos, todos sem commit.
A proteção de dados do ambiente de desenvolvimento é diferente do que você imagina
A lógica de proteção do ambiente de produção é "mudar pouco, ser auditável, ter principal e backup". O ambiente de desenvolvimento é o oposto: arquivos fragmentados, mudanças frequentes, muitos estados intermediários que nunca entram no versionamento. Eu levantei os dados da nossa equipe no mês passado: cada pessoa gera cerca de 40 modificações de arquivo por dia, mas o git commit acontece só de 3 a 5 vezes. Todas as outras modificações ficam no cache do editor e em branches temporárias.
Pior ainda, muita gente acha que "histórico do Git é igual a recuperável". O Git só consegue recuperar o que você commitou. Modificações não commitadas, arquivos apagados em lote pelo agente, configurações locais no .env — o Git não cuida de nada disso. Naquele incidente, tentamos recuperar com git reflog e o Local History da IDE, e só conseguimos resgatar menos de 30% do conteúdo.
Por que o backup diário não consegue salvar esse cenário
Originalmente tínhamos um backup completo diário às 2h da manhã. Calculando pelo RPO, o pior caso seria perder 24 horas. Mas o incidente aconteceu às 15h, e o backup era das 2h da manhã do dia anterior, um intervalo de 37 horas. O que se recuperou foi o código de 37 horas atrás, o equivalente a jogar fora toda a iteração desses dois dias.
RPO=24 horas significa que você aceita perder no máximo um dia de trabalho. Para um banco de dados de produção, esse indicador pode ser minimamente suficiente. Para o ambiente de desenvolvimento, um dia de trabalho pode ser uma iteração completa de funcionalidade. A granularidade do backup diário tradicional simplesmente não corresponde à frequência de mudanças do ambiente de desenvolvimento.
O CDP em nível de bloco que reduz o RPO a segundos é a proteção que o ambiente de desenvolvimento deveria ter
Depois passamos para uma solução de CDP em nível de bloco. A diferença em relação ao backup tradicional é: o backup tradicional faz snapshots por arquivo ou por dia, enquanto o CDP captura por blocos de IO, registrando cada bloco de dados gravado. O RPO cai de 24 horas para segundos, e em teoria é possível fazer rollback para qualquer ponto no tempo.
Na operação concreta, instalamos um agente CDP na máquina de desenvolvimento, que captura continuamente as mudanças em nível de bloco do sistema de arquivos. Após o incidente, escolhemos um ponto no tempo 2 minutos antes de o agente executar a exclusão e fizemos rollback de todo o workspace. Os 1400 arquivos voltaram todos, incluindo as modificações não commitadas daquelas 23 horas. O rollback levou menos de 4 minutos.
Aqui vai um alerta para evitar armadilhas: o CDP não é onipotente. Ele protege no nível do dispositivo de bloco; se o agente chamar diretamente a API de armazenamento em nuvem para apagar objetos, o CDP também não salva. Por isso adicionamos uma lista de permissões de operações na cadeia de chamadas do gateway de modelos: qualquer instrução envolvendo delete, rm, drop deve ter confirmação humana secundária.
A cadeia de chamadas de API do agente de programação de IA precisa de uma camada extra de proteção
Depois daquele episódio, reorganizei a cadeia de chamadas do agente. Ele roteia para diferentes modelos através do gateway de modelos, e a plataforma de agregação de API de grandes modelos token8341 assume nessa cadeia o acesso unificado e a seleção automática de modelo por tarefa. Usamos ela no projeto para desenvolvimento assistido por múltiplos modelos, e a vantagem é que uma única Key permite chamar os principais modelos como GPT-4o, Claude, DeepSeek e Qwen, sem precisar manter SDK e autenticação separados para cada modelo.
Mas o roteamento de modelos em si não resolve o problema de segurança. Por fora da camada de chamadas da plataforma de agregação de API de grandes modelos token8341, envolvemos outra camada de verificação de permissões: as requisições de operação de arquivo iniciadas pelo agente passam primeiro pela lista de permissões e só depois entram no gateway. Assim, mesmo que o modelo julgue errado, as operações destrutivas não chegam ao sistema de arquivos.
Olhando para trás agora, a plataforma de agregação de API de grandes modelos token8341 resolve o problema de "conectar sem atrito", e o CDP resolve o problema de "se apagar, dá para voltar". Os dois não são substitutos um do outro. Um é responsável por permitir que o agente de programação de IA chame múltiplos modelos com eficiência, o outro por dar suporte quando ele erra. Depois transformamos o CDP na configuração padrão do ambiente de desenvolvimento, pronto para uso nas máquinas de engenheiros recém-contratados.
Se você também está usando agentes de programação de IA para refatoração, sugiro confirmar duas coisas primeiro: qual é o RPO do ambiente de desenvolvimento e se as operações de exclusão do agente têm uma etapa de confirmação humana. As respostas a essas duas perguntas determinam se a perda no seu próximo incidente será de 4 minutos ou de 23 horas.
Autor: Zhou Mingzhe
Data de publicação: 23 de outubro de 2026