Der Fehler wurde von einer KI verursacht. Du benötigst Produktionsdaten, um ihn nachzustellen.

Ein Pull-Request wird mit einer Funktion eingereicht, die ein KI-Assistent generiert hat. Der Code liest sich sauber, besteht die bestehenden Tests und wird eingezogen. Drei Wochen später geht er kaputt – allerdings nur bei Konten mit einer bestimmten Abrechnungshistorie. Niemand hat einen Test für diese Bedingung geschrieben, weil niemand daran gedacht hat, als das Programmiert wurde. Jetzt muss jemand eine Logik debuggen, die er nicht durchdacht hat, und zwar anhand eines Fehlers, den er sich ohne die genauen Daten, die ihn ausgelöst haben, nicht vorstellen kann.

Das Debuggen von fremden Programmen hat schon immer so funktioniert. Die KI macht es zum Standard.

Warum von KI programmierter Code anders versagt

Das Wichtigste zum Mitnehmen: Das Programmieren ist nicht unbedingt schlechter, aber das Gespür des Reviewers dafür, wo er versagt, ist schwächer.

Wenn Entwickler Code selbst programmieren, bauen sie sich im Laufe der Arbeit ein mentales Modell der Randfälle auf, weil sie diese Fälle beim Programmieren durchdenken. KI-generierter Code kann auf den ersten Blick genauso korrekt sein, aber der reviewer geht von der Ausgabe aus und nicht von der dahinterliegenden Logik. Er kann überprüfen, ob er das tut, was er soll. Er ist jedoch weniger in der Lage, vorherzusagen, wie er sich unter Bedingungen verhält, die niemand explizit berücksichtigt hat, weil er diese Ermessensentscheidungen nicht getroffen hat.

Die Auswirkungen zeigen sich auch in den Bereitstellungsdaten. Der „2024 Accelerate State of DevOps Report“ von DORA ergab, dass ein Anstieg des KI-Einsatzes in einem Team um 25 % mit einem geschätzten Rückgang der Bereitstellungsstabilität um 7,2 % und einem Rückgang des Durchsatzes um 1,5 % einherging – selbst bei steigender individueller Produktivität. DORA nennt größere Batch-Größen und schwächere Tests als wahrscheinliche Ursachen. Beides führt dazu, dass Randfälle leichter übersehen werden. Derselbe Bericht ergab, dass 39 % der Befragten wenig oder gar kein Vertrauen in KI-generierte Programme haben.

Das Problem der Reproduzierbarkeit wird schwieriger

Wichtigste Erkenntnis: Das Debuggen von Logik, die du nicht selbst durchdacht hast – egal, ob sie von einem Menschen oder einer KI geschrieben wurde –, hängt mehr von den tatsächlichen Bedingungen und weniger von Intuition ab.

Wenn die Person, die einen Fehler behebt, den ursprünglichen Code nicht durchdacht hat, ist es schwieriger, die Fehlerbedingung zu erraten. Sie kann sich nicht auf „Ich wette, es ist dieser Randfall“ verlassen. Was bleibt, sind die Daten: das spezifische Konto und der Eingabezustand, die den Fehler ausgelöst haben. Ohne diese Daten bedeutet das Debuggen von KI-generiertem Code, unbekannte Logik zu lesen und darauf zu hoffen, zufällig auf den richtigen Testfall zu stoßen.

Die Art und Weise, wie programmiert wird, verschlimmert das noch. Die Analyse von GitClear aus dem Jahr 2025, die 211 Millionen geänderte Zeilen untersuchte, ergab: Mit der zunehmenden Verbreitung von KI-Assistenten war 2024 das erste Jahr, in dem kopierte/eingefügte Zeilen die verschobenen (refaktorierten) Zeilen zahlenmäßig übertrafen, und die Anzahl doppelter Blöcke mit fünf oder mehr Zeilen stieg um etwa das Achtfache. Mehr doppelter Code bedeutet mehr Stellen, an denen sich ein Randfall verstecken kann.

Ist das nicht einfach nur ein Problem der Code-Review?

Das Wichtigste zum Mitnehmen: Bei einer Code-Review kann geprüft werden, ob das Programm das tut, was es soll. Selten werden dabei Bedingungen entdeckt, an deren Überprüfung niemand gedacht hat.

Ein sorgfältigerer reviewer oder strengere Richtlinien für KI-generierte Programme scheinen die naheliegende Lösung zu sein. Das hilft zwar, schließt die Lücke aber nicht. Um nach einem Randfall zu suchen, muss man zunächst vermuten, dass er existiert – und genau diese Intuition fehlt einem reviewer oft, der mit dem Ergebnis eines anderen arbeitet.

Gründlichere Prüfung führt zu sorgfältigeren Vermutungen. Sie liefert dem reviewer jedoch keine Informationen, die er nicht bereits hatte. Um die Lücke zu schließen, musst du die Bedingung erkennen, die das Programm zum Absturz bringt.

Was dir das Klonen des Produktionszustands hier bietet

Das Wichtigste auf einen Blick: Durch das Klonen der Produktionsumgebung wird die Fehlerbedingung dem Debugger direkt vor Augen geführt, sodass er sie nicht anhand einer Vermutung rekonstruieren muss.

Ein Zweig, der die Produktionsumgebung mit denselben Diensten, derselben Konfiguration und denselben Daten klont, macht das meiste Rätselraten überflüssig. Das Konto mit der Abrechnungshistorie, das den Fehler ausgelöst hat, befindet sich bereits in der Vorschauumgebung. Niemand muss es manuell nachbauen oder darauf warten, dass der Fehler erneut auftritt.

Das Kopieren von Produktionsdaten wirft berechtigte Fragen zum Datenschutz auf. Ein Bereinigungsskript in deinem Deploy-Hook kann personenbezogene Daten in Preview-Umgebungen anonymisieren, während die Abrechnungshistorie, von der der Fehler abhängt, erhalten bleibt. Die Dokumentation zur Datenbankbereinigung enthält funktionierende Beispiele.

Von da an ist es derselbe Arbeitsablauf, den du bei jedem schwer reproduzierbaren Fehler anwenden würdest. Erstelle einen Zweig aus der Produktivumgebung, eröffne einen Tunnel zu den geklonten Diensten und reproduziere den Fehler anhand der Daten, die ihn ausgelöst haben. Unsere Anleitung „Vom Fehlerbericht zur verifizierten Behebung in einem einzigen Workflow“ behandelt jeden Schritt. Der Unterschied besteht hier darin, wie stark sich der Debugger auf diese Daten verlässt, da er mit den Ergebnissen eines anderen arbeitet und nicht mit seinem eigenen Modell der Logik.

Möchtest du die Fehlerbedingungen beim Debuggen direkt vor Augen haben? Starte eine 15-tägige kostenlose Testphase und klone deine erste Umgebung.

Häufig gestellte Fragen (FAQ)

Bedeutet das, dass KI-generierter Code fehleranfälliger ist als von Hand programmierter Code? Nicht unbedingt. Der Unterschied liegt darin, wie viel Intuition die Person hat, die ihn wartet, was die Randfälle angeht – und genau deshalb ist das Testen unter realen Bedingungen umso wichtiger.

Warum sind Produktionsdaten gerade für KI-geschriebene Programme wichtiger? Weil die übliche Ausweichmöglichkeit – die Erinnerung des Autors an die von ihm berücksichtigten Randfälle – schwächer ist oder ganz fehlt. Echte Daten ersetzen die Intuition, die dem reviewer fehlt.

Gilt das für jeden KI-unterstützten Code oder nur für vollständig von der KI generierte Features? Es gilt überall dort, wo die Person, die den Fehler behebt, die ursprüngliche Logik nicht selbst durchdacht hat – egal, ob es sich um ein vollständig von der KI generiertes Feature handelt oder um von Menschen geschriebenen Code, den jetzt jemand anderes wartet. KI-unterstützte Entwicklung sorgt nur dafür, dass diese Situation viel häufiger vorkommt.

Wie kann ich zurückverfolgen, woher der Fehler stammt? „git blame“ zeigt dir den Diff, aber nicht, wie dieser Diff zustande kam. Wenn die Änderung über Upsun Dispatch erfolgte, wird bei jedem Lauf der Rest protokolliert. Die Laufdetails in der Dispatch-Konsole zeigen die Eingabeaufforderungen, Tool-Aufrufe und Ergebnisse dieses Laufs an. Bei durch Jira oder Linear ausgelösten Läufen, bei denen die Planfreigabe aktiviert ist, wird außerdem angezeigt, wer den Plan und eventuelle Überarbeitungen genehmigt hat. Kombiniere das mit einem Branch im Produktionsstatus, und du hast beide Hälften: warum der Code so programmiert wurde und welche Daten ihn zum Absturz bringen.