Wenn die KI deinen Code besser kennt als du

KI kann bei der Fehlersuche beeindruckend schnell sein. Du beschreibst ein Problem, lieferst relevante Klassen mit und bekommst innerhalb kurzer Zeit einen konkreten Änderungsvorschlag zurück. Noch bequemer wird es, wenn ein Agent die Änderungen direkt selbst durchführt und dir anschließend nur noch den fertigen Diff präsentiert. Genau an diesem Punkt beginnt für mich aber ein Problem, das in der Diskussion über KI-generierten Code häufig zu kurz kommt.

Es geht nicht darum, ob der erzeugte Code syntaktisch korrekt ist oder ob ein Test anschließend wieder grün wird. Es geht um das Wissen darüber, was im eigenen Projekt eigentlich verändert wurde. Wenn du eine Fehlerbehebung selbst entwickelst, kennst du normalerweise nicht nur das Ergebnis. Du weißt auch, an welcher Stelle du eingegriffen hast, welche Bedingungen vorher gegolten haben, warum du eine Methode geändert hast und welche anderen Stellen davon betroffen sein könnten. Bei umfangreicher generiertem Code fehlt genau dieser Entstehungsprozess. Der Code ist vorhanden, aber das Wissen darüber ist nicht automatisch mit entstanden.

Code lesen ist nicht dasselbe wie eine Änderung selbst entwickeln

Natürlich kannst du generierten Code anschließend lesen. Das ist aber nicht dasselbe wie ihn selbst entwickelt zu haben. Wenn du einen Fehler eigenständig untersuchst, arbeitest du dich normalerweise durch den betroffenen Ablauf. Du verfolgst Werte, setzt Breakpoints, prüfst Bedingungen, liest Aufrufketten und verwirfst möglicherweise mehrere Vermutungen, bevor du die eigentliche Ursache findest. Danach entscheidest du bewusst, an welcher Stelle die Korrektur sinnvoll ist.

Während dieses Prozesses entsteht ein mentales Modell der betroffenen Fachlogik. Du weißt später nicht nur, dass irgendwo eine Bedingung ergänzt wurde. Du erinnerst dich daran, warum genau diese Bedingung notwendig war und weshalb sie an dieser Stelle sitzt. Dieses Wissen steht häufig in keinem Kommentar und in keiner Dokumentation. Es entsteht während der Arbeit am Problem.

Bei generierten Änderungen kannst du diesen gesamten Weg überspringen. Die KI analysiert mehrere Klassen, verändert vielleicht fünf Methoden und liefert eine fertige Lösung. Danach siehst du einen Diff und kannst durchaus nachvollziehen, was dort technisch passiert. Trotzdem fehlt dir häufig die gleiche Verbindung zu den einzelnen Entscheidungen. Du hast die Änderung gesehen, aber du hast sie nicht selbst hergeleitet.

Genau das halte ich für gefährlich. Ein Code Review ersetzt diesen Prozess nur teilweise. Dass du eine Änderung beim Lesen verstehst, bedeutet noch lange nicht, dass du sie einige Wochen später gedanklich sofort wieder zuordnen kannst. Gerade bei komplexerer Fachlogik entsteht dadurch schnell Code, den du grundsätzlich lesen kannst, dessen konkrete Zusammenhänge aber nicht mehr fest in deinem eigenen Verständnis des Systems verankert sind.

Besonders kritisch wird es bei Fachlogik

Bei kleinen, lokal begrenzten Änderungen ist das Problem überschaubar. Wenn eine KI einen offensichtlichen Nullcheck ergänzt oder eine fehlerhafte Bedingung korrigiert, lässt sich die Änderung meist vollständig erfassen. Kritisch wird es dort, wo eine Fehlerbehebung mehrere Komponenten betrifft oder bestehende Fachlogik verändert.

In gewachsenen Anwendungen entsteht ein Verhalten selten an genau einer Stelle. Ein Wert kommt beispielsweise aus der Datenbank, wird in einem Service verarbeitet, durchläuft weitere Geschäftslogik und landet später in der Oberfläche oder einer Folgeoperation. Wenn eine KI diesen Ablauf analysiert und anschließend an mehreren Stellen eingreift, reicht es nicht zu prüfen, ob der neue Java-Code plausibel aussieht.

Du musst verstehen, was sich fachlich verändert hat.

Ein stark vereinfachtes Beispiel könnte so aussehen:

if (booking.isClosed()) {
    calculateBalance(booking);
}

Eine KI könnte während der Analyse feststellen, dass die Berechnung früher erfolgen muss und daraufhin mehrere Abläufe anpassen. Entscheidend ist dann nicht, ob du das neue if lesen kannst. Du musst wissen, warum die Berechnung jetzt früher erfolgt, für welche Zustände das gilt, welches Verhalten vorher falsch war und welche nachfolgenden Prozesse davon abhängen.

Wenn du diese Fragen nicht beantworten kannst, hast du zwar einen Fix im Repository, aber gleichzeitig eine Wissenslücke erzeugt.

Das ist für mich einer der problematischsten Aspekte von KI-generiertem Code. Software besteht nicht nur aus Quelltext. Sie besteht auch aus Annahmen, Entscheidungen, Abhängigkeiten und Fachwissen. Wird Code schneller erzeugt, als dieses Wissen bei den verantwortlichen Entwicklern entstehen kann, wächst das Projekt technisch weiter, während das Verständnis dafür zurückbleibt.

Damit entsteht eine neue Form technischer Schuld. Nicht unbedingt schlechter Code, sondern Code, dessen Entstehung und fachliche Bedeutung niemand mehr ausreichend im Kopf hat.

Ein grüner Test ist noch kein verstandener Fix

Besonders verführerisch ist bei KI-generierten Fehlerbehebungen der schnelle Erfolg. Das ursprüngliche Problem tritt nicht mehr auf, der Build läuft durch und die Tests sind grün. Damit wirkt die Aufgabe zunächst abgeschlossen.

Für mich reicht das nicht.

Ein erfolgreicher Test beweist lediglich, dass die geprüften Fälle funktionieren. Er beweist nicht, dass die Änderung vollständig verstanden wurde. Gerade wenn eine KI mehrere Stellen verändert hat, kann ein Fix Auswirkungen haben, die in den vorhandenen Tests überhaupt nicht abgedeckt sind.

Deshalb halte ich es für problematisch, einer KI einfach eine größere Fehlerbeschreibung zu geben und anschließend nur das Ergebnis zu kontrollieren. Je mehr Verantwortung bei der Analyse und Umsetzung an die KI abgegeben wird, desto wichtiger wird die Frage, ob du hinterher wirklich noch erklären kannst, was verändert wurde.

Ein sinnvollerer Einsatz besteht für mich darin, KI zunächst für die Analyse zu verwenden. Sie kann mögliche Ursachen identifizieren, Aufrufketten nachvollziehen und auf verdächtige Stellen hinweisen. Die Entscheidung darüber, wie die Fachlogik tatsächlich verändert wird, sollte aber nicht leichtfertig vollständig ausgelagert werden.

Wenn Code trotzdem generiert wird, muss die Änderung anschließend mindestens so gründlich geprüft werden, dass jede fachlich relevante Anpassung erklärbar ist. Warum wurde diese Methode geändert? Welche Zustände sind betroffen? Welche Auswirkungen hat die Änderung auf andere Abläufe? Was würde passieren, wenn diese Zeile nicht vorhanden wäre?

Kannst du diese Fragen nicht beantworten, ist die Änderung für mich noch nicht abgeschlossen.

Auch die Größe einer generierten Änderung spielt dabei eine entscheidende Rolle. Je größer der Patch, desto schwieriger wird es, ihn wirklich zu durchdringen. Wenn gleichzeitig ein Fehler behoben, Methoden umgebaut, Klassen verschoben und nebenbei noch Code aufgeräumt wird, wird es fast unmöglich zu unterscheiden, welche Änderung fachlich notwendig und welche nur eine zusätzliche Entscheidung der KI war.

Deshalb sollten generierte Änderungen möglichst klein bleiben. Fehlerbehebung, Refactoring und Aufräumarbeiten gehören auch hier getrennt. Nicht nur für eine saubere Git-Historie, sondern vor allem dafür, dass das Wissen über die Veränderung erhalten bleibt.

Fazit

Ich halte KI-generierten Code gerade bei größeren Fehlerbehebungen für deutlich problematischer, als es der schnelle Erfolg zunächst vermuten lässt. Nicht weil eine KI grundsätzlich keinen funktionierenden Code erzeugen kann, sondern weil sie einen wichtigen Teil der Entwicklungsarbeit unsichtbar macht: den Weg zum Verständnis.

Wenn du eine Änderung selbst entwickelst, lernst du währenddessen zwangsläufig etwas über den betroffenen Code. Du verstehst Zusammenhänge, stößt auf Sonderfälle und baust Wissen über die Fachlogik auf. Bei einer vollständig generierten Lösung kann dieses Lernen ausfallen. Du erhältst das Ergebnis, ohne den Weg dorthin gegangen zu sein.

Kurzfristig spart das Zeit. Langfristig kann es genau diese Zeit wieder kosten oder im schlimmsten Fall sogar noch mehr.

Beim nächsten Fehler musst du dann nicht nur das neue Problem analysieren. Du musst möglicherweise zunächst rekonstruieren, was bei der letzten Änderung überhaupt passiert ist, warum bestimmte Bedingungen existieren und weshalb einzelne Methoden heute anders arbeiten als früher.

Für mich ist deshalb die entscheidende Frage bei KI-generiertem Code nicht nur:

"Funktioniert der Fix?"

Mindestens genauso wichtig ist:

"Verstehe ich danach noch genau, wie dieser Teil meines Systems funktioniert?"

Wenn die Antwort darauf Nein lautet, ist der Preis für die schnelle Code-Generierung möglicherweise höher, als es auf den ersten Blick aussieht.