Resolver A Issue Não Basta: O Que O Parsimony Mede Sobre Quanto Código Um Agente Adiciona

Todo tech lead conhece a sensação de abrir um pull request em que a correção funciona e, ainda assim, o diff parece grande demais. Os testes passam, o comportamento está certo, a issue pode ser fechada. Mesmo assim, algo nas quatrocentas linhas adicionadas para consertar um bug que, na sua cabeça, pedia umas quinze, faz você pausar antes de aprovar. É uma observação genérica, que qualquer pessoa que revisa código com frequência já teve, e não o relato de um caso específico. Mas ela captura uma pergunta que a maioria dos rankings de agentes de código simplesmente não faz.

Essa pergunta voltou à minha cabeça ao ler a página do Parsimony, um projeto pequeno e novo que apareceu como Show HN. A tese vem na própria página: os benchmarks existentes medem taxa de resolução e custo, mas não punem código em excesso. Em outras palavras, um agente que resolve a tarefa com doze unidades de código e outro que resolve a mesma tarefa com cento e vinte recebem exatamente a mesma nota, e na hora de escolher ferramenta, quase todo mundo olha só essa nota.

Preciso ser claro sobre o que li e o que não li. Li o texto da página do Parsimony e dois digests de Hacker News que o mencionam. Não consegui ler os gráficos nem o ranking, porque dependem de JavaScript, e por isso não vou citar nenhum resultado por modelo. Também não rodei a ferramenta, não medi o código do meu time e não tenho dado próprio. Este é um post de opinião sobre uma ideia de medição, escrito a partir da leitura do método e das limitações que o próprio autor assume.

Vou percorrer o que a taxa de resolução esconde, como o Parsimony conta, o que a página admite que a métrica não resolve, a minha posição sobre como usá-la, o melhor contra-argumento que consigo montar e, por fim, como um time poderia olhar para isso nos próprios PRs gerados por agente, tratando essa parte como hipótese.

O Que A Taxa De Resolução Esconde

Taxa de resolução é uma métrica binária por tarefa: os testes que deveriam passar passam, ou não passam. Isso é útil e honesto naquilo que mede. Mas binário significa que toda solução correta vale o mesmo, e é aí que mora o ponto cego. Um patch cirúrgico e um patch que reescreve três funções vizinhas "por garantia" contam como um acerto cada. Quem lê o ranking não tem como saber qual dos dois está por trás da nota.

Para quem avalia ferramentas, isso importa porque o custo de um acerto não termina quando o teste fica verde. Código adicionado precisa ser lido na revisão, entendido por quem mexer ali depois, coberto por teste e mantido quando o contexto ao redor mudar. Já escrevi sobre como a dívida técnica do código gerado se acumula sem barulho, e o mecanismo é parecido: cada linha a mais é um pequeno compromisso futuro, e o compromisso existe mesmo quando a linha está correta.

Há também o lado da revisão, que é onde a conta chega primeiro. Quando discuti o que acontece com o código gerado por IA na hora do code review, a tensão central era que gerar ficou barato e revisar não. Um agente que entrega diffs maiores para o mesmo problema transfere trabalho para o revisor humano, e essa transferência não aparece em nenhuma coluna de leaderboard. O mesmo vale para o raciocínio que fiz em avaliar agentes com evals que representem o seu trabalho: uma métrica única comprime várias dimensões em uma e esconde justamente as que o seu time vai sentir.

Existe ainda um problema de incentivo, e nele eu seria cuidadoso para não exagerar. Não tenho evidência de que algum laboratório treine para inflar patches, e a página do Parsimony também não afirma isso. O que dá para dizer é mais simples: se a única coisa que o ranking recompensa é passar nos testes, nada no ranking recompensa a economia. Quem não é medido por uma coisa tende a não otimizá-la, mesmo sem má intenção de ninguém.

Como O Parsimony Conta

O método, pelo que a página descreve, é deliberadamente simples. O projeto pega patches que benchmarks existentes já publicam e os aplica ao código da tarefa. Em seguida faz o parse das duas versões de cada arquivo alterado, a anterior e a posterior ao patch, e conta o que chama de unidades de código. Essas unidades são chamadas, nomes e literais, e não linhas. A diferença entre linhas e unidades é a parte mais interessante do desenho, e vale um parágrafo próprio.

Contar linhas é frágil porque formatação muda o número sem mudar o programa. Uma chamada de função quebrada em cinco linhas por causa de um formatador vale cinco, e a mesma chamada em uma linha vale um. Ao contar nós sintáticos, o Parsimony fica mais próximo do tamanho do que o código diz do que do tamanho de como ele foi diagramado. O número final de uma tarefa são as unidades líquidas, ou seja, as adicionadas menos as removidas, o que significa que um patch que troca uma implementação longa por uma curta pode ter valor negativo.

Um exemplo ilustrativo, só para fixar a conta e que não vem de nenhum resultado real. Imagine que um patch adiciona uma função com duas chamadas, três nomes e um literal, e remove uma chamada antiga e dois nomes. Seriam seis unidades adicionadas e três removidas, ou três unidades líquidas. Se outro patch resolve a mesma tarefa adicionando quinze e removendo uma, o saldo seria catorze. Os dois passam no teste, mas a diferença entre três e catorze é o que a métrica tenta tornar visível.

O que o Parsimony deliberadamente não faz é tão importante quanto o que faz. Nada é executado: o projeto não reroda testes e não reverifica correção. O status de resolvido vem dos resultados publicados do SWE-bench, e a página cita o SWE-bench Verified para isso, além de mencionar tarefas Python do DeepSWE na descrição de um gráfico, sem listar as tarefas em detalhe. Testes, documentação e arquivos gerados ficam fora da contagem, e só Python é medido. É uma escolha coerente com um projeto pequeno: aproveitar dados que já existem, em vez de construir uma infraestrutura nova de execução.

Dessas escolhas saem as métricas. A página reporta a média de unidades líquidas adicionadas em todas as tentativas, inclusive as que falharam, e a média nas tarefas resolvidas. Reporta também a contagem de resolvidas e a de medidas, que são as tentativas resolvidas que puderam ser medidas. O ranking ordena pela média de unidades líquidas adicionadas nas tarefas resolvidas, da menor para a maior. Repare no recorte: só se compara o tamanho do que foi entregue quando a tarefa foi de fato resolvida, o que evita premiar quem não fez nada.

O Que A Própria Página Admite Que Não Resolve

O que mais me fez levar o projeto a sério foi a lista de limitações, que a página assume sem que ninguém precise cavar. A primeira é a mais importante: unidades medem tamanho, não legibilidade nem design, e menor nem sempre é melhor. Um patch pequeno pode ser enigmático, acoplado a um detalhe interno ou espertinho demais, e ainda assim pontuar bem. A métrica enxerga volume, não clareza.

A segunda limitação é quase um paradoxo, e a página também a declara: um modelo cujos patches mais apagam código pode ficar em primeiro lugar, com valor líquido negativo. Se o ranking ordena da menor média para a maior, apagar muito é o caminho mais curto para o topo. Isso significa que a métrica, lida sem cuidado, poderia premiar um modelo que remove código útil, desde que os testes publicados continuem passando. E testes publicados raramente cobrem tudo o que o código apagado fazia.

A terceira é um efeito estatístico menos óbvio. Tentativas que falham sem mudar nada puxam a média calculada sobre todas as medidas para perto de zero. Faz sentido: um patch vazio tem custo zero em unidades, então um modelo que desiste com frequência parece enxuto. É por isso que a média em tarefas resolvidas é a métrica do ranking, e é por isso que eu desconfiaria de qualquer leitura que use só a média geral para comparar modelos.

A quarta limitação é a que mais pesa contra a tese do post, e vou tratá-la na seção do contra-argumento: a página reporta que modelos que escrevem mais código tendem a resolver mais tarefas, com correlação de Spearman entre 0,33 e 0,60 em quadros com 26 ou mais modelos. A quinta é que todos os modelos rodam sobre o mesmo agente, o mini-SWE-agent, o que ainda influencia quanto código é escrito. Ou seja, o número mede modelo mais harness, e não o modelo isolado, o que também vale para o ranking de resolução.

Minha Posição: Ao Lado Da Taxa, Nunca Como Nota Única

Aqui entra a opinião, e na minha leitura ela tem duas metades que precisam ficar juntas. A primeira: eu gostaria de ver uma medida de quanto código o agente adiciona ao lado da taxa de resolução toda vez que alguém compara agentes para adotar num time. Não porque o tamanho seja uma verdade absoluta, mas porque é uma dimensão do custo que hoje simplesmente não aparece. Quando escrevi sobre o que o SWE-bench Pro mede e não mede, o argumento era que um número só carrega mais certeza do que merece. Adicionar uma segunda coluna não resolve isso, mas ao menos desfaz a ilusão de que existe uma coluna só.

A segunda metade é o que me impede de transformar o Parsimony em juiz: eu não o trataria como nota única, e a página tampouco sugere isso. Pegue o caso que ela mesma descreve, o do modelo que apaga código e lidera. Se eu escolhesse ferramenta olhando só o ranking de unidades, estaria otimizando para algo que o próprio autor classifica como imperfeito. Um número que mede tamanho não pode virar meta, porque meta vira alvo, e alvo distorce o comportamento de quem é medido. Isso vale para o modelo, que poderia ser ajustado para apagar mais, e vale para o time, que poderia começar a cobrar diffs pequenos por si só.

O que eu defenderia, então, é o uso como sinal de triagem, e não como veredito. Um agente que resolve com muito mais código do que os pares em tarefas parecidas merece uma olhada em amostras reais dos diffs dele. Um agente que lidera em enxugamento merece a mesma olhada, com a pergunta oposta: o que ele está removendo, e alguém notaria se estivesse errado? Nos dois casos o número serve para apontar onde olhar, e a decisão continua exigindo leitura de código por gente.

Há um motivo adicional, de natureza organizacional, pelo qual eu gostaria desse segundo eixo. Quem decide a compra de uma ferramenta de código raramente é quem vai revisar os PRs dela todos os dias. A taxa de resolução fala com quem compra; o tamanho do diff fala com quem revisa. Colocar as duas no mesmo quadro aproxima duas conversas que hoje correm separadas, e essa aproximação, por si só, já me parece valiosa, mesmo que o número exato do Parsimony seja discutível.

O Melhor Contra-Argumento

O contra-argumento mais forte vem da própria página, e eu seria desonesto se o deixasse de lado. Se modelos que escrevem mais código tendem a resolver mais tarefas, então talvez o volume não seja ruído, e sim parte do mecanismo pelo qual o acerto acontece. Escrever mais pode significar tratar mais casos de borda, validar mais entradas, cobrir mais caminhos. A correlação de Spearman de 0,33 a 0,60 não é perfeita e não prova causa, mas é suficiente para dizer que punir tamanho ingenuamente poderia punir também competência.

Um segundo ponto, mais pragmático, é que nem todo código adicionado é custo. Uma validação que evita um incidente em produção é código que se paga. Uma refatoração que adiciona abstração hoje pode remover duplicação em três lugares amanhã. A métrica de unidades líquidas, por construção, não distingue código que se paga de código que pesa; ela só vê saldo. Quem defende o agente prolixo pode argumentar que o Parsimony mede o sintoma errado.

O terceiro contra-argumento é empírico e vem de fora do Parsimony. A pesquisa que a Anthropic publicou em 16 de outubro sobre emprego dentro da empresa relata que os commits por engenheiro estão em torno de cinco vezes o nível de seis meses antes. Os autores ressalvam que mais código não significa necessariamente mais impacto, nem código melhor. O dado mais relevante para o meu argumento é outro: usando proxies como linhas apagadas em 90 dias, reverts e supressões de lint, a Anthropic relatou diferença não mensurável entre o código escrito por agente e o escrito por humano. É a evidência da própria empresa que, nessas proxies, não mostrou piora.

Como pesar isso? Primeiro, é a avaliação de uma empresa sobre o próprio código, com proxies que ela escolheu, e proxies capturam o que capturam. Linhas apagadas, reverts e supressões de lint medem churn e atrito visível, não clareza de design nem custo de leitura. Segundo, a ausência de diferença mensurável nessas medidas não equivale à ausência de custo nas outras dimensões. Terceiro, e aqui sou honesto: o dado enfraquece a versão forte da minha tese. Se o código de agente não apresenta mais desfazimento do que o humano, a urgência de policiar tamanho diminui. Ainda defendo olhar o eixo, mas com menos alarme do que eu teria sem essa ressalva.

Resumindo o placar de forma justa, a favor da tese há um custo de revisão e manutenção que o ranking ignora e um mecanismo plausível de acúmulo. Contra ela há uma correlação entre volume e acerto, a possibilidade de que código maior seja código que se paga e uma medição interna que não achou piora. Não considero nenhum dos lados vencedor com os dados disponíveis em outubro de 2026.

Como Um Time Poderia Olhar Isso Nos Próprios PRs

Esta seção é hipótese, não relato: não testei isso e não sei o que um time encontraria. Mas a ideia do Parsimony é portátil, e o ponto de partida mais barato dispensa qualquer benchmark. Imagine um time que usa um agente de código há alguns meses e marca, no repositório, os PRs abertos por ele. Para cada um, registra o tamanho do diff em código de produção, excluindo testes, documentação e arquivos gerados, as mesmas exclusões que o Parsimony faz, e a categoria da tarefa: correção de bug, ajuste pequeno, funcionalidade nova.

O recorte por tipo de tarefa é o que daria sentido ao número. Comparar o diff de um bug de uma linha com o de uma funcionalidade nova não diz nada; comparar bugs parecidos entre si, ou o mesmo agente em tarefas parecidas ao longo do tempo, pode dizer. Um cenário comum seria o time descobrir que o tamanho mediano do diff para correções simples é maior no agente do que nos PRs humanos equivalentes. Seria um indício, e não uma prova, e a pergunta seguinte seria ler uma amostra desses diffs para entender se o excesso é tratamento de erro útil ou duplicação.

A segunda camada seria cruzar tamanho com o que acontece depois. Quanto tempo de revisão aquele PR consumiu? Quantos comentários? Foi alterado de novo nas semanas seguintes? Essas perguntas se aproximam do que a Anthropic usou como proxy, como reverts e retrabalho, e dão ao time um jeito de testar localmente se tamanho importa no seu contexto. Se não houver correlação com revisão e retrabalho, o eixo pode ser descartado sem culpa; essa é uma conclusão legítima e, como acabo de argumentar, bastante possível.

Dois cuidados antes de transformar isso em prática. Não usar o número para avaliar pessoas nem como meta de agente, pelo mesmo motivo de antes: meta distorce. E lembrar que o custo de triar o que a IA produz já é uma dor conhecida, como mostrei ao falar de revisão com LLM e a triagem de defeitos num grande projeto de código aberto. Adicionar mais um indicador só se justifica se ele reduzir o esforço de olhar, e não se virar mais uma tarefa de acompanhamento.

Conclusão

O que me convenceu no Parsimony não foi um resultado, porque nem consegui ler os resultados, e sim a pergunta. Resolver a issue é condição necessária, e acho difícil defender que seja suficiente. Quanto código entra no repositório para resolvê-la é uma parte real do custo, que hoje cai fora de quase todo comparativo. Que um projeto pequeno tenha decidido medir isso com um método simples e com as limitações declaradas já me parece uma contribuição, ainda que o projeto seja novo e tenha pouca tração: um Show HN com algumas dezenas de pontos não é adoção.

Ao mesmo tempo, desconfio de qualquer pressa em transformar a ideia em critério de compra. A própria página lembra que menor nem sempre é melhor, que apagar código pode levar ao topo e que modelos mais prolixos tendem a acertar mais. A pesquisa da Anthropic sobre o próprio código, com as proxies que escolheu, não achou piora. Se eu fosse montar um quadro de decisão hoje, usaria o tamanho como sinal para abrir amostras de diff, e nunca como substituto da leitura.

Fico com uma dúvida que não sei fechar: existe um nível de código adicionado que seja bom para o acerto e ruim para a manutenção, ou os dois efeitos andam juntos de um jeito que nenhuma métrica separa? Não tenho essa resposta, e suspeito que só dados de times reais, acompanhados por tempo suficiente, vão dar. Até lá, vale ao menos fazer a pergunta na revisão do próximo PR gerado por agente: isso precisava ser tão grande?

Fontes:

Resolver A Issue Não Basta: O Que O Parsimony Mede Sobre Quanto Código Um Agente Adiciona

Resolver A Issue Não Basta: O Que O Parsimony Mede Sobre Quanto Código Um Agente Adiciona

O Que A Taxa De Resolução Esconde

Como O Parsimony Conta

O Que A Própria Página Admite Que Não Resolve

Minha Posição: Ao Lado Da Taxa, Nunca Como Nota Única

O Melhor Contra-Argumento

Como Um Time Poderia Olhar Isso Nos Próprios PRs

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose