Correção É a Metade Fácil: Duas Medidas Computáveis da Outra Metade

Verbosidade: 0,15 mais ou menos 0,06 em repositórios estabelecidos, 0,33 mais ou menos 0,10 em código gerado por agente. Erosão: 0,31 mais ou menos 0,17 contra 0,68 mais ou menos 0,20. Esses quatro números vêm do SlopCodeBench, e o texto que publicou as duas fórmulas por trás deles resume a comparação em uma linha: o código do agente é, em média, mais ou menos duas vezes mais verboso e mais erodido que o código humano.

As fórmulas importam mais que os números. As duas são computáveis ainda hoje com ferramentas de prateleira, e as duas produzem uma única razão por repositório, que é exatamente o formato que um gate de CI consegue consumir.

A metade que ninguém calcula

Fazer um modelo gerar código e deixar testes ocultos verificarem o resultado é direto. O autor de Measuring code sloppiness descreve o problema da outra metade sem rodeios: verificar a sujeira desse código “em geral exige intuição humana e tempo, e é uma tarefa extremamente difícil”.

A formulação dele sobre o que a corretude deixa de fora: “O fato de o código estar formalmente correto não significa que ele deixe de introduzir abstrações desnecessárias, criar duplicatas ou simplesmente tomar decisões ruins no geral.”

Já reportamos o benchmark da Sonar com 53 modelos e já entregamos uma taxonomia qualitativa de como agentes degradam uma base de código. Nenhum dos dois trazia uma fórmula que o leitor pudesse rodar. Estas duas trazem.

Fórmula um: Verbosidade

Verbosidade = |linhas_marcadas ∪ linhas_clonadas| / LOC

linhas_marcadas é o conjunto de linhas capturadas por regras do AST-Grep. linhas_clonadas é o conjunto que um detector de clones aponta como duplicado. Use a união. Uma linha duplicada e marcada ao mesmo tempo conta apenas uma vez, onde uma soma a contaria duas. Divida pelo total de linhas de código.

A métrica captura duplicação e verbosidade desnecessária em uma razão só. A ferramenta é de prateleira: AST-Grep mais um detector de clones. Sem modelo no circuito, sem juízo humano na medição, sem custo por revisão que cresça junto com o volume.

Fórmula dois: Erosão

A Erosão mede a degradação estrutural rumo a funções grandes e emaranhadas. Ela começa atribuindo uma massa a cada função:

massa(f) = CC(f) * raiz(SLOC(f))

CC(f) é a complexidade ciclomática da função. SLOC(f) são suas linhas de código. A raiz quadrada amortece o termo de tamanho para que a complexidade pese mais que o comprimento bruto. Veja o efeito em um par inventado: uma função de 200 linhas de atribuições em sequência é um bicho diferente de uma função de 60 linhas com catorze desvios.

Em seguida:

Erosão = soma de massa(f) para todo f com CC(f) > 10
         --------------------------------------------
         soma de massa(f) para todo f

O resultado é a fração da massa estrutural da base de código que vive dentro de funções acima do limiar de complexidade. O limiar, CC > 10, é o parâmetro copiável. É o único número do par que um time pode defender ou alterar com um argumento.

As duas fórmulas compartilham uma escolha de projeto que vale registrar: elas normalizam. Um repositório que triplica de tamanho não triplica automaticamente a própria pontuação. É isso que as torna usáveis como linha de tendência ao longo de meses.

O que os valores de referência dizem e o que não dizem

O SlopCodeBench é trabalho de terceiros, citado pelo texto que fornece as fórmulas. O crédito corre em duas direções: o benchmark para o artigo, as duas medidas para o texto.

Métrica	Repositórios estabelecidos	Gerado por agente
Verbosidade	0,15 mais ou menos 0,06	0,33 mais ou menos 0,10
Erosão	0,31 mais ou menos 0,17	0,68 mais ou menos 0,20

Carregue as margens toda vez que citar esses valores. “0,33” sozinho é uma afirmação diferente de “0,33 mais ou menos 0,10”, e as faixas da Erosão em particular são largas o bastante para que um repositório isolado perto de uma fronteira informe muito pouco. A razão de aproximadamente duas vezes é aritmética sobre as médias, e a fonte já a enuncia; ela não acrescenta evidência nova.

Esses valores servem como ponto de calibração para a sua própria linha de base. Eles não servem como limiar. Nada na fonte recomenda um valor a partir do qual um build deveria falhar, e inventar um seria exatamente o tipo de precisão que o dado não sustenta. Meça primeiro os seus repositórios, ao longo de alguns meses de histórico, e defina o gate a partir do que você vê.

O lugar onde essas fórmulas se encaixam

Rachel Laycock, CTO da Thoughtworks, publicou no mesmo mês o argumento dela contra revisar todo esse código. A descrição do gargalo: “Se um agente consegue produzir dez vezes mais código, mas cada linha acaba numa fila esperando um engenheiro sênior inspecionar, não criamos uma organização de engenharia dez vezes maior, criamos um backlog grande e um gargalo novo.”

A substituição que ela propõe para a revisão humana é “codificar as restrições importantes como fitness functions”. Ela também nomeia o antipadrão escondido na alternativa: “um agente de IA fingindo ser o revisor humano para que a gente preserve exatamente o mesmo processo em velocidade maior. Isso é automatizar a cerimônia em vez de questionar por que a cerimônia existe.”

Já defendemos a posição de revisão por exceção e não vamos reabrir o debate. Verbosidade e Erosão são candidatas a fitness function para a vaga que aquele argumento deixou em aberto. Elas convivem com o resto da pilha de práticas de Laycock: pair programming, trunk-based development, testes automatizados, análise estática, varredura de segurança.

Laycock mantém também uma lista de gatilhos para o que ainda chega a um humano: uma mudança arquitetural fundamental, algo que cruza uma fronteira sensível de segurança, uma mudança com raio de impacto enorme, uma parte desconhecida de um sistema crítico, ou “simplesmente algo em que o time diz: não estou confiante sobre isso”. Nenhuma das duas fórmulas toca em qualquer um desses casos. Elas medem forma, e intenção fica fora do alcance delas.

Ela concede o contra-argumento mais forte, vindo de Brian Houck, da DX: times acumulam “dívida cognitiva e de intenção: o software cresce enquanto os humanos responsáveis por ele entendem cada vez menos sobre por que ele funciona do jeito que funciona”. Laycock concorda que a dívida é real e discorda apenas de que pull requests obrigatórios protejam contra ela. Um número de Erosão em alta é um dos poucos sinais que tornam parte dessa dívida visível antes que as pessoas capazes de explicá-la vão embora.

O aviso de Goodhart vem junto com a métrica

O autor cita a Lei de Goodhart explicitamente e é direto ao dizer que o julgamento final ainda precisa de um humano. Essa ressalva é a coisa mais confiável do par.

A forma óbvia de burlar a Verbosidade é remover linhas duplicadas e manter as mesmas decisões ruins, rearranjadas. A forma óbvia de burlar a Erosão é repartir a complexidade em mais funções e realocar o emaranhado para o grafo de chamadas. As métricas são instrumentos para perceber, e o que percebem é o que merece a atenção do humano. Elas não substituem essa atenção, e a fonte não afirma que substituam. Nenhuma adoção em produção de qualquer uma das duas medidas está documentada.

Já defendemos impor valores, e não disciplinas, aos agentes. Uma métrica é uma disciplina. O valor que ela serve é que a base de código continue compreensível para quem responde por ela, e a métrica só é útil enquanto acompanha esse valor.

Faça isso agora

Rode as duas fórmulas sobre os últimos seis meses de histórico, um ponto por semana, em um repositório onde agentes escrevem uma fatia relevante do código. É uma tarde de trabalho: AST-Grep, um detector de clones, uma ferramenta de complexidade e um script que percorre o git log.

Você está procurando uma inclinação. A nota de uma semana isolada não diz nada. Linha plana significa que suas práticas atuais estão segurando. Erosão subindo com Verbosidade plana significa que a complexidade está se concentrando enquanto a duplicação segue controlada, o que aponta para revisão de design em vez de faxina. As duas subindo significam que o processo de revisão parou de capturar estrutura.

Defina o seu gate a partir da inclinação que você mediu. Os valores de referência ficam fora dessa conta. O benchmark conta como um repositório saudável e um repositório pesado em agentes se pareciam na amostra de outra pessoa. A sua própria linha de base é o único número em que o seu build deveria falhar.

Fontes

Sebastian (earendil.com). “Measuring code sloppiness.” Setembro de 2026.
arXiv 2603.24755. “SlopCodeBench.” 2026.
Rachel Laycock, Thoughtworks. “Maybe we shouldn’t be reviewing all this code.” Setembro de 2026.

A Victorino ajuda organizações de engenharia a construir fitness functions e gates de qualidade para código escrito por agentes: contato@victorino.com.br | www.victorino.com.br