Programmieren ist längst weniger das Schreiben von Code als vielmehr das Verstehen von Systemen. Jede Codebasis wird weit öfter gelesen als erweitert. Und genau dort zeigt sich ein häufiges strukturelles Defizit: Das „Warum“ der Entscheidungen ist meist unsichtbar.

Wer ein bestehendes System analysiert – ob Mensch oder KI –, trifft zwar auf Klassen und Module, erkennt jedoch nicht unmittelbar, wie diese zusammenhängen und wofür sie stehen. KI-Modelle spiegeln dieses Problem besonders deutlich: Sie erkennen Muster, aber keine Herleitung. Eine aktuelle Übersichtsstudie aus dem Jahr 2025 kommt zu dem Ergebnis, dass ein erheblicher Teil der Fehler in generiertem Code nicht syntaktischer Art ist, sondern logisch-semantischen Fehlannahmen unterliegt. Modelle folgen vorhandenen Strukturen. Wird die zugrunde liegende Bedeutung und Herleitung nicht sichtbar, dann halluzinieren sie – so wie auch Menschen raten oder recherchieren müssten.

Diese Beobachtung zeigt, dass wir Abstraktion perfektioniert, aber Verständlichkeit oft unterschätzt haben.

Der lange Kampf gegen mentale Last

In der Rückschau wirkt die Geschichte der Softwareentwicklung wie ein kontinuierlicher Versuch, mentale Last zu reduzieren. Assembler verließ die Ebene direkter Maschinenbefehle, Hochsprachen entfernten Hardwaredetails, Frameworks umhüllten Komplexität mit wenigen Zeilen Code. Mit jedem Schritt rückte der Fokus weg vom „Wie“ und hin zum „Was“:

Doch die Entlastung ist ambivalent. Abstraktionen sparen Tipparbeit, erzeugen aber zusätzliche Interpretationsarbeit. Eine Funktion wie calculateTotal() versteckt Implementation, aber auch Bedeutung: Welches Total? Welche Regeln? Welche Domäne? Welche Ausnahmen? Eine Zeile Code wird zum mentalen Sprungbrett, das die Lesenden zwingt, das Unsichtbare zu rekonstruieren.

Mit zunehmender Reife der Softwareentwicklung rückte eine neue Art der Schwierigkeit in den Mittelpunkt. Das Schreiben von Code wurde deutlich einfacher, doch das gemeinsame Verständnis der dahinter liegenden Bedeutung anspruchsvoller. Der entscheidende Engpass verlagerte sich von der technischen Umsetzung zur Semantik. Eric Evans beschrieb 2003 in seinem Buch „Domain-Driven Design“ erstmals konsequent, dass die eigentliche Herausforderung in der Softwareentwicklung in der vom Code repräsentierten Bedeutung liegt (vgl. Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003).

Domain-driven Design (DDD) war ein Durchbruch, denn das Konzept verschob die Diskussion von implementierungsgetriebenen Strukturen hin zur fachlichen Semantik. Konzepte wie Ubiquitous Language, Bounded Contexts und Aggregates stärken das gemeinsame Verständnis über Begriffe und Abläufe. Damit macht DDD ein Problem sichtbar, das bis heute besteht: Bedeutung lässt sich modellieren, bleibt aber in vielen Systemen im fertigen Code nur indirekt erkennbar.

Neben DDD verfolgen auch andere Architekturprinzipien wie Clean Code dieselbe Kernidee: Code verständlich machen. Sie entstanden aus der Einsicht, dass die technische Struktur nur ein Teil des Problems, die eigentliche Hürde aber das Verstehen ist.

Diese Konzepte setzen jedoch voraus, dass das erforderliche fachliche Verständnis bereits vorhanden ist. Sie schaffen eine Struktur, die dieses Wissen abbildet, machen die zugrunde liegenden Entscheidungen im Code selbst aber nur begrenzt sichtbar.

Aus der Forschung: Wie mentale Last entsteht

Mentale Last entsteht überall dort, wo ein System Bedeutung nicht ausdrückt, sondern das Verständnis den Leserinnen und Lesern überlässt. Dieser Effekt ist gut untersucht.

Bei Untersuchungen mit funktioneller Magnetresonanztomographie (fMRT) zeigte sich, dass Codeverständnis mit messbarer kognitiver Belastung einhergeht und dass diese Belastung je nach Verständlichkeit des Codes variiert. Fehlen Orientierung und Kontext, steigt der mentale Aufwand: Das Gehirn muss mehr kognitive Arbeit investieren, um Zusammenhänge herzustellen, die im Code nicht unmittelbar ersichtlich sind.

Scheinbare Banalitäten können schon messbare Auswirkungen haben, wie eine andere Studie zeigt, in der ausgeschriebene Wort-Identifier rund 19 Prozent schneller verstanden wurden als Kürzel oder Einzelbuchstaben.

In der Programmierpraxis zeigt sich mentale Last besonders deutlich in drei Situationen:

1. Unmarkierte Bedeutungswechsel

Beispiel: Ein Vorgang wandelt sich im Code von „Order“ zu „Booking“, ohne dass der Wechsel sichtbar wird. Für das Gehirn bedeutet das einen Kontextsprung. Es fehlt die semantische Markierung, die den Übergang verständlich macht.

2. Implizite Regeln

Beispiel: Ein Parameter darf nur in bestimmten Zuständen gesetzt werden. Das System läuft, aber es drückt nicht aus, welche Annahme gilt. Leserinnen und Leser kompensieren das durch mentale Simulation.

3. Struktur ohne semantische Orientierung

Beispiel: Technische Schichten trennen Abläufe, aber nicht Begriffe. Das Gehirn folgt dem Code, aber nicht dem fachlichen Gedankengang. Orientierung entsteht erst nach mehreren inneren Rekonstruktionsschritten.

Die Beispiele haben ein gemeinsames Muster: Der Code trägt syntaktische Struktur, nicht semantische Bedeutung.

KI als Spiegel

Wie fügt sich nun künstliche Intelligenz (KI) in diese Betrachtungen? Die Geschichte der Softwareentwicklung hat große Fortschritte vom „Wie“ zum „Was“ gemacht. KI soll diesen Weg nun abschließen, indem sie ein Code-Interface in natürlicher Sprache gestaltet. Einstweilen gibt es hier aber noch spürbare Hürden.

Eine der faszinierendsten Eigenschaften von Large Language Models (LLMs) ist, dass sie den Kontext ihres Prompts spiegeln. Eine Studie aus dem Jahr 2023 hat untersucht, welche Arten von Codefehlern LLMs machen. Dabei zeigten sich wiederkehrende Fehlerklassen: falsche Annahmen und inkorrekte logische Richtung. Sprich: keine Syntaxpatzer, sondern Hinweise auf eine fehlende Entscheidungsspur im Kontext. Modelle reproduzieren Struktur, verfehlen aber häufig Bedeutung – ganz so wie es Menschen oft tun, wenn sie ohne Vorwissen in ein System stolpern.

Noch deutlicher wird dieser Effekt, wenn die Lesbarkeit bewusst verschlechtert wird. Bei obfuskiertem Code bricht die Leistung spürbar ein. Erfahrene Entwicklerinnen und Entwickler können sich in solchen Fällen teilweise mit Erfahrung und analytischem Vorgehen behelfen, arbeiten dabei jedoch langsamer, unsicherer und mit höherem Fehlerrisiko. Hier wird sehr deutlich: Nimmt die Lesbarkeit ab, sinkt die Leistungsfähigkeit – bei Menschen wie auch bei KI-Modellen. Beide sind auf explizite Hinweise angewiesen, um Bedeutung zuverlässig zu erschließen.