Supõe-se que os assistentes de codificação de IA reduzam o trabalho necessário para transformar a intenção do desenvolvedor em um software funcional. Mas alguns usuários dos modelos Opus 4.8 e Opus 5 da Anthropic dizem que estão tendo que gastar mais tempo, avisos e tokens corrigindo a linguagem dos modelos, às vezes até roteando sua saída através de modelos de IA mais baratos para torná-los utilizáveis.
Em uma edição detalhada do GitHub, Peter Bower, fundador e CEO da startup de tecnologia SpaceCell, com sede em Londres, disse que a tendência do Opus 4.8 de usar terminologia confusa ou inventada estava criando trabalho extra nos fluxos de trabalho de desenvolvimento de software, especialmente ao gerar documentação de código.
Isso ocorreu apesar de ter sido explícita e repetidamente solicitado a evitar certos termos e usar alternativas específicas, escreveu Bower, acrescentando que o modelo continuou a introduzir os termos indesejados, forçando repetidas passagens de limpeza, inclusive por meio de modelos Sonnet ou Haiku mais baratos, para tornar a documentação “sã e apresentável”.
Esses passes adicionais, disse ele ainda, estavam aumentando os custos dos tokens em até duas vezes mais do que seriam de outra forma.
A edição de Bower, publicada no mês passado, recebeu desde então quase 265 reconhecimentos, o que pode indicar que vários outros usuários enfrentaram problemas com a coerência de linguagem do Opus 4.8 de uma forma ou de outra.
Alguns até comentaram ter enfrentado um problema semelhante. O próprio Bower também faz referência a um subreddit de ClaudeAI em sua edição, que aponta para a incoerência de linguagem do Opus 4.8. Isso também recebeu um número significativo de votos positivos, que são o equivalente do Reddit a um sinal de positivo que é frequentemente usado nas redes sociais para indicar aprovação ou apoio a uma postagem ou comentário.
Outro tópico do subreddit aponta para um problema semelhante com o Opus 5, com usuários relatando a tendência do modelo de produzir resultados confusos e difíceis de analisar, e recebeu quase o dobro de votos positivos.
Por que resultados pouco claros de IA podem retardar o desenvolvimento de software
Para as equipes de desenvolvimento empresarial, a natureza persistente do problema relatado com os modelos Opus pode resultar em um impacto significativo na produtividade, dizem os analistas.
“Ciclos de correção repetidos podem prejudicar a produtividade quando os desenvolvedores gastam tempo suficiente revisando, redirecionando e reparando a saída de IA. Isso compensa o tempo economizado na geração de código por meio de um assistente de codificação ou qualquer outra tarefa”, disse Abhishek Satapathy, analista principal da Avasant.
Essa erosão na produtividade, de acordo com Advait Patel, engenheiro sênior de confiabilidade de site (SRE) da Broadcom, também está ligada aos aspectos operacionais do ciclo de vida de desenvolvimento de software (SDLC), já que uma prosa pouco clara gerada por IA pode afetar a documentação de projeto, runbooks, registros de decisão de arquitetura (ADRs) e registros de incidentes.
“Um runbook escrito em um estilo que os engenheiros consideram difícil ou desagradável de ler, por exemplo, pode se tornar um problema durante um incidente, quando as equipes precisam compreender e agir rapidamente com base nas informações que têm à sua frente”, disse Patel.
A revisão do código, acrescentou Patel, apresenta outro problema potencial devido à prosa pouco clara: “Descrições de solicitações pull excessivamente preenchidas ou confusas provavelmente serão examinadas em vez de revisadas cuidadosamente, aumentando o risco de detalhes importantes ou defeitos potenciais serem perdidos”.
Resultados pouco claros podem ter repercussões nos custos
As implicações da prosa pouco clara estendem-se também aos custos.
Isso ocorre porque o preço que as empresas pagam por uma ferramenta de codificação de IA não reflete necessariamente o custo de obter resultados utilizáveis, disse Bhupendra Chopra, diretor de receitas da empresa de consultoria de TI Kanerika.
Se os desenvolvedores tiverem que fazer passagens repetidas para corrigir, reescrever ou revisar uma resposta, ou encaminhá-la por meio de outro modelo, essas etapas adicionais se tornarão parte do custo geral de conclusão da tarefa, incluindo o tempo de revisão humana, acrescentou Chopra.
E a maioria das empresas, de acordo com Patel, muitas vezes não realiza esse cálculo porque tudo isso “está agrupado em um único item de linha” na conta do agente de codificação.
Esse custo oculto também pode ter implicações na capacidade da Anthropic de reter desenvolvedores.
“A troca de assistentes de codificação ou modelos subjacentes tornou-se relativamente fácil para as equipes de desenvolvimento, especialmente porque as plataformas de codificação suportam cada vez mais modelos de vários provedores, embora as empresas provavelmente encontrem custos irrecuperáveis na configuração, nos ganchos e na configuração do MCP. Mas o código não se move, os repositórios não se movem e, portanto, nenhum plano de migração é necessário”, disse Patel.
“Esse é um risco comercial genuíno para qualquer fornecedor de modelo. O baixo custo de troca significa que a boa vontade é sua única garantia, e as reclamações sobre legibilidade corroem a boa vontade rapidamente porque as pessoas as atacam diariamente”, observou Patel.
Soluções alternativas imediatas podem não ser suficientes
No entanto, a Anthropic ainda não respondeu ao problema do GitHub de Bower, que também descreve as mudanças que ele acredita que a empresa deveria fazer para resolver o problema.
O fundador da startup pediu que a Anthropic ajustasse o estilo de escrita padrão do modelo para ficar mais próximo de “um white paper técnico ou uma boa resposta Stack Overflow”, que é “simples, declarativo e direto”.
Ele também pediu que o modelo fosse menos detalhado e ao mesmo tempo seguisse fortemente as instruções definidas em CLAUDE.md e repetidas durante uma conversa, argumentando que essas instruções deveriam persistir em vez de serem gradualmente substituídas pelo estilo de comunicação padrão do modelo.
Enquanto isso, Patel, que disse ter enfrentado desvios de modelo semelhantes no trabalho, especialmente ao trabalhar com repositórios envolvendo pilhas Jenkins, Python, Terraform, GKE e Helm, apontou para uma correção que ele e sua equipe usam ao gerar documentação e resumos de pull request.
Em vez de pedir que Claude seja conciso, sua equipe usa regras explícitas na configuração do projeto para proibir frases específicas, porque pedir concisão às vezes pode tornar o resultado mais curto, porém mais enigmático, disse Patel.
No entanto, Patel alertou que confiar simplesmente em soluções alternativas imediatas pode não ser suficiente para as empresas porque o comportamento do modelo pode mudar com o tempo.
“O comportamento do modelo é um alvo móvel”, disse Patel. “Um aumento de versão pode alterar o registro de saída sem que você implante nada e nada em seu pipeline alerta sobre isso.”
Isso significa que os CIOs e os líderes de engenharia devem tratar as mudanças no comportamento do modelo como algo que precisa ser testado e monitorado continuamente.
“Fixar versões de modelo para qualquer coisa em um pipeline em vez de rastrear as mais recentes. Mantenha um pequeno conjunto de avaliação de suas próprias tarefas reais e execute-o novamente a cada mudança de modelo. Rastreie a rejeição e a taxa de retrabalho, esse é o seu aviso prévio. E não deixe que trinta equipes inventem, cada uma, suas próprias soluções alternativas não documentadas”, aconselhou Patel.
