¿Claude aumentó los errores en rsync?

Artículo original ↗ Discusión en Hacker News ↗

Un análisis reciente del historial de errores de rsync intentó comprobar las afirmaciones de que introducir código generado por Claude había empeorado drásticamente la fiabilidad de la herramienta. Los comentaristas debaten el rigor estadístico y las limitaciones del estudio (tamaño de muestra pequeño, errores por commit como métrica tosca, falta de análisis profundo de la gravedad), al tiempo que señalan que el aumento de commits se debe en gran medida a informes de seguridad generados por IA y al trabajo de endurecimiento, no a “vibe coding”. El hilo se amplía a preocupaciones sobre la prosa escrita por IA, la procedencia del código, la responsabilidad legal y ética de los parches generados por LLM, y cómo el desarrollo cada vez más asistido por IA está reconfigurando las expectativas en el mantenimiento de código abierto.

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.