KI erhöht das Entwicklungstempo, verursacht aber 1,7-mal mehr Bugs

• Die Analyse von 470 Open-Source-PRs zeigt, dass von KI geschriebener Code im Durchschnitt 1,7-mal mehr Probleme enthält als von Menschen geschriebener Code
• Wichtige Mängel wie Logikfehler, schlechtere Lesbarkeit und Sicherheitslücken traten in KI-Code deutlich häufiger auf; insbesondere Probleme bei der Lesbarkeit nahmen um mehr als das Dreifache zu
• In KI-Code traten fehlende Fehlerbehandlung, Nebenläufigkeitsfehler und inkonsistente Benennung häufig auf, was den Review-Aufwand und das Betriebsrisiko erhöht
• Als Ursachen werden mangelndes Verständnis der Business-Logik, Fokus auf oberflächliche Korrektheit und Bevorzugung ineffizienter Muster genannt
• Der Bericht betont die Notwendigkeit, Mechanismen zur Qualitätssicherung für KI-Code zu stärken und KI-bewusste Code-Review-, Sicherheits- und Testverfahren einzuführen

---

Überblick über den Bericht „AI vs Human Code Generation Report“

• CodeRabbit führte die Studie durch, um die Qualitätsunterschiede zwischen von KI und von Menschen geschriebenem Code empirisch zu analysieren
  • Untersucht wurden 470 Open-Source-GitHub-PRs, davon 320 mit KI-Co-Autorschaft und 150 ausschließlich von Menschen verfasst
  • Alle Ergebnisse wurden auf die Anzahl der Issues pro 100 PRs normalisiert, und die Häufigkeit der Problemtypen wurde per statistischem Verhältnisvergleich gemessen
• Das Ergebnis: KI steigert die Produktivität, erhöht aber zugleich die Fehlerquote
  • Pro von KI erstelltem PR wurden im Durchschnitt 10,83 Probleme gefunden, bei von Menschen erstellten PRs 6,45
  • Insbesondere Fehler mit hoher Schwere wurden in KI-Code häufiger entdeckt

Grenzen der Studie

• Da sich nicht direkt verifizieren ließ, ob ein PR mit KI erstellt wurde, wurden PRs mit dem Signal AI co-authored-by als KI-erstellt klassifiziert
  • PRs ohne dieses Signal wurden als von Menschen erstellt betrachtet, eine vollständige Trennung war jedoch nicht möglich
• Trotz dieser Einschränkung zeigten sich statistisch signifikante Unterschiede in den Problemmustern zwischen den beiden Gruppen
• Die vollständige Methodik ist am Ende des Berichts offengelegt

Die 10 wichtigsten Erkenntnisse

• Nicht alle Fehlertypen kommen ausschließlich bei KI vor, aber in den meisten Kategorien ist die Fehlerquote von KI-Code höher
  • Menschen und KI machen dieselben Arten von Fehlern, doch bei KI treten sie häufiger und in größerem Umfang auf

• 1. 1,7-mal mehr Issues insgesamt

  • Im Durchschnitt 10,83 Issues pro von KI erstelltem PR gegenüber 6,45 bei menschlich erstellten PRs
  • PRs mit stark konzentrierten Issues (Outlier) kommen bei KI-Code deutlich häufiger vor und erhöhen den Review-Aufwand

• 2. Mehr schwerwiegende Fehler

  • Schwerwiegende und kritische Probleme traten 1,4- bis 1,7-mal häufiger auf

• 3. 75 % mehr Probleme bei Logik und Korrektheit

  • Dazu zählen Fehler in der Business-Logik, falsche Abhängigkeiten, Mängel im Kontrollfluss und Konfigurationsfehler
  • Die Behebung ist teuer und kann zu Betriebsstörungen führen

• 4. Mehr als dreimal so viele Lesbarkeitsprobleme

  • Benennungsregeln, Code-Struktur und Konsistenz des Ausdrucks waren deutlich schwächer
  • Auch wenn der Code auf den ersten Blick ordentlich aussieht, werden lokale Muster häufig verletzt

• 5. Doppelt so häufig fehlende Fehlerbehandlung und Ausnahmewege

  • null-Checks, Guard-Bedingungen und Exception-Handling-Logik fehlen häufig
  • Ein Typ von Problem, der direkt zu Serviceausfällen führen kann

• 6. Sicherheitsprobleme bis zu 2,74-mal häufiger

  • Typische Beispiele sind unsachgemäße Passwortverarbeitung und Schwachstellen bei Objektreferenzen
  • Es handelt sich nicht um einzigartige Schwachstellen, aber die meisten Sicherheitsmängel werden verstärkt

• 7. Weniger Performance-Probleme, aber auf KI konzentriert

  • Übermäßige I/O-Aufrufe traten etwa 8-mal häufiger auf
  • KI bevorzugt auf Klarheit ausgerichteten Code, was die Effizienz senkt

• 8. Rund doppelt so viele Nebenläufigkeits- und Abhängigkeitsfehler

  • Reihenfolgefehler, falsche Abhängigkeitsflüsse und Fehlgebrauch von Nebenläufigkeitskontrolle traten häufig auf

• 9. 2,66-mal mehr Formatierungsprobleme

  • Formale Fehler wie Einrückung, Leerzeichen und Stilinkonsistenzen kamen häufig vor
  • Selbst mit automatischen Formatierern und Lintern nimmt das Rauschen in KI-Code zu

• 10. Doppelt so viele Inkonsistenzen bei Benennungen

  • Unklare Namen, inkonsistente Terminologie und generische Bezeichner erhöhen die kognitive Belastung der Reviewer

Ursachen der Probleme

• KI hat zu wenig Verständnis für die Business-Logik
  • Sie generiert Code auf Basis statistischer Muster und übersieht dabei Systemregeln
• Generierung mit Fokus auf oberflächliche Korrektheit
  • Der Code wirkt auf den ersten Blick korrekt, enthält aber Fehler beim Schutz des Kontrollflusses oder in der Reihenfolge von Abhängigkeiten
• Konventionen des jeweiligen Repositorys werden nicht eingehalten
  • Benennungs-, Struktur- und Formatregeln werden in verallgemeinerter Form verfälscht
• Abgeschwächte Sicherheitsmuster
  • Ohne explizite Anweisungen reproduziert die KI veraltete oder anfällige Code-Muster
• Einfachheit wird gegenüber Effizienz bevorzugt
  • Tendenz zu wiederholtem I/O und nicht optimierten Strukturen

Maßnahmen für Engineering-Teams

• Die Einführung von KI erfordert nicht nur mehr Geschwindigkeit, sondern auch eine Neugestaltung der Qualitätssicherungssysteme

• 1. Der KI ausreichend Kontext geben

  • Business-Regeln, Konfigurationsmuster und Architekturgrenzen müssen explizit gemacht werden, um Fehler zu verringern
  • In den Prompts repositoriespezifische Richtlinien und Schemas aufnehmen

• 2. Richtlinienbasierten Code-Stil erzwingen

  • Mit CI-Formatierern, Lintern und Styleguides Lesbarkeitsprobleme vorbeugen

• 3. Schutzmechanismen für Korrektheit ergänzen

  • Tests verpflichtend machen, null-/Typ-Prüfungen, Standardisierung der Ausnahmebehandlung und klare Guard-Bedingungen

• 4. Sichere Defaults stärken

  • Zentralisierung von Credentials, direkte Passwortnutzung verhindern, automatische SAST- und Sicherheits-Linter ausführen

• 5. Effiziente Muster fördern

  • Batch-Verarbeitung für I/O, geeignete Datenstrukturen wählen und Performance-Hinweise geben

• 6. KI-bewusste PR-Checklisten einführen

  • Beim Review folgende Punkte prüfen:
    • Sind Fehlerpfade abgedeckt?
    • Ist die Nebenläufigkeitskontrolle korrekt?
    • Werden Konfigurationswerte validiert?
    • Wie werden Passwörter verarbeitet?

• 7. Automatisierte Reviews für KI-Code einführen

  • Um das Übersehen von Bugs durch wachsende Review-Müdigkeit zu verhindern, wird der Einsatz eines KI-Code-Review-Tools (CodeRabbit) vorgeschlagen
    • Standardisierung der Review-Qualität und Reduzierung von Prüfzeit und kognitiver Belastung

Fazit

• KI-Coding-Tools sind starke Beschleuniger, aber Beschleunigung ohne Schutzmechanismen ist riskant
• KI-generierter Code weist mehr Schwankungen, eine höhere Fehlerquote und höhere Schweregrade auf
• KI sollte nicht als Ersatz, sondern als ergänzendes Werkzeug genutzt werden, während Qualitäts-, Sicherheits- und Testsysteme gestärkt werden müssen
• Wer Geschwindigkeit und Qualität zugleich sichern will, braucht bewusstes Engineering-Management
• Der Einsatz von KI-Code-Review-Tools kann konkret helfen, die Qualität aufrechtzuerhalten

[cshj55]

1,7-mal klingt weniger, als ich erwartet hätte ...?

[ds2ilz]

Ich hatte beim Programmieren mit AI ganz ähnliche Eindrücke. Wenn man sich die geordneten Ursachen ansieht, liegt es meiner Meinung nach wahrscheinlich daran, dass beim Codieren Dinge wie Muster, Benennungsregeln, die Behandlung von Edge Cases, Guard-Bedingungen usw., die Menschen auf Basis ihres Grundwissens voraussetzen, nicht ausreichend als Kontext mitgegeben werden.
Deshalb habe ich eine Regeldatei erstellt, in der genau solche Dinge gesammelt sind, und gebe beim Codieren die Anweisung, diese Datei unbedingt zu lesen und einzuhalten. Wenn man dann nur die Regeldatei verbessert, werden die Ergebnisse deutlich besser.

[princox]

Ich habe ein bisschen Angst davor, dass jetzt die Meinung aufkommt: „Es wurde doch massenhaft mehr produziert — sind 1,7-mal so viele Bugs da nicht praktisch geschenkt?“...

[kimjoin2]

Da muss ich an das Meme denken: „Aber es war doch schnell?" lol

[GN⁺]

Hacker-News-Kommentare

• Ich denke, „Vibe Coding“ gab es schon vor AI

  • Ich habe viele Entwickler gesehen, die sich nicht gefragt haben, warum ein Objekt null ist, sondern einfach überall null-Checks drangeklebt haben
  • So ein Ansatz kann in manchen Bereichen nützlich sein, aber wenn das ganze System so gebaut ist, wird die Wartung zum Albtraum
  • AI-basiertes Vibe Coding beschleunigt nur diesen Stil, bei dem man nur das gewünschte Ergebnis auf dem Bildschirm sehen will, ohne zu wissen, warum es funktioniert
  • Ich habe früher in so einer Firma gearbeitet; dort wurden Exceptions mit null-Checks verschluckt, sodass Fehler still untergingen
    • Das Team hielt sich für brillant, aber tatsächlich lief das System mit von StackOverflow kopiertem Code und einer veralteten MVP-Struktur
    • In so einer Umgebung war eigenständiges Denken fast unmöglich
    • Trotzdem steigern Tools wie Claude Code die Produktivität auf einer gut entworfenen Codebasis enorm
  • Vibe Coding ist genau dieses von StackOverflow kopieren und dann bei „läuft irgendwie“ stehenbleiben
    • AI hat diesen Prozess nur automatisiert
  • Treffender als „man sieht, was man sehen will“ wäre: „Man zeigt einfach irgendetwas auf dem Bildschirm an“
    • Ein gedankenlos eingefügter null-Check kann später subtile Datenfehler verursachen, deren Ursache extrem schwer nachzuverfolgen ist
  • Ich stimme auch zu, aber Vibe Coding macht StackOverflow-abhängige Entwickler einfach schneller
    • Dadurch nimmt die Zahl der Entwickler zu, die Probleme nicht selbst lösen
    • Außerdem ist die Zuverlässigkeit noch geringer als früher
  • Das Frustrierendste an AI ist für mich, dass sie je nach Sprache einfach einen mittelmäßigen Coding-Stil übernimmt
    • Ich folge dem Prinzip „Wenn man keine falschen Daten erzeugt, muss man sie auch nicht verarbeiten“, aber AI verstößt ständig dagegen
    • Sie pflegt kaum Typdefinitionen oder Invariants und versucht alles nur mit Strings und Integers zu behandeln
    • Deshalb nutze ich AI nur stückweise über Tab-Completion und korrigiere strukturelle Fehler selbst
    • Nach den Korrekturen folgt AI dann auch der richtigen Richtung, deshalb dürfte sie mit besserer IDE- und LSP-Integration deutlich nützlicher werden

• Die Kritik an Vibe Coding ist berechtigt, aber tatsächlich war die Codequalität auch schon vor AI miserabel

  • Der meiste Code wurde langsam ausgeliefert und war trotzdem von niedriger Qualität
  • Wenn schnellere Releases die Validierung von Ideen beschleunigen, finden manche ein gewisses Maß an Fehlern akzeptabel
  • Heute fragen Führungskräfte oft: „Warum dauert so eine Funktion Monate?“
  • Aber der Grund, warum selbst „kleine Features“ lange dauern, liegt nicht an Algorithmen, sondern an Infrastruktur und Kollaborationsstrukturen
    • AI kann diese grundlegenden Probleme nicht lösen
  • Wartungskosten und Komplexität akkumulieren sich mit der Zeit wie Zinseszinsen
    • Für kurzfristige Projekte mag Vibe Coding okay sein, für langfristige Systeme ist es ungeeignet
  • Ich halte das Gleichgewicht zwischen intentionalen Entwicklern und Vibe-Entwicklern für wichtig
    • AI verstärkt die Vibe-Seite übermäßig und bringt das System aus dem Gleichgewicht
  • Wichtiger als Codequalität ist ein gemeinsames Verständnis von Business-Problem und technischer Lösung
    • Selbst bei niedriger Qualität ist es wichtiger, die Gründe und Trade-offs klar zu kennen
  • Aber wenn jemand ohne Softwareverständnis Entwicklern sagt, sie machten es falsch, ist das kaum als positiv zu bewerten

• Die Aussage „AI-Code erzeugt 1,7-mal mehr Probleme“ bezieht sich nur auf die Zahl gefundener Bugs

  • In der Praxis wird bei PR-Reviews vieles übersehen, deshalb entgehen auch viele Probleme in AI-Code
  • Es gibt auch Forschung dazu, dass Code Reviews sich stärker auf das Verstehen und Teilen von Struktur als auf reines Bug-Finden konzentrieren sollten
  • Andererseits sagen manche, AI-Code werde gerade deshalb gründlicher geprüft, weil er viele Kommentare enthält und leichter zu lesen ist
    • In von Menschen geschriebenem Code findet man eher Kommentare wie: „Ich weiß nicht, was das ist, aber wenn man es löscht, geht alles kaputt“

• Vor Kurzem hat Copilot mir in .NET eine IComparable-Implementierung vorgeschlagen und mir damit ein paar Minuten gespart

  • Danach habe ich aber eine Stunde debuggt, weil es Variablennamen als x und y vertauscht hatte
  • Wenn ich es selbst geschrieben hätte, wäre mir so ein Fehler nicht passiert
  • Trotzdem war das Ergebnis am Ende fast identisch mit dem Code, den ich selbst geschrieben hätte

• So eine Situation gab es früher schon einmal

  • Wenn man Error-Handling und Edge Cases ignoriert, kann man sehr viel schneller deployen, aber am Ende wird daraus eine Bug-Bombe
  • AI treibt das nur bis zum Extrem
  • Daher kommt auch der Scherz: „Sollte man dann nicht gleich zu Erlang oder Elixir wechseln?“

• Ich fand es interessant, dass ein LLM-basiertes Unternehmen behauptet, „AI sei weniger schlecht als gedacht“

  • Aber Coderabbit ist ein Unternehmen für LLM-Code-Reviews und hat daher eher den Anreiz zu sagen: „AI ist chaotisch, also braucht man AI, um sie zu reviewen“
  • Ich nutze Copilot ebenfalls als Review-Tool, und AI-Reviews sind fast immer korrekt, was schon vor dem menschlichen Review sehr hilfreich ist

• Ich nutze CodeRabbit oft, aber es gibt immer noch viele False Positives

  • Manchmal weist es selbst bei bereits validiertem Code darauf hin, dass „keine Datenvalidierung“ vorhanden sei
  • Trotzdem akzeptiert das Tool es, wenn man ihm sagt, dass es falsch liegt, und lernt daraus

• „1,7-mal mehr“ und „um das 1,7-Fache gestiegen“ sind nicht dasselbe

  • Aber diese Debatte über Zahlen fühlt sich letztlich wie ein bedeutungsloser Streit an

• Agentic AI Coding ist nur ein Werkzeug; wenn man es falsch einsetzt, kommen natürlich auch falsche Ergebnisse heraus

  • Als gelungenes Beispiel für den Einsatz wird das Python-Beispiel justhtml empfohlen
  • Problematisch ist aber die schwarz-weiße Logik nach dem Motto: „Wer es nicht nutzen kann, ist unfähig“
    • Ob man AI als nützlich empfindet oder nicht, ist letztlich einfach eine Frage der Erfahrung

• Die Formulierung in der Überschrift des Artikels, „AI-Code erzeugt 1,7-mal mehr Probleme“, ist ungenau

  • Tatsächlich geht es bei den „Problemen“ nicht nur um Bugs, sondern auch um Formatierungs- und Naming-Probleme
  • Eine konkrete Bug-Zahl selbst wird im Artikel nicht genannt