Claude aumentou os bugs do rsync?

 (alexispurslane.github.io)
2 pontos por GN⁺ 2026-06-06 | 2 comentários | Compartilhar no WhatsApp
  • 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

Leituras relacionadas

2 comentários

 
GN⁺ 2026-06-06
Comentários do Hacker News

  • Ao olhar os commits, encontrei o commit original e o commit de reversão: https://github.com/RsyncProject/rsync/commit/d046525de39315d...
    Até caminhos que deveriam usar malloc foram trocados para calloc, forçando todas as alocações como se calloc fosse um superconjunto estrito compatível. Em alocações grandes ou recursivas, o custo fica bem alto. Isso parece um bom exemplo de como esse tipo de coisa pode passar despercebido em código escrito com Claude. A reversão está em https://github.com/RsyncProject/rsync/commit/7db73ad9a1b8721..., e mesmo lendo só por cima a explicação da reversão já parece texto escrito por LLM. Entendo o sentimento de quem publicou o post original

    • A própria quantidade de commits também é suspeita. Nos últimos dois meses, o número de commits que entrou no rsync é parecido com o dos 2 anos anteriores, e a maioria são commits escritos com Claude. Vendo mudanças como essa entrando, parece o caso clássico de alguém empolgado com IA e ficando cada vez mais descuidado
    • “Escrito com Claude” não está correto. O commit de reversão referencia https://github.com/RsyncProject/rsync/issues/959, e nesse issue o autor explica diretamente: “a mudança para zerar a memória foi ideia minha e alteração minha”
      Em um relatório de segurança apareceu uso de elementos além do fim de um array, e a avaliação foi que inicializar a alocação com zero aumenta a chance de bugs parecidos no futuro terminarem em dereferência de ponteiro nulo, em vez de um ponteiro válido. Claude foi usado apenas para organizar o conjunto de commits, e como qualquer pequena edição adiciona a tag de coautoria, isso não significa que Claude escreveu a mudança. Ele afirma que o código em si foi escrito por ele
    • Eu não concluiria que foi Claude quem tomou essa decisão. Não foi uma mudança incidental escondida no meio de um commit grande; a própria mensagem do commit já começa com “inicializa toda memória recém-alocada com zero” e de fato faz exatamente isso. Nem sei que tipo de prompt as pessoas estão imaginando
      É perfeitamente possível que um humano tenha achado primeiro que era uma melhoria e depois mudado de ideia ao ver a regressão de RSS. E também não existe alguma lei natural obrigando essa mudança a aumentar o RSS. calloc pode tratar isso de forma especial ao saber que um novo mapeamento de memória recém-recebido do sistema operacional já vem zerado. Se há culpa da IA aqui, ela está mais no sentido de que a IA está causando uma explosão de relatórios de vulnerabilidade, o que leva a uma explosão de correções urgentes, e correções urgentes às vezes criam outros problemas
    • Impressionante viver na era da IA multiplicada por overcommit do Linux. Pessoalmente, 10.8GB hoje em dia nem é tanta coisa, e o buffer de sprintf talvez seja ainda maior do que isso. Se não for, deveria ser; senão é hora de começar a usar snprintf

  • Recomendo ler o texto linkado pelo autor do rsync antes de comentar: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0
    Para deixar claro, não falo com o Tridge há alguns anos, mas ele foi colega e mentor por muito tempo. Vale considerar a perspectiva dele antes de entrar na cruzada

    • Este deveria ser o comentário no topo. É bem triste que ele tenha precisado escrever um texto desses. Tem gente julgando demais sem nem pagar a conta dele
    • Não entendo totalmente a parte “achei melhor construir primeiro em público, na master, a estrutura central da nova suíte de testes”. Se ele tivesse atualizado só os testes ou feito push só para a master, as pessoas não teriam ficado furiosas
      Mas ele também fez push de mudanças quebradas para a branch de release. Quebrar um workflow que funcionava havia anos é a forma mais garantida de irritar as pessoas, e ainda por cima ver “Claude” no commit é jogar gasolina no fogo
    • Acho que a resposta dele foi uma reação realmente muito bem escrita

  • Não tenho nenhum envolvimento direto nessa briga, mas há algumas partes que parecem suspeitas. A release à qual foi atribuído o maior número de bugs foi a release de janeiro, justamente a imediatamente anterior à primeira release com commits coautorados pelo Claude; então fico me perguntando se não podem ter entrado nessa release commits escritos por LLM sem marcação de atribuição
    A metodologia de atribuição por release também não é muito boa. Bugs introduzidos numa atualização de versão menor tendem a ser atribuídos à release de patch dessa versão menor que permaneceu por mais tempo. É difícil acreditar que a 3.4.1 realmente tenha introduzido muitos bugs; como ela saiu no dia seguinte à 3.4.0, é bem provável que bugs surgidos naquela release tenham acabado sendo registrados como 3.4.1. Além disso, releases recentes tiveram menos tempo para que bugs fossem reportados, então também pode haver um viés que faz as releases mais recentes parecerem menos bugadas

    • Concordo. A frase do texto, “a pior release da história do rsync foi antes da introdução do Claude, e ninguém percebeu”, me passa menos a sensação de que o autor não tem interesse nessa briga e mais a de que ele embrulha uma opinião em termos estatísticos chamativos
      “Deslumbrantemente claro”? Era só fazer um gráfico. E a v3.4.1 é de 2025-01-16, então tecnicamente já está na era da programação assistida por AI, antes de a marcação de atribuição virar prática padrão
    • Considerando que as releases são bem raras, comecei a olhar a mesma coisa. Para evitar o problema de commits escritos por LLM sem atribuição, acho que a análise precisa incluir uma comparação da gravidade dos bugs antes e depois da v3.3.0. A data é 6 de abril de 2024
    • LLMs podem ser usados de várias maneiras. Vai desde uma pessoa intervindo de forma bem direta e fazendo só mudanças locais até delegar tudo completamente
      Já vi muito código gerado por LLM sem coautor no commit message. Normalmente parece que essa tag só aparece quando a interface com o codebase acontece inteiramente por ferramentas como Claude/Codex, e esses commits costumam ser os mais prolixos, mas quase não dizem por que algo foi mudado, só resumem as alterações no código. Por outro lado, também já vi desenvolvedores usarem o Claude como ferramenta: alternando entre o VSCode e o terminal do Claude, verificando pessoalmente se o código está correto e deixando para o Claude só o trabalho mais braçal. Talvez o autor também tenha começado pequeno e aumentado isso com o tempo
    • O primeiro e o segundo ponto parecem se contradizer. Se todos os bugs da 3.4.1 devem ser atribuídos à 3.4.0, então o momento em que commits de LLM sem atribuição teriam entrado no projeto teria de ser ainda mais cedo, e isso só deixaria a hipótese mais absurda
      O problema maior é que não há evidência alguma para sustentar a hipótese de que commits de LLM entraram escondidos em releases anteriores e por isso a taxa de bugs ficou alta. Não há base para isso, a menos que se assuma que um número alto de bugs automaticamente implica intervenção de AI, e isso é raciocínio circular. O terceiro ponto é válido. Eu tinha analisado quanto tempo normalmente leva para encontrar bugs e em que ponto do ciclo de releases cada versão está; posso postar isso se quiserem
    • Começando pelo erro mais escancaradamente espantoso: as estatísticas sobre Claude vêm de apenas 2 pontos de dados

  • Há uma ironia importante num nível meta aqui. O texto original defende o uso de AI, mas também claramente parece ter usado AI para analisar os dados e apresentar os resultados
    Nesse processo, o autor usou estatística de um jeito que claramente não entende bem e chegou a várias conclusões erradas. A discussão relacionada pode ser vista em https://news.ycombinator.com/item?id=48417626. Em resumo, esse estudo não tem poder estatístico suficiente e faz uma afirmação injustificada de “não há diferença”. No fim, ao interpretar os dados com um LLM, ele acabou cometendo o mesmo tipo de erro que o estudo queria investigar: afirmar falsidades com confiança

    • AI é religiosa demais. Não importa o que você diga a quem acredita, nada vai fazê-lo questionar a fé. Falando de forma mais geral, não dá para convencer pela razão alguém a abandonar algo em que quer acreditar

  • Acho que a única coisa que pessoas irritadas com isso conseguiriam ao pressionar o mantenedor do rsync seria fazer com que outros deixem de divulgar de forma responsável o uso de AI. Vão acabar fazendo as pessoas desativarem a marcação de atribuição ao Claude nos commits para evitar polêmica

    • Eu não ligo muito para divulgação de uso de AI. Se não for alguém que eu conheça pessoalmente, não acredito que código feito por humano seja necessariamente melhor que código feito por AI
      De qualquer forma, a responsabilidade pelo código que é commitado e enviado é do humano. Isso nunca mudou. Se foi escrito à mão, se surgiu porque um gato andou em cima do teclado, ou se foi gerado por AI, isso não me importa. A qualidade do código de um projeto pode cair por todos os tipos de motivo, e ficar obcecado só com o fato de ter sido ou não feito por AI não é produtivo. Se alguém quer procurar um pretexto para criticar AI, e outra pessoa quer defendê-la, tudo bem, mas isso não serve como forma de avaliar a qualidade do código de um projeto
    • Independentemente da polêmica, o certo é desativar essas marcações mesmo. Não há motivo para fazer propaganda gratuita para empresas de porte trilionário. Trailers como Generated-by só fazem sentido quando se contribui para um projeto de terceiros, e nesse caso divulgar isso é questão de educação
    • Isso soa como “não fique bravo porque alguém fez algo antiético ou imoral, senão ele vai fazer algo ainda mais antiético ou imoral!”
      Desativar a marcação de atribuição de código gerado por LLM é fraude. Porque equivale a dizer que foi você quem escreveu o código. Claro, isso também combina bem com gerar código com LLM para começo de conversa. Na prática, é só repetir a entrada removendo a licença e os avisos de copyright
    • Não sei se isso é algo ruim. Do ponto de vista do departamento de marketing da Anthropic, talvez seja, mas se um agente é só mais uma ferramenta na caixa de ferramentas do desenvolvedor, a marcação de atribuição parece meio estranha. No fim, a responsabilidade pelo commit é do desenvolvedor
    • Essa lógica aparece toda vez, mas não é convincente. É verdade que apontar um problema publicamente cria incentivo para escondê-lo, mas não entendo o que se espera que façamos com isso
      Deixando a discussão sobre AI ser ruim de lado por um instante, para fazer uma analogia: evasão fiscal é ruim, antiética, e deve ser apontada quando aparece. O fato de isso criar incentivo para esconder não leva à conclusão de que devemos ficar calados e não apontar nada

  • Sou grato pelo trabalho do Andrew em criar e manter o rsync, mas como dependo bastante do rsync para backup de arquivos entre máquinas na rede de casa, gastei um tempo para descobrir como fixar a versão do rsync do Homebrew em 3.4.1
    Os bugs das duas versões seguintes são realmente assustadores, e o relatório original que desencadeou tudo isso também. O procedimento, bem mais complicado do que eu esperava, está resumido aqui: https://gist.github.com/e40/caa67c1b8d439a528695f996d0519d8e

  • Este texto deixa mais perguntas do que respostas, então é difícil chegar a um julgamento. Não entendo por que a v3.4.1, imediatamente antes do commit do Claude, tinha mais bugs, nem por que “ninguém percebeu”. É estranho demais para simplesmente tratar como erro humano
    Também acho questionável por que a v3.4.2 tem 0 bugs ou pontuação de bug 0. Também é estranho que esse tipo de outlier, que não parece existir em outros commits, tenha sido misturado às estatísticas agregadas e permitido baixar a pontuação de “Claude cria bugs?”. Sinceramente, não entendo como isso não foi um sinal de alerta na análise do autor. Dá a sensação de uma análise pela metade apresentada como um produto final muito complexo só porque rodou estatística avançada

    • Não sei qual seria a razão para considerar que a v3.4.1 não foi erro humano, além da suposição prévia de que isso não poderia acontecer
      A v3.4.2 também tinha 4 bugs na métrica original antes de filtrar pedidos de recurso e perguntas, e antes disso era ainda mais alta, mas isso não fazia grande diferença para a análise geral. Ficava bem dentro do intervalo interquartil, inclusive no lado mais baixo. Como só há dois releases do Claude, acho pior e mais arbitrário remover um outlier só porque ele parece engraçado

  • Se a ideia é algo como “não controlo complexidade do commit, foco em segurança nem gravidade do bug. É um porrete que não distingue entre corrigir um erro de digitação de uma linha e aplicar um patch de CVE. Mas as críticas de que ‘Claude piora a situação’ também são um porrete, então o porrete é a resposta mais justa”, então acho difícil concordar
    Do ponto de vista do usuário, é preciso entender se a natureza dos bugs piorou. Mesmo que a proporção permaneça a mesma, se a qualidade percebida do software caiu, especialmente para quem mantém o projeto, isso seria visto como piora. Não estou tentando descartar totalmente essa análise, mas acho difícil responder bem a esse tipo de pergunta só com análise quantitativa

    • Ainda assim, acho justo. Até agora não vi ninguém analisar o código e dizer quantas regressões de cada gravidade apareceram. Só dizem “os bugs aumentaram por causa do LLM”
      Essa análise pode ser verificada diretamente por quem quiser e diz que “mesmo com LLM, a quantidade de bugs é bastante mediana”. Ela responde diretamente a essa alegação. Se alguém quer uma análise mais sutil, pode fazer e compartilhar o resultado
    • Afirmações feitas sem evidência podem ser descartadas sem evidência. Esta análise tem mais evidência e mais rigor do que a alegação original. Para mim, isso basta. Se alguém realmente fizer o trabalho de sustentar a alegação original com evidência melhor, ótimo, eu gostaria de ver. Até lá, não vou me preocupar com essa questão
    • O ônus da prova não é de quem faz a alegação?

  • Programo há mais de 20 anos, sempre adorei programar e provavelmente continuarei adorando. Até alguns meses atrás eu era cético em relação à IA, mas Claude e Codex mudaram meu jeito de desenvolver e minha velocidade de formas que eu nunca teria imaginado
    Como resultado, estou produzindo mais código e também encontrando mais bugs. Por isso fico bastante surpreso quando vejo nos comentários do HN esse ódio extremo a coisas feitas com IA. Só porque a IA ajudou ou gerou tudo não quer dizer que o projeto de repente vira vibe coding, nem que essa expressão deva ser um insulto lançado contra usuários de LLM. Isso me lembra muito das expressões depreciativas dirigidas aos “desenvolvedores indianos” quando o desenvolvimento terceirizado no exterior cresceu desde meados dos anos 90. Em meados dos anos 2020, comentários parecidos estão sendo dirigidos à IA. Não entendo. O que é certo é que, gostem ou não os opositores, cada vez mais código será gerado por IA

    • Eu também era um cético parecido há 3 anos. Quando o GPT-4 era estado da arte, eu achava que logo ia estagnar por causa do limite de contexto. Lembro da época em que usar 32K de contexto custava um dinheiro absurdo
      No ano passado vi pela primeira vez um agente de IA depurar e corrigir de forma satisfatória um bug não trivial. Mesmo então, estava claro que, ao usar em tarefas grandes, ainda não era um nível em que se pudesse simplesmente passar o rastreador de issues inteiro. Agora venho trabalhando nos últimos meses com o Codex em um projeto não trivial. Fiz o protótipo em C++ por causa de bibliotecas, a versão inicial foi escrita em Haskell e mais recentemente portei para Rust para conter o uso de memória no mobile. Não é uma ferramenta sem problemas, mas a velocidade de progresso no último ano é impressionante. Ceticismo é bom, mas ceticismo saudável deve recuar diante de evidência concreta
    • Em qualquer assunto envolvendo ferramentas, há pessoas que gostam da ferramenta em si e pessoas que gostam de fazer outra coisa com a ferramenta. Em programação, eu era do segundo tipo. Programação é a ferramenta que me permite fazer o que eu realmente gosto: resolver problemas, pensar em nível de sistema e oferecer soluções legais por meio de software
      Então é realmente divertido quando a IA ajuda nas partes chatas, e também é muito divertido ver colegas não programadores empolgados ao ver suas ideias em estilo vibe coded virando realidade. Estou sinceramente curioso sobre a perspectiva anti-IA de quem trabalha na indústria de software. Será por causa do fim iminente da profissão ou de uma transição tecnológica?
    • Se surgiram expressões depreciativas contra “desenvolvedores indianos” quando a terceirização internacional cresceu em meados dos anos 90, qual foi o gatilho disso?
    • Lido com código terceirizado o tempo todo e, sem exceção, é um incêndio de pneus. Acabei de passar uma semana limpando uma base de código em que um desenvolvedor, por não saber configurar o ambiente local de trabalho, fez commit com uma flag de bypass de verificação de autenticação ativada por padrão
      Esse mesmo problema de “atalhos” também tem sido relatado no vibe coding com IA, e mesmo quando usei modelo de ponta com nível de raciocínio 11, tive que reescrever quase todo o código gerado por IA. Ainda assim, a IA é muito útil em outras atividades, como revisão de PR, análise de vulnerabilidades de segurança, encontrar typos e engenharia reversa. Provavelmente vou até subir meu plano de assinatura, mas ao mesmo tempo o código gerado por IA continua inutilizável. Se dentro de uma mesma pessoa podem coexistir “é tão útil que preciso pagar mais” e “a qualidade do código gerado é inútil”, então é natural que exista uma grande variedade de opiniões no conjunto dos usuários
    • LLM é bom para busca em contexto e saída por template. Mas o que ele garante é a resposta mais chamativa do menor denominador comum, uma produção sem proteção de direitos autorais e também risco jurídico potencial por vazamento de copyright
      Estamos agora na era de ouro Napster do plágio homomórfico

  • Fico pensando que diabos é isso. O que realmente importa é apenas se, depois que código escrito por IA foi permitido na base, os bugs aumentaram. Todo mundo sabe a resposta. Ainda assim, é sempre interessante ver o que pode ser usado para fabricar uma conclusão que precisa de “dados”
 
GN⁺ 2026-06-06
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.