Ein Entwickler hat eine Programmiersprache entworfen, deren erklärtes Ziel nicht Produktivität ist, sondern Verwirrung: KI-Modelle sollen den damit geschriebenen Code nur sehr schwer nachvollziehen können. Dazu arbeitet die Sprache unter anderem mit irreführenden Angaben und Anweisungen, die etwas anderes tun, als sie vorgeben.

Das Projekt ist ein Experiment, kein Werkzeug für den Produktivbetrieb. Trotzdem lohnt der Blick darauf, denn es stellt eine Frage, die in vielen Entwicklungsteams gerade praktisch relevant wird: Woran genau scheitern KI-Assistenten, wenn sie Code lesen, erklären oder verändern sollen?

Warum sich Modelle überhaupt täuschen lassen

Große Sprachmodelle – also KI-Systeme, die auf Basis riesiger Textmengen das jeweils wahrscheinlichste nächste Zeichen vorhersagen – haben bei Quellcode einen entscheidenden Vorteil: Programmiersprachen sind hochgradig konventionalisiert. Eine Funktion namens validateEmail prüft in der Regel E-Mail-Adressen. Ein Kommentar beschreibt meistens das, was darunter passiert. Ein verbreitetes Framework folgt bekannten Mustern.

Genau diese Erwartbarkeit ist die Grundlage dafür, dass KI-Assistenten brauchbare Vorschläge machen. Sie erkennen Muster wieder, die sie millionenfach gesehen haben. Wird die Verbindung zwischen Benennung und tatsächlichem Verhalten systematisch gekappt, bricht dieser Mechanismus zusammen: Das Modell liest weiterhin Signale, aber die Signale lügen.

Bemerkenswert ist, dass menschliche Entwicklerinnen und Entwickler diesem Effekt grundsätzlich ebenfalls unterliegen. Auch sie lesen Code überwiegend überfliegend, vertrauen Namen und Kommentaren und prüfen nur im Zweifel Zeile für Zeile. Der Unterschied liegt im Ausweg: Menschen können ein Programm ausführen, Logs lesen, Kolleginnen fragen oder misstrauisch werden, wenn etwas sich falsch anfühlt. Ein Assistent, der nur den Textausschnitt im Kontextfenster sieht, hat diese Korrekturmöglichkeiten nicht automatisch.

Vom Kunstprojekt zum realen Risiko

Eine absichtlich verwirrende Sprache wird in keinem Unternehmensprojekt zum Einsatz kommen. Die Mechanik dahinter begegnet Teams aber ständig in abgeschwächter Form – unbeabsichtigt und über Jahre gewachsen:

  • Funktions- und Variablennamen, die seit dem dritten Refactoring nicht mehr beschreiben, was der Code tut.
  • Kommentare, die einen früheren Stand dokumentieren und nie aktualisiert wurden.
  • Konfigurationswerte, die an einer Stelle gesetzt und an einer völlig anderen stillschweigend überschrieben werden.
  • Eigene Konventionen, die von den Standards des eingesetzten Frameworks abweichen, ohne dass dies irgendwo festgehalten ist.

Solche Codebasen sind für Menschen anstrengend und für KI-Werkzeuge gefährlich. Denn ein Assistent äußert selten Unsicherheit. Er liefert eine plausible Erklärung oder einen plausiblen Patch – auch dann, wenn die Grundannahme falsch war. Wer solche Vorschläge ungeprüft übernimmt, verteilt die Irreführung weiter im System.

Konsequenzen für Reviews

Viele Teams setzen KI inzwischen nicht nur beim Schreiben, sondern auch beim Prüfen von Code ein: automatisierte Review-Kommentare, Zusammenfassungen von Pull Requests, Erklärungen zu fremden Modulen. Der Nutzen hängt direkt davon ab, wie verlässlich der Code über sich selbst Auskunft gibt.

Praktisch heißt das: Die Qualität eines KI-Reviews ist kein Produktmerkmal des gewählten Tools allein, sondern ein Spiegel der eigenen Codebasis. Wer dieselbe Aufgabe in einem sauber strukturierten Projekt und in einem historisch gewachsenen Altsystem laufen lässt, erhält Ergebnisse von sehr unterschiedlicher Belastbarkeit – ohne dass der Unterschied im Output sichtbar wäre.

Was sich daraus ableiten lässt

Aus dem Experiment folgt keine Warnung vor KI-Assistenten, sondern ein nüchterner Blick auf ihre Voraussetzungen. Einige Punkte, die sich in Projekten umsetzen lassen:

  1. Benennung als Teil der Architektur behandeln. Namen sind keine Kosmetik, sondern die wichtigste Dokumentationsebene – für Menschen wie für Maschinen.
  2. Kommentare pflegen oder löschen. Ein falscher Kommentar ist schlechter als gar keiner, weil er aktiv in die Irre führt.
  3. Konventionen schriftlich festhalten. Abweichungen vom Framework-Standard gehören begründet und an einer Stelle dokumentiert, auf die auch Assistenten zugreifen können.
  4. KI-Vorschläge gegen Tests prüfen, nicht gegen das Bauchgefühl. Automatisierte Tests sind die einzige Instanz, die Verhalten unabhängig von Beschriftungen bewertet.
  5. Reviewverantwortung bei Menschen belassen. Ein KI-Review beschleunigt die Vorarbeit, ersetzt aber keine fachliche Freigabe.

Die andere Lesart: Code als Schutzraum

Der Ansatz lässt sich auch umgekehrt denken. Wenn Lesbarkeit maschinelles Verstehen erst ermöglicht, dann ist Unlesbarkeit eine Form von Abschottung – gegen automatisiertes Auslesen, Nachbauen oder Weiterverwenden von Code. Für den praktischen Einsatz ist diese Richtung allerdings wenig attraktiv: Was KI-Modelle ausbremst, bremst neue Teammitglieder, Sicherheitsaudits und Wartung gleichermaßen aus. Der Preis für Verschleierung wird in Wartungskosten bezahlt.

Für Web- und Softwareprojekte heißt das vor allem eines: Lesbarer, konsistent benannter Code ist zur Infrastrukturfrage geworden. Investitionen in Namenskonventionen, aktuelle Dokumentation und automatisierte Tests zahlen sich heute doppelt aus – sie verkürzen die Einarbeitung im Team und entscheiden zugleich darüber, wie viel Entlastung KI-Werkzeuge tatsächlich bringen. Wer KI-Unterstützung im Entwicklungsprozess plant, sollte deshalb zuerst den Zustand der eigenen Codebasis bewerten, nicht die Feature-Liste des Assistenten.

Quellen