Hat Claude die Zahl der Bugs in rsync erhöht?

• Claude-unterstützte Releases gibt es nur zwei, rsync v3.4.2 und v3.4.3, und es gibt keine Hinweise darauf, dass sie gemessen an schwerengewichteten Bugs pro 10 Commits ungewöhnlich viel fehlerhafter sind als frühere Releases
• sev/10c ist die zentrale Kennzahl: Dabei werden Bug-Schweregrade auf 0 bis 1 normalisiert, pro Release aufsummiert, durch die Zahl der Commits geteilt und auf 10 Commits hochgerechnet
• v3.4.2 hatte 50 Commits, 9 Claude-Commits, 0 Bugs und 0,00 sev/10c; v3.4.3 hatte 34 Commits, 28 Claude-Commits, 17 Bugs und 3,29 sev/10c und liegt beidseits des IQR, ohne dass eines von beiden ein Ausreißer wäre
• Der p-Wert des exakten Permutationstests beträgt 46 %, der p-Wert von Fishers exaktem Test 74 %, bei einer Odds Ratio von 1,06; es gibt also kaum ein Signal dafür, dass Claude-Releases schlechter sind als zwei zufällig gewählte Releases oder häufiger über dem Median liegen
• v3.4.1 war ein Release vor der Einführung von Claude, hatte aber mit 59 Bugs, 9 Commits und 39,39 sev/10c den schlechtesten Wert im gesamten Datensatz; der Kern der rsync-Kontroverse liegt darin, eine einzelne Regression ohne historische Verteilung mit Claude zu verknüpfen

---

Hintergrund und Fragestellung

• Die rsync-Kontroverse Ende Mai 2026 begann mit einem Mastodon-Post, der die Regression in v3.4.3 mit Claude-Commits in diesem Release verknüpfte, und verbreitete sich über Hacker News und das GitHub-Issue "Please Do Not Vibe Fuck Up This Software"; dort sammelten sich mehr als 300 Kommentare
• Die wiederholte Kernthese lautete, dass Claude-unterstützte Entwicklung Bugs in ein zuvor stabiles Tool eingebracht habe; die Datenfrage ist, ob Claude-unterstützte Releases im Vergleich zu historischen Releases ungewöhnlich viele Bugs haben
• Auf Lobsters wurde gefordert, die Zahl der Regressionen pro Release in einem Zeitdiagramm zu betrachten; der Fokus der Analyse ist die einzelne Frage: „Haben Claude-unterstützte Releases ungewöhnlich viele Bugs?“

Datenumfang und Reproduzierbarkeit

• Die Daten umfassen 36 Releases aus RsyncProject/rsync von v2.4.6 bis v3.4.3, für die Bug-Daten vorliegen; Releases mit Claude-Commits gibt es nur zwei: v3.4.2 und v3.4.3
• Auswahl von Kennzahlen, Methodik und Datenquellen erfolgte manuell und unter Einbezug des Rats einer Ehepartnerin mit Masterabschluss in Statistik
• Datenerhebung, Laden in DuckDB, View-Erstellung und Skripte für die statistische Analyse wurden von GLM 5.1 erstellt, aber alle Zahlen, Statistiken, Karten und Grafiken wurden per automatischer Vorlage aus dem Python-Skript eingefügt, das die statistische Analyse ausgeführt hat
• Das Reproduktions-Repository alexispurslane/rsync-analysis kann die komplette Pipeline von Anfang bis Ende ausführen

Kennzahl und Zuordnung der Bugs

• Die zentrale Kennzahl ist die nach Schweregrad gewichtete Zahl der Bugs pro 10 Commits, sev/10c, mit der Formel sev/10c = (Σ severity/100 ÷ total_commits) × 10
• Die Commits werden nach dem committer date des Basis-Branches sortiert; der Bereich eines Releases reicht vom vorherigen Tag bis zum jeweiligen Tag, wobei pre- und rc-Tags an den Grenzen ausgeschlossen und in das finale Release aufgenommen werden
• Quellen der Bugs sind GitHub-Issues, rsync Bugzilla und die rsync-Mailingliste; Bugs aus GitHub-Issues und der Mailingliste werden dem neuesten Release zugeordnet, das unmittelbar vor dem Meldezeitpunkt ausgeliefert wurde
• Bei Bugzilla-Einträgen benennt das Feld „Version“ explizit das Release, in dem der Bug gemeldet wurde; entsprechend werden sie diesem Release zugeordnet
• Der Grund für die Analyse auf Release-Ebene ist, dass die Kritik selbst die Form hat, „gesamte Releases mit Claude-Commits wurden fehlerhafter“, und die meisten Bugs nicht explizit angeben, aus welchem Commit sie genau stammen

Bewertung der Schweregrade

• Alle Bug-Reports wurden von Qwen 3 35B auf einer Skala von 0 bis 100 bewertet; der Prompt wies dem Modell die Rolle eines Senior Reliability Engineers aus Sicht realer Auswirkungen auf Nutzer zu
• 90 bis 100 Punkte stehen für stille Datenkorruption, Datenverlust, Remote Code Execution oder Sicherheitslücken mit unbefugtem Zugriff; 70 bis 89 für Abstürze, Hänger, Backup-Fehler oder Build-Fehler; 50 bis 69 für funktionale Regressionen mit möglichem Workaround
• Bei Bugzilla und der Mailingliste lagen nur Titel ohne Text vor, daher bewertete das Modell nur anhand der Titel; bei unzureichender Information wurde es angewiesen, eher in den mittleren Bereich von 40 bis 60 Punkten zu tendieren
• Die Ausgabe ließ über structured output per JSON-Schema nur ganzzahlige Schweregrade zu; temperature war auf 0 fixiert, damit derselbe Input stets denselben Score ergibt
• Issues mit 0 Punkten, etwa Funktionswünsche, Spam, nichttechnische AI-bezogene Beschwerden oder leere Einreichungen, wurden aus der Basiszahl der Bugs ausgeschlossen

Statistische Ergebnisse der Claude-Releases

• v3.4.2 hatte bei 50 Commits 9 Claude-Commits, 0 tatsächliche Bugs, 0,00 sev/10c und liegt im 0. Perzentil
• v3.4.3 hatte bei 34 Commits 28 Claude-Commits, 17 Bugs, 3,29 sev/10c und liegt im 77. Perzentil
• Der historische IQR liegt bei 0,29 bis 2,59 sev/10c; v3.4.2 liegt knapp darunter, v3.4.3 knapp darüber, sodass beide Releases die mittlere Verteilung auf entgegengesetzten Seiten flankieren
• Der exakte Permutationstest ergibt, dass bei 272 von 595 möglichen Kombinationen aus zwei Releases der Mittelwert der Claude-Gruppe von 1,65 sev/10c erreicht oder überschritten wird; daraus folgt ein p-Wert von 46 %
• Fishers exakter Test prüfte anhand des Medians von 0,74 sev/10c, ob Claude-Releases häufiger oberhalb des Medians liegen, und ergab einen p-Wert von 74 % bei einer Odds Ratio von 1,06

Commit-Zahl und Änderungsumfang

• Claude-Releases hatten im Mittel 42 Commits, Releases ohne Claude im Mittel 185 Commits; die Wahrscheinlichkeit, dass zwei beliebige Releases ebenso viele oder mehr Commits haben, lag bei 88 %
• Gemäß GitHub Compare API lag die Zahl geänderter Zeilen bei Claude-Releases im Mittel bei 3.756, bei Releases ohne Claude im Mittel bei 696; die Wahrscheinlichkeit, dass zwei beliebige Releases ebenso viele oder mehr geänderte Zeilen haben, lag bei 5 %
• Die Zahl schwerengewichteter Bugs lag bei Claude-Releases im Mittel bei 5,6, bei Releases ohne Claude im Mittel bei 14,9; die Wahrscheinlichkeit, dass zwei beliebige Releases ebenso viele oder mehr schwerengewichtete Bugs haben, lag bei 77 %
• Insgesamt hatten Claude-Releases also deutlich mehr geänderte Zeilen, aber nicht mehr Commits und auch nicht mehr schwerengewichtete Bugs

Versionssystem und frühere Ausreißer

• Der Mittelwert der v2.x-Releases liegt bei 1,11 sev/10c, der der v3.x-Releases bei 4,23 sev/10c; v3.x zeigt also generell höhere Bugraten
• Selbst bei einem Vergleich nur innerhalb von v3.x liegen Claude-Releases im Mittelfeld oder besser; damit Claude als Ausreißer erscheint, müsste man mit einer ruhigeren früheren Ära vergleichen und Veränderungen, die schon vor Claude einsetzten, Claude zuschreiben
• Der Wald–Wolfowitz-Runs-Test ergab für 35 Releases ohne Claude 13 beobachtete Runs, einen Zufallserwartungswert von 18,5, z=-1,88 und p=0,060; nach einem 0,05-Kriterium ist das nicht stark genug, um Zufälligkeit zu verwerfen
• v3.4.1 war ein Release vor der Einführung von Claude und verzeichnete dennoch mit 59 Bugs, 9 Commits und 39,39 sev/10c die höchste Bugrate im gesamten Datensatz
• v3.4.1 war ein Hotfix-Release am Tag nach v3.4.0 und zeigte die mit Abstand höchste Bugrate aller Releases, mit mehr als einem einstelligen Abstand zum restlichen Feld, allerdings zu einer Zeit, in der man keine AI verantwortlich machen konnte

Interpretation und Grenzen

• Die mit den Daten konsistente Interpretation lautet: „Die beiden bisherigen Claude-Releases sind statistisch nicht von historischen Releases zu unterscheiden.“
• v3.4.3 liegt mit 3,29 sev/10c im 77. Perzentil und damit zwar relativ hoch, ist aber kein Extremwert; acht historische Releases erzielten höhere Werte
• Die These „Claude hat es eindeutig schlechter gemacht“ wird weder durch die Release-Verteilung noch durch den Permutationstest oder Fishers Test gestützt
• Umgekehrt folgt aus diesen Daten aber auch nicht, dass Claude-Commits künftig im Allgemeinen nichts verschlechtern; die Aussage reicht nur so weit, dass die beiden aktuellen Releases im normalen Bereich liegen
• Die Kennzahl ist ein grobes Instrument und kontrolliert weder für Commit-Komplexität noch für die Intensität von Sicherheitsarbeit

Diskutierte Störfaktoren

• Ein Nutzer auf Hacker News vermutete, dass sicherheitsbezogene CVE-Fixes Programmierfehler offengelegt hätten, die seit 2007 im Code vorhanden waren
• Ein Nutzer auf Lobsters skizzierte die Kausalkette „LLM → mehr bekannte Sicherheitsprobleme → mehr Änderungen als üblich nötig → mehr Regressionen als üblich“
• Andrew Tridgell erklärte, dass eine Flut AI-generierter CVE-Meldungen rasche und weitreichende Änderungen an der Angriffsfläche von rsync erforderlich gemacht habe
• Berücksichtigt man auch diesen Störfaktor, liegt das Problem eher nicht bei Claude selbst, sondern bei umfangreicherer Sicherheitsarbeit und der daraus resultierenden größeren Änderungsmenge

[GN⁺]

Hacker-News-Kommentare

• Beim Durchsehen der Commits sind mir der ursprüngliche Commit und der Revert aufgefallen: https://github.com/RsyncProject/rsync/commit/d046525de39315d...
  Sogar Pfade, die malloc hätten sein sollen, wurden auf calloc umgestellt, wodurch alle Allokationen so behandelt wurden, als wäre calloc eine strikt aufwärtskompatible Obermenge. Bei großen oder rekursiven Allokationen kann das ziemlich teuer werden. Das wirkt wie ein gutes Beispiel dafür, wie so etwas in mit Claude geschriebenem Code durch die Kontrolle rutschen kann. Der Revert steht hier: https://github.com/RsyncProject/rsync/commit/7db73ad9a1b8721..., und schon beim halbherzigen Lesen der Revert-Erklärung merkt man, dass sie nach LLM klingt. Ich kann die Stimmung des ursprünglichen Posters nachvollziehen

  • Auch die schiere Zahl der Commits wirkt verdächtig. In den letzten zwei Monaten sind ungefähr so viele Commits in rsync gelandet wie in den vorherigen zwei Jahren, und die meisten davon wurden mit Claude erstellt. Dass sogar solche Änderungen hineingeraten sind, sieht für mich nach dem typischen Muster aus, dass man vom Einsatz von AI begeistert ist und dabei zunehmend unvorsichtig wird
  • „Mit Claude erstellt“ trifft es nicht. Der Revert-Commit verweist auf https://github.com/RsyncProject/rsync/issues/959, und dort erklärt der Autor selbst: „Die Änderung, Speicher auf 0 zu setzen, war meine Idee und meine Änderung.“
    In einem Security-Report ging es um die Verwendung eines Elements hinter dem Ende eines Arrays, und seine Einschätzung war, dass eine null-initialisierte Allokation dazu führt, dass ein ähnlicher Bug in Zukunft eher in einer Null-Pointer-Dereferenz als in der Nutzung eines gültigen Zeigers endet. Claude wurde nur zum Aufräumen des Commit-Bundles verwendet, und da schon kleine Bearbeitungen ein Co-Authored-Tag hinzufügen, bedeutet das nicht, dass Claude die Änderung geschrieben hat. Er sagt ausdrücklich, dass er den eigentlichen Code selbst geschrieben hat
  • Ich würde nicht einfach annehmen, dass Claude diese Entscheidung getroffen hat. Es war keine heimlich in einen großen Commit eingeschmuggelte Nebenänderung; schon die Commit-Message beginnt mit „Allen neu allozierten Speicher auf 0 initialisieren“, und genau das macht der Commit auch. Ich weiß nicht, welches Prompt man sich dabei ursprünglich vorstellt
    Es ist gut möglich, dass ein Mensch das zuerst für eine Verbesserung hielt und nach einer RSS-Regression dann umgedacht hat. Und es ist auch kein Naturgesetz, dass diese Änderung RSS zwangsläufig erhöhen muss. calloc kann Sonderbehandlungen nutzen, weil das Betriebssystem frisch zugewiesene Memory-Mappings oft ohnehin bereits auf 0 initialisiert. Wenn man hier AI die Schuld gibt, dann eher in dem Sinn, dass AI zu einer Flut von Schwachstellenmeldungen führt, daraus eine Flut hastiger Fixes entsteht und hastige Fixes gelegentlich andere Probleme verursachen
  • Was für eine Zeit, in der auch noch Linux-Overcommit mit AI multipliziert wird. Persönlich finde ich 10,8 GB heute nicht einmal besonders viel, und der sprintf-Puffer könnte sogar noch größer sein. Wenn nicht, sollte er es sein, und wenn nicht, sollte man anfangen, snprintf zu verwenden

• Ich würde empfehlen, vor dem Kommentieren den vom rsync-Autor verlinkten Text zu lesen: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0
  Zur Offenlegung: Ich habe seit einigen Jahren keinen Kontakt mehr zu Tridge, aber er war lange ein Kollege und Mentor von mir. Bevor man sich dem Kreuzzug anschließt, lohnt es sich, seine Perspektive zu berücksichtigen

  • Das sollte der Top-Kommentar sein. Dass er überhaupt gezwungen war, so einen Text zu schreiben, ist ziemlich traurig. Leute, die nicht einmal seine Rechnungen bezahlen, urteilen hier viel zu viel
  • Ich verstehe die Stelle „Ich hielt es für besser, die Kernstruktur der neuen Test-Suite zuerst öffentlich auf master aufzubauen“ nicht vollständig. Wenn er nur die Tests aktualisiert oder nur auf master gepusht hätte, wären die Leute wohl nicht wütend geworden
    Aber er hat auch kaputte Änderungen in den Release-Branch gepusht. Einen Workflow kaputtzumachen, der jahrelang funktioniert hat, ist der sicherste Weg, Leute zu verärgern, und wenn dann im Commit auch noch „Claude“ auftaucht, gießt das nur Öl ins Feuer
  • Ich finde, seine Antwort ist wirklich eine sehr gut geschriebene Reaktion

• Ich habe in diesem Streit zwar nichts direkt zu gewinnen oder zu verlieren, aber ein paar Dinge wirken verdächtig. Das Release, dem die meisten Bugs zugeschrieben werden, ist das Januar-Release direkt vor dem ersten Release mit einem von Claude mitverfassten Commit; ich frage mich, ob es möglich ist, dass in dieses Release von LLMs verfasste Commits ohne entsprechende Kennzeichnung eingeflossen sind
  Auch die Methodik zur Zuordnung von Releases überzeugt nicht besonders. Bugs, die in einem Minor-Update eingeführt wurden, werden tendenziell dem Patch-Release dieser Minor-Version zugeschrieben, das am längsten Bestand hatte. Es ist schwer zu glauben, dass 3.4.1 tatsächlich besonders viele Bugs eingeführt hat; da es schon am Tag nach 3.4.0 erschien, wurden Bugs aus diesem Release vermutlich als 3.4.1 erfasst. Außerdem hatten neuere Releases weniger Zeit, damit Bugs gemeldet werden konnten, was zu einer Verzerrung führen könnte, bei der neuere Releases als weniger fehlerhaft erscheinen

  • Stimme zu. Die Formulierung im Artikel, „das schlechteste Release in der Geschichte von rsync lag vor der Einführung von Claude, und niemand hat es bemerkt“, vermittelt mir weniger den Eindruck, dass der Autor in diesem Streit keine Eigeninteressen hat, sondern eher, dass er seine Meinung in schillernde Statistikbegriffe einwickelt
    „Blendend klar“? Dafür reicht ein einzelnes Diagramm. Und v3.4.1 ist vom 2025-01-16, liegt also technisch gesehen bereits in der Ära des AI-unterstützten Codings und stammt aus einer Zeit, bevor solche Kennzeichnungen gängige Praxis waren
  • Angesichts der recht seltenen Releases habe ich angefangen, mir denselben Punkt anzusehen. Um das Problem nicht gekennzeichneter, von LLMs verfasster Commits zu vermeiden, sollte die Analyse meiner Meinung nach einen Vergleich der Bug-Schwere vor und nach v3.3.0 enthalten. Das Datum ist der 6. April 2024
  • LLMs können auf viele Arten eingesetzt werden. Das reicht von sehr direkter menschlicher Steuerung mit nur lokalen Änderungen bis hin zu vollständiger Delegation
    Ich habe viel von LLMs erzeugten Code gesehen, bei dem in der Commit-Message kein Co-Autor angegeben war. Solche Tags scheinen in der Regel nur dann aufzutauchen, wenn die Schnittstelle zum Codebestand vollständig über Tools wie Claude/Codex läuft, und solche Commits sind meist die ausschweifendsten, sagen aber fast nichts darüber, warum etwas geändert wurde, sondern fassen nur die Codeänderungen zusammen. Andererseits habe ich auch Entwickler gesehen, die Claude wirklich als Werkzeug verwenden: Sie wechseln zwischen VSCode und dem Claude-Terminal, prüfen den korrekten Code selbst und überlassen Claude nur die Klempnerarbeit. Vielleicht hat auch der Autor klein angefangen und den Einsatz mit der Zeit ausgeweitet
  • Der erste und der zweite Punkt wirken widersprüchlich. Wenn alle Bugs von 3.4.1 eigentlich 3.4.0 zugeschrieben werden müssten, dann müsste der Zeitpunkt, zu dem unmarkierte LLM-Commits ins Projekt gelangten, noch weiter nach vorn rücken, und damit würde die Hypothese nur noch abwegiger
    Das größere Problem ist, dass es überhaupt keine Belege für die Hypothese gibt, dass sich in frühere Releases heimlich LLM-Commits eingeschlichen haben und deshalb die Bug-Rate höher war. Es gibt keine Grundlage dafür, außer man setzt voraus, dass eine hohe Zahl von Bugs automatisch auf AI-Beteiligung hindeutet — und das wäre ein Zirkelschluss. Der dritte Punkt ist stichhaltig. Ich habe analysiert, wie lange es typischerweise dauert, Bugs zu finden, und wo jede Version im Release-Zyklus stand; wenn gewünscht, kann ich das posten
  • Der offenkundigste verblüffende Fehler ist wohl, dass die Claude-Statistik auf ganzen 2 Datenpunkten beruht

• Hier gibt es eine wichtige Meta-Ironie. Der ursprüngliche Artikel verteidigt die Nutzung von AI, aber bei der Analyse der Daten und der Darstellung der Ergebnisse scheint ebenfalls offensichtlich AI verwendet worden zu sein
  Dabei hat der Autor Statistik auf eine Weise eingesetzt, die er offenbar nicht gut versteht, und ist zu mehreren falschen Schlussfolgerungen gelangt. Die zugehörige Diskussion findet sich unter https://news.ycombinator.com/item?id=48417626. Kurz gesagt hat diese Studie nicht genug statistische Aussagekraft und behauptet unbegründet, es gebe „keinen Unterschied“. Am Ende hat man also LLMs zur Interpretation von Daten verwendet und dabei genau die Art von Fehler gemacht, die diese Untersuchung eigentlich erfassen wollte: nämlich Unwahrheiten mit großem Selbstvertrauen zu behaupten

  • AI ist zu sehr wie eine Religion. Egal, was man Gläubigen sagt, es bringt sie nicht dazu, ihren Glauben infrage zu stellen. Allgemeiner gesagt: Man kann niemanden durch Vernunft dazu bringen, etwas aufzugeben, das er glauben will

• Ich glaube, das Einzige, was wütende Leute hier erreichen, wenn sie den rsync-Maintainer unter Druck setzen, ist, dass andere ihre AI-Nutzung nicht mehr verantwortungsvoll offenlegen. Um Kontroversen zu vermeiden, werden sie einfach die Claude-Zuschreibung in Commits abschalten

  • Die Offenlegung von AI-Nutzung ist mir ziemlich egal. Wenn ich die Person nicht persönlich kenne, glaube ich nicht, dass von Menschen geschriebener Code zwangsläufig besser ist als von AI erzeugter Code
    Am Ende muss ohnehin ein Mensch die Verantwortung für den Code übernehmen, den er committet und pusht. Das war schon immer so. Ob er von Hand geschrieben wurde, dadurch entstanden ist, dass eine Katze über die Tastatur gelaufen ist, oder von AI erzeugt wurde, interessiert mich nicht. Die Codequalität eines Projekts kann aus allen möglichen Gründen sinken, und sich allein darauf zu versteifen, ob AI im Spiel war, ist nicht produktiv. Wenn jemand einen Vorwand sucht, um AI zu kritisieren, und jemand anderes AI verteidigen will, bitte — aber zur Bewertung der Codequalität eines Projekts taugt das nicht
  • Unabhängig von der Kontroverse ist es richtig, solche Kennzeichnungen abzuschalten. Es gibt keinen Grund, Billionenunternehmen kostenlose Werbung zu machen. Trailer wie Generated-by sind nur relevant, wenn man zu Projekten Dritter beiträgt; dann ist eine Offenlegung höflich
  • Das klingt nach: „Reg dich nicht darüber auf, dass ich etwas Unethisches oder Unmoralisches getan habe, sonst werde ich etwas noch Unethischeres oder Unmoralischeres tun!“
    Die Zuschreibung für von LLMs erzeugten Code abzuschalten, ist Betrug. Es läuft darauf hinaus zu behaupten, man habe den Code selbst geschrieben. Das passt natürlich gut dazu, überhaupt Code mit LLMs zu erzeugen. In der Praxis ist das nur ein Wiederkäuen von Eingaben, bei dem Lizenz- und Copyright-Hinweise entfernt wurden
  • Ich bin nicht sicher, ob das etwas Schlechtes ist. Aus Sicht der Marketingabteilung von Anthropic vielleicht, aber wenn der Agent einfach nur ein weiteres Werkzeug im Werkzeugkasten eines Entwicklers ist, wirkt so eine Zuschreibung etwas seltsam. Letztlich liegt die Verantwortung für den Commit beim Entwickler
  • Diese Argumentation kommt jedes Mal wieder, überzeugt aber nicht. Es stimmt schon, dass öffentliches Ansprechen einen Anreiz schafft, Dinge zu verbergen, aber ich weiß nicht, was daraus folgen soll
    Lassen wir die Debatte darüber, ob AI schlecht ist, kurz beiseite: Als Analogie ist Steuerhinterziehung schlecht und unethisch, und wenn man sie sieht, sollte man sie benennen. Dass dadurch ein Anreiz entsteht, sie zu verbergen, führt nicht zu dem Schluss, dass man lieber nichts sagen und den Mund halten sollte

• Ich bin Andrew dankbar für alles, was er beim Aufbau und der Pflege von rsync geleistet hat, aber weil ich rsync im Heimnetz stark für Datei-Backups zwischen Rechnern nutze, habe ich mir die Zeit genommen herauszufinden, wie man die Homebrew-Version von rsync auf 3.4.1 festpinnt
  Die Bugs in den beiden folgenden Versionen sind wirklich beängstigend, und ebenso der ursprüngliche Bericht, der das alles ausgelöst hat. Die Vorgehensweise war deutlich komplizierter, als ich erwartet hatte; ich habe sie hier dokumentiert: https://gist.github.com/e40/caa67c1b8d439a528695f996d0519d8e

• Dieser Beitrag lässt mehr Fragen als Antworten offen, daher ist es schwer, zu einem Urteil zu kommen. Ich verstehe nicht, warum ausgerechnet v3.4.1 direkt vor dem Claude-Commit die meisten Bugs hatte und warum „niemand es bemerkt hat“. Das einfach als menschlichen Fehler abzutun, wirkt zu seltsam.
  Außerdem ist fraglich, warum v3.4.2 entweder 0 Bugs oder einen Bug-Score von 0 hat. Es wirkt ebenfalls seltsam, dass solche Ausreißer, die bei anderen Commits nicht aufzutreten scheinen, in die aggregierte Statistik einfließen durften und so den Score „Claude erzeugt Bugs?“ nach unten ziehen. Ehrlich gesagt verstehe ich nicht, warum das in der Analyse des Autors kein Warnsignal war. Es fühlt sich an, als würde eine halbgare Analyse nur deshalb wie ein sehr komplexes, fertiges Werk präsentiert, weil fortgeschrittene Statistik darauf angewendet wurde

  • Ich sehe nicht, aus welchem Grund man annehmen sollte, dass v3.4.1 kein menschlicher Fehler war, außer aufgrund der vorgängigen Annahme, dass es nicht so gewesen sein könne
    Auch v3.4.2 hatte in den ursprünglichen Metriken 4 Bugs, bevor Feature Requests und Fragen herausgefiltert wurden, und davor lag der Wert sogar noch höher, aber das machte für die Gesamtanalyse keinen großen Unterschied. Es lag innerhalb des Interquartilsabstands, und zwar klar im unteren Bereich. In einer Situation, in der es nur zwei Claude-Releases gibt, wäre es meiner Meinung nach schlechter und willkürlicher, einen Ausreißer einfach zu entfernen, nur weil er komisch aussieht

• Wenn die Haltung lautet: „Commit-Komplexität, Sicherheitsfokus und Bug-Schweregrad werden nicht kontrolliert. Es ist ein stumpfes Instrument, das einen Ein-Zeilen-Tippfehler-Fix nicht von einem CVE-Patch unterscheidet. Aber weil auch die Vorwürfe der Kritiker, Claude verschlimmere die Lage, stumpf sind, ist ein stumpfes Instrument die fairste Antwort“, dann fällt es mir schwer, zuzustimmen
  Aus Sicht der Nutzer muss man verstehen, ob die Art der Bugs schlimmer geworden ist. Selbst wenn das Verhältnis gleich bleibt: Wenn die wahrgenommene Softwarequalität gesunken ist, würden viele das als Verschlechterung ansehen, besonders Projekt-Maintainer. Ich will diese Analyse nicht völlig ignorieren, aber ich glaube, solche Fragen lassen sich nur schwer allein mit quantitativer Analyse ausreichend beantworten

  • Ich halte es trotzdem für fair. Ich habe bisher niemanden gesehen, der den Code analysiert und gesagt hat, wie viele Regressionen welcher Schwere aufgetreten sind. Stattdessen heißt es nur: „Wegen LLMs gibt es mehr Bugs“
    Diese Analyse kann man, wenn man will, selbst überprüfen, und sie sagt: „Selbst mit LLMs ist die Zahl der Bugs ziemlich durchschnittlich.“ Auf diese Behauptung antwortet sie also direkt. Wenn jemand eine differenziertere Analyse möchte, kann er sie selbst machen und die Ergebnisse teilen
  • Was ohne Belege behauptet wurde, kann ohne Belege verworfen werden. Diese Analyse hat mehr Evidenz und mehr Strenge als die ursprüngliche Behauptung. Mir reicht das. Es wäre gut, wenn tatsächlich jemand die ursprüngliche Behauptung mit besseren Belegen untermauern würde, und ich würde das gern sehen. Bis dahin mache ich mir darüber keine Sorgen
  • Liegt die Beweislast nicht bei der Person, die die Behauptung aufstellt?

• Ich programmiere seit über 20 Jahren, habe es immer geliebt und werde es wahrscheinlich auch weiterhin tun. Noch vor ein paar Monaten war ich AI-Skeptiker, aber Claude und Codex haben meine Art zu entwickeln und mein Tempo auf eine Weise verändert, die ich mir nie hätte vorstellen können
  Das Ergebnis ist, dass ich mehr Code produziere und auch mehr Bugs finde. Deshalb überrascht mich der extreme Hass auf AI-Erzeugtes in HN-Kommentaren ziemlich. Nur weil etwas mit Hilfe von AI entstanden ist oder vollständig generiert wurde, wird ein Projekt nicht plötzlich zu vibe coding, und dieser Ausdruck sollte auch keine Beleidigung sein, die man LLM-Nutzern an den Kopf wirft. Das erinnert mich stark an die verächtlichen Formulierungen, die seit Mitte der 90er im Zuge zunehmender Offshore-Outsourcing-Entwicklung auf „indische Entwickler“ abzielten. Mitte der 2020er kommen nun ähnliche Sprüche gegenüber AI auf. Ich verstehe das nicht. Sicher ist nur, dass unabhängig von den Gegnern immer mehr Code von AI erzeugt werden wird

  • Ich war vor 3 Jahren ähnlich AI-skeptisch. Als GPT-4 State of the Art war, dachte ich wegen der Kontextgrößenbegrenzung, dass es bald stagnieren würde. Ich erinnere mich noch an die Zeit, als man absurd viel Geld bezahlen musste, um 32K Kontext zu nutzen
    Letztes Jahr habe ich zum ersten Mal gesehen, wie ein AI-Agent einen nichttrivialen Bug zufriedenstellend debuggt und behebt. Selbst damals war klar, dass das für große Aufgaben noch nicht ausreichte, also nicht auf einem Niveau war, bei dem man dem Modell einfach den gesamten Issue-Tracker übergeben könnte. Jetzt arbeite ich seit einigen Monaten mit Codex an einem nichttrivialen Projekt. Aus Bibliotheksgründen habe ich einen Prototyp in C++ gebaut, die erste Version in Haskell geschrieben und das Ganze zuletzt nach Rust portiert, um den Speicherverbrauch auf Mobilgeräten zu senken. Es ist kein fehlerfreies Werkzeug, aber das Tempo des Fortschritts allein im letzten Jahr ist erstaunlich. Skepsis ist gut, aber gesunde Skepsis sollte sich angesichts konkreter Belege zurücknehmen
  • Bei jedem Thema rund um Werkzeuge gibt es Menschen, die das Werkzeug selbst mögen, und Menschen, die es mögen, mit dem Werkzeug etwas anderes zu tun. Beim Programmieren gehörte ich zur zweiten Gruppe. Programmieren ist für mich ein Werkzeug, das das ermöglicht, was ich wirklich mag: Probleme lösen, auf Systemebene denken und mit Software elegante Lösungen liefern
    Deshalb macht es mir wirklich Spaß, dass AI die langweiligen Teile übernimmt, und es ist auch sehr unterhaltsam zu sehen, wie nichtprogrammierende Kollegen begeistert sind, wenn ihre vibe coded Ideen Wirklichkeit werden. Mich würde die anti-AI-Haltung von Menschen, die in der Softwarebranche arbeiten, ehrlich interessieren. Geht es um das drohende Ende des Berufs oder um einen technologischen Wandel?
  • Wenn es seit Mitte der 90er verächtliche Formulierungen gegenüber „indischen Entwicklern“ gab, als Offshore-Outsourcing zunahm, was war der Auslöser dafür?
  • Ich habe ständig mit Outsourcing-Code zu tun, und er ist ausnahmslos ein Dumpster Fire. Ich habe gerade erst eine Woche damit verbracht, eine Codebasis aufzuräumen, in die irgendein Entwickler standardmäßig aktivierte Flags eingecheckt hatte, die Authentifizierungsprüfungen umgehen, weil er seine lokale Arbeitsumgebung nicht einrichten konnte
    Dasselbe Problem von „Abkürzungen“ wird auch beim AI-vibe-coding berichtet, und selbst ich musste fast allen von AI generierten Code neu schreiben, obwohl ich Frontier-Modelle mit Denkstufe 11 eingesetzt habe. Trotzdem ist AI für andere Tätigkeiten wie PR-Reviews, die Analyse von Sicherheitslücken, das Finden von Tippfehlern und Reverse Engineering sehr nützlich. Vermutlich sollte ich mein Abo auf die nächste Stufe upgraden, aber gleichzeitig bleibt AI-generierter Code für mich unbrauchbar. Wenn in einer einzigen Person zugleich „so nützlich, dass ich mehr Geld dafür zahlen sollte“ und „die Qualität des ausgegebenen Codes ist unbrauchbar“ koexistieren können, ist es nur natürlich, dass es in der gesamten Nutzerschaft unterschiedliche Meinungen gibt
  • LLMs sind gut für Kontextsuche und Template-Ausgabe. Aber garantiert ist letztlich nur die auffälligste Antwort des kleinsten gemeinsamen Nenners, dazu Outputs ohne urheberrechtlichen Schutz und potenzielle rechtliche Risiken durch Copyright-Leaks
    Im Moment ist das das Napster-Goldene Zeitalter des isomorphen Plagiats

• Ich frage mich wirklich, was das hier eigentlich sein soll. Was tatsächlich zählt, ist einzig, ob nach der Zulassung von AI-geschriebenem Code in die Codebasis mehr Bugs aufgetreten sind. Die Antwort kennen alle. Trotzdem ist es immer interessant zu sehen, wie sich mit „Daten“ Schlussfolgerungen konstruieren lassen, für die sie gebraucht werden können

[GN⁺]

Lobste.rs-Meinungen

• Ich denke, jeder kann für sich entscheiden, ob er FOSS-Projekte weiter nutzen will, die künftig per Vibe Coding entwickelt werden. Allerdings war ich ziemlich überrascht, wie wütend die Community reagierte, nachdem der Maintainer auf Vibe-Coding-Tools umgestiegen war, und die im Artikel gezeigten empirischen Daten helfen zumindest dabei, die Auswirkungen dieses Praxiswechsels besser einzuordnen
  Ob das Vertrauen erhalten bleibt oder durch die Übernahme dieser Coding-Methode weiter beschädigt wird, wird sich erst mit der Zeit zeigen

  • Ich frage mich, wie viele der Leute, die über diesen Wechsel verärgert waren, tatsächlich substanziell zu rsync beigetragen oder Geld dafür bezahlt haben

• Diese Analyse war genau das, was ich mir erhofft hatte, und noch mehr. Besonders gut fand ich den Teil „Alle Metriken, die Methodik und die Datenquellen habe ich selbst ausgewählt, nachdem ich sie mit meiner Frau besprochen hatte, die einen Master in Statistik von der Penn State University hat“, und dass ein echter Statistikexperte eingebunden wurde und der Text gut lesbar ist
  Es wurde zwar nur die einzelne Kennzahl „Bugs pro 10 Commits“ verwendet, aber damit wurde die Gelegenheit verpasst, mit SI-Präfixen von Dezibugs pro Commit zu sprechen

  • Stimme zu. Es ist nicht mein Text, aber ich fand es gut, dass jemand jenseits der überhitzten Pro-und-Contra-Debatte mit Daten gezeigt hat, welchen Einfluss das auf die Codequalität hatte

• Der Erfolg von Open-Source-Projekten hängt so stark von der Wahrnehmung ab, dass Leute sogar GitHub-Stars kaufen. Leider ist dieses Wahrnehmungsproblem diesmal außer Kontrolle geraten und zu einem Talking Point geworden, und irgendwelche Daten werden das kaum ändern
  Künftig wird die Aussage „Der rsync-Maintainer hat ein LLM benutzt und es kaputtgemacht“ wohl von AI-Skeptikern zusammen mit Talking Points wie „Datacenter verschwenden pro Tag 500.000 Gallonen sauberes Wasser“ oder „METR-Forschung hat gezeigt, dass LLMs die Produktivität senken“ hervorgeholt werden
  Ich will damit nicht sagen, ob ich ein AI-Skeptiker bin oder nicht, sondern nur, dass Debatten zu diesem Thema normalerweise so verlaufen

  • Warum ist das ein „Talking Point“ und nicht einfach eine Tatsache?
  • Ich weiß nicht, ob der Autor mit Daten irgendjemanden überzeugen wollte. Ich sehe den Text eher als Datenkontext für die hitzige Debatte um die Tool-Einführung bei rsync
    Es stimmt aber, dass andere nicht quantitative Faktoren im Text komplett fehlen, und vermutlich war das Absicht, weil es auf Seiten der Evangelisten wie der Skeptiker schon genug Lärm gibt

• Dass der schlimmste Release in der Geschichte von rsync noch vor der Einführung von Claude lag und 39,39 Bugs pro 10 Commits hatte, ist ein sehr wichtiger und vorhersehbarer Befund
  Wenn Prozesse wie Tests und Qualitätssicherung zwischen Nutzern und Entwicklern die Korrektheit von Software nicht sicherstellen, werden Bugs ausgeliefert, egal ob ein LLM im Spiel ist oder nicht. LLMs können diesem Prozess schaden oder auch helfen

  • Stimme zu. Ein aktueller Beitrag zu cURL scheint das Gegenbeispiel zu zeigen
    Dank starker Software-Engineering-Praktiken, die dort schon seit Jahren etabliert sind, ist der generelle Nutzen ähnlicher AI-Tools beim Finden von Bugs eher gering geworden
  • Ich habe einige Sorgen bezüglich der Zukunft von rsync. Das größte Problem ist, dass rsync im Grunde schon seit Jahren ein abgeschlossenes Projekt war, dann mit AI die bestehende Testbasis herausgerissen und durch eine Python-Test-Suite ersetzt wurde und über längere Zeit keine parallele Validierung mit den bisherigen Tests stattfand
    Nach meinem Maßstab ist das verantwortungslos. Vor allem, weil rsync in erster Linie dazu dient, wertvolle Daten zu übertragen, und die Integrität dieser Daten absolut entscheidend ist

• Ich wünschte, man würde Formulierungen wie „Wie typisch für AI-Gegner, eskalierte es am Ende zu Gewaltfantasien“ vermeiden. Das verallgemeinert nicht nur einige Leute, denen der Autor nicht zustimmt, sondern schreckt auch Leser ab, die ohnehin anderer Meinung sind, sodass gerade die Leute, die den Text am ehesten lesen sollten, ihn dann nicht lesen
  Unabhängig davon ist es mir ziemlich egal, ob diese Version mehr oder weniger Bugs hat als frühere. Was für mich zählt, ist, dass sie auf eine Weise entwickelt wird, die nicht mit meinem Verständnis von Softwareentwicklung übereinstimmt. Wenn man nicht das grundlegende Verständnis dafür hat, dass es neben Effizienz noch andere Probleme gibt, erwarte ich nicht, jemanden davon überzeugen zu können, dass diese Position vernünftig ist
  Zum Glück muss man diese Version von rsync nicht verwenden, wenn man nicht will, und ich werde eine Alternative wählen, die vor dem Einsatz von LLMs abgespalten wurde

  • Dieser Text ist so voller Wut, dass ich ihn nicht lange lesen konnte und irgendwann aufgegeben habe. Es wäre besser gewesen, wenn er fairer gewesen wäre oder zumindest so gewirkt hätte
    Auch die Wiederholung eines Mems, das schon vor langer Zeit widerlegt wurde, nämlich dass der erste Bugreport ein Issue gewesen sei, auf das sich alle gestürzt hätten, war nicht hilfreich. Den tatsächlichen ersten Bugreport gab es separat

• Ich finde den aktuellen Text ehrlich gesagt besser. Allerdings verfehlt die Passage „Diese Metrik kontrolliert weder Commit-Komplexität noch Sicherheitsrelevanz oder Fehlerschwere. Sie ist ein stumpfes Werkzeug, das einen Ein-Zeilen-Tippfehler-Fix nicht von einem CVE-Patch unterscheiden kann“ aus meiner Sicht, die eher auf der Seite LLMs sind schlecht steht, die zentrale Kritik.
  Die Kritik, die ich und andere vorbringen, ist, dass AI dazu führt, dass größere, schwerer verständliche Commits herausgepumpt werden, die die Komplexität erhöhen. Auch LLM-Befürworter sagen oft etwas Ähnliches und verschieben dann die Torpfosten von der jahrzehntelang bewährten Praxis des „PR-Lesens“ zu „das LLM sollte alles testen können“. Aber das Problem, dass Code-Komplexität technische Schulden bedeutet, verschwindet dadurch nicht.
  In diesem Fall ist die Fehlerschwere sehr hoch. Denn der Backup-Workflow wurde tatsächlich kaputtgemacht. rsync wird breit für Backups eingesetzt, und die Leute haben es als so „kampferprobtes“ Werkzeug angesehen, dass sie sich kaum vorstellen konnten, dass ein Patch-Update Backup-Skripte kaputtmachen könnte.
  Man kann sagen, dass es Zufall war, dass das LLM fehlerhafte Software erzeugt hat, oder dass der Maintainer den LLM-Workflow ändern und die Testabdeckung erhöhen müsse. Tatsächlich hat der Maintainer das auch gesagt. Aber der Kern der Wut liegt darin, dass dieses Tool dieses Vertrauen gebrochen hat.
  Tatsächlich gibt es inzwischen eine neue Art von LLM-Programmierern, die sagen, sie „lesen den Code überhaupt nicht“. Es dauere zu lange und sei komplexer zu durchschauen als Code von normalen Programmierern. Code zu lesen bedeutet, das mentale Modell anderer Menschen zu lernen, aber LLM-Tools liefern kein einziges konsistentes mentales Modell.
  Unabhängig davon sollte auch die Zugänglichkeit der Website geprüft werden. Ich sehe ziemlich gut und bin Ende 20, aber hellgrauer Text auf creme-/gelbem Hintergrund ist wirklich schmerzhaft zu lesen.

  • Die zitierte Stelle verwirrt mich. Die im Artikel verwendete Metrik scheint die Zahl der Bugs pro 10 Commits mit einer Schweregewichtung zu versehen. Widerspricht sich der Autor da selbst? Oder habe ich es falsch gelesen?
  • Für die Leute, deren Workflow kaputtgegangen ist, ist das vielleicht eine gute Gelegenheit zu lernen, was Open-Source-Software und die GPL-Lizenz sind und welche Garantien sie geben.
    Ich glaube nicht, dass die Leute diesen Bug selbst entdeckt hätten. Ich vermute, dass über 90 % der rsync-Nutzer noch eine ältere Version ohne diesen Bug verwenden. Ich gehöre auch dazu.

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

    Dass das so viel Aufmerksamkeit auf sich zieht, ist auch ohne Steven Pinker nachvollziehbar, weil gerade ein großer Teil der Community in Verwirrung steckt. Dass LLMs besser programmieren als Menschen, ist nicht leicht zu akzeptieren.
    Menschen, die ihre Identität und ihr Selbstwertgefühl auf ihre Programmierfähigkeiten oder ihren Beruf gegründet haben, erleben nun eine doppelte Krise: Unsicherheit über den künftigen Lebensunterhalt bzw. Marktwert und eine Identitätskrise.
    Angst, Unsicherheit und Zweifel sind schwer zu bewältigen, und die LLM-Firmen tun ihr Bestes, diese Effekte zur Kurssteigerung ihrer Aktien zu verstärken. Wenn sich der Markt nach Oktober stark korrigiert, könnte auch dieser Verstärker schwächer werden.
    Der sehr kleine Anteil der Programmierer weltweit, der Code als Kunstform betrachtet, wird LLMs vermutlich für Training und zur Verbesserung der eigenen Fähigkeiten nutzen.

• Der Artikel zitiert viele Kommentare, die von Regressionen sprechen, aber die Analyse selbst misst keine Regressionen, sondern nur Bug-Reports. Sie ordnet Bugs der Release zu, in der sie gemeldet wurden, nicht der Release, in der sie eingeführt wurden, und misst die Schwere einer Release an der Zahl der Commits, während offensichtliche Faktoren wie Release-Dauer oder Distributions-Adoption ausgelassen werden.
  Ich verstehe nicht, wie das sinnvoll sein soll.

• Ich persönlich meide Projekte, die LLMs verwenden. Nicht weil ich dafür einen besonders sachlichen Grund hätte, sondern einfach weil es sich sehr unangenehm anfühlt, ähnlich wie wenn jemand „kek“ oder „fren“ sagt und ich das ohne großen Grund als Signal lese, lieber nicht weiter zu interagieren.
  Die Erklärungen, die derzeit dafür gegeben werden, warum Leute LLM-Nutzung nicht mögen, wirken auf mich wie nachträglich aufgesetzte Rationalisierungen. Die aktuellen Sorgen um Ethik, Qualität usw. sind berechtigt, aber selbst wenn diese Probleme gelöst würden, würden Leute wie ich mit anti-AI-Neigung das wohl nicht plötzlich okay finden.
  Deshalb meide ich Projekte mit „AGENTS.md“ oder von Claude mitverfassten Commits ohne einen konkreten Grund. Es ist einfach unangenehm, trifft nicht meinen Geschmack, und ob es Bugs gibt oder nicht, ist mir dabei egal. Ich vermute, dass andere das ähnlich empfinden.

• An den Autor gerichtet: Erstens ist Fantasie Sprache. In Wirklichkeit behauptest du also, es sei bei Sprache stehengeblieben, oder zumindest behauptest du nicht, dass es zu einer nichtsprachlichen Eskalation gekommen sei.
  Zweitens solltest du, wenn du so eine Behauptung aufstellen willst, einen Statistikexperten in deiner Nähe fragen, wie man sie stützen kann. Nur weil ein paar Leute solche Posts verfasst haben, lässt sich die Behauptung, das sei „typisch“, nicht sinnvoll belegen.
  Meine nicht statistisch untermauerte anekdotische Beobachtung ist, dass „anti-AI“-Nutzer eher traurig darüber sind, dass LLMs sich dort einmischen, wo sie nicht helfen, als dass sie darauf überwiegend aggressiv reagieren.

  • Gelegentlich sehe ich sehr ausführliche und detaillierte Texte, die einen Teil der LLM-Gegner widerlegen sollen, meist diejenigen, die emotional oder sozial auf LLMs reagieren. Solche Texte wirken auf mich sehr unaufrichtig, auch wenn ich schwer genau erklären kann, warum, und sie fühlen sich an, als würde man nach unten treten.
    Sie sind so detailliert, dass man aus einer emotionalen Perspektive kaum dagegenhalten kann, und am Ende läuft es darauf hinaus: „LLMs sind nicht das Problem, wenn man sie richtig einsetzt, sind sie ein Verstärker. Die AI-Gegner verstehen es nur nicht und haben bloß Angst, abgehängt zu werden.“
    Ich möchte die Arbeit der rsync-Maintainer auch nicht zu einer Debatte herabwürdigen, daher weiß ich nicht, wie ich einen überzeugenden Gegenpunkt formulieren könnte.
    Die Statistik hier mag aus Sicht von Open-Source-Maintenance interessant sein, aber die Schlussfolgerung ist seltsam einseitig, und es bleibt bei mir das Gefühl, dass GitHub-artiges Open Source nicht die Form ist, zu der ich beitragen möchte.
    Trotzdem finde ich es überhaupt nicht gut, dass Leute die Maintainer im rsync-Repository kollektiv bedrängt haben.
  • Es ist richtig, öffentliche Gewaltfantasien nicht okay zu nennen. Das ist nichts, worauf wir als Zivilisation hinarbeiten sollten. Aber dass der Autor das als „typisch“ bezeichnet, stört mich, weil es eine Verallgemeinerung ist.
    Was anekdotische Beobachtungen angeht, scheint dieser Comic recht zu haben. Ich sehe gern konkrete, messbare Behauptungen, auch weil ich Zahlen mag und weil es Online-Diskussionen zumindest ein wenig näher an die ideale Welt des letzten Panels bringt.

• Danke für die Analyse, aber bei der Methodik bin ich mir nicht sicher. Mich würden Kennzahlen interessieren wie die Anzahl der Bugs pro Diff-Einheit, also etwa die Zahl der geänderten Zeilen im Kerncode pro Commit — Änderungen an Tests oder Dokumentation ausgenommen —, sowie eine Analyse, wie lange es nach einem Release dauert, bis eine bestimmte Zahl von Bugs erreicht wird.
  Allerdings scheint es gut möglich, dass dieses Release viel mehr Aufmerksamkeit als andere Releases bekommen hat und deshalb mehr Bugs gemeldet wurden. Daher wirkt es schwierig, eine wirklich überzeugende Kennzahl zu entwickeln. Auch Fragen wie „Ist das gemessen an den Wochen nach dem Release typisch?“ sind womöglich nicht besonders nützlich.