Wenn KI von KI lernt: Das Kopierer-Problem

Wenn du ein JPEG speicherst, verlierst du Bildinformation. Das ist der Deal: kleinere Datei, weniger Detail. Öffnest du das JPEG und speicherst es erneut, verlierst du nochmal. Und nochmal. Nach zwanzig Durchläufen ist das Bild ein Matsch aus Artefakten. Die Konturen sind noch da, ungefähr. Aber die Feinheit ist weg.

Genau das passiert gerade mit Code. Und im Gegensatz zum JPEG merkt es kaum jemand, weil der Code ja noch „funktioniert“.

Wie der Feedback-Loop funktioniert

Große Sprachmodelle lernen von Code, den Menschen geschrieben haben. Das ist die erste Generation: echte Entwickler, echte Probleme, echte Lösungen. Dieser Code ist nicht perfekt — menschlicher Code ist nie perfekt. Aber er wurde in Code Reviews diskutiert, in Produktion getestet, bei Incidents debuggt. Hinter jeder Zeile steckt ein Lernprozess.

Dann kommt die zweite Generation. KI generiert Code basierend auf dem, was sie gelernt hat. Dieser Code landet auf GitHub, in Repositories, in Tutorials, in Stack-Overflow-Antworten. Neue Modelle werden trainiert. Sie lernen jetzt nicht mehr nur von menschlichem Code — sie lernen von einem Mix aus menschlichem und KI-generiertem Code. Ohne zu wissen, was was ist.

Dritte Generation: Modelle, die überwiegend auf KI-generiertem Code trainiert werden, der auf KI-generiertem Code basiert. Jede Runde ist ein neues Abspeichern des JPEG.

Was bei jeder Runde verloren geht

Das Tückische: Du siehst es nicht sofort. Der Code kompiliert. Die Tests laufen durch. Die App startet. Aber unter der Oberfläche erodiert die Qualität — an Stellen, die erst unter Druck sichtbar werden.

Error Handling wird zum Einzeiler. Ich sehe das ständig in KI-generiertem Code. Ein try/catch, das die Exception fängt und … nichts tut. Oder schlimmer: sie loggt und dann trotzdem weitermacht, als wäre nichts passiert. Menschliche Entwickler lernen Error Handling, weil sie nachts von PagerDuty geweckt werden. KI hat keine PagerDuty.

Copy-Paste-Architekturen. KI produziert Code, der funktioniert, aber nicht abstrahiert. Drei Controller mit fast identischem Code, weil das Modell jede Anfrage isoliert beantwortet. Kein Mensch, der den Gesamtkontext sieht und sagt: „Das gehört in einen Service.“ Die nächste Modellgeneration lernt von diesen drei Controllern und reproduziert das Pattern. Copy-Paste wird zum Standard.

Edge Cases verschwinden. Ein menschlicher Entwickler, der mal einen Race-Condition-Bug in Produktion hatte, denkt beim nächsten Mal automatisch an Concurrency. Er hat den Schmerz erlebt. KI hat keinen Schmerz. Sie generiert den Happy Path, weil der Happy Path im Trainingsdatensatz am häufigsten vorkommt. Und mit jeder Generation wird der Anteil an Happy-Path-Code größer, weil KI immer mehr Happy-Path-Code produziert.

Sicherheit wird zum Nachgedanken. SQL Injection, XSS, CSRF — menschliche Entwickler haben diese Lektionen kollektiv gelernt, über Jahre, oft schmerzhaft. KI kennt die Patterns, aber sie versteht nicht, warum sie nötig sind. Wenn im Trainingsdatensatz genug unsicherer Code vorkommt — und das tut er — reproduziert das Modell auch unsichere Patterns. Nicht aus Bosheit, sondern aus statistischer Wahrscheinlichkeit.

Die JPEG-Analogie, weitergedacht

Zurück zum Bild. Beim JPEG siehst du die Artefakte. Die Blockbildung, die verwischten Kanten, die falschen Farben. Du merkst, dass die Qualität nachlässt.

Bei Code merkst du es nicht. Weil die Tests grün sind. Weil die App startet. Weil der Reviewer auch nur fünf Minuten hat und der Code „sieht okay aus“. Die Artefakte im Code sind subtiler: eine fehlende Validierung hier, ein hartcodierter Timeout dort, ein catch (Exception $e) das jeden Fehler schluckt, inklusive der, die auf ein echtes Problem hinweisen.

Einzeln betrachtet ist jeder dieser Punkte harmlos. Zusammen ergeben sie Software, die bei Schönwetter funktioniert und beim ersten Sturm umfällt. Und mit jeder Modellgeneration verschiebt sich die Baseline: Was gestern ein Anti-Pattern war, ist morgen ein Pattern, weil das Modell es oft genug gesehen hat.

Wer weiß in zehn Jahren noch, was gut ist?

Das ist die Frage, die mich wirklich beschäftigt. Nicht ob KI Code schreiben kann — das kann sie offensichtlich. Sondern ob in zehn Jahren noch genug Menschen da sind, die den Unterschied zwischen gutem und schlechtem Code erkennen.

Wenn Junior-Entwickler nur noch mit KI lernen, lernen sie von Code, der bereits durch den Feedback-Loop gelaufen ist. Sie sehen die vereinfachten Patterns, die kopierten Strukturen, die fehlenden Edge Cases — und halten das für normal. Weil es alles ist, was sie kennen. Wer sagt ihnen, dass da etwas fehlt, wenn alle ihre Kollegen mit demselben Werkzeug gelernt haben?

Ein Senior Developer, der 15 Jahre lang Software in Produktion betreut hat, erkennt schlechten Code instinktiv. Nicht weil er schlauer ist, sondern weil er die Narben hat. Er hat gesehen, was passiert, wenn du den Connection Pool nicht begrenzt. Er hat erlebt, was passiert, wenn du Floating-Point-Zahlen für Geldbeträge verwendest. Er hat die Nacht durchgemacht, weil eine Race Condition nur unter Last an einem Feiertag auftritt.

Diese Narben kann man nicht trainieren. Und sie werden weniger, wenn jede neue Entwicklergeneration den Schmerz outsourced.

Das Model Collapse Problem

Forscher nennen das Phänomen „Model Collapse“ — den Punkt, an dem ein Modell, das auf seinen eigenen Outputs trainiert wird, an Qualität und Diversität verliert. Die Verteilung wird enger. Die Vielfalt nimmt ab. Ungewöhnliche, kreative, unkonventionelle Lösungen verschwinden, weil sie statistisch seltener sind. Übrig bleibt der Durchschnitt.

Für Bilder bedeutet das: generische Gesichter, generische Landschaften, generische Kunst. Für Code bedeutet das: generische Architekturen, generische Patterns, generische Lösungen. Code, der funktioniert, aber nie überrascht. Der nie eine elegante Abkürzung nimmt, weil die elegante Abkürzung im Trainingsdatensatz zu selten vorkommt.

Die besten Lösungen in der Softwareentwicklung sind oft unkonventionell. Ein Cache an einer Stelle, an die niemand gedacht hätte. Eine Datenstruktur, die das Problem neu formuliert statt es frontal zu lösen. Diese Kreativität entsteht aus tiefem Verständnis — nicht aus statistischer Häufigkeit.

Was wir tun können

Ich nutze KI-Tools täglich. Jeden Tag. Sie machen mich schneller, und ich möchte sie nicht mehr missen. Aber ich lese jeden generierten Code so, als hätte ihn ein Junior geschrieben — mit gesundem Misstrauen und der Erwartung, dass irgendwo ein Fehler steckt. Meistens steckt einer drin.

Die Lösung ist nicht, KI-Code abzulehnen. Die Lösung ist, die menschliche Kompetenz zu erhalten, die nötig ist, um ihn zu bewerten. Das heißt: Code Reviews ernst nehmen. Nicht durchwinken, weil „die KI das geschrieben hat“. Junior-Entwickler an echte Probleme lassen, nicht nur an KI-gestützte Übungen. Und den Mut haben, Code abzulehnen, der funktioniert, aber schlecht ist.

Ein Kopierer produziert keine Fehler, die er selbst erkennen kann. Er reproduziert sie nur — zuverlässig, skalierbar und ohne jedes Schuldbewusstsein.

Code lesen ist wichtiger als Code schreiben. Das war schon immer so. Aber wenn niemand mehr liest, was die Maschine schreibt, bekommen wir irgendwann nur noch Rauschen. Und das Schlimmste daran: Das Rauschen kompiliert fehlerfrei.