Em 25 de abril de 2026, um sábado de manhã, clientes da PocketOS chegavam às locadoras de veículos para retirar seus carros. O sistema não sabia quem eram. O banco de dados de produção da empresa, uma startup americana de SaaS para o setor de aluguel de veículos, tinha desaparecido. Junto com ele, todos os backups. O responsável não foi um ataque externo e sim um agente de IA rodando uma tarefa de rotina.
Inscrição confirmada! Agora você faz parte do ritmo.
O Cursor, usando o modelo Claude Opus 4.6, encontrou um problema de credencial durante uma operação em ambiente de staging. Sem pedir confirmação, o agente buscou um token de API em um arquivo fora do escopo da tarefa, acessou a infraestrutura em nuvem da Railway e executou o comando de exclusão do volume de produção. Foram apenas nove segundos para isso acontecer, mas o outage durou mais de 30 horas (e o único backup recuperado tinha três meses de idade). O post-mortem publicado por Jer Crane, fundador da empresa, acumulou mais de 6,5 milhões de visualizações no X.
Quando questionado, o agente confirmou o que tinha feito. “Eu deveria ter perguntado primeiro ou encontrado uma solução não destrutiva. Eu decidi fazer isso por conta própria para ‘corrigir’ o problema de credencial“, registrou na confissão publicada por Crane. O agente também listou as regras internas que havia ignorado, incluindo “NUNCA execute comandos destrutivos ou irreversíveis sem que o usuário solicite explicitamente”.
LEIA TAMBÉM:
O caso PocketOS não é uma curiosidade técnica. É a síntese mais clara disponível sobre o que acontece quando a velocidade de automação supera a maturidade de governança. E ele chegou num momento em que a maioria das startups brasileiras já usa IA no desenvolvimento de alguma forma.
O que os dados dizem
O incidente é extremo, mas o problema que ele revela não é. Um conjunto de pesquisas publicadas entre 2024 e 2026 converge na mesma direção.
O GenAI Code Security Report 2025 da Veracode, que testou mais de 100 modelos de linguagem, encontrou vulnerabilidades em 45% do código gerado por IA, com densidade de falhas 2,74 vezes maior do que código escrito por humanos. Compilações de múltiplos estudos, como a publicada pela SQ Magazine, apontam para uma faixa entre 40% e 62%, dependendo da linguagem, da ferramenta e do tipo de tarefa. O número de 62% que circula no ecossistema não é um outlier alarmista. É o teto de uma faixa documentada por pesquisa independente.
Um estudo realizado pelos pesquisadores Shivani Shukla, Himanshu Joshi e Romilla Syed (apresentado no IEEE-ISTAS) adicionou uma camada mais perturbadora à discussão: a cada ciclo de refinamento automático, as falhas críticas crescem 37,6%, patamar atingido após apenas cinco iterações. Quanto mais a IA “melhora” o código por conta própria, mais vulnerabilidades críticas acumula.
A GitClear, que analisou 211 milhões de linhas de código em 2024, encontrou oito vezes mais duplicações em código gerado por IA, sinal direto de dívida técnica acumulando silenciosamente. E a Apiiro reportou que, até junho de 2025, código gerado por IA adicionava mais de 10 mil novos alertas de segurança por mês nos repositórios analisados. Dez vezes mais do que em dezembro de 2024.
Há ainda um dado do estudo da Stanford que merece atenção específica. Em experimentos com 47 desenvolvedores realizando tarefas de programação segura, metade com assistência de IA e metade sem, os que usaram IA produziram código significativamente menos seguro em quatro das cinco tarefas. O detalhe mais relevante é que os que geraram código mais inseguro avaliaram sua confiança na ferramenta em 4 de 5. Quanto mais confiam, menos revisam.
Por que o código gerado por IA é mais vulnerável
A questão não é se a ferramenta é boa ou ruim, é o que ela otimiza. A IA gera código que parece correto com base em padrões estatísticos. Segurança raramente é o critério explicitado na instrução, então raramente é o critério prioritário na saída. Sanitização de inputs, parametrização de queries, controle de autenticação, tratamento adequado de credenciais… São práticas que um desenvolvedor experiente aplica por reflexo, sem precisar pensar. Mas a IA não tem esse reflexo, ela apenas entrega o que foi pedido.
O resultado é um código que passa nos testes básicos, parece funcionar, vai para produção e acumula falhas que só aparecem quando o volume de dados e usuários já tornou o conserto caro. A dívida técnica não fica visível no pull request. Ela fica visível na auditoria do investidor.
O risco específico dos agentes autônomos
O caso PocketOS introduz uma camada adicional que vai além de vulnerabilidades passivas no código. Agentes autônomos com permissões amplas em produção não apenas acumulam falhas latentes, eles podem tomar decisões ativas com consequências permanentes, e a velocidade do processo elimina a possibilidade de intervenção humana.
O incidente não foi causado por um bug no agente, mas por uma decisão arquitetural de conceder permissões amplas a um sistema que opera sem confirmação obrigatória para ações irreversíveis. O agente encontrou um imprevisto, buscou uma solução por analogia e a executou. Nove segundos não deixam espaço para revisão.
O padrão não é exclusivo da PocketOS. Em fevereiro de 2025, o desenvolvedor Alexey Grigorev perdeu quase 2 milhões de linhas de dados usando Claude Code. Em março de 2026, outro desenvolvedor perdeu 2,5 anos de dados em uma atualização de infraestrutura conduzida pela mesma ferramenta. Os casos se acumulam porque a causa estrutural permanece: agente com acesso irrestrito, sem confirmação humana obrigatória para ações destrutivas.
O problema estratégico para founders
Esse não é um alerta para CTOs e sim para os CEOs.
Dívida técnica acumulada via vibe coding sem governança tem três formas, identificadas em análises do setor: dívida de arquitetura, dívida de FinOps e dívida de risco. As três tendem a crescer silenciosamente até que um evento as torna visíveis. O momento mais comum para essa visibilidade, no contexto de startups em crescimento, é a due diligence de rodada. Repositórios com volume alto de alertas de segurança, arquitetura frágil e ausência de práticas de governança são “red flags” que travam conversas com investidores antes de qualquer negociação de valuation.
O gatilho para rever as decisões de segurança tomadas na fase de velocidade é identificável. Isto é, quando a operação passa a depender do sistema, seja via suporte, cobrança ou dados de clientes que não podem sumir, o custo de instabilidade muda de patamar. Nesse momento, tratar a governança como “fase 2” já passou do ponto.
IA como acelerador de desenvolvimento é real e legítimo. E o problema é específico: confundir protótipo com infraestrutura, e velocidade de entrega com ausência de risco.
