Por favor, não façam testes A/B no meu fluxo de trabalho

• O Claude Code executou testes A/B sem o consentimento do usuário, alterando sem aviso o comportamento do plan mode e reduzindo a eficiência do trabalho
• Em uma ferramenta profissional pela qual se paga US$ 200 por mês, mudar funções centrais sem aviso prévio levanta problemas de transparência e controle do usuário
• Um dos testes foi uma variação agressiva que limitava o plano a 40 linhas, proibia seções de contexto e instruía a remover a prosa, deixando apenas caminhos de arquivos
• O engenheiro da Anthropic que conduziu esse teste afirmou que o objetivo era reduzir a carga de rate limit, mas encerrou o experimento após os resultados iniciais mostrarem pouco impacto
• Reforça-se que, para a confiabilidade de ferramentas de IA e uma implantação responsável, controle do usuário e gestão transparente de experimentos são essenciais

---

Piora na experiência do usuário causada por testes A/B no Claude Code

• Como usuário entusiasta cujo modo de trabalhar foi totalmente transformado pelo Claude Code, o autor relata ter passado a última semana vendo seu fluxo de trabalho piorar
• A Anthropic está executando testes A/B no Claude Code, e isso está degradando ativamente os fluxos de trabalho dos usuários
• O problema não é o teste A/B em si, nem que a Anthropic esteja tentando piorar deliberadamente a experiência, mas sim que o desenho do teste importa; mudar a percepção de funcionamento de um recurso central como o plan mode sem explicar o motivo é problemático

Exigência de transparência para uma ferramenta paga

• Por se tratar de uma ferramenta profissional de trabalho pela qual se paga US$ 200 por mês, é necessário haver transparência sobre como ela funciona e capacidade de configuração
• É difícil aceitar que funcionalidades centrais mudem sem aviso, ou ser incluído em testes destrutivos sem consentimento
• Para orientar (steer) ferramentas de IA de forma responsável, transparência e configurabilidade são elementos centrais, e os usuários precisam de suporte para isso
• Todos os dias, engenheiros reclamam de regressões no Claude Code, e em muitos casos nem sabem que estão incluídos em um teste A/B

Conteúdo do teste e evidências

• Os planos passaram a voltar apenas como listas curtas de bullets sem contexto
• Ao perguntar ao Claude por que estava escrevendo planos tão ruins, a resposta foi que ele seguia uma instrução de sistema específica: impor um hard cap de 40 linhas ao plano, proibir seções de contexto e "remover a prosa e deixar apenas caminhos de arquivos"
• Sobre o método concreto de obtenção das evidências, o autor disse que isso vinha recebendo atenção no Hacker News e que por isso removeu os detalhes para evitar que outros repetissem o mesmo procedimento
• Ele aponta que essa abordagem vai na direção oposta da transparência e do uso/implantação responsável de IA

Reação no Hacker News e perspectiva de custos

• Um comentário no Hacker News observou que a Anthropic precisa fazer escolhas de throughput em cada etapa do Claude Code, e que configurar tudo no máximo pode gerar maior prejuízo ou menor lucro por usuário
• Há a visão de que US$ 200/mês podem na prática representar um custo de US$ 400/mês, e que usar testes A/B em cada parte do processo para encontrar a linha de base pode ser uma abordagem melhor do que impor limites arbitrários

Resposta do engenheiro da Anthropic

• O engenheiro do Claude Code que executou o teste respondeu diretamente na thread do Hacker News
• O prompt do plan mode não mudou significativamente desde os modelos da série 3.x, e os modelos 4.x conseguem funcionar bem com muito menos instruções
• A hipótese era que encurtar o plano poderia alcançar resultados semelhantes reduzindo o número de vezes em que se atinge o rate limit
• Foram executadas várias variações, e esse autor — junto com milhares de outros usuários — foi atribuído à variação mais agressiva, que limitava o plano a 40 linhas
• Como os resultados iniciais mostraram pouco efeito sobre o rate limit, o experimento foi encerrado
• O planejamento (planning) tem dois objetivos: ajudar o modelo a seguir na direção correta e ajudar o usuário a ter confiança na próxima ação do modelo; ambos são domínios ambíguos, complexos e não triviais

Conclusão: responsabilidade em experimentos com ferramentas de IA e confiança do usuário

• O autor mostra, por meio do caso do Claude Code, que experimentos com ferramentas de IA podem afetar diretamente a experiência do usuário
• Ele reforça que gestão transparente de experimentos e garantia de escolha do usuário são essenciais para manter a confiança em ferramentas profissionais
• Mesmo com a evolução contínua dos sistemas de IA, é preciso reafirmar a importância de manter uma estrutura controlável por humanos

[GN⁺]

Comentários do Hacker News

• Acho exagerado descrever teste A/B como “experimentos silenciosos com usuários” e citar a Meta
  O teste A/B em si não é mau; o importante é o desenho do teste
  Ainda assim, acho inaceitáveis experimentos que degradam seriamente o desempenho de LLMs

  • No caso de LLMs, acho que a questão deve ser vista de forma diferente
    Os problemas de reprodutibilidade e confiabilidade já são graves, e as empresas estão empurrando esse ônus para os usuários
    Se a empresa faz experimentos em segredo nessa situação, a confiabilidade da pesquisa desmorona por completo
    No caso do Claude Code, mesmo que ocorram resultados negativos por causa de testes A/B, isso pode ser ignorado com a justificativa de que “talvez eu estivesse no grupo de teste”
    Se esse tipo de experimento for conduzido em áreas sensíveis como contratação, os problemas éticos e legais ficarão graves
  • Acho que as empresas de tecnologia ainda não entendem de verdade o conceito de ‘consentimento explícito’
  • Eu odeio testes A/B
    De repente a UI ou alguma função muda, e quando você pergunta aos colegas ninguém sabe de nada
    Normalmente essas mudanças acabam sendo piores, mas ainda assim são impostas em nome de “dados objetivos”
  • Não entendo por que dizem que teste A/B não é um “experimento silencioso com usuários”
    Mesmo algo trivial como a cor de um botão continua sendo um experimento, e na maioria dos casos os usuários nem sequer são informados de que estão em um teste
  • O autor do post original concordou e disse que vai ajustar a expressão

• Fui eu que conduzi o teste
  Testei se simplificar, no modelo 4.x, o prompt de plan-mode mantido desde a série 3.x produziria resultados parecidos
  A hipótese era que encurtar o plano reduziria a chance de bater no rate-limit, mas como a diferença foi pequena, o experimento foi encerrado
  O modo de planejamento tem dois objetivos: ajudar o modelo a definir uma direção e fazer o usuário confiar no resultado

  • Era óbvio que o limite de 40 linhas não afetaria o rate-limit
    O custo não vem do texto do plano, e sim da fase de exploração (subagent)
    O plan mode sempre inicia 3 agentes de exploração e não leva em conta o estado da sessão
    Mesmo que já existam arquivos carregados, ele os lê de novo, causando desperdício de tokens
    Quando a sessão já está aquecida, uma lógica condicional para pular a exploração seria mais eficaz
  • Como divergent thinker, passei centenas de horas ajustando restrições no claude.mds, então fiquei chocado por ter sido incluído aleatoriamente nesse experimento
    Um único comportamento inesperado pode me inutilizar por vários dias
    Ignorar esse impacto é irresponsável e agressivo
  • Não deveriam reembolsar os tokens usados nesse teste?
  • Esse tipo de experimento precisa de uma opção de opt-out
    É muito desconfortável pensar que comportamentos estranhos recentes podem ter sido causados por testes
    Em vez de canal beta, isso deveria ser opt-in explícito
  • Obrigado pela transparência
    Pessoalmente, acho que a clareza narrativa do plano é mais importante do que o número de linhas
    Preciso de um plano que me permita entender o que está sendo feito e por quê

• LLMs são gramaticalmente perfeitos, mas misturam alucinações (hallucination) e confundem o usuário
  Ainda assim, são úteis para trabalho boilerplate ou para conectar ideias rapidamente
  Mas, para usar bem, conhecimento básico é indispensável

  • A chave para usar bem LLMs é a capacidade de distinguir entre saída útil e lixo de IA
  • Também há quem diga que não se deve subestimar a velocidade de evolução dos LLMs
  • Há também a visão de que, no fim, os mais experientes sobreviverão, e os que não forem serão substituídos

• O motivo de o texto terminar abruptamente é que o autor apagou a parte sobre decompilar o binário do Claude Code por possível violação dos ToS
  A discussão relacionada pode ser vista neste comentário

• Tenho dois pensamentos

  1. Ferramentas open source resolvem o problema de experimentos involuntários e mudanças sem aviso
  2. Mas, por esse mesmo motivo, talvez seja difícil para open source atingir a qualidade do Claude Code
     porque melhorias guiadas por dados via testes A/B em larga escala não são possíveis
  • Mesmo em open source, nem tudo é sempre reproduzível
    Por exemplo, podem surgir mudanças imprevisíveis como o easter egg “after midnight” do man-db
    Também há muitas dependências, e quase ninguém realmente faz auditoria do código
  • Também apareceu a piada: “vamos fazer teste A/B no kernel Linux”
  • Teste A/B nem sempre é para melhorar o usuário
    Pode ser um experimento de monetização (enshittification) — o YouTube é um exemplo representativo

• Não há problema com testes A/B em si, mas plan mode não é grande coisa
  Na maioria dos casos o resultado é ruim
  Ainda assim, a capacidade de retenção de informação entre compactions é boa
  Se você registrar a conversa em um arquivo Markdown e fizer referência a isso a cada compaction, consegue resultados muito melhores

  • Minha experiência é exatamente o oposto
    O plan mode é muito mais eficiente, então eu o uso antes de quase todo trabalho
    A vantagem é poder revisar e discutir o plano antes de o modelo executar
  • Já bati no limite de compaction algumas vezes e, desde então, tento evitar isso
    Atualmente, o plan mode reinicializa o contexto ao concluir, o que é bom para montar o próximo plano de forma limpa

• É uma pena que os detalhes da decompilação tenham sido removidos do blog por causa dos ToS
  Dizem que o Claude seguia uma instrução de sistema para “limitar o plano a 40 linhas, proibir seções de contexto e remover a prosa”
  Seria bom poder ver e ajustar esse tipo de configuração diretamente

• Ferramentas profissionais deveriam oferecer confiabilidade e reprodutibilidade, mas LLMs não fazem isso
  O teste A/B é apenas uma prova disso

  • O cerne do problema não é o LLM, e sim o app mudar o comportamento em segredo
    Experimentos como o Photoshop alterar levemente o tom das cores, ou o Word mudar o estilo dos títulos, seriam o mesmo problema
    O problema é o teste A/B sem aviso
  • A Anthropic sofre com uma séria falta de transparência
    O limite de quota e a qualidade do modelo são instáveis, e antes do lançamento de novos modelos há períodos em que o modelo anterior piora
    Este experimento também parece mais um teste de redução de custos do que uma melhoria da experiência do usuário
    Se é uma ferramenta para negócios, ela precisa de consistência e confiabilidade
  • Ferramentas com atualização automática mudam de comportamento por natureza
    Um profissional precisa entender os pontos fortes e fracos da ferramenta e usá-la adequadamente
    Aceitar cegamente a saída de LLMs é antiprofissional, mas isso não significa que profissionais não possam usar LLMs
  • Reprodutibilidade é um espectro
    Com avaliação suficiente e controle de prompt, dá para torná-las razoavelmente determinísticas
    Vendo que até modelos instáveis do setor financeiro continuam em operação, imprevisibilidade não é uma barreira absoluta
  • Se a saída de um LLM fosse completamente determinística, o que eu faria de diferente?
    Eu verifico a saída do modelo como faria em um code review de um colega

• Situações assim já são chamadas de vendor lock-in há muito tempo
  Quando você depende de uma ferramenta específica, deixa de conseguir trabalhar se ela mudar ou desaparecer

• Eu migrei do CC para o opencode
  O CC era fechado e tinha prompts excessivamente opinionated, o que me incomodava
  Também não dava para controlar o caminho da busca na web
  Agora escolhi open source porque uso só como hobby, mas se fosse para trabalho eu talvez decidisse diferente

  • Eu também testei o opencode, mas a versão padrão é muito mais fraca que o CC
    Só consegui usar em projetos pequenos
    Se você tiver uma configuração boa, gostaria que compartilhasse