Claude aumentou os bugs do rsync?

• Lançamentos com auxílio do Claude foram apenas dois, rsync v3.4.2 e v3.4.3, e não há evidência de que tenham tido uma quantidade anormalmente alta de bugs em comparação com lançamentos anteriores com base em bugs ponderados por gravidade/10 commits
• sev/10c é a métrica central, que normaliza a pontuação de gravidade dos bugs em uma escala de 0 a 1, soma por lançamento, divide pelo número de commits e converte para um valor por 10 commits
• v3.4.2 teve 50 commits, 9 commits do Claude, 0 bugs e 0.00 sev/10c; v3.4.3 teve 34 commits, 28 commits do Claude, 17 bugs e 3.29 sev/10c, ficando em lados opostos do IQR, sem que qualquer um dos dois seja outlier
• O teste exato de permutação deu valor p de 46%, o teste exato de Fisher deu valor p de 74% e a razão de chances foi 1.06, indicando quase nenhum sinal de que os lançamentos com Claude sejam piores do que dois lançamentos aleatórios ou mais propensos a ficar acima da mediana
• v3.4.1, embora seja um lançamento anterior à adoção do Claude, já era o pior valor de todo o conjunto de dados, com 59 bugs, 9 commits e 39.39 sev/10c, e o ponto central da controvérsia do rsync é ter ligado uma única regressão ao Claude sem considerar a distribuição histórica

---

Contexto e pergunta

• No fim de maio de 2026, a controvérsia do rsync começou com uma postagem no Mastodon que ligava a regressão da v3.4.3 aos commits do Claude naquele lançamento, espalhando-se depois para o Hacker News e para a issue do GitHub "Please Do Not Vibe Fuck Up This Software", que acumulou mais de 300 comentários
• A tese central repetida era que o desenvolvimento assistido por Claude havia introduzido bugs em uma ferramenta que antes era estável, e a pergunta dos dados é se os lançamentos com auxílio do Claude tiveram quantidade anormal de bugs em relação aos lançamentos históricos
• No Lobsters, houve um pedido para ver um gráfico temporal do número de regressões por lançamento, e o foco da análise é uma única pergunta: “os lançamentos com auxílio do Claude têm bugs em quantidade incomum?”

Escopo dos dados e reprodutibilidade

• Os dados cobrem 36 lançamentos do RsyncProject/rsync, de v2.4.6 até v3.4.3, para os quais há dados de bugs, e apenas dois lançamentos têm commits do Claude: v3.4.2 e v3.4.3
• A escolha de métricas, metodologia e fontes de dados foi feita manualmente por uma pessoa, com orientação de sua esposa, que tem mestrado em estatística
• A coleta de dados, a carga no DuckDB, a criação de views e os scripts de análise estatística foram escritos pelo GLM 5.1, mas todos os números, estatísticas, cartões e gráficos foram inseridos por template automático a partir de um script Python que executou a análise estatística
• O repositório de reprodução alexispurslane/rsync-analysis permite executar todo o pipeline do início ao fim

Métrica e forma de atribuir bugs

• A métrica central é bugs ponderados por gravidade por 10 commits, ou sev/10c, calculada por sev/10c = (Σ severity/100 ÷ total_commits) × 10
• Os commits são ordenados pela data do committer no branch principal, e cada intervalo de lançamento vai da tag anterior até a tag atual, enquanto tags pre e rc são excluídas como fronteiras e absorvidas pelo lançamento final
• As fontes dos bugs são três: issues do GitHub, Bugzilla do rsync e mailing list do rsync; bugs do GitHub e da mailing list são atribuídos ao lançamento mais recente já publicado imediatamente antes do momento do relato
• Itens do Bugzilla são atribuídos ao lançamento indicado no campo “Version”, já que esse campo especifica o lançamento em que o bug foi relatado
• A análise em nível de lançamento foi escolhida porque a crítica em si tem a forma de “os lançamentos inteiros com commits do Claude passaram a ter mais bugs”, e porque a maioria dos bugs não indica exatamente de qual commit se originou

Forma de avaliar a gravidade

• Todos os relatórios de bugs foram pontuados em gravidade de 0 a 100 pelo Qwen 3 35B, usando um prompt que atribuía ao modelo o papel de engenheiro sênior de confiabilidade sob a perspectiva do impacto real para o usuário
• Pontuações de 90 a 100 correspondem a corrupção silenciosa de dados, perda de dados, execução remota de código ou vulnerabilidades de segurança com acesso não autorizado; 70 a 89 correspondem a crash, travamento, falha de backup ou falha de build; 50 a 69 correspondem a regressões funcionais com contorno possível
• Como Bugzilla e mailing list só tinham títulos, sem corpo, o modelo avaliou apenas com base no título, e foi instruído a tender para a faixa intermediária de 40 a 60 quando faltasse informação
• A saída foi restringida a gravidade inteira por meio de um JSON schema com structured output, e a temperatura foi fixada em 0 para que a mesma entrada sempre produzisse a mesma pontuação
• Issues que receberam 0 pontos, como pedidos de funcionalidade, spam, protestos não técnicos sobre IA ou envios vazios, foram excluídas da contagem básica de bugs

Resultados estatísticos dos lançamentos com Claude

• v3.4.2 teve 9 commits do Claude em 50 commits totais, 0 bugs reais, 0.00 sev/10c e ficou no percentil 0 entre os lançamentos
• v3.4.3 teve 28 commits do Claude em 34 commits totais, 17 bugs, 3.29 sev/10c e ficou no percentil 77
• O IQR histórico vai de 0.29 a 2.59 sev/10c; v3.4.2 fica logo abaixo do IQR e v3.4.3 logo acima, de modo que os dois lançamentos enquadram a distribuição intermediária em lados opostos
• O teste exato de permutação mostrou que, entre 595 combinações possíveis de 2 lançamentos, 272 tiveram média de pelo menos 1.65 sev/10c, igual ou superior ao grupo Claude, resultando em valor p de 46%
• O teste exato de Fisher verificou se os lançamentos com Claude apareciam acima da mediana de 0.74 sev/10c com mais frequência, e retornou valor p de 74% e razão de chances de 1.06

Número de commits e tamanho das mudanças

• Os lançamentos com Claude tiveram em média 42 commits, enquanto os sem Claude tiveram média de 185 commits, e a probabilidade de dois lançamentos aleatórios terem essa mesma quantidade ou mais commits foi de 88%
• Segundo a API de compare do GitHub, os lançamentos com Claude tiveram em média 3.756 linhas modificadas, enquanto os sem Claude tiveram média de 696 linhas, e a probabilidade de dois lançamentos aleatórios terem esse mesmo volume ou mais linhas alteradas foi de 5%
• O número de bugs ponderados por gravidade foi, em média, 5.6 nos lançamentos com Claude e 14.9 nos lançamentos sem Claude, e a probabilidade de dois lançamentos aleatórios terem esse mesmo número ou mais bugs ponderados por gravidade foi de 77%
• Em resumo, os lançamentos com Claude tiveram muito mais linhas modificadas, mas não mais commits nem mais bugs ponderados por gravidade

Regime de versões e outliers anteriores

• A média dos lançamentos v2.x foi 1.11 sev/10c, enquanto a dos v3.x foi 4.23 sev/10c, mostrando taxa de bugs mais alta na série v3.x
• Mesmo comparando apenas v3.x, os lançamentos com Claude ficam na faixa intermediária ou melhor; para fazer o Claude parecer um outlier, seria preciso compará-lo a uma era anterior mais tranquila e atribuir ao Claude uma mudança que já havia ocorrido antes dele
• O teste de corridas de Wald–Wolfowitz, aplicado aos 35 lançamentos sem Claude, encontrou 13 runs observados, 18.5 esperados ao acaso, z=-1.88 e p=0.060, o que não é forte o bastante para rejeitar aleatoriedade no limiar de 0.05
• v3.4.1, embora anterior à introdução do Claude, registrou a maior taxa de bugs de todo o conjunto de dados, com 59 bugs, 9 commits e 39.39 sev/10c
• v3.4.1 foi um lançamento hotfix no dia seguinte ao v3.4.0 e mostrou a maior taxa de bugs, superando todos os outros lançamentos por margem de pelo menos um dígito, em uma época em que não havia IA para culpar

Interpretação e limitações

• A interpretação consistente com os dados é que “os dois lançamentos atuais com Claude não se distinguem estatisticamente dos lançamentos históricos”
• v3.4.3, com 3.29 sev/10c e percentil 77, é elevado, mas não extremo, e há 8 lançamentos históricos com pontuação ainda maior
• A afirmação de que “Claude claramente piorou as coisas” não é sustentada nem pela distribuição dos lançamentos, nem pelo teste de permutação, nem pelo teste de Fisher
• Por outro lado, os dados também não permitem concluir que “commits do Claude em geral não vão piorar as coisas no futuro”; eles apenas indicam que esses dois lançamentos atuais estão dentro da faixa do comum
• Essa métrica tem a limitação de ser uma ferramenta grosseira, incapaz de controlar a complexidade dos commits ou a intensidade do trabalho de segurança

Fatores de confusão discutidos

• Um usuário do Hacker News sugeriu que correções de segurança em resposta a CVEs parecem ter revelado erros de programação que estavam no código desde 2007
• Um usuário do Lobsters propôs a cadeia causal “LLM → aumento de problemas de segurança conhecidos → necessidade de mais mudanças que o normal → mais regressões que o normal”
• Andrew Tridgell explicou que uma enxurrada de relatórios de CVE gerados por IA exigiu mudanças rápidas e amplas na superfície de ataque do rsync
• Considerando também esse fator de confusão, o problema parece estar menos no Claude em si e mais no maior volume de trabalho de segurança e no consequente aumento do volume de mudanças

[GN⁺]

Opiniões no Lobste.rs

• Acho que cada um pode decidir se continua ou não usando projetos FOSS que daqui para frente serão tocados com vibe coding. Dito isso, a raiva que a comunidade mostrou depois que o mantenedor mudou para ferramentas de vibe coding foi bem surpreendente, e os dados empíricos do texto pelo menos ajudam a contextualizar melhor o impacto dessa mudança de prática
  Só com o tempo vai dar para saber se, com o mantenedor adotando esse estilo de programação, a confiança será mantida ou vai se desgastar ainda mais

  • Fico curioso sobre quantas das pessoas irritadas com essa mudança realmente contribuíram de forma significativa para o rsync ou colocaram dinheiro no projeto

• Essa análise foi exatamente o que eu queria ver, e até mais. Gostei especialmente da parte “escolhi pessoalmente todos os indicadores, a metodologia e as fontes de dados depois de consultar minha esposa, que tem mestrado em estatística pela Penn State University”, e foi excelente envolver uma especialista real em estatística e transformar isso num texto fácil de ler
  Já que usaram o indicador único de “bugs por 10 commits”, parece que perderam a chance de usar um prefixo SI e chamar de decibugs por commit

  • Concordo. O texto não é meu, mas gostei de ver alguém ir além do Fla-Flu inflamado e mostrar com dados o impacto na qualidade do código

• O sucesso de projetos open source depende demais de percepção, a ponto de gente até pagar por estrelas no GitHub. Infelizmente, esse problema de percepção já fugiu do controle e virou um talking point, e é difícil qualquer dado mudar isso
  Daqui para frente, a frase “o mantenedor do rsync usou LLM e estragou tudo” vai ser usada por céticos de IA junto com pontos como “datacenters desperdiçam 500 mil galões de água limpa por dia” e “uma pesquisa da METR disse que LLMs reduzem a produtividade”
  Não estou dizendo se sou ou não cético de IA; só estou dizendo que o debate sobre esse tema normalmente segue por esse caminho

  • Por que isso seria um “talking point”? Não é simplesmente um fato?
  • Não sei se o autor estava tentando convencer alguém com dados. Vejo esse texto como uma forma de adicionar contexto de dados à discussão acalorada sobre a adoção dessas ferramentas no rsync
    Dito isso, é verdade que o texto deixa de fora completamente outros fatores não quantitativos, e imagino que tenha sido de propósito, já que o barulho dos dois lados, evangelistas e céticos, já é grande o bastante

• É muito importante, e ao mesmo tempo previsível, a conclusão de que o pior release da história do rsync foi antes da adoção do Claude, com 39,39 bugs por 10 commits
  Se processos como testes e garantia de qualidade entre usuários e desenvolvedores não conseguem assegurar a correção do software, bugs vão ser distribuídos com ou sem LLM. LLM pode prejudicar esse processo ou pode ajudar

  • Concordo. Um post recente sobre o cURL parece mostrar o caso oposto
    Graças a práticas fortes de engenharia de software já estabelecidas há anos, o valor geral de encontrar bugs com ferramentas de IA parecidas acabou ficando menor
  • Tenho algumas preocupações sobre o futuro do rsync. O principal problema é que o rsync era, na prática, um projeto já concluído havia anos, mas com o uso de IA passaram a desmontar o código de testes existente e substituí-lo por uma suíte de testes em Python, e por um período considerável não executaram os testes antigos em paralelo para verificar a correção
    Para mim, isso é irresponsável. Especialmente porque o objetivo principal do rsync é mover dados valiosos, e a integridade desses dados é absolutamente crucial

• Eu preferia que evitassem frases como “como é típico de usuários anti-IA, isso acabou escalando para fantasias de violência”. Esse tipo de retórica não só generaliza algumas pessoas das quais o autor discorda, como também afasta leitores que já discordam dele, fazendo com que justamente quem mais deveria ler o texto acabe não lendo
  Separadamente, me importo pouco se esta versão tem mais ou menos bugs do que as anteriores. O que importa para mim é que ela está sendo desenvolvida de um jeito que não combina com a minha visão de como software deve ser desenvolvido. Se não houver um entendimento básico de que existem problemas além da eficiência, não espero convencer ninguém de que essa posição é razoável
  Felizmente, se eu não quiser, não preciso usar esta versão do rsync, e vou escolher uma alternativa derivada de antes do uso de LLM

  • Esse texto estava carregado de raiva demais, então não consegui ler por muito tempo e desisti. Teria sido melhor se tentasse ser imparcial, ou ao menos parecesse ser
    Também não ajudou repetir um meme já refutado há muito tempo, aquele de que o primeiro bug report foi uma issue para a qual as pessoas correram em massa. O primeiro bug report real foi outro

• Acho sinceramente que o texto agora está melhor. Ainda assim, a parte que diz “essa métrica não controla a complexidade do commit, a sensibilidade de segurança nem a gravidade do bug. É uma ferramenta grosseira que não distingue uma correção de typo de uma linha de um patch de CVE” deixa passar a crítica central, do meu ponto de vista de LLM é ruim
  A crítica que eu e outras pessoas levantamos é que a IA faz despejar commits maiores, mais difíceis de entender de relance e que aumentam a complexidade. Até os defensores de LLMs dizem algo parecido, mas depois deslocam a trave da prática de décadas de “ler o PR” para “o LLM deveria conseguir testar tudo”. Só que o problema de a complexidade do código ser dívida técnica não desaparece
  Neste caso, a gravidade do bug é muito alta. Porque o workflow de backup realmente quebrou. O rsync é amplamente usado para backup, e as pessoas o tratavam como uma ferramenta “testada em batalha”, a ponto de nem imaginarem que uma atualização de patch pudesse quebrar scripts de backup
  Dá para dizer que foi um acidente o LLM produzir software com bug, ou que o mantenedor precisa mudar o fluxo de trabalho com LLM e aumentar a cobertura de testes. De fato, o mantenedor disse isso mesmo. Mas o centro da indignação é que essa ferramenta quebrou essa confiança
  Na prática, hoje existe uma nova classe de programadores com LLM dizendo que “não lê código nenhum”. Porque leva tempo demais para ler e é mais complexo de entender do que código de programador comum. Ler código é aprender o modelo mental de outra pessoa, mas ferramentas de LLM não oferecem um único modelo mental coerente
  Separadamente, também é preciso verificar a acessibilidade do site. Mesmo tendo uma visão bem boa e estando no fim dos 20 anos, texto cinza-claro sobre fundo creme/amarelo é realmente doloroso de ler

  • Fiquei confuso com o trecho citado. A métrica usada no texto parece dar um peso de gravidade aos bugs por 10 commits; o autor está se contradizendo ou fui eu que li errado?
  • Para quem diz que o workflow quebrou, isso me parece uma boa oportunidade para aprender o que são software open source e a licença GPL, e que garantias eles oferecem
    Não acho que as pessoas teriam encontrado esse bug por conta própria. Meu palpite é que mais de 90% dos usuários de rsync estão usando uma versão anterior sem esse bug. Eu sou um deles

    $ uname -a  
    Darwin riemann.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:31 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T8103 arm64
    
    $ port info rsync  
    rsync @3.4.1 (net)  
    [...]  
    

    Quanto ao motivo de isso ter chamado atenção, não precisa ser Steven Pinker para entender que boa parte da comunidade está em confusão agora. Não é fácil aceitar o fato de que LLMs programam melhor do que humanos
    Pessoas que colocavam sua identidade e autoestima na capacidade de programar ou na profissão estão enfrentando duas crises: a incerteza sobre seu sustento futuro/valor de mercado e uma crise de identidade
    Medo, incerteza e dúvida são difíceis de lidar, e as empresas de LLM estão fazendo o possível para amplificar esse efeito para inflar o preço das ações. Se o mercado passar por uma correção brusca depois de outubro, acho que esses amplificadores também podem enfraquecer
    Uma fração muito pequena dos programadores do mundo, isto é, pessoas que veem código como uma forma de arte, provavelmente vai usar LLMs para treino e aprimoramento de habilidade

• Este texto cita muitos comentários que mencionam regressão, mas a análise em si não mede regressões, só mede relatórios de bug. Ela liga o bug ao release em que foi reportado, não ao release em que foi introduzido, e mede a gravidade do release pelo número de commits, deixando de fora fatores óbvios como duração do release ou adoção por distribuições
  Não entendo como isso faz sentido

• Pessoalmente, evito projetos que usam LLM. Não por ter um motivo prático concreto, mas porque simplesmente me causam muita repulsa; é parecido com quando alguém usa termos como “kek” ou “fren” e eu tomo isso, mesmo sem grande razão, como um sinal de que não quero mais interagir
  As explicações dadas agora para não gostar do uso de LLM parecem racionalizações coladas ao contrário. As preocupações atuais com ética, qualidade etc. são válidas, mas mesmo que esses problemas fossem resolvidos, não acho que pessoas com uma postura anti-IA como a minha passariam de repente a achar isso aceitável
  Então eu evito, sem precisar de uma razão específica, projetos com “AGENTS.md”, commits coassinados pelo Claude e coisas do tipo. Simplesmente acho desagradável, não combina com meu gosto, e não importa se há bugs ou não. Imagino que outras pessoas possam sentir algo parecido

• Para responder ao autor: primeiro, fantasia é linguagem. Na prática, você está alegando que isso ficou só na fala, ou pelo menos não está alegando que houve escalada não verbal
  Segundo, para fazer esse tipo de afirmação, seria preciso perguntar a algum especialista em estatística próximo como sustentá-la. O fato de algumas pessoas terem postado esse tipo de coisa não sustenta de forma significativa a alegação de que isso é “típico”
  Minha observação anedótica, sem sustentação estatística, é que usuários “anti-IA”, quando veem LLM sendo enfiado onde não ajuda, em geral ficam mais tristes do que propriamente violentos

  • Às vezes vejo textos muito longos e detalhados refutando alguns opositores de LLM, geralmente a parte deles que reage ao LLM de modo emocional e social. Tenho dificuldade de explicar por quê, mas esses textos parecem muito desonestos e passam uma sensação de bater em cachorro morto
    São detalhados demais para ser fácil refutá-los num plano emocional, e no fim parecem terminar em “o problema não é o LLM; se usado direito ele é um amplificador. Os anti-IA é que não entendem nada e só estão com medo de ficar para trás”
    Também não quero reduzir o trabalho dos mantenedores do rsync a mera polêmica, então não sei como eu poderia montar uma contraposição convincente
    Essas estatísticas podem ser interessantes do ponto de vista de manutenção de open source, mas a conclusão pende de forma estranha para um lado, e fica a sensação de que open source no estilo GitHub não é a forma para a qual eu quero contribuir
    Ainda assim, acho nada bom que tenham ido em massa atrás do mantenedor no repositório do rsync
  • Chamar fantasias públicas de violência de algo inaceitável está correto. Não é o tipo de coisa que devamos almejar como civilização. Mas me incomoda a parte em que o autor chama isso de “típico”, porque isso é uma generalização
    Quanto à observação anedótica, acho que esta tirinha está certa. Gosto de ver afirmações concretas e mensuráveis, em parte porque gosto de números e em parte porque isso ajuda a empurrar debates online um pouco mais para perto do mundo ideal do último quadro.

• A análise é bem-vinda, mas não tenho muita confiança na metodologia. Tenho curiosidade sobre métricas como número de bugs por unidade de diferença, por exemplo multiplicando, para cada commit, as linhas alteradas no código principal — isto é, código que não seja testes nem documentação —, e também uma análise de quanto tempo leva, após o lançamento, para atingir um certo número de bugs.
  Dito isso, como este lançamento provavelmente recebeu muito mais atenção do que outros, é bem possível que mais bugs tenham sido reportados por causa disso; por isso, parece difícil criar uma métrica realmente convincente. Perguntas como “isso é típico considerando algumas semanas após o lançamento?” talvez também não sejam muito úteis.