Hat Claude Bugs in rsync verursacht? Eine Datenanalyse

Anfang Juni 2026 entzündete sich eine Kontroverse um rsync: Ein Mastodon-Post suggerierte einen Zusammenhang zwischen Claude-assistierten Commits und Regressionen. Die Empörung verbreitete sich rasch bis auf Hacker News. Doch eine datengestützte Analyse widerlegt die Vorwürfe elegant.

Die Metrik

Die Analyse verwendet “severity-weighted bugs per 10 commits” (sev/10c). Jeder Bug wird auf einer Skala von 0-100 gewichtet, wobei 90-100 Datenverlust oder Korruption darstellen und niedrigere Werte kleinere Fehler abdecken. Die Schwere-Gewichtung verhindert, dass ein Tippfehler und eine CVE gleich gewichtet werden.

Die Daten

• Bug-Quellen: GitHub Issues, rsync Bugzilla, Mailing-Liste
• Zuordnung: Jeder Bug wird dem Release zugeordnet, gegen den er gemeldet wurde
• Zeitraum: Alle rsync-Releases mit verfügbaren Bug-Daten

Das Ergebnis

Die Claude-assistierten Releases v3.4.2 und v3.4.3 fallen beide innerhalb des historischen Interquartilbereichs (IQR). v3.4.2 liegt sogar unter dem Median, v3.4.3 etwas darüber. Keines ist ein statistischer Ausreißer.

Die exakte Permutationstests zeigen: Die Wahrscheinlichkeit, aus der historischen Verteilung equally “schlechte” oder schlechtere Releases zu ziehen, liegt deutlich im normalen Bereich. Die Claude-Releases sind nicht ungewöhnlich buggy – sie sind statistisch unauffällig.

Fazit

Die Empörung basierte auf einer spurious correlation. Ein Nutzer erlebte eine Regression nach einem Upgrade und verknüpfte diese willkürlich mit Claude-Commits. Die Daten zeigen jedoch: Claude hat die Bug-Rate in rsync nicht erhöht. Das ist eine wichtige Lektion über evidenzbasierte Softwarekritik in Zeiten von KI-Unterstützung.