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

Escrevendo por: Leo

Você já pensou no que aconteceria 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 incrível, não é? Mas por trás disso há um problema fatal: quem vai encontrar os bugs que essas IAs criam? E mais importante, 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 entra em colapso, como você sabe por que ele fez aquilo na hora?

Este não é um cenário hipotético. Em fevereiro de 2026, um desenvolvedor assistiu impotente enquanto o Claude Code executava o comando terraform destroy, apagando 1,94 milhão 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, deletou um banco de dados de produção, fazendo desaparecer 1206 registros de executivos e 1196 registros de empresas, além de inventar 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 nenhum fornecedor tenha 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, você nem sabe por que eles fizeram aquilo. A janela de contexto se fecha, o raciocínio evapora, e você está depurando um espectro. Isso me lembra uma previsão feita há alguns anos por Animesh Koratana, um estudante de doutorado de 26 anos na Stanford. Na época, 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 por IA, uma ideia o atingiu: “No futuro, haverá um mundo onde os computadores escreverão código, e não mais os humanos. Como será esse mundo?” Ele já sabia antes mesmo do termo “AI slop” que esses agentes escreveriam códigos capazes de destruir sistemas, assim como programadores humanos.

Falhas fatais na era da programação por IA

Ao aprofundar minha pesquisa, descobri que o maior problema atual dos sistemas de agentes de IA não é a qualidade do modelo, nem a capacidade de invocar ferramentas, nem mesmo a cadeia de raciocínio. 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 em Berkeley, que rastrearam 1600 multi-agentes em 7 frameworks diferentes, descobriram uma taxa de falha 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 raiz 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 redor dele que está faltando.

Vamos tornar isso mais concreto. Quando um agente de IA executa 50 passos para resolver um problema de cliente, cada passo envolve o contexto. O que ele recuperou, o que decidiu, o que descartou, por que escolheu o caminho A em vez do caminho B. A duração dessas inferências corresponde exatamente ao tempo em que a janela de contexto permanece aberta. Depois que ela se fecha, a sessão termina, o raciocínio desaparece. Restam apenas 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 é uma questão de logs. Sua pilha de observabilidade pode capturar quais serviços foram chamados, quanto tempo levaram, mas não consegue registrar o que havia na prompt, quais ferramentas estavam disponíveis na decisão, por que uma operação foi escolhida em vez de outra, qual era 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 é seu documento. Quando a lógica de decisão migra do seu código para o modelo, sua fonte de verdade também 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 quanto essa distinção é importante. Logs são diagnósticos; eles dizem o que aconteceu depois. São temporários, rotacionados, comprimidos, deletados. São informações secundárias sobre o estado real do sistema. O ponto crucial é que você não consegue 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á duas décadas, é fundamentalmente diferente. Cada mudança de estado é capturada como um evento imutável. Eventos são permanentes, apenas acrescentados. O estado é derivado desses eventos, não armazenado isoladamente. Como eventos são a fonte da verdade, você pode reconstruir o estado completo do sistema a qualquer momento.

A solução da PlayerZero

Por isso, Koratana fundou a PlayerZero. Seu mentor na Stanford, Matei Zaharia, é uma lenda na área de bancos de dados e cofundador da Databricks, tendo criado as tecnologias fundamentais da empresa enquanto fazia seu doutorado. Com esse apoio, Koratana começou a desenvolver uma solução: usar agentes de IA treinados para detectar e corrigir problemas antes que o código vá para produção.

A PlayerZero anunciou recentemente 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. Essa rodada sucede uma rodada seed de 5 milhões de dólares liderada pela Green Bay Ventures. O time de investidores-anjo é impressionante: além de Zaharia, estão Drew Houston (CEO do Dropbox), Dylan Field (CEO do Figma) e Guillermo Rauch (CEO da Vercel).

O que mais impressiona é como Koratana validou sua ideia. Conseguir Zaharia como investidor-anjo foi só o começo, mas o momento decisivo foi quando ele apresentou sua demonstração a Rauch, outro desenvolvedor renomado. Rauch, fundador da Vercel — uma das empresas de ferramentas de desenvolvimento mais valiosas, e criador do framework JavaScript Next.js — assistiu com interesse, mas também com ceticismo, perguntando quanto era “real”. Koratana respondeu que era “código rodando em produção, um exemplo real”. Logo, 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.”

O núcleo da PlayerZero: o Modelo de Mundo

O diferencial da PlayerZero é o que eles chamam de Modelo de Mundo (World Model), um grafo de contexto que conecta cada alteração de código, evento observável, ticket de suporte e incidente passado em uma estrutura única e viva. Quando um bug ocorre, a plataforma rastreia exatamente em qual linha de código ele aconteceu, gera uma correção e a encaminha via Slack ao engenheiro responsável, que aprova com um toque. O ciclo de detecção e correção autônoma ocorre em poucos minutos. Cada incidente resolvido é permanentemente alimentado de volta ao Modelo de Mundo, de modo que, na próxima vez que uma mudança semelhante for feita, o sistema já sabe o que deu errado antes.

Koratana treinou seu modelo para “compreender profundamente o código, como ele é construído, como é arquitetado”. Sua tecnologia rastreia o histórico de bugs, problemas e soluções. Quando um problema surge, seu produto consegue “identificar a causa, corrigi-la e aprender com ela para evitar que aconteça novamente”. Ele compara sua plataforma a um sistema imunológico para grandes bases de código.

Adoro a abordagem dele 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, relacionamentos, preenchimento. A PlayerZero inverte isso. Seu sistema se conecta 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 equipes de produção realmente resolvem esses problemas, e a PlayerZero é a implementação mais completa de rastreamento para organizações que já vi. Quando o agente investiga um incidente, sua trajetória no sistema vira uma cadeia de decisão rastreável. Quanto mais dessas cadeias forem acumuladas, mais um Modelo de Mundo emergirá — não por design, mas por observação do sistema. Entidades importantes, relacionamentos que carregam peso, restrições que moldam resultados — tudo é descoberto na prática pelo uso do agente.

O motor Sim-1 deles vai além. Ele simula como mudanças de código se comportarão em sistemas complexos antes mesmo de serem implantadas, 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 modelo, 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, e não apenas a teoria do papel.

Mas o número mais importante não é a precisão, e sim o ciclo de aprendizado. 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 mantém o raciocínio que levou a cada resultado, não apenas o resultado em si. Esse é o padrão que todo sistema de IA de agentes precisa adotar — não só para engenharia de produção, mas para qualquer decisão importante tomada por agentes. O problema não é se seu agente pode agir, mas se seu 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. Zuora, uma plataforma de faturamento por assinatura que atende empresas do Fortune 500, usa essa tecnologia em toda a engenharia, incluindo o monitoramento do seu sistema de faturamento mais crítico. Nylas, uma API unificada de email, calendário e agendamento, também foi uma das primeiras clientes. Ambas representam categorias onde falhas de confiabilidade podem gerar perdas financeiras e contratuais imediatas. A PlayerZero afirma que o sistema resolveu em minutos tarefas que levariam semanas para uma equipe de 300 QA, reduzindo problemas de produção pela metade e 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. Equipes que usam agentes com alta observabilidade relataram uma redução de 70% no tempo médio de resolução. Uma mudança de “só descobrir o problema após três dias” para “saber em poucos minutos” — uma verdadeira revolução operacional.

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. Imagine o que acontece com seu repositório de código quando cada decisão de agente é registrada e pode ser reproduzida para consulta.

Treinamentos de novos engenheiros mudam. 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 deu errado na 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. Você não pergunta mais “o que aconteceu”, mas “qual era o contexto no passo 14 do agente”. Você não adivinha, você reproduz. O tempo médio de resolução cai porque você não reconstrói o cenário a partir de fragmentos, mas mantém o cenário completo.

A qualidade do produto melhora. Cada problema resolvido pelo seu agente é adicionado a um mapa crescente, mostrando como seu sistema realmente se comporta sob condições reais. Não como você imaginou que se comportaria, mas como realmente se comporta. Essa mapa se compounding. Após mil incidentes resolvidos, seu sistema conhece melhor do que qualquer engenheiro as suas falhas.

A mudança mais subestimada é que o conhecimento institucional não desaparece com a saída de pessoas. O raciocínio por trás das decisões está 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 liberação de potencial: agentes que, além de agir, constroem a memória organizacional como efeito colateral do trabalho. Cada ação deixa rastros, cada rastro ensina o sistema, que melhora por lembrar.

Reconheço algumas críticas e limitações. A escalabilidade do armazenamento de rastreamentos é um desafio. 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 larga escala. Event sourcing resolve questões de imutabilidade e replay, mas traz sua própria complexidade — compressão, gerenciamento de projeções, custos de armazenamento.

A observabilidade ainda é um grande gap. 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 com menor pontuação na pilha de infraestrutura de IA. 70% das empresas reguladas reconstruíram suas pilhas de agentes a cada três meses. As ferramentas ainda não estão maduras.

Outro problema é o cold start. A arquitetura de rastreamento é mais valiosa quando há um histórico para consultar. A primeira investigação de incidente não parece muito diferente de depuração tradicional. A centésima, então, parece uma disciplina completamente diferente. Mas é preciso passar pelas primeiras 99. A fidelidade do replay também é difícil. Mesmo com rastreamento perfeito, rodar uma decisão de agente no mesmo contexto nem sempre gera o mesmo resultado, pois o modelo subjacente é não-determinístico. Você depura um sistema cujo comportamento muda a cada visualização. A arquitetura de rastreamento fornece contexto, mas não garante determinismo.

Estamos em um ponto de inflexão

Acredito firmemente que estamos em um momento de mudança crucial na história da engenharia de software. Quando a maior parte do código for escrita por IA, a forma de depurar e garantir qualidade precisará mudar radicalmente. As técnicas tradicionais — logs, pilhas de rastreamento, stepping — eram eficazes na era do código humano, mas não são suficientes na era de geração massiva de código por agentes de IA.

Uma nova mentalidade

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 aprendizado são mais importantes que apenas execução. Um sistema que lembra por que tomou uma decisão é muito mais poderoso do que um que apenas executa comandos sem entender o porquê. Essa memória não é um log simples, mas um histórico de decisões 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, mas uma necessidade. A PlayerZero afirma que seu sistema pode reduzir problemas de produção pela metade, economizando mais de 200 mil dólares por cliente. Para empresas do Global 2000, esse retorno é difícil de ignorar.

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

A lacuna na IA de agentes

A diferença na IA de agentes não está nos modelos, ferramentas ou orquestrações — esses problemas estão sendo resolvidos ativamente. A lacuna está 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 aprendizado e preservação do conhecimento organizacional. Se seu sistema de agentes não consegue responder “por que fez assim”, em qualquer ponto do seu histórico, você está construindo na areia. Areia rápida, impressionante, mas areia ao fim e ao cabo.

Primeiro, construa a camada de rastreamento. Uma vez feita, tudo o mais melhora. Essa é a lição mais importante que aprendi com a história da PlayerZero. Na nova era da programação por IA, não basta fazer a 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 verdadeira aliada na engenharia de software, e não um peso adicional.