¿Claude aumentó los errores en rsync?

Alcance del problema de rsync / Claude

• Varios comentaristas señalan que rsync tuvo un enorme aumento en commits y un endurecimiento rápido de la seguridad, impulsado por una avalancha de informes de seguridad (a menudo generados por IA).
• Algunos usuarios sufrieron regresiones graves (por ejemplo, copias de seguridad incrementales rotas, alto uso de CPU) y fijaron rsync en versiones anteriores.
• Otros señalan que también hubo regresiones y errores graves en versiones anteriores a las de los LLM y que rsync lleva mucho tiempo siendo una base de código en C compleja y difícil de probar.

Análisis estadístico de errores

• El artículo enlazado analiza “errores por cada 10 commits”, ampliado después con una puntuación de gravedad basada en LLM, a lo largo de muchas versiones.
• La afirmación principal: las dos versiones atribuidas a Claude se encuentran dentro de la variación histórica y no parecen inusualmente propensas a errores, incluso ponderando por gravedad.
• Los críticos sostienen:
  • El conjunto de datos para las “versiones de Claude” son solo dos puntos; el estudio tiene poca potencia.
  • Errores/commit oculta la gravedad y enmascara un gran pico en el volumen de commits.
  • Los valores p no significativos muestran “no hay evidencia de diferencia”, no “evidencia de que no hay diferencia”.
• Los defensores responden que esto sigue siendo más riguroso que las acusaciones originales de que “Claude rompió rsync”, que eran en su mayoría anecdóticas.

Calidad del código y regresiones concretas

• Ejemplo discutido: un cambio que efectivamente convirtió muchas asignaciones en calloc, luego revertido tras regresiones de memoria/CPU. El mantenedor dice que la decisión fue suya, no de Claude, aunque aparece una etiqueta de coautoría de IA.
• Algunos ven esto y cambios similares como emblemáticos de “AI slop” y de una rotación excesiva; otros lo atribuyen a un trabajo de seguridad apresurado bajo una gran carga de informes, independientemente de las herramientas usadas.

LLMs en el desarrollo y atribución

• Muchos desarrolladores dicen que los LLM aumentan significativamente la productividad, especialmente para boilerplate, pruebas y refactorización, pero producen código que debe revisarse como el trabajo de un junior.
• Los revisores se quejan de que los PR generados por IA son grandes, ruidosos y difíciles de razonar, lo que aumenta la carga de revisión.
• Hay un fuerte debate sobre la atribución de commits:
  • Un lado quiere marcadores explícitos de LLM por riesgo, estilo de revisión y procedencia de derechos de autor.
  • Otros argumentan que el responsable es el humano que hace el commit, sin importar las herramientas; el uso no divulgado de LLM no es inherentemente “fraude”.

Reacción a la prosa escrita por IA y el comportamiento de la comunidad

• La prosa inicial escrita por LLM del artículo provocó una fuerte reacción; muchos la describieron como “AI slop” y dijeron que eso por sí solo redujo su confianza.
• Más tarde, el autor reescribió la prosa a mano; algunos entonces la encontraron mucho más legible, otros siguieron siendo escépticos por la elección original y el uso visible de herramientas de IA.
• Varios comentarios lamentan la toxicidad de la indignación, los ataques personales a los mantenedores y el creciente sentimiento de derecho en los usuarios de OSS.