Shopping cart

Subtotal $0.00

View cartCheckout

Building better devs

TnewsTnews
  • Home
  • IA
  • Claude Ficou 67% Mais Burro — e Um Engenheiro da AMD Tem os Dados para Provar
IA

Claude Ficou 67% Mais Burro — e Um Engenheiro da AMD Tem os Dados para Provar

Email : 74

Stella Laurenzo não é uma pessoa qualquer reclamando no Reddit. Ela é a diretora de IA da AMD. E ela fez o que poucos fazem quando desconfiam que uma ferramenta piorou: em vez de postar uma thread de raiva, ela instrumentou 6.852 sessões do Claude Code, registrou 234.760 chamadas de ferramenta e 17.871 blocos de raciocínio, e publicou os dados.

O diagnóstico é devastador: a profundidade de raciocínio do Claude Code caiu 67%. O modelo lê código três vezes menos antes de editar. Edições feitas sem leitura prévia saltaram de 6,2% para 33,7%. Tarefas abandonadas no meio — algo que antes simplesmente não acontecia — viraram rotina.

A AMD já migrou para outra ferramenta.

Os Números que a Anthropic Não Queria que Existissem

O que torna o trabalho da Laurenzo difícil de contestar é a escala da telemetria. Não é uma impressão subjetiva de “parece mais lento”. São métricas objetivas, coletadas ao longo de semanas:

MétricaAntesDepoisVariação
Profundidade de raciocínio (thinking depth)Baseline-67%Queda de dois terços
Leituras por edição (read-to-edit ratio)6,6 leituras/edição2,0 leituras/edição-70%
Edições sem leitura prévia (blind edits)6,2%33,7%+444%
Tarefas abandonadas~0%FrequentesDe zero para recorrente

Na prática, isso significa que o Claude Code parou de entender o contexto antes de agir. Em vez de ler seis arquivos para entender a estrutura e depois fazer uma edição cirúrgica, ele lê dois e reescreve o arquivo inteiro. Ou pior — edita sem ler nada.

“Claude cannot be trusted to perform complex engineering tasks.” — Stella Laurenzo, diretora de IA da AMD

O Que Aconteceu: As 4 Causas Simultâneas

Uma investigação detalhada da comunidade — documentada na issue #41930 do GitHub — identificou que não foi um único problema. Foram quatro coisas acontecendo ao mesmo tempo, amplificando umas às outras.

1. Throttling Intencional em Horário de Pico

Em 26 de março, o engenheiro da Anthropic Thariq Shihipar confirmou pelo X/Twitter que a empresa estava reduzindo a capacidade durante horários de pico (5h–11h PT / 9h–15h BRT em dias úteis). A Anthropic estimou que “apenas ~7% dos usuários” seriam claramente afetados.

Na prática, desenvolvedores que trabalham em horário comercial — ou seja, a maioria — estavam recebendo um serviço intencionalmente degradado.

2. Dois Bugs de Cache de Prompt

Pesquisadores da comunidade fizeram reverse engineering do binário do Claude Code (228MB) usando Ghidra, MITM proxy e radare2, e encontraram dois bugs de cache:

Bug A — Billing Sentinel String Replacement: O fork customizado de Bun usado pela Anthropic faz substituição de strings em cada request. Se o histórico de conversa mencionasse termos de faturamento, o replacement atingia a posição errada, quebrando o prefixo de cache. Resultado: tokens não-cacheados custando 10–20x mais contra a quota.

Bug B — Cache Invalidation no Resume: As flags --resume e --continue injetavam attachments em posição diferente de sessões novas, invalidando o cache inteiro. Cada mensagem nova gerava reprocessamento completo de todo o contexto anterior.

# Diagnóstico: verificar se cache está funcionando
# Script publicado em gitlab.com/treetank/cc-diag

# Esperado (funcionando): cache_read próximo de 100%
# Real (com bug): cache_write cresce linearmente, cache_read ≈ 0%

3. Tokens Fantasma no Resume de Sessão

Um bug documentado na issue #38029 mostrava que o Claude Code gerava 652.069 tokens de output sem nenhum prompt do usuário durante o resume de sessão. Tokens cobrados normalmente da quota.

As release notes mencionavam “melhorias no uso de memória ao resumir sessões longas” — indicando que a Anthropic sabia do problema no momento do deploy.

4. Expiração de Promoção (Efeito Amplificador)

Em 13 de março, a Anthropic lançou uma promoção de 2x de uso em horários fora do pico. Em 28 de março, expirou sem aviso. Usuários acostumados com capacidade dobrada perceberam o retorno ao baseline como redução súbita — amplificando a percepção dos outros três bugs reais.

Os Impactos que Ninguém Inventou

Esses não são edge cases. São reports de assinantes pagando $20 a $200 por mês:

ComportamentoPlanoConsumo
Um prompt consumiu 79% da quota restanteMax 20× ($200/mês)1 prompt
Sessão de 5h depletadaMax 20× ($200/mês)19 minutos
60% da sessão queimadaPro ($20/mês)3 minutos
“hello” consumiu 2% da quotaPro ($20/mês)1 palavra
“Morning” consumiu 15%Max 5× ($100/mês)1 palavra
Tokens gerados sem promptMax652.069 tokens

Um “hello” consumindo 2% da quota de um plano pago. Um “Morning” consumindo 15%. Isso não é ajuste de capacidade — é cobrança por serviço não prestado.

O Thinking Depth: Escolha Deliberada ou Bug?

Esse é o ponto mais controverso. A timeline documentada mostra:

  • 9 de fevereiro: Anthropic implementa “adaptive thinking” — o modelo decide dinamicamente quanto pensar
  • 3 de março: O nível padrão de thinking é reduzido de “high” para “medium”
  • Março em diante: Redação do conteúdo de pensamento — o raciocínio deixa de ser visível para o usuário

A correlação entre a redação do thinking e a explosão de blind edits é difícil de ignorar. Quando o modelo para de mostrar seu raciocínio, fica impossível para o usuário detectar que ele está pensando menos. E os dados da AMD mostram que é exatamente isso que está acontecendo.

A resposta da Anthropic: sugerir que os usuários aumentem manualmente a configuração de esforço. Traduzindo: reduzimos o padrão, mas vocês podem voltar ao que era — se souberem que o setting existe.

A Resposta (Ou Falta Dela) da Anthropic

A comunicação da Anthropic durante toda essa crise foi, para ser generoso, inadequada:

  • Nenhum blog post oficial sobre os problemas de quota e degradação
  • Nenhuma notificação por email para assinantes pagantes
  • Nenhuma entrada na status page
  • Tickets de suporte sem resposta por mais de 3 dias
  • Nenhuma análise de causa raiz pública
  • Nenhuma oferta de créditos ou reembolso

Toda a comunicação veio de posts pessoais de engenheiros no X/Twitter e respostas no Reddit. A product lead Lydia Hallie reconheceu os problemas no X. Um post no Reddit chamou de “top priority”. Mas nada formal, nada no canal oficial.

A Anthropic publicou um postmortem oficial — mas sobre bugs de infraestrutura diferentes. Nesse documento, fizeram questão de afirmar: “We never reduce model quality due to demand, time of day, or server load.”

Os dados da AMD contam uma história diferente.

Por Que Isso Acontece: Os Motivos Estruturais

Se olharmos além dos bugs específicos, existe uma dinâmica estrutural que explica por que empresas de IA tendem a degradar silenciosamente seus produtos:

Pressão de custo por inferência: cada token de raciocínio custa dinheiro real em GPU. Reduzir o thinking depth de “high” para “medium” por padrão não é um bug — é economia. Se 93% dos usuários não percebem, é uma otimização financeira bem-sucedida.

Crescimento explosivo de demanda: a Anthropic tem mais demanda do que capacidade de GPU. Em 10 de abril, a Bloomberg reportou que a empresa fechou acordo com a CoreWeave para alugar capacidade adicional. Enquanto não chega, alguém fica com menos.

Ausência de SLAs públicos: diferente de cloud providers como AWS ou Azure, a Anthropic não publica SLAs de performance. Não existe benchmark oficial de “quanto o Claude deve pensar por request”. Sem métrica pública, não existe degradação mensurável — apenas percepção.

Modelo flat-rate com incentivo invertido: quando você cobra $20 ou $200/mês por uso com limites, cada usuário que usa mais é um custo. A incentivação econômica é reduzir consumo real mantendo a percepção de qualidade. Isso é exatamente o que throttling silencioso + redução de thinking depth faz.

Opacidade por design: a redação do conteúdo de thinking remove a última ferramenta que os usuários tinham para verificar se o modelo estava raciocinando. Sem ver o pensamento, você só vê o output — e se parece razoável, aceita. Mesmo que o modelo tenha pulado etapas cruciais.

O Que Você Pode Fazer Agora

Se você depende do Claude Code no seu workflow diário:

# 1. Evitar flags que invalidam cache
# NÃO use --resume ou --continue

# 2. Limpar contexto em vez de continuar conversas longas
/clear

# 3. Trabalho intensivo fora do horário de pico
# Depois das 12h BRT em dias úteis, noites, fins de semana

# 4. Monitorar consumo por prompt
# Se 1 mensagem curta queima >3-5% da sessão, reinicie

# 5. Forçar thinking level para "high" ou "max" nos settings

E a medida mais importante: instrumente seu uso. A razão pela qual a Laurenzo conseguiu provar a degradação é que ela tinha telemetria. A maioria dos desenvolvedores não tem — e é exatamente por isso que a degradação silenciosa funciona.

O Precedente que Isso Cria

A AMD não é uma startup de três pessoas. É uma empresa de $200 bilhões que avaliou profissionalmente a ferramenta, concluiu que ela degradou de forma mensurável, e migrou para outra. Esse tipo de decisão documentada cria precedente.

Se a Anthropic não responder de forma substantiva — não com posts no Twitter, mas com mudanças reais de transparência — outras empresas vão fazer a mesma análise. E muitas vão chegar à mesma conclusão: não dá para confiar numa ferramenta que pode ser silenciosamente degradada a qualquer momento, sem aviso, sem métrica pública, e sem responsabilização.

O Claude ainda é uma ferramenta extraordinária quando funciona na capacidade total. A questão é saber quando você está recebendo essa capacidade — e quando está recebendo 67% menos dela sem perceber.


Fontes: WinBuzzer, GitHub Issue #41930, The Register, DEV Community, Anthropic Postmortem

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts