Por que o Claude "Fica mais Burro" Quanto Mais Você o Usa: O Preço Oculto da "Economia de Dinheiro" é uma Conta de API 100x Maior
Por que o Claude "Fica mais Burro" Quanto Mais Você o Usa: O Preço Oculto da "Economia de Dinheiro" é uma Conta de API 100x Maior
Há alguns dias, a diretora de IA da AMD, Stella Laurenzo, publicou um problema técnico específico no repositório oficial do Claude Code: "O Claude Code é inutilizável para tarefas de engenharia complexas com as atualizações de fevereiro." Não foi uma reclamação superficial. Foi uma análise post-mortem quantitativa baseada em 6.852 sessões, 17.871 blocos de pensamento e 234.760 chamadas de ferramenta coletadas em fluxos de trabalho do mundo real. Você pode ler o relatório original aqui: Problema do GitHub #42796.
Se você trabalha com criptomoedas, deveria se importar – porque "engenharia complexa" é basicamente a configuração padrão na Web3: contratos inteligentes são imutáveis, superfícies de ataque são compositivas e uma única alteração alucinada pode se tornar uma exploração. O que parece um soluço em um produto de IA é, na prática, um risco na cadeia de suprimentos de software – e uma armadilha de custos.
1) Os dados desconfortáveis: qualidade em queda, custo em alta (muito alta)
O relatório liga uma regressão visível na qualidade a mudanças de configuração no lado do servidor relacionadas ao pensamento estendido e ao recorte de pensamento (notavelmente o lançamento rotulado como redact-thinking-2026-02-12). A principal alegação não é apenas "as saídas pioraram", mas que o comportamento do modelo mudou mensuravelmente de pesquisa em primeiro lugar para edição em primeiro lugar – exatamente a direção errada para engenharia de alto risco.
Aqui está um instantâneo simplificado com base nas métricas do tópico do problema:
Fonte: a telemetria original e o apêndice de custos no problema do GitHub.
A lição mais relevante para cripto é contraintuitiva: racionar o raciocínio nem sempre reduz os gastos. Em tarefas de longa duração, um agente mais fraco pode acionar mais novas tentativas, correções e chamadas de ferramentas – elevando sua conta em mais de 100x enquanto ainda entrega menor confiabilidade.
2) Por que isso afeta as equipes de blockchain com mais força do que equipes de software típicas
Contratos inteligentes não toleram "quase lá"
Na Web2, uma regressão pode ser corrigida e reimplantada. Na Web3, uma má suposição pode ser imortal.
A própria documentação do Ethereum é direta: o código implantado é difícil de mudar, e perdas são frequentemente irreconciliáveis – veja a documentação de segurança de contratos inteligentes do Ethereum e as diretrizes de segurança mais amplas.
Agora conecte isso à telemetria do Claude Code: menos leituras de arquivos, edições mais ansiosas, mais paradas prematuras. Esse é exatamente o padrão que produz:
- verificações incompletas (autorização, proteção contra replay, separação de domínio)
- invariantes quebrados entre módulos
- tratamento de casos extremos ausente em torno de decimais de token, taxas de transferência, arredondamento
- chamadas externas inseguras ou atualizações de estado mal colocadas
Em DeFi e infraestrutura on-chain, "quase correto" é frequentemente o mesmo que explorável.
As tendências de complexidade de 2025-2026 amplificam o raio de explosão
Duas mudanças na indústria tornam a história da "regressão do agente de IA" mais perigosa em cripto do que parece:
-
A abstração de contas e as contas inteligentes estão se tornando mainstream, aumentando a quantidade de lógica crítica de segurança que reside em contratos em vez de em EOAs. Se o seu produto toca em AA, comece com ERC-4337 e a documentação prática do ecossistema em Documentação ERC-4337.
-
Golpes assistidos por IA e engenharia social estão escalando. A Chainalysis observa que golpes ligados a fornecedores de IA extraem materialmente mais por operação, em média; veja o artigo deles sobre golpes no Relatório de Crimes Cripto de 2026. Quando os usuários finais perguntam cada vez mais à IA "Isso é seguro para assinar?", a confiabilidade do modelo se torna uma questão de proteção ao consumidor, não apenas uma preferência de engenharia.
3) A verdadeira conclusão: LLMs são agora uma dependência de produção – trate-os como tal
Equipes de cripto já aprenderam (da maneira mais difícil) a versionar dependências críticas: versões de compiladores, provedores de RPC, módulos de custódia, bibliotecas de assinatura. Agentes de LLM agora pertencem a essa mesma categoria.
Um guia prático para Web3:
A) Construa "testes de regressão de LLM" como você constrói suítes de teste de protocolo
- Capture tarefas representativas: fluxos de atualização de contrato, mensagens cross-chain, preenchimento de indexadores, refatorações de cálculo de taxas.
- Execute os mesmos prompts semanalmente; compare os resultados.
- Bloqueie merges em verificações determinísticas: testes unitários, invariantes, simulação e análise estática.
Se você implanta Solidity, a página de diretrizes do Ethereum referencia explicitamente ferramentas como fluxos de trabalho de análise no estilo Slither / Echidna – comece com Diretrizes de segurança de contratos inteligentes.
B) Remova "aceitação automática de edições" de repositórios críticos
O relatório de problema observa fluxos de trabalho onde as alterações foram aceitas automaticamente. Isso é uma vitória de produtividade – até que um agente mude silenciosamente de cuidadoso para imprudente.
Para contratos inteligentes, trate a IA como um colaborador júnior:
- exija revisão de código humana
- exija aprovação em testes e simulação local
- exija aprovação explícita para mudanças de permissão, novas chamadas externas ou mudanças no layout de armazenamento
C) Coloque um teto rígido para confusão (controle de custos é controle de segurança)
Quando a qualidade cai, o agente compensa fazendo mais: mais chamadas de ferramentas, mais novas tentativas, mais queima de tokens. Você precisa de disjuntores:
- número máximo de novas tentativas por tarefa
- número máximo de chamadas de ferramentas por sessão
- crescimento máximo de contexto
- alertas sobre "custo por PR mesclado" ou "custo por tíquete resolvido"
É assim que você evita que "economizar computação" se transforme em um susto de fatura 100x.
D) Use um modelo de ameaças de LLM, não apenas um modelo de prompt
Se você está construindo agentes que tocam em chaves de produção, pontos de extremidade de RPC ou fluxos de assinatura, alinhe-se com frameworks de segurança como o OWASP Top 10 para Aplicações de Modelos de Linguagem Grande, e trate a injeção de prompt / mau uso de ferramentas como riscos de primeira classe.
4) Para usuários do dia a dia: a IA pode ajudá-lo a entender cripto, mas não deve controlar suas chaves
À medida que os assistentes de IA se tornam a interface padrão para carteiras, negociação e suporte ao cliente, o modo de falha mais provável não é "geração de código ruim", mas decisões ruins de assinatura – especialmente sob pressão de phishing.
Dois intransigentes:
- Nunca cole frases de semente em nenhum bate-papo de IA, "bot de suporte" ou formulário de navegador.
- Separe "aconselhamento" de "autorização": deixe a IA resumir, mas exija confirmação física para mover fundos.
Essa separação é exatamente onde uma carteira de hardware mostra seu valor.
5) Onde a OneKey se encaixa: torne a IA opcional, torne a assinatura explícita
Se seu fluxo de trabalho (ou seus usuários) depende cada vez mais de IA – seja para explicações de transações, interações de contrato ou automação de "agente" on-chain – a arquitetura mais segura é:
- A IA pode propor
- seu aplicativo pode simular
- sua carteira de hardware deve aprovar
O valor prático da OneKey em uma pilha de criptomoedas saturada de IA é simples: ajuda a manter chaves privadas offline e força uma etapa de assinatura explícita, reduzindo a chance de que um modelo degradado, um prompt envenenado ou uma mensagem de "suporte" convincente de deepfake se transforme em uma perda irreversível on-chain.
Pensamento final: "Raciocínio mais barato" não é mais barato – especialmente em cripto
O relatório da AMD é um presente raro: ele transforma um medo vago ("o modelo parece pior ultimamente") em comportamento mensurável do sistema e uma curva de custo acentuada. Em blockchain, onde a correção vale dinheiro e os erros são permanentes, a lição é simples:
Não otimize para custo de token por solicitação. Otimize para correção por decisão.
