Es funktioniert. Aber weiß noch jemand, warum?

Der Ablauf ist inzwischen Alltag: Anforderung formulieren, Code generieren lassen, Tests laufen lassen. Die Pipeline wird grün, die Oberfläche tut, was sie soll. Am Ende steht der Satz, mit dem ein Ticket geschlossen wird: „Es funktioniert.”

Der Satz ist nicht falsch. Er ist nur eine sehr kurze Antwort auf eine ziemlich lange Frage.

Jede Stufe hat etwas mitgenommen

Der Vorwurf, eine neue Abstraktionsstufe entfremde uns von der Maschine, ist so alt wie das Fach. Und er hatte jedes Mal einen wahren Kern.

Mit C# und Java hat die Speicherverwaltung ein Laufzeitsystem übernommen. Der Gewinn war enorm, die Klasse von Fehlern, die man sich damit vom Hals geschafft hat, ebenfalls. Bezahlt wurde er mit einem Stück Distanz: Wer nie selbst Speicher freigegeben hat, entwickelt kein Gefühl dafür, was ein Objekt kostet. Bei Frameworks wiederholt sich das eine Ebene höher. Sie nehmen die immer gleiche Verdrahtung ab und geben dafür eine Vorstellung davon mit, wie eine Anwendung aussehen soll. Wer sich darin bewegt, ohne die Vorstellung zu kennen, kämpft irgendwann gegen das Framework, statt mit ihm zu arbeiten. Cloud-Plattformen haben dasselbe mit dem Betrieb gemacht. Server, Netzwerk und Speicher sind heute Konfiguration. Das ist gut, bis eine Abrechnung oder ein Ausfall daran erinnert, dass unter der Konfiguration weiterhin ein Rechenzentrum steht.

Das Muster ist immer gleich: Die Abstraktion übernimmt eine Aufgabe. Sie verschwindet aus dem Alltag, und mit ihr verschwindet ein Teil des Verständnisses für sie. In der Regel ist das ein guter Tausch. Niemand möchte zurück zu manueller Speicherverwaltung, nur um ein Gefühl für Objektgrößen zu behalten.

Warum KI nicht einfach die nächste Stufe ist

Was sich mit KI ändert, ist die Art der Aufgabe, die übernommen wird.

Ein Garbage Collector nimmt eine Tätigkeit ab, die klar umrissen ist. Ein Framework nimmt Struktur ab, eine Cloud-Plattform Betrieb. Alle drei sind deterministisch genug, dass man sie prüfen, messen und im Zweifel nachlesen kann. Sie nehmen Arbeit ab, aber keine Entscheidungen.

Ein Sprachmodell kann Entscheidungen abnehmen. Es liefert nicht nur die Umsetzung, es liefert auch den Entwurf: die Aufteilung in Module, die Wahl der Datenstruktur, die Reihenfolge der Prüfungen, den Umgang mit dem Sonderfall. Wenn das Ergebnis funktioniert, gibt es keinen natürlichen Anlass, diese Entscheidungen noch einmal aufzurollen. Bei früheren Abstraktionsstufen musste man das Denken selbst mitbringen, weil die Werkzeuge es nicht konnten. Jetzt kann man es delegieren, ohne dass es auffällt. Das ist der Unterschied, und er ist kein gradueller.

Hinzu kommt, dass generierter Code selten schlecht aussieht. Er ist formatiert, benannt, kommentiert und passt sich dem Stil der Umgebung an. Genau das macht die Prüfung schwerer als bei Code, der handgeschrieben und sichtbar unfertig ist. Wir haben das in unserem Zwischenstand zu Coding-Agents als „plausibel statt korrekt” beschrieben: Der Code liest sich richtig, und deshalb liest man ihn weniger genau.

Die Frage ist nicht, wer jede Zeile erklären kann

Aus dieser Diagnose wird gern eine Forderung, die niemand erfüllen kann: dass Entwickler ihren Code bis zum Maschinencode durchdringen müssten. Das war nie so und muss auch nicht so sein. Die Abstraktion hat einen Sinn, und der Sinn ist, dass man eben nicht jede Ebene gleichzeitig im Kopf hat.

Die tragfähigere Anforderung liegt auf der Ebene des Teams. Für jedes System, das im Betrieb ist, müssen drei Fragen jederzeit beantwortbar sein:

1. Warum ist das so gebaut? Nicht wie, sondern warum. Welche Alternative wurde verworfen, und aus welchem Grund?
2. Welche Annahmen stecken darin? Über Datenmengen, über Antwortzeiten, über das Verhalten fremder Systeme, über die Reihenfolge von Ereignissen.
3. Was passiert, wenn sich eine dieser Annahmen ändert? Bricht dann eine Funktion, oder bricht die Architektur?

Diese Fragen sind nicht neu. Neu ist, dass ein System heute entstehen kann, ohne dass sie im Team jemals gestellt wurden. Früher war die Mühe des Schreibens ein Nebeneffekt, der das Nachdenken erzwang. Dieser Nebeneffekt ist weg, und er kommt nicht von allein zurück.

Das Problem ist die unbesetzte Verantwortung

KI-generierter Code ist nicht das Problem. Code, für den sich niemand mehr verantwortlich fühlt, schon.

Der Unterschied zeigt sich nicht beim Schreiben, sondern beim ersten Vorfall. Wenn nachts etwas ausfällt, hilft kein Prompt-Verlauf. Es hilft jemand, der das Modell im Kopf hat: der weiß, welche Annahme gerade verletzt wurde, wo sie herkam und was sie sonst noch trägt. Dieselbe Rolle braucht es bei der nächsten Erweiterung, bei der Frage, ob eine Anforderung in die bestehende Struktur passt oder sie sprengt, und bei jeder Migration.

Praktisch heißt das: Übernommener Code braucht einen Menschen, der dafür einsteht. Nicht als Formalie in einem Review-Feld, sondern im Sinne von: Diese Person kann die drei Fragen beantworten, auch in einem halben Jahr. Ob der Code dafür von Hand geschrieben, aus der Dokumentation kopiert oder von einem Modell erzeugt wurde, ist gleichgültig. Was nicht gleichgültig ist: dass die Person existiert und benannt ist. Bei uns ist das einer der Gründe, warum wir Software nicht nur bauen, sondern auch betreiben – Verantwortung, die mit der Übergabe endet, ist keine.

Was sich an der Arbeit verschiebt

Wahrscheinlich schreiben Entwickler künftig weniger Code selbst. Das ist keine Verarmung des Berufs, sondern eine Verschiebung des Schwerpunkts, wie bei den Abstraktionsstufen davor.

Was dadurch wichtiger wird, ist die Urteilsfähigkeit: einschätzen können, ob ein vorgeschlagener Entwurf zum Problem passt; erkennen, welche Annahme in einem Vorschlag steckt, die dort nicht stehen sollte; eine Lösung ablehnen, die funktioniert, aber am falschen Ort ansetzt. Das ist anspruchsvoller als Tippen, nicht einfacher. Und es ist schwerer zu erwerben, wenn die Gelegenheit zum Selbstbauen seltener wird. Diese Frage ist offen, und wir haben sie in unserem Agenten-Post ebenfalls offen gelassen: Wie erwirbt jemand Urteilsvermögen über Code, ohne die Jahre des Selberschreibens?

Darum lohnt die alte Frage in neuer Form. Ist das nur die vertraute Skepsis gegenüber der nächsten Abstraktionsstufe, die sich in zehn Jahren so überholt anhört wie heute die Warnung vor Garbage Collection? Oder ist der Unterschied diesmal ein anderer, weil zum ersten Mal nicht die Ausführung abstrahiert wird, sondern die Entscheidung?

Wir halten beides für möglich und richten uns vorerst nach dem, was in jedem Fall stimmt: Für jedes System muss jemand die drei Fragen beantworten können. Solange das gesichert ist, darf der Code herkommen, woher er will.