Os 80% da Anthropic São Spec de Compra Para Questionar, Não Meta a Perseguir

A Anthropic reporta que mais de 80% do código integrado à sua base de produção em maio de 2026 foi de autoria do Claude. Os engenheiros de lá agora entregam 8x mais código por trimestre do que a própria média da empresa entre 2021 e 2025. O número é limpo, grande e citável. Também é a coisa errada para copiar.

Esses dados são internos e autorreportados. Vêm da Anthropic medindo a Anthropic, retransmitidos pela VentureBeat. Isso não é uma crítica à empresa. É a condição de partida para qualquer organização que lê a manchete e se pergunta se está ficando para trás. Antes de tratar 80% como meta, trate como spec de compra: uma alegação com unidades ocultas que você tem o direito de questionar.

O Que “Autoria do Claude” Não Diz

Leia a alegação ao pé da letra. “Mais de 80% do código integrado foi de autoria do Claude.” Ela define um numerador (código que o Claude escreveu) sobre um denominador (código integrado), em um único mês, no repositório de uma empresa. O que nunca define é a unidade de autoria.

“Autoria” significa linhas commitadas literalmente de uma sessão do Claude? Linhas que um humano aceitou após editar? Linhas em um pull request que o Claude abriu mas um humano reescreveu? Um arquivo onde o Claude escreveu o esqueleto e um humano escreveu a lógica que importava? Cada uma dessas opções produz uma porcentagem radicalmente diferente a partir do mesmo trabalho. A manchete escolhe uma e mostra o resultado, não a regra.

Essa é a primeira coisa a notar em toda estatística de autoria de IA: a porcentagem vem depois de uma decisão de atribuição que ninguém publicou. Quando a regra de atribuição é invisível, o número é infalsificável. Você não consegue reproduzir, auditar nem comparar com o seu.

Volume Não É Valor

O número de 8x é explícito sobre o que mede: volume bruto de código por engenheiro por trimestre. A Anthropic afirma isso com todas as letras. É throughput, não valor, não qualidade, não resultado de negócio.

Linhas de código é a métrica desacreditada mais antiga do software. Aprendemos há décadas que mais código costuma ser pior código: mais superfície para manter, mais lugares para defeitos se esconderem, mais carga cognitiva para quem ler depois. Uma equipe que entrega 8x o volume para entregar as mesmas funcionalidades não ficou 8x melhor. Pode ter ficado pior, só que mais rápido.

Então a alegação de throughput, isolada, não diz nada sobre se o Claude tornou o produto da Anthropic melhor. Diz que o Claude produziu mais texto que passou no merge. Se esse texto avançou o roadmap, reduziu defeitos ou serviu clientes é uma pergunta separada que a métrica de volume é estruturalmente incapaz de responder.

Há um sinal real enterrado no relatório, e não são os 80%. Um agente Claude entregou mais de 800 correções para uma única classe de erro de API em abril de 2026, reduzindo aquela taxa de erro em cerca de 1000x. O engenheiro supervisor estimou o equivalente manual em torno de quatro anos-pessoa. Isso é uma alegação de resultado: uma taxa de erro medida, antes e depois, atrelada a um problema definido. É muito mais convincente do que qualquer porcentagem de autoria, justamente porque nomeia o que melhorou em vez de quanto foi escrito.

A Régua Já Quebrou

O benchmark externo que todo mundo usava para dimensionar modelos de código, o SWE-bench, saturou ao longo de uma janela de cerca de dois anos. A Anthropic observa que o Opus 4.6 sustenta tarefas de 12 horas e um modelo Mythos Preview roda por mais de 16 horas. A taxa de sucesso do Claude em problemas de engenharia altamente complexos e mal especificados teria chegado a 76% em maio de 2026, uma alta de 50 pontos em seis meses.

Pare nesse último. Uma “taxa de sucesso” de 76% sem definição publicada de sucesso. Sucesso julgado por quem, contra quais critérios de aceitação, sobre um conjunto de tarefas selecionado como? Quando um benchmark satura, fornecedores migram para medidas internas e sob medida. Essas medidas internas são exatamente as que um comprador externo não consegue validar. A régua que permitia comparar entre fornecedores se foi, e o que a substituiu é uma história que cada fornecedor conta sobre o próprio dever de casa.

Essa é a armadilha. A manchete convida você a se comparar com 80% e 8x. Mas o benchmark que tornava a comparação entre empresas significativa se dissolveu. Você estaria perseguindo um número definido pelas regras não divulgadas de outra pessoa, na base de código de outra pessoa, contra a ideia de sucesso de outra pessoa.

Construa a Spec de Medição Que Você de Fato Controla

A jogada defensável não é igualar os 80%. É especificar, na sua própria casa, o que você vai medir e como. Uma spec de medição é um contrato que você escreve antes da ferramenta, para que os números signifiquem algo quando chegarem. Três compromissos a sustentam.

Defina a atribuição explicitamente. Decida o que conta como autoria de IA e escreva. Uma regra viável: código é de autoria de IA se entra em um commit de sessão de agente e sobrevive à revisão humana com menos de algum limite de linhas editadas. Escolha o limite, publique internamente, aplique de forma consistente. A regra exata importa menos do que o fato de ela existir e ser estável. Sem ela, a sua própria porcentagem é tão inauditável quanto a manchete a que você reage.

Meça resultado, não linhas. Ancore em taxa de defeitos por funcionalidade, taxa de falha de mudança, tempo do merge ao valor para o cliente e itens de roadmap entregues. A história das 800 correções é o modelo: nomeie um problema, meça antes e depois, atribua o delta. Se uma métrica não consegue distinguir 8x mais software funcionando de 8x mais texto, descarte.

Faça do revisor de CI/CD a trilha de auditoria. Essa é a parte que a maioria das equipes esquece. O revisor automatizado da própria Anthropic teria capturado cerca de um terço dos bugs históricos de indisponibilidade do claude.ai. O revisor no seu pipeline já vê toda mudança, quem ou o que a propôs e se ela passou. Instrumente esse revisor para registrar autoria, veredito de revisão e incidentes pós-merge por mudança. Ele vira o único lugar onde autoria de IA e resultado se encontram em um registro que ninguém editou depois. Quando a geração de código acelera, o revisor é o único controle ainda operando na velocidade do merge, o que faz dele a única trilha de auditoria honesta que você tem.

Faça Isto Agora

Uma spec de medição que você consegue defender, antes de citar os 80% de quem quer que seja:

Escreva a regra de atribuição. Uma frase definindo autoria de IA, mais o limite de edição. Publique internamente.
Troque volume por métricas de resultado. Acompanhe taxa de defeitos por funcionalidade, taxa de falha de mudança e tempo do merge ao valor. Aposente painéis de linhas de código.
Instrumente o revisor de CI/CD como sistema de registro. Registre autoria, veredito de revisão e incidentes pós-merge em toda mudança.
Exija definições dos fornecedores. Antes de aceitar qualquer alegação de autoria ou taxa de sucesso, peça a unidade e os critérios de aceitação. Sem definição, sem comparação.
Separe as alegações convincentes das barulhentas. Uma taxa de erro antes e depois sobre um problema nomeado vence qualquer porcentagem agregada. Pondere suas decisões de acordo.

O relatório da Anthropic é genuíno, e o resultado das 800 correções é impressionante nos seus próprios termos. A manchete de 80% não é uma meta que você perdeu. É um convite para escrever a spec de medição que seus concorrentes estão ocupados demais perseguindo o número para escrever.

Fontes

VentureBeat. “Anthropic says 80% of its new production code is now authored by Claude.” Junho de 2026.

A Victorino ajuda empresas a transformar manchetes de produtividade de IA em especificações de medição auditáveis: contato@victorino.com.br | www.victorino.com.br