¿Claude aumentó los bugs de rsync?

• Los lanzamientos asistidos por Claude fueron solo dos: rsync v3.4.2 y v3.4.3, y no hay evidencia de que hayan tenido inusualmente más bugs que lanzamientos anteriores según la métrica de bugs ponderados por severidad/10 commits
• sev/10c es la métrica central: normaliza la severidad de los bugs a una escala de 0 a 1, la suma por lanzamiento, la divide por la cantidad de commits y luego la expresa por cada 10 commits
• v3.4.2 tuvo 50 commits, 9 commits de Claude, 0 bugs y 0.00 sev/10c; v3.4.3 tuvo 34 commits, 28 commits de Claude, 17 bugs y 3.29 sev/10c, y ambos quedaron a cada lado del IQR sin que ninguno sea un valor atípico
• El valor p de la prueba exacta de permutación fue 46%, el valor p de la prueba exacta de Fisher fue 74% y la razón de momios fue 1.06, lo que indica que casi no hay señal de que los lanzamientos con Claude sean peores que dos lanzamientos aleatorios o tengan más probabilidad de quedar por encima de la mediana
• v3.4.1 fue un lanzamiento previo a la adopción de Claude y aun así tuvo 59 bugs, 9 commits y 39.39 sev/10c, el peor valor de todo el conjunto; el núcleo de la controversia de rsync está en vincular una sola regresión con Claude sin considerar la distribución histórica

---

Contexto y la pregunta

• A fines de mayo de 2026, la controversia de rsync comenzó con una publicación en Mastodon que vinculaba la regresión de v3.4.3 con los commits de Claude en ese lanzamiento; luego se expandió a Hacker News y al issue de GitHub "Please Do Not Vibe Fuck Up This Software", que acumuló más de 300 comentarios
• La tesis central repetida era que el desarrollo asistido por Claude introdujo bugs en una herramienta que antes era estable, y la pregunta de datos es si los lanzamientos asistidos por Claude tuvieron una cantidad anormalmente alta de bugs en comparación con los lanzamientos históricos
• En Lobsters se pidió ver la cantidad de regresiones por lanzamiento en una gráfica temporal, y el análisis se enfoca en una sola pregunta: “¿Los lanzamientos asistidos por Claude tienen inusualmente muchos bugs?”

Alcance de los datos y reproducibilidad

• Los datos cubren 36 lanzamientos de RsyncProject/rsync desde v2.4.6 hasta v3.4.3 con datos de bugs disponibles; solo dos lanzamientos tienen commits de Claude: v3.4.2 y v3.4.3
• La elección de métricas, metodología y fuentes de datos fue hecha por una persona, incorporando el consejo de su cónyuge con maestría en estadística
• La recolección de datos, la carga en DuckDB, la creación de vistas y los scripts de análisis estadístico fueron hechos por GLM 5.1, pero todas las cifras, estadísticas, tarjetas y gráficas fueron insertadas automáticamente por el script de Python que ejecutó el análisis estadístico
• El repositorio reproducible alexispurslane/rsync-analysis permite ejecutar toda la tubería de principio a fin

Métrica y atribución de bugs

• La métrica central es sev/10c, o bugs ponderados por severidad por cada 10 commits, calculada como sev/10c = (Σ severity/100 ÷ total_commits) × 10
• Los commits se ordenan por committer date en la rama principal, y cada rango de lanzamiento va desde la etiqueta anterior hasta la etiqueta actual; las etiquetas pre y rc se excluyen como fronteras y se absorben en el lanzamiento final
• Las fuentes de bugs son tres: issues de GitHub, rsync Bugzilla y la lista de correo de rsync; los bugs de issues de GitHub y de la lista de correo se atribuyen al lanzamiento más reciente distribuido justo antes del momento del reporte
• Los elementos de Bugzilla se atribuyen al lanzamiento indicado en el campo “Version”, que especifica en qué lanzamiento se reportó el bug
• Se eligió el análisis por lanzamiento porque la crítica en sí plantea que “los lanzamientos completos con commits de Claude tuvieron más bugs”, y porque la mayoría de los bugs no especifican exactamente de qué commit provienen

Método de evaluación de severidad

• Todos los reportes de bugs fueron calificados por Qwen 3 35B con una severidad de 0 a 100, usando un prompt que le asigna el rol de un ingeniero senior de confiabilidad desde la perspectiva del impacto real en usuarios
• Los puntajes de 90 a 100 corresponden a corrupción silenciosa de datos, pérdida de datos, ejecución remota de código o vulnerabilidades de seguridad con acceso no autorizado; 70 a 89 corresponde a crashes, bloqueos, fallas de backup o fallas de compilación; 50 a 69 corresponde a regresiones funcionales con solución alternativa
• En Bugzilla y la lista de correo solo había títulos sin cuerpo, así que el modelo evaluó basándose únicamente en el título, y se le indicó inclinarse al rango intermedio de 40 a 60 si faltaba información
• La salida se limitó a severidades enteras mediante un JSON schema de structured output, y se fijó temperature en 0 para que la misma entrada produzca el mismo puntaje
• Los issues con puntaje 0, como solicitudes de funciones, spam, quejas no técnicas sobre IA o envíos vacíos, se excluyeron del conteo base de bugs

Resultados estadísticos de los lanzamientos con Claude

• v3.4.2 tuvo 9 commits de Claude de un total de 50, 0 bugs reales, 0.00 sev/10c y quedó en el percentil 0 entre lanzamientos
• v3.4.3 tuvo 28 commits de Claude de un total de 34, 17 bugs, 3.29 sev/10c y quedó en el percentil 77 entre lanzamientos
• El IQR histórico es de 0.29 a 2.59 sev/10c; v3.4.2 quedó justo debajo del IQR y v3.4.3 justo por encima, de modo que ambos lanzamientos enmarcan la distribución media desde lados opuestos
• La prueba exacta de permutación arrojó que 272 de las 595 combinaciones posibles de dos lanzamientos tenían un promedio de grupo de Claude de 1.65 sev/10c o más, dando un valor p de 46%
• La prueba exacta de Fisher evaluó si los lanzamientos con Claude quedaban por encima de la mediana de 0.74 sev/10c con mayor frecuencia, y dio un valor p de 74% junto con una razón de momios de 1.06

Número de commits y tamaño de los cambios

• Los lanzamientos con Claude tuvieron en promedio 42 commits, mientras que los lanzamientos sin Claude promediaron 185 commits; la probabilidad de que dos lanzamientos aleatorios tuvieran esa misma cantidad o más commits fue de 88%
• Según el compare API de GitHub, las líneas modificadas promediaron 3,756 por lanzamiento con Claude frente a 696 en los lanzamientos sin Claude; la probabilidad de que dos lanzamientos aleatorios tuvieran esa misma cantidad o más líneas cambiadas fue de 5%
• Los bugs ponderados por severidad promediaron 5.6 en los lanzamientos con Claude frente a 14.9 en los lanzamientos sin Claude; la probabilidad de que dos lanzamientos aleatorios tuvieran esa misma cantidad o más bugs ponderados por severidad fue de 77%
• En conclusión, los lanzamientos con Claude sí tuvieron muchas más líneas modificadas, pero no más commits ni más bugs ponderados por severidad

Sistema de versiones y valores atípicos previos

• El promedio de los lanzamientos v2.x fue 1.11 sev/10c, mientras que el de los v3.x fue 4.23 sev/10c, mostrando una tasa de bugs más alta en la serie v3.x
• Incluso comparando solo dentro de v3.x, los lanzamientos con Claude quedan en la zona media o mejor; para hacer que Claude parezca un valor atípico habría que compararlo con una era anterior más tranquila y atribuirle a Claude un cambio que ya había ocurrido antes de su adopción
• La prueba de rachas de Wald–Wolfowitz dio 13 rachas observadas en 35 lanzamientos sin Claude, frente a un valor esperado aleatorio de 18.5, con z=-1.88 y p=0.060; con un umbral de 0.05, no es lo bastante fuerte como para rechazar la aleatoriedad
• v3.4.1 fue un lanzamiento previo a Claude pero aun así registró 59 bugs, 9 commits y 39.39 sev/10c, la tasa de bugs más alta de todo el conjunto de datos
• v3.4.1 fue un hotfix publicado al día siguiente de v3.4.0, y mostró la tasa de bugs más alta superando a todos los demás lanzamientos por una diferencia de dos dígitos, en una época en la que no había ninguna IA a la que culpar

Interpretación y límites

• La interpretación consistente con los datos es que “los dos lanzamientos actuales con Claude no se distinguen estadísticamente de los lanzamientos históricos”
• v3.4.3, con 3.29 sev/10c, sí es alto y queda en el percentil 77, pero no es un valor extremo; hay 8 lanzamientos históricos con puntajes más altos
• La afirmación de que “Claude claramente empeoró las cosas” no está respaldada ni por la distribución de lanzamientos, ni por la prueba de permutación, ni por la prueba de Fisher
• A la inversa, de estos datos tampoco se puede concluir que “los commits de Claude en general no vayan a empeorar las cosas en el futuro”; por ahora solo se puede decir que estos dos lanzamientos caen dentro de un rango ordinario
• Esta métrica tiene la limitación de ser una herramienta tosca, ya que no controla por complejidad de los commits ni por la intensidad del trabajo de seguridad

Factores de confusión discutidos

• Un usuario de Hacker News señaló que las correcciones de seguridad por CVE parecen haber expuesto errores de codificación que estaban en el código desde 2007
• Un usuario de Lobsters propuso la cadena causal “LLM → aumento de issues de seguridad conocidos → necesidad de hacer más cambios que de costumbre → más regresiones que de costumbre”
• Andrew Tridgell explicó que la avalancha de reportes de CVE generados por IA obligó a hacer cambios rápidos y extensos en la superficie de ataque de rsync
• Si se incluyen estos factores de confusión, el problema parece estar más relacionado con una mayor carga de trabajo de seguridad y el consiguiente aumento del volumen de cambios que con Claude en sí

[GN⁺]

Opiniones en Lobste.rs

• Creo que cada quien puede decidir si seguirá usando o no proyectos FOSS que de ahora en adelante se desarrollen con vibe coding. Dicho eso, la furia que mostró la comunidad después de que el mantenedor cambió a herramientas de vibe coding fue bastante sorprendente, y los datos empíricos del artículo al menos ayudan a dar mejor contexto al impacto de ese cambio de práctica
  Habrá que ver con el tiempo si, al adoptar este estilo de programación, la confianza en el mantenedor se mantiene o se deteriora aún más

  • Me pregunto cuántas de las personas que se enojaron por esta transición realmente contribuyeron de forma significativa a rsync o aportaron dinero

• Este análisis era exactamente lo que esperaba ver, y más. En particular, me gustó la parte de “elegí personalmente todas las métricas, la metodología y las fuentes de datos tras consultarlo con mi esposa, que tiene una maestría en estadística de Penn State University”, y me parece excelente que haya involucrado a una verdadera experta en estadística y que lo haya presentado en un texto fácil de leer
  Dice que usó la métrica única de “errores por cada 10 commits”, pero parece que dejó pasar la oportunidad de usar un prefijo del SI y llamarlos decibugs por commit

  • De acuerdo. No es mi texto, pero me gustó que alguien fuera más allá del debate acalorado a favor o en contra y mostrara con datos el impacto en la calidad del código

• El éxito de un proyecto de código abierto depende demasiado de la percepción, al punto de que hay gente que hasta compra estrellas de GitHub. Lamentablemente, en este caso el problema de percepción se salió de control y se convirtió en un talking point, y va a ser difícil que cualquier dato cambie eso
  De aquí en adelante, “el mantenedor de rsync usó LLM y lo arruinó” será una de esas frases que los escépticos de la IA van a sacar junto con cosas como “los centros de datos desperdician 500 mil galones de agua potable al día” o “un estudio de METR dijo que los LLM reducen la productividad”
  No estoy tratando de decir si yo soy o no escéptico de la IA, solo que las discusiones sobre este tema suelen irse por ese lado

  • ¿Y por qué eso sería un “talking point”? ¿No es simplemente un hecho?
  • No sé si el autor intenta convencer a alguien con datos. Yo veo este texto como una forma de poner contexto con datos a la discusión picante sobre la adopción de herramientas en rsync
    Dicho eso, sí es cierto que el texto deja fuera por completo otros factores no cuantitativos, y supongo que fue a propósito porque ya hay suficiente ruido tanto de evangelistas como de escépticos

• Es muy importante, y una conclusión predecible, que la peor release en la historia de rsync haya sido antes de la adopción de Claude, con 39.39 errores por cada 10 commits
  Si procesos como pruebas y control de calidad entre usuarios y desarrolladores no logran garantizar la corrección del software, entonces se van a distribuir bugs haya o no LLM. Los LLM pueden perjudicar este proceso o pueden ayudar

  • De acuerdo. La publicación reciente de cURL parece mostrar el caso opuesto
    Gracias a prácticas de ingeniería de software sólidas que ya llevan años establecidas, el valor de encontrar bugs con herramientas de IA similares se ha reducido en general
  • Tengo varias preocupaciones sobre el futuro de rsync. El mayor problema es que rsync en la práctica ya era un proyecto terminado desde hace años, pero al empezar a usar IA arrancaron el código de pruebas existente y lo reemplazaron por una suite de pruebas en Python, y durante un periodo considerable no validaron la corrección ejecutando en paralelo las pruebas anteriores
    Para mí eso es irresponsable. Especialmente porque el propósito principal de rsync es mover datos valiosos, y la integridad de esos datos es absolutamente crítica

• Preferiría que evitaran frases como “como es típico de los usuarios anti-IA, al final eso escaló a fantasías de violencia”. No solo generaliza a algunas personas con las que el autor no está de acuerdo, sino que además genera rechazo entre lectores que ya de por sí no están de acuerdo, haciendo que justo la gente que más debería leer el texto no lo haga
  Aparte de eso, me importa poco si esta versión tiene más o menos bugs que la anterior. Lo que me importa es que se está desarrollando de una forma que no encaja con mi idea de cómo debe hacerse el desarrollo de software. Si no hay una comprensión básica de que hay problemas más allá de la eficiencia, no espero poder convencer a nadie de que esta postura es razonable
  Por suerte, si uno no quiere, no tiene que usar esta versión de rsync, y yo elegiré una alternativa derivada de antes del uso de LLM

  • Este texto transmite demasiado enojo; no pude leerlo mucho tiempo y lo dejé. Habría sido mejor si hubiera intentado ser justo, o al menos parecerlo
    Tampoco ayudó que repitiera un meme ya refutado hace tiempo, o sea, la idea de que el primer reporte de bug fue un issue al que la gente se le fue encima. En realidad hubo otro primer reporte de bug

• Creo que el texto ahora está francamente mejor. Aun así, la parte de “esta métrica no puede controlar la complejidad de los commits, la sensibilidad de seguridad ni la gravedad de los bugs. Es una herramienta torpe que no puede distinguir entre corregir un typo de una sola línea y un parche para un CVE” pasa por alto la crítica central, al menos desde mi postura de los LLM son malos
  La crítica que yo y otras personas planteamos es que la IA hace que se produzcan commits más grandes, más difíciles de entender y que aumentan la complejidad. Incluso los partidarios de los LLM dicen cosas parecidas, pero luego mueven la portería de la práctica, validada durante décadas, de “leer el PR” a “el LLM debería poder probarlo todo”. Pero el problema de que la complejidad del código sea deuda técnica no desaparece
  En este caso, la gravedad del bug es muy alta. Porque realmente se rompió un flujo de trabajo de respaldos. rsync se usa ampliamente para respaldos, y la gente ha confiado en él como una herramienta “probada en batalla”, hasta el punto de que ni siquiera imaginan que una actualización de parche pueda romper sus scripts de respaldo
  Se puede decir que fue casualidad que el LLM produjera software con bugs, o que el mantenedor tiene que cambiar su flujo de trabajo con LLM y aumentar la cobertura de pruebas. De hecho, el mantenedor dijo justamente eso. Pero el centro de la indignación está en que esta herramienta rompió esa confianza
  De hecho, hoy existe una nueva clase de programadores con LLM que dicen que “ya no leen el código en absoluto”. Dicen que tarda demasiado leerlo y que es más complejo de entender que el código de un programador normal. Leer código es aprender el modelo mental de otra persona, pero las herramientas LLM no ofrecen un modelo mental coherente
  Aparte, también habría que revisar la accesibilidad del sitio. Tengo bastante buena vista y estoy a finales de mis 20, pero el texto gris claro sobre fondo crema/amarillo claro es realmente doloroso de leer

  • La parte citada me confunde. La métrica usada en el texto parece dar un peso por gravedad a la cantidad de bugs por cada 10 commits; ¿el autor se está contradiciendo a sí mismo? ¿O leí mal?
  • Para la gente cuyo flujo de trabajo se rompió, creo que esta es una buena oportunidad para aprender qué son el software de código abierto y la licencia GPL, y qué garantías ofrecen
    No creo que la gente haya descubierto ese bug por su cuenta. Supongo que más del 90% de los usuarios de rsync estarán usando una versión anterior que no tiene ese bug. Yo soy uno de ellos

    $ 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)  
    [...]  
    

    Si atrajo tanta atención, no hace falta ser Steven Pinker para entender que buena parte de la comunidad está confundida en este momento. No es fácil aceptar el hecho de que los LLM programan mejor que los humanos
    Quienes basaban su identidad y autoestima en su habilidad para programar o en su profesión están enfrentando una doble crisis: la incertidumbre sobre su futuro sustento/valor de mercado y una crisis de identidad
    El miedo, la incertidumbre y la duda son difíciles de manejar, y las empresas de LLM están haciendo todo lo posible por amplificar esos efectos para subir el precio de sus acciones. Si el mercado se corrige con fuerza después de octubre, creo que esos amplificadores también podrían debilitarse
    Un porcentaje muy pequeño de los programadores del mundo, o sea quienes ven el código como una forma de arte, probablemente usarán los LLM para entrenarse y mejorar sus habilidades

• Este texto cita muchos comentarios que mencionan regresiones, pero el análisis en sí no mide regresiones, sino solo reportes de bugs. Vincula los bugs al release en el que se reportaron, no al release en el que fueron introducidos, y mide la gravedad del release por el número de commits, dejando fuera factores evidentes como la duración del release o la adopción en distribuciones
  No entiendo cómo se supone que eso tenga sentido

• Personalmente evito los proyectos que usan LLM. No por una razón práctica de peso, sino simplemente porque me generan muchísimo rechazo; es parecido a cuando alguien usa palabras como “kek” o “fren” y lo tomo como una señal de que ya no quiero interactuar con esa persona, incluso sin una razón concreta
  Las explicaciones que ahora se dan para justificar el rechazo al uso de LLM me suenan a racionalizaciones puestas al revés. Las preocupaciones actuales, como ética o calidad, son válidas, pero aunque esos problemas se resolvieran no creo que personas con una inclinación anti-IA como la mía de pronto fueran a sentirse cómodas
  Por eso evito proyectos con cosas como “AGENTS.md” o commits coescritos con Claude, sin una razón específica. Simplemente me resultan desagradables y no van con mis gustos, haya bugs o no. Me imagino que otras personas sentirán algo parecido

• Al autor le diría que, primero, una fantasía es lenguaje. En la práctica, lo que está afirmando es que se quedó en palabras, o al menos no está afirmando que hubiera una escalada no verbal
  Segundo, si va a hacer este tipo de afirmaciones, debería preguntarle al experto en estadística más cercano cómo respaldarlas. Que unas cuantas personas hayan publicado cosas así no respalda de manera significativa la afirmación de que eso sea “típico”
  Como observación anecdótica no respaldada estadísticamente, yo diría que los usuarios “anti-IA”, más que sentir de forma violenta que los LLM se entrometen donde no ayudan, suelen sentirse tristes por ello

  • A veces veo textos muy largos y detallados que intentan refutar a algunos opositores a los LLM, normalmente a quienes reaccionan a los LLM desde lo emocional o lo social. Me cuesta explicar bien por qué, pero esos textos me parecen muy poco sinceros, como si estuvieran golpeando al más débil
    Son tan detallados que resulta difícil responderles desde una perspectiva emocional y, al final, parece que terminan en “el problema no es el LLM; si se usa bien es un amplificador. Los anti-IA no entienden nada y solo tienen miedo de quedarse atrás”
    Tampoco quiero rebajar el trabajo de los mantenedores de rsync a una discusión ideológica, así que no sé cómo podría construir una contraargumentación convincente
    Las estadísticas de aquí pueden ser interesantes desde la perspectiva del mantenimiento de código abierto, pero la conclusión se inclina de forma rara hacia un solo lado y me deja la sensación de que el código abierto estilo GitHub no es la clase de proyecto a la que quiero contribuir
    Aun así, no me parece nada bien que la gente se haya abalanzado en masa sobre el mantenedor en el repositorio de rsync
  • Está bien decir que una fantasía pública de violencia no es aceptable. No es algo a lo que debamos aspirar como civilización. Pero me molesta que el autor la llame “típica”, porque eso ya es una generalización
    En cuanto a la observación anecdótica, creo que esta historieta tiene razón. Me gusta ver afirmaciones concretas y medibles, en parte porque me gustan los números y en parte porque ayudan a que las discusiones en línea se acerquen хотя sea un poco al mundo ideal del último cuadro.

• Gracias por el análisis, pero no estoy convencido de la metodología. Me gustaría ver métricas como el número de bugs por unidad de diferencia, multiplicando por commit las líneas modificadas del código principal —es decir, código que no sea pruebas ni documentación—, y también un análisis del tiempo que tarda en alcanzarse cierta cantidad de bugs después del lanzamiento
  Aun así, parece difícil construir una métrica realmente convincente, porque es muy probable que este lanzamiento haya recibido mucha más atención que otros y, por eso, se hayan reportado más bugs. Preguntas como “¿es típico según cuántas semanas hayan pasado desde el lanzamiento?” quizá tampoco sean muy útiles.