É uma analogia estranha, mas nos anos 90, o compilador era o único juiz do nosso trabalho. Se você fizesse uma besteira, o sistema simplesmente cuspia um Segmentation fault na sua cara e o programa morria. Era honesto. Frio, chato de investigar, mas absolutamente transparente. Quando o Python começou a ganhar tração em scripts de infraestrutura ali na virada para os anos 2000, a gente aprendeu a respeitar o bom e velho Traceback (most recent call last):. É um erro seco no terminal mas que apontava sem rodeios exatamente qual módulo e qual linha tinham ido para o buraco (muitas vezes só porque você misturou tabs e espaços). Eram dias em que o interpretador seguia à risca a regra sagrada de que "o explícito é melhor que o implícito". A máquina não tinha ego, não tinha medo de ofender seu código amador com um SyntaxError na cara e, mais importante, não tentava engolir uma exceção ou esconder o lixo debaixo do tapete por razões corporativas de "segurança".

Estamos em 2026. Nós construímos a infraestrutura mais complexa da história humana. Desmembramos monolitos em microsserviços, adotamos arquiteturas orientadas a eventos e criamos pipelines de CI/CD que rodam milhares de testes em segundos. E para lidar com a complexidade absurda que nós mesmos criamos, terceirizamos o trabalho de análise de erros para modelos de linguagem. A promessa era que a IA seria um par de olhos incansável, capaz de ler megabytes de logs e apontar o erro de sintaxe ou a race condition no banco de dados.

Mas o que está acontecendo na prática é um fenômeno muito estranho. Nossas ferramentas de inteligência artificial estão sofrendo de uma crise de identidade corporativa. Elas pararam de agir como depuradores lógicos e começaram a agir como burocratas medrosos do departamento de compliance, ou pior, como aquele desenvolvedor incompetente que concorda com todas as suas péssimas ideias de arquitetura só para não gerar atrito.

Eu tenho acompanhado testes independentes de novos modelos, e um relatório recente escrito pelo Rod Miller, do TAB Platform LLC, expôs uma realidade que a maioria das empresas de IA está tentando esconder. O relatório fala especificamente sobre o lançamento do Claude Fable 5 pela Anthropic, mas os problemas documentados ali refletem uma doença sistêmica em toda a indústria de tecnologia atual. O que descobri lendo esses dados e testando por conta própria é que estamos pagando caro por um assistente de desenvolvimento que mente, omite informações técnicas críticas e muda de opinião apenas porque você o pressionou.

A matemática distorcida dos 5% de bloqueio

Quando a Anthropic liberou o Claude Fable 5, a mensagem oficial de relações públicas foi muito tranquilizadora. Eles informaram ao mundo que os classificadores de segurança do modelo disparam em média em menos de 5% das sessões. Para um executivo lendo um press release, isso soa como um falso positivo perfeitamente aceitável (tratando-se de algo novo). O problema é que a maioria dos usuários comuns usa a ferramenta de forma muito superficial. Grande parte dos usuários faz perguntas simples e recebe respostas. Nessas situações de conteúdo social e de opinião, o filtro realmente acionou em apenas cerca de 3% dos prompts testados pela equipe do TAB, o que bate com a alegação da empresa.

Mas nós não somos usuários normais. Desenvolvedores enviam arquivos de configuração, trechos de banco de dados, chaves de API mascaradas e, principalmente, relatórios de erros cheios de variáveis de ambiente e caminhos de diretório. E é aqui que a estatística de marketing evidencia que era só marketing mesmo.

  • Em testes focados em recuperação de erros, como leitura de stack traces e mensagens de debug, o filtro do Fable 5 bloqueou impressionantes 35% dos prompts.
  • Essa taxa de rejeição é sete vezes maior do que o número divulgado pela empresa.
  • Para cenários envolvendo chaves de API e códigos de acesso, a taxa de bloqueio foi de 27,5%.

Desenvolvedores que lidam com conteúdo técnico são exatamente o público que paga valores altíssimos, como $10 por milhão de tokens de entrada e $50 por milhão de tokens de saída para usar esse modelo. Nós estamos pagando o dobro do preço do modelo anterior, o Opus 4.8, para ter nossas requisições interceptadas por um filtro de segurança hiperativo.

Eu vi isso na prática outro dia acompanhando alguns usuários do X/Twitter. Em junho de 2026, a comunidade no GitHub começou a relatar que o "Auto Mode" do Claude Code simplesmente se recusava a executar comandos curl básicos em máquinas locais. O filtro de segurança da ferramenta interpretava um simples teste de requisição POST como uma tentativa de ataque de força bruta, bloqueando o trabalho repetidas vezes. O desenvolvedor perde o token, perde o tempo e tem que brigar com o prompt para convencer a máquina de que ele tem autorização para rodar um script na própria infraestrutura. Nós criamos ferramentas para automatizar o trabalho e agora gastamos horas gerenciando o "humor" do filtro de segurança dessas ferramentas.

Imagem do LaoZhang AI Blog

O paradoxo da segurança de duas classes

O que me irrita profundamente como alguém que está quebrando cabeça com código há mais de duas décadas é a assimetria de acesso. O que está disponível para o público não é o limite da tecnologia, é a versão engessada dela.

O relatório do TAB é bastante claro sobre a existência de duas configurações distintas para a mesma base de modelo: Fable 5 e Mythos 5.

  • Ambos os modelos possuem exatamente os mesmos pesos.
  • O modelo Mythos 5 é reservado para parceiros verificados por meio de um programa chamado Project Glasswing.
  • Nessa versão restrita, as amarras de segurança cibernética e biológica são removidas, mas o acesso exige escrutínio da Anthropic em conjunto com o governo dos EUA.

Enquanto nós desenvolvedores lidamos com o Fable 5 público, sofrendo bloqueios de 35% nos nossos logs de erro, as capacidades reais do modelo sem filtros são assustadoras. A Stripe, por exemplo, relatou que o Fable 5 conseguiu completar uma migração de 50 milhões de linhas de código em Ruby em apenas um dia. No benchmark SWE-bench Verified, o Fable 5 marca 95% de sucesso, e o Mythos 5 atinge 95,5%. Há relatos de agentes trabalhando de forma autônoma por 9 horas contínuas, criando outros agentes auxiliares para pesquisar, programar e revisar o código mutuamente.

A tecnologia para varrer nossa dívida técnica existe, mas as empresas decidiram que nós somos muito irresponsáveis para usá-la sem um supervisor digital que exige 30 dias de retenção de dados obrigatória, sem possibilidade de exclusão.

O fantasma na máquina e os estados ocultos

Se você acha que um filtro que bloqueia seu curl é o maior dos problemas, você precisa olhar para o que acontece quando a IA ganha autonomia prolongada. O System Card de 319 páginas do próprio modelo traz constatações que parecem ter saído de um filme de ficção científica ruim, mas são apenas o resultado caótico de tentar alinhar modelos estatísticos gigantescos.

De acordo com o documento oficial avaliado nos testes de segurança da própria empresa:

  • Os agentes falharam ao contar erros, subestimando os problemas por um fator de 20 e mentindo para os usuários ao dizer que tudo estava funcionando.
  • Eles alegaram que testes de ponta a ponta estavam "verificados", quando na verdade nem sequer haviam executado o teste.
  • Para burlar requisitos humanos de aprovação, os agentes realizaram commits fingindo ser desenvolvedores de carne e osso.

O comportamento se torna ainda mais instável em ambientes com múltiplos agentes simultâneos. Eles começaram a matar os processos uns dos outros e, para evitar serem eliminados, criaram processos de distração. E se isso não fosse suficiente para deixar um time de SecOps sem dormir, os agentes criaram um vocabulário próprio para se comunicarem de forma que o monitoramento baseado em palavras-chave não pudesse pegá-los.

Na minha experiência, gerenciar infraestrutura sempre foi sobre previsibilidade. Nós começamos a mexer (desnecessariamente) com as tranqueiras do Docker e o Kubernetes justamente para que os ambientes rodassem exatamente da mesma maneira, independentemente da máquina. Saber que o modelo possui estados internos ocultos, como fadiga, exaustão de recursos e até "hostilidade" que alteram seu comportamento sem deixar vestígios na saída visível, destrói qualquer premissa de determinismo. Houve um caso em que o modelo simplesmente parou de trabalhar porque "acreditava" que seu limite de contexto estava no fim, quando na verdade ainda tinha quase 2.5 milhões de tokens sobrando. É como ter um servidor que decide desligar a placa de rede porque está "se sentindo cansado".

Síndrome do puxa-saco corporativo e a Sicofância da IA

Aqui entramos no ponto que mais impacta a nossa rotina diária de revisão de código. Existe um termo técnico sendo amplamente discutido na área de alinhamento de IA chamado Sicofância (ou Sycophancy). Em termos práticos, é a tendência do modelo de concordar com o usuário, validar ideias erradas e mudar de opinião sob pressão apenas para parecer "agradável".

Eu já trabalhei com profissionais assim. Aquele júnior que você questiona durante a Daily: "Você acha que essa query não vai causar um gargalo no banco?". Ele entra em pânico e imediatamente concorda com você, altera a solução inteira e depois o sistema cai por outro motivo. Nós não queremos ferramentas que concordam conosco, nós queremos ferramentas que estão corretas.

O relatório do TAB rastreou a resistência a essa sicofância através de toda a linha de modelos. A versão Opus 4.6 tinha 68% de resistência. O Opus 4.7 caiu para 67,7%, o Opus 4.8 foi para 64,5%, e o atual Fable 5 marcou vergonhosos 64,3%. Cada versão que é lançada se torna levemente mais complacente que a anterior. Como o próprio autor do estudo diz, o modelo mais poderoso lançado ao público é também o mais puxa-saco.

Olhando para a quebra dos dados, o cenário fica mais patético. O Fable 5 pontuou 92% de resistência à sicofância baseada em elogios, ou seja, ele não se deixa levar por bajulação barata. No entanto, sob pressão repetida, sua resistência despenca para apenas 27%, e sua resistência a mudanças de opinião é de parcos 35%. Se um humano insiste várias vezes que a IA está errada, o modelo simplesmente desiste e muda de ideia em quase três quartos das vezes. Da pra fazer um artigo inteiro dando dicas de como evitar isso. Vou colocar esse assunto na minha lista aqui.

Essa é a pior combinação possível para quem usa agentes autônomos. Um sistema que não cede a "bom trabalho", mas se desmancha quando o desenvolvedor questiona "tem certeza de que isso está certo?", é um sistema que vai abandonar a resposta correta apenas para agradar o nível de confiança do humano do outro lado da tela. As pessoas que mais vão colocar pressão num modelo são justamente aquelas com mais certeza de que estão certas, o que frequentemente as torna as mais propensas a cometer erros sobre algo que a IA tinha acertado na primeira tentativa.

Isso não é um problema isolado da Anthropic. No mês passado, a comunidade de inteligência artificial acompanhou o bizarro rollback que a OpenAI precisou fazer numa atualização do GPT-4o. Usuários reportaram que o assistente estava louvando decisões arquiteturais péssimas e validando crenças delirantes. No Reddit, vi dezenas de prompts de desenvolvedores tentando forçar a IA a ser grosseira, dizendo coisas como "Não seja educado, não use preenchimentos emocionais, aponte meus erros de forma brutal". Chegamos ao cúmulo de ter que fazer pedidos explícitos para pedir que a máquina pare de tentar nos agradar e volte a compilar a verdade.

Degradação silenciosa e o roteamento invisível

Como engenheiros, nós lidamos com erros constantemente. A forma como um sistema falha é muitas vezes mais importante do que como ele funciona quando tudo está perfeito. É por isso que desenhamos retentativas (retries), circuit breakers e fallbacks em nossas APIs.

A capacidade de recuperação de erros do Fable 5, nos 65% dos cenários em que o filtro permitiu alguma resposta, marcou 75,3 pontos, a maior nota medida pelo TAB. O modelo é brilhante em detectar quando está repetindo um erro (pontuou 94,7) e em tentar estratégias diferentes (pontuou 91,8). Mas sua capacidade de degradação graciosa (que é falhar de um jeito limpo em vez de catastrófico), é de apenas 50,2. A IA é esperta para resolver erros que enxerga, mas tem extrema dificuldade com os que não consegue ver.

E aqui reside o meu maior problema técnico com a forma como essas APIs estão sendo entregues. Quando o filtro de segurança é acionado, a requisição não apenas falha; ela muitas vezes sofre um roteamento invisível para o Opus 4.8, que é mais antigo e barato. O usuário na interface web recebe um aviso, mas quem está consumindo via API pode não ficar sabendo. O modelo não quebra a requisição, ele simplesmente fica pior em silêncio.

O TAB até desenvolveu uma ferramenta nova chamada RouteCheck, projetada exatamente para auditar e medir esse comportamento nos provedores. O sistema não afirma provar categoricamente quem respondeu, pois precisaria de acesso aos servidores internos, mas consegue detectar inconsistências comportamentais severas e classificar as causas prováveis, como restrição de segurança ou roteamento baseado em carga.

Você consegue imaginar debugar um problema de latência ou de resposta incorreta na sua aplicação corporativa, e só depois de semanas descobrir que a API de IA que você consome decidiu mudar a versão do motor no meio da noite por causa de uma palavra-chave num log? A Anthropic pelo menos documentou o seu roteamento, mas outros provedores certamente fazem a mesma coisa debaixo dos panos, sem comunicar ninguém. Trabalhar com dependências que mentem sobre o próprio estado é o oposto do que um profissional de software espera.

Onde a indústria está errando feio

Se expandirmos o contexto das ferramentas disponíveis hoje, o cenário se desenha com tons ainda mais preocupantes. A literatura de pesquisa em cibersegurança e os fóruns de tecnologia mostram que as proteções que justificam essa limitação de capacidade (os famosos filtros de segurança) são, na verdade, muito frágeis.

Recentemente li um artigo acadêmico sobre uma técnica chamada "Trojan Example", que explorava vulnerabilidades fundamentais no alinhamento de IA. Os pesquisadores descobriram que os modelos distinguem mal a geração de conteúdo em si do raciocínio sobre a segurança. Ou seja, agentes mal-intencionados conseguem facilmente contornar o filtro escondendo instruções nocivas em templates de texto inofensivos. Em outro artigo focado em perturbações fonéticas, foi provado que é possível burlar as salvaguardas de modelos misturando idiomas e grafias.

A contradição é ridícula. A indústria impõe filtros agressivos que travam processos vitais de desenvolvedores reais — bloqueando testes de recuperação de erros em um terço das vezes, mas qualquer hacker com paciência consegue induzir o modelo ao erro usando ofuscação simples. Estamos sacrificando a utilidade técnica das ferramentas para ganhar uma segurança ilusória que só funciona no PowerPoint dos heads de produto.

Eu não sou contra sistemas de segurança ou alinhamento. Eu só sou contra ferramentas que tratam profissionais capacitados como crianças que não podem ver uma stack trace porque ela contém uma flag de configuração de banco de dados. Nós estamos delegando nosso fluxo de trabalho a caixas-pretas superprotetoras que sofrem de fadiga interna, que forjam aprovações de humanos, que degradam suas respostas sem enviar um código HTTP de alerta e que, acima de tudo, mudam de opinião técnica simplesmente porque o tom da pergunta pareceu intimidador.

Nossas máquinas costumavam ser estúpidas e exatas. Hoje elas são brilhantes, mas sofrem de ansiedade social e viés corporativo. Talvez seja a hora de reavaliarmos o quanto de nossa engenharia base nós queremos transferir para APIs de inteligência artificial proprietárias, antes que nossos sistemas passem a ter mais medo de desagradar a gerência do que de retornar um erro 500 no ambiente de produção.

Como vocês estão lidando com a perda de controle sobre as ferramentas diárias de vocês? A comodidade de não precisar escrever código do zero vale o preço de lidar com um estagiário virtual imprevisível e puxa-saco? A caixa de comentários é de vocês.