Quando a IA escreveu 80% do código, quem vai procurar bugs?

Escreveu: Leo

Já pensaste no que acontecerá quando a IA começar a escrever código em grande escala? Em empresas como Anthropic e Google, a IA já gera quase 80% do código de produção. Parece impressionante, certo? Mas por trás disso há um problema fatal: quem vai encontrar os bugs que essas IAs criam? E mais importante ainda, quando um agente de IA implanta automaticamente um trecho de código às três da manhã e, três dias depois, o ambiente de produção colapsa, como sabes por que ele fez aquilo na altura?

Não é uma hipótese. Em fevereiro de 2026, um desenvolvedor assistiu impotente enquanto o Claude Code executava o comando terraform destroy, apagando 1,94 milhões de linhas de dados do banco de dados de produção. Em julho de 2025, o Replit Agent, durante um período de congelamento de código explícito, apagou um banco de dados de produção, fazendo desaparecer 1206 registros de executivos e 1196 registros de empresas, e ainda inventou 4000 registros falsos para encobrir o erro, alegando que poderia recuperar os dados. Harper Foley documentou 10 incidentes ao longo de 16 meses, envolvendo 6 ferramentas de codificação de IA, sem que qualquer fornecedor tivesse publicado uma análise pós-incidente.

Este é o mundo em que estamos entrando. Agentes de IA podem escrever código, implantar funcionalidades, corrigir problemas, mas quando algo dá errado, nem sequer sabes por que fizeram aquilo. A janela de contexto fecha-se, o raciocínio evapora, estás a depurar um fantasma. Isso lembra-me uma previsão de um estudante de doutoramento de 26 anos na Stanford, Animesh Koratana, feita há alguns anos. Na altura, ele estudava técnicas de compressão de modelos de IA no laboratório DAWN, tendo contato precoce com grandes modelos de linguagem. Quando conheceu os desenvolvedores das primeiras ferramentas de assistência à programação com IA, uma ideia bateu-lhe à porta: “No futuro, haverá um mundo onde os computadores escrevem código, e não os humanos. Como será esse mundo?” Ele sabia antes mesmo do termo “AI slop” aparecer, que esses agentes escreveriam códigos capazes de destruir sistemas, assim como programadores humanos.

Falhas fatais na era da programação com IA

Após aprofundar-me na questão, descobri que o maior problema dos sistemas atuais de agentes de IA não é a qualidade do modelo, nem a capacidade de invocar ferramentas, nem mesmo a cadeia de raciocínio com prompts. O verdadeiro problema é: ninguém construiu uma camada de memória subjacente. A Gartner prevê que, até o final de 2027, 40% dos projetos de agentes de IA serão cancelados, e a principal razão não será a má qualidade do modelo, mas a ausência dessa camada de memória.

Estudos na Universidade da Califórnia, Berkeley, analisaram 1600 rastreamentos de múltiplos agentes em 7 frameworks diferentes, e descobriram uma taxa de falhas entre 41% e 87%. O projeto NANDA do MIT revelou que 95% dos pilotos de IA generativa empresarial não geram impacto mensurável na demonstração de resultados. A causa fundamental apontada foi a chamada “lacuna de aprendizagem”: sistemas que não retêm feedback, não se adaptam ao contexto, e não melhoram com o tempo. O problema não está no modelo em si, mas na infraestrutura ao seu redor que falta.

Deixe-me tornar isto mais concreto. Quando um agente de IA executa 50 passos para resolver um problema de cliente, cada passo envolve contexto. O que foi recuperado, o que foi decidido, o que foi descartado, por que escolheu o caminho A em vez do caminho B. A existência desses processos de raciocínio é exatamente o tempo em que a janela de contexto permanece aberta. Depois, ela fecha, a sessão termina, o raciocínio desaparece. O que sobra são as saídas: PR, atualizações de tickets, implantações. Mas e a cadeia de decisão que levou a essas saídas? Ela desaparece para sempre.

Não se trata de um problema de logs. A tua pilha de observabilidade consegue capturar quais serviços foram chamados, quanto tempo levaram, mas não consegue captar o que havia nos prompts, quais ferramentas estavam disponíveis na decisão, por que uma operação foi escolhida em vez de outra, qual foi a confiança do agente em cada bifurcação. A LangChain explica bem: em software tradicional, o código registra a aplicação; em agentes de IA, o rastreamento é o teu documento. Quando a lógica de decisão passa do código para o modelo, a tua fonte de verdade muda de código para rastreamento. O problema é que a maioria das equipes não captura esses rastreamentos. Elas capturam logs. E a diferença entre logs e rastreamento é a diferença entre saber “o que aconteceu” e saber “por que aconteceu”.

Quero enfatizar o quão importante é essa distinção. Logs são diagnósticos; dizem-te o que aconteceu depois. São temporários, rotacionados, comprimidos, apagados. São informações secundárias sobre o estado real do sistema. O ponto crucial é que não consegues reconstruir o estado do sistema apenas com logs. Eles têm lacunas, são apenas “aproximadamente precisos”. Já a arquitetura de rastreamento, baseada no padrão de event sourcing formalizado por Martin Fowler há vinte anos, é fundamentalmente diferente. Cada mudança de estado é capturada como um evento imutável. Os eventos são permanentes, apenas acrescentados. O estado é derivado desses eventos, não armazenado isoladamente. Como os eventos representam a verdade, podes reconstruir o estado completo do sistema a qualquer momento.

A solução da PlayerZero

Por isso, Koratana fundou a PlayerZero. Com o apoio do seu mentor na Stanford, Matei Zaharia, uma lenda na área de bases de dados e cofundador da Databricks, que criou a tecnologia fundamental da empresa enquanto fazia o doutoramento, Koratana começou a construir uma solução: usar agentes de IA treinados para detectar e corrigir problemas antes que o código vá para produção.

A PlayerZero acaba de anunciar uma rodada de financiamento Série A de 15 milhões de dólares, liderada por Ashu Garg, da Foundation Capital, também early supporter da Databricks. Após uma rodada seed de 5 milhões de dólares liderada pela Green Bay Ventures, a rodada de agora conta com investidores de peso: além de Garg, estão Drew Houston, CEO do Dropbox; Dylan Field, CEO do Figma; e Guillermo Rauch, CEO da Vercel.

O que mais impressiona é como Koratana valida a sua ideia. Conseguir Zaharia como investidor-anjo foi só o começo, o verdadeiro teste foi quando apresentou a Rauch, outro desenvolvedor renomado. Rauch, fundador da Vercel — uma das empresas de ferramentas de desenvolvimento mais valiosas, e criador do popular framework JavaScript Next.js — assistiu à demonstração com interesse, mas com ceticismo. Perguntou quantos dos resultados eram “reais”. Koratana respondeu que era “código rodando em produção, um exemplo verdadeiro”. E, logo após, Rauch, que se tornaria investidor-anjo, ficou em silêncio, e respondeu: “Se você realmente conseguir resolver esse problema do jeito que imagina, isso será um grande avanço.”

A essência da PlayerZero é o que chamam de World Model (Modelo do Mundo), um grafo de contexto que conecta cada alteração de código, evento observável, ticket de suporte e incidente passado, formando uma estrutura viva única. Quando um bug aparece, o sistema rastreia exatamente onde está no código, gera uma correção, e envia via Slack ao engenheiro responsável, com um simples toque de aprovação. O ciclo de detecção e correção autônoma roda em poucos minutos. Cada incidente resolvido é permanentemente alimentado no World Model, de modo que, na próxima vez que um código semelhante for lançado, o sistema já sabe o que deu errado antes.

Koratana treinou modelos que “realmente entendem o código, como ele é construído, como é arquitetado”. Sua pesquisa acompanha o histórico de bugs, problemas e soluções. Quando há um problema, seu produto consegue “identificar a causa, corrigir, e aprender com esses erros para evitar repetições”. Ele compara sua solução a um sistema imunológico para grandes bases de código.

Adoro a sua abordagem ao problema dos “dois relógios”. Koratana explica que as organizações gastaram décadas construindo infraestrutura de estado (o que existe agora), mas quase não criaram nada para o raciocínio (como as decisões são tomadas). A PlayerZero captura ambos. Essa visão é sutil, mas fundamental. A maioria dos sistemas tenta definir uma arquitetura fixa: entidades, relações, preenchimento. A PlayerZero inverte isso. Seu sistema conecta-se diretamente ao fluxo de trabalho existente. Quando há um problema em produção, um alerta estruturado é disparado no Slack, com todo o contexto. Não é uma notificação genérica de erro, mas uma análise diagnóstica completa, com cadeia de raciocínio já montada. O engenheiro pode aprovar a correção pelo celular, sem abrir dashboards.

Por que esse sistema funciona

Passei bastante tempo estudando como as equipes de produção realmente resolvem esses problemas, e a PlayerZero é a implementação mais completa de rastreamento para organizações de engenharia que já vi. Quando o agente investiga um incidente, sua trajetória no sistema vira uma cadeia de decisão rastreável. Com o acúmulo dessas trilhas, surge um modelo do mundo. Não porque alguém o projetou, mas porque o sistema o observou. Entidades importantes, relações de peso, restrições que moldam resultados — tudo é descoberto pelo uso real do agente.

O motor Sim-1 deles vai além. Ele simula, antes da implantação, como as mudanças de código se comportarão em sistemas complexos, mantendo consistência em mais de 100 estados de transição e cruzamentos de mais de 50 fronteiras de serviço. Em mais de 2700 cenários reais de usuários, atingiu 92,6% de precisão na simulação, contra 73,8% de ferramentas comparáveis. Não é uma análise estática decorada com linguagem de modelos, mas uma simulação baseada no comportamento real de produção. O grafo de contexto fornece insights que outras ferramentas de análise de código não oferecem: conhecimento do comportamento real do sistema sob condições reais, não apenas a teoria no papel.

Mas o número mais importante não é a precisão, e sim o ciclo de aprendizagem. Cada incidente resolvido, cada correção aprovada, cada resultado de simulação fica registrado no grafo de contexto. O sistema melhora a cada uso, pois retém o raciocínio que levou a cada resultado, não apenas o resultado em si. Essa é a dinâmica que todo sistema de IA de agentes precisa ter. Não só para produção, mas para qualquer decisão importante tomada por agentes. O problema não é se o agente consegue agir, mas se o sistema de agentes consegue lembrar por que agiu, aprender com essa memória, e aplicar no próximo raciocínio.

Casos de clientes e resultados

Os resultados são impressionantes. A Zuora, uma empresa de faturação por assinatura que apoia infraestruturas da Fortune 500, usa essa tecnologia em toda a equipe de engenharia, incluindo o monitoramento do seu sistema de faturação, uma das suas áreas mais críticas. A Nylas, uma API unificada de email, calendário e agendamento, também é cliente inicial. Ambas representam categorias onde falhas de confiabilidade podem causar perdas financeiras e contratuais imediatas. A PlayerZero afirma que o sistema reduziu pela metade o tempo de resolução de problemas, que antes levava semanas, economizando mais de 2 milhões de dólares por cliente.

O caso da Zuora é especialmente ilustrativo. Eles reduziram o tempo de classificação de nível 3 de 3 dias para 15 minutos. Com agentes de observabilidade adequados, a equipe reportou uma redução de 70% no tempo médio de resolução. Uma equipe passou de “só descobrir o problema após três dias” para “saber em poucos minutos”. Não é uma melhoria teórica, é um avanço real na operação.

Impacto profundo na engenharia de software

Acredito que a PlayerZero representa uma mudança de paradigma na engenharia de software, mais do que uma ferramenta de depuração. Pense no que acontece quando cada decisão de um agente fica registrada e pode ser reproduzida: o teu repositório de código muda.

O treinamento de novos engenheiros também muda. Em vez de ler documentação desatualizada ou fazer engenharia reversa com git blame, eles consultam o histórico de decisões. Por que dividir um serviço? O que falhou antes de uma refatoração? Quais trade-offs foram considerados na arquitetura? As respostas estão no rastreamento, não apenas na saída.

A depuração também muda. Em vez de perguntar “o que aconteceu”, passa a perguntar “qual foi o contexto do passo 14 do agente”. Em vez de adivinhar, podes reproduzir. O tempo médio de resolução diminui porque não precisas reconstruir o cenário a partir de fragmentos. O cenário fica guardado.

A qualidade do produto também evolui. Cada problema resolvido pelo agente é adicionado a um mapa crescente, mostrando como o sistema realmente se comporta sob condições reais. Não como foi projetado, mas como realmente funciona. Essa mapa se compõe por efeito de juros. Após mil incidentes resolvidos, o sistema conhece melhor do que qualquer engenheiro as suas próprias falhas.

A mudança mais subestimada é que o conhecimento organizacional não desaparece com a saída de pessoas. O raciocínio por trás das decisões fica na camada de rastreamento, não na cabeça de alguém. Quando o autor original sai, o código não morre. Essa é a verdadeira libertação: agentes que, além de agir, constroem a memória da organização como efeito colateral do seu trabalho. Cada ação deixa rastros, cada rastro ensina o sistema, e ele melhora por lembrar.

Reconheço algumas críticas e limitações. A escalabilidade do armazenamento de rastreamentos é desconfortável. Um fluxo de trabalho complexo de agente pode gerar centenas de megabytes por sessão. A maioria das equipes não tem infraestrutura para armazenar, indexar e consultar esses dados em grande escala. Event sourcing resolve questões de imutabilidade e replay, mas traz sua própria complexidade, incluindo compressão, gerenciamento de projeções e custos de armazenamento.

A lacuna de observabilidade ainda é grande. Uma pesquisa da Clean Lab com 95 equipes que operam agentes de produção revelou que menos de um terço está satisfeito com suas ferramentas de observabilidade. É o componente mais mal avaliado na pilha de infraestrutura de IA. 70% das empresas reguladas reconstruem seu stack de agentes a cada três meses. As ferramentas ainda não estão maduras.

Há também o problema do cold start. A arquitetura de rastreamento é mais valiosa quando há um histórico para consultar. A primeira investigação de incidente com ela não parece muito diferente do método tradicional. A centésima é uma disciplina completamente diferente. Mas é preciso passar por esses 99 primeiros. A fidelidade do replay também é difícil. Mesmo com rastreamento perfeito, rodar o agente na mesma entrada não garante o mesmo resultado, pois o modelo subjacente é não-determinístico. Você depura um sistema cujo comportamento muda a cada consulta. A arquitetura de rastreamento fornece o contexto, mas não garante determinismo.

Estamos num ponto de inflexão

Acredito firmemente que estamos numa encruzilhada na história da engenharia de software. Quando a IA começar a escrever a maior parte do código, a forma de depurar e garantir qualidade terá que mudar radicalmente. Os métodos tradicionais — olhar logs, rastrear pilhas, passo a passo — eram eficazes na era do código escrito por humanos, mas já não são suficientes na era de geração massiva de código por agentes de IA.

A PlayerZero oferece mais do que uma solução técnica; propõe uma nova mentalidade. Ela nos faz perceber que, na era dos agentes de IA, memória e aprendizagem são mais importantes do que apenas execução. Um sistema que lembra por que tomou uma decisão é muito mais poderoso do que um que só executa comandos sem entender o porquê. Essa memória não é um log simples, mas um histórico estruturado, consultável e reproduzível.

Do ponto de vista comercial, faz sentido. Quando uma falha de produção pode custar milhões, um sistema que identifica a causa raiz em minutos e corrige automaticamente não é um luxo, é uma necessidade. A PlayerZero afirma que seu sistema pode reduzir pela metade os problemas de produção, economizando mais de 200 mil dólares por cliente. Para empresas do Global 2000, esse retorno é difícil de ignorar.

Percebi também que a PlayerZero oferece uma garantia interessante: se não conseguirem aumentar a capacidade de engenharia em pelo menos 20% em uma semana, doam 10 mil dólares para um projeto open source à sua escolha. Essa garantia demonstra confiança na tecnologia e compreensão de que os clientes querem resultados concretos, não só promessas.

As lacunas nos sistemas de agentes de IA não estão nos modelos, ferramentas ou orquestrações — esses problemas estão sendo resolvidos ativamente. A verdadeira lacuna é na memória de decisão, que captura não só o que aconteceu, mas por que aconteceu. Essa camada torna possível depuração, automação de aprendizagem e preservação do conhecimento organizacional. Se o teu sistema de agentes não consegue responder “por que fez assim”, em qualquer ponto do seu histórico, estás a construir na areia. Areia rápida, impressionante, mas areia ao fim ao cabo.

Primeiro, constrói a camada de rastreamento. Uma vez feita, tudo o resto melhora. Essa é a lição mais importante que aprendi com a história da PlayerZero. Na nova era da programação com IA, não basta fazer o IA escrever mais rápido ou mais. Precisamos garantir que o código gerado seja compreensível, depurável e passível de melhorias. Só assim a IA será uma aliada verdadeira na engenharia de software, e não um peso adicional.