Schrödingers Doomer:Software stirbt nicht, sie zieht eine Etage höher

Code erzeugen ist im Wesentlichen gelöst. Die Frage misst nur die eine Schicht, die gerade billig wird.

Meine These dazu ist: Die Rolle von Source Code wird der Rolle von Assembler zunehmend ähnlich. Die Idee habe ich bereits vor ein paar Monaten in einem Podcast gesagt, und seitdem ist sie mir eher fester geworden. Um zu verstehen, was das bedeutet, muss man einmal sechzig Jahre zurück und sich anschauen, was der Sprung von Assembler zu Hochsprachen wirklich gebracht hat.

Die einzelne Zeile wurde damit leichter zu schreiben, klar. Der eigentliche Effekt war aber ein anderer: Hochsprachen haben Software größer gemacht. Sie ermöglichten Programme, die in Assembler nicht unmöglich waren, sondern unwartbar. Die Grenze lag nie bei der Frage, ob die Maschine etwas ausführen kann. Die Grenze lag immer bei der Frage, ob ein Mensch es über Jahre und über wechselnde Teams hinweg noch versteht. Und die verschob sich nicht, sie wanderte nur mit.

Und die Folge war nicht weniger Software. Es war absurd viel mehr. Das Muster hat einen Namen, Jevons-Paradox, und das Paradoxe daran ist die enttäuschte Erwartung: Als James Watts Dampfmaschine deutlich weniger Kohle pro Arbeitseinheit brauchte, rechneten alle mit sinkendem Kohleverbrauch. Stattdessen verdreifachte er sich, weil Dampfkraft auf einmal überall wirtschaftlich war. Effizienz senkt den Verbrauch nicht, sie erschließt neue Verwendungen. Genau so hat jede frühere Kostensenkung in der Softwareentwicklung eine Welle von Anwendungen ausgelöst, die vorher niemand auf dem Schirm hatte: Assembler zu Hochsprache, Mainframe zu PC, Desktop zu Web, Web zu Mobile.

Ehrlicherweise ist das keine Garantie. Wenn die Nachfrage diesmal schnell sättigt, gewinnt die Verdrängungsgeschichte. Das weiß im Moment niemand.

Was man aber weiß: Die Assembler-Leute wurden nicht arbeitslos. Über ihnen entstand eine Rolle, die es vorher nicht gab, nämlich Systemarchitektur. Die Komplexität ist nicht verschwunden. Sie ist eine Etage hochgezogen.

Dass diese Rotation auch heute real ist, lässt sich zeigen. In einem Microsoft-Projekt namens Societas haben sieben Teilzeit-Engineers in zehn Wochen 110.000 Zeilen Code produziert, davon 98 Prozent KI-generiert. Die menschliche Arbeit verschob sich dabei vom Schreiben zum Dirigieren (Quelle: Futurum Group, 2026).

Wie sehr die Messposition entscheidet, sieht man auch an den Zahlen, mit denen solche Posts arbeiten. Die SaaS-Bewertungen sind wirklich gefallen, der Median lag im März 2026 bei 3,4x Umsatz (Quelle: Aventis Advisors, 2026). Nur wird dabei die komplette Bewegung der KI zugeschrieben, obwohl ein guter Teil davon schlicht Zinsumfeld ist. 2021 war Nullzins, heute nicht.

Viel interessanter ist, was danach passierte. Im Juni-Quartal 2026 lag der Schnitt wieder bei 4,7x, hoch von 3,9x im Vorquartal, und SaaS-Aktien schlugen den S&P 500. Die Einordnung der Analysten dazu, wörtlich: Der Markt schien zu begreifen, dass viele, wenn nicht die meisten Softwareunternehmen eben nicht durch KI ersetzt werden (Quelle: First Analysis, 2026). Wie weit dieser Sprung selbst nur kurzfristig war und wieder zurückfällt, wird sich zeigen. Aber er zeigt: Auf die 3,4x vom März folgte nicht einfach der nächste Verlust, es gibt eine Gegenbewegung.

Der Markt selbst war also in Superposition. Wer im Frühjahr eine Momentaufnahme als Strukturaussage verkauft hat, hat genau den Fehler gemacht, um den es hier geht. Ich sage das ohne Häme, aber es ist genau die Illustration für den Diskussionspunkt.

Alle drei liegen außerhalb des Systems, das den Code erzeugt.

Bevor ich die drei aufmache, kurz die Begründung, warum sie in zwei Jahren nicht egal sind. Jeder Satz der Form „KI kann das noch nicht gut genug“ ist in sechs Monaten Altpapier. Ich brauche also eine Behauptung, die auch dann noch steht, wenn die Modelle dreimal besser sind.

Ein System kann nicht sein eigenes Abnahmekriterium sein. Irgendwer muss von außen sagen, was richtig heißt, und die Konsequenzen tragen, wenn es falsch war.

Diese Lücke schließt kein Modell. Sie ist strukturell.

Und es reicht weiter als diese drei Richtungen. Ein Modell ist auf das trainiert, was im Schnitt am besten bewertet wurde. Sein Default ist deshalb die Mitte, nicht weil es nichts Besseres könnte, sondern weil die Mitte das ist, wohin es ohne Führung zieht. Für Texte habe ich das in „Warum KI-Texte generisch klingen“ auseinandergenommen, dort heißt der Satz: Der Default ist die Mitte, nicht deine Kante. Für Software gilt er genauso. Und daraus folgt eine Verschiebung, die über meine drei Kategorien hinausgeht: Die Mitte wird zur Grundausstattung, und wertvoll wird alles, was oberhalb davon liegt.

Und hier liegt der Punkt, den ich in der ganzen Assembler-Analogie für den wichtigsten halte. Assembler zu C war eine deterministische Abstraktion. Der Compiler ist eine Funktion. Gleicher Input, gleicher Output. Und wenn er falsch liegt, liegt er reproduzierbar falsch. Genau deshalb durftest du aufhören, den Assembler zu lesen.

Prompt zu Code ist nicht deterministisch. Der neue Compiler ist stochastisch, er ist nicht beweisbar. Also leckt die Abstraktion nach unten, und zwar dauerhaft. Du kannst die untere Ebene noch nicht aus den Augen lassen, solange die obere keinen Beweis mitliefert.

Die eigentliche Frage der nächsten Jahre ist deshalb nicht, ob KI Entwickler:innen ersetzt. Sie lautet: Was wird die Verifikationsschicht, die den stochastischen Compiler deterministisch genug macht?

Verifikation: der Engpass ist schon umgezogen

Die Daten dazu sind ziemlich eindeutig. KI schreibt inzwischen 42 Prozent des committeten Codes. 96 Prozent der Entwickler:innen vertrauen der funktionalen Korrektheit dieses Codes nicht vollständig. Und nur 48 Prozent prüfen ihn immer, bevor sie ihn committen (Quelle: Sonar, 2026). AWS-CTO Werner Vogels hat einen Namen dafür geprägt: Verifikationsschuld. Wie jede Schuld wird sie nicht sofort fällig.

In der Produktion sieht das dann so aus: 43 Prozent der KI-generierten Änderungen brauchen manuelles Debugging im Live-Betrieb, obwohl sie QA und Staging bestanden haben. Und kein einziger der befragten Engineering-Leader bezeichnete sich als sehr zuversichtlich, dass der Code im Deployment korrekt läuft (Quelle: Lightrun, 2026).

Eine problematische Ergänzung dazu: 96 Prozent misstrauen, 48 Prozent prüfen. Das ist keine Wissenslücke, das ist eine Zeitlücke. Und genau in dieser Lücke entstehen gerade die Systeme, die erst viel später auffallen.

Verantwortung über Zeit: ein System bauen, das man verantworten kann

Mike Grouchy hat das Risiko in einem Satz formuliert, den ich seitdem oft im Kopf habe. Das Problem sei nicht, dass Entwickler:innen nichts mehr zu tun haben, sondern mehr Software, als Organisationen sicher betreiben, absichern und warten können (Quelle: AmazingCTO, 2026).

Betreiben, absichern, warten. Diese drei Verben sind die Arbeit. Denn Verantwortung über Zeit heißt nicht, dass jemand hinterher geradesteht. Es heißt, ein System zu bauen, das sich überhaupt verantworten lässt. Und das entscheidet sich vor der ersten Zeile Code, an vier Fragen.

Wie fügt sich das in die bestehende Systemlandschaft ein? Nicht: läuft das Ding für sich genommen. Sondern: Was gibt es schon, was redet mit was, wo entstehen Doppelungen, und wo entsteht plötzlich eine zweite Wahrheit über denselben Kunden. Ein Tool, das isoliert perfekt funktioniert und danebenher eine eigene Kundenliste führt, hat kein Feature-Problem. Es hat ein Landschaftsproblem.

Welche anderen Systeme benutze ich, und wie hängen die zusammen? Jede Verbindung nach außen ist eine Annahme über ein fremdes System. Über Feldnamen, über Fehlercodes, über das, was passiert, wenn die Gegenseite mal nicht antwortet. Diese Annahmen gehören an genau eine Stelle geschrieben, gegen die alles andere prüft. Sonst merkst du erst im Fehlerfall, dass sie falsch war, und dann suchst du in drei Systemen gleichzeitig.

Wer darf eigentlich was? Berechtigungen sind kein Detail für später. Wer sieht welche Kundendaten, wer darf löschen, wer darf exportieren, wer darf Preise ändern. Ein schnell gebauter Prototyp hat meistens genau eine Berechtigungsstufe, nämlich alles. Und das ist die Entscheidung, die sich später am teuersten korrigieren lässt.

Was passiert, wenn etwas schiefgeht? Nicht ob, sondern wenn. Wer merkt es überhaupt, und wie schnell? Gibt es ein Backup, und ist es jemals zurückgespielt worden? Und vor allem: Wie groß ist der Radius, wenn dieser eine Teil ausfällt? Steht ein Formular still oder das Geschäft?

Keine dieser vier Fragen ist eine Code-Frage. Alle vier muss eine Person beantworten, die den Kontext kennt und die Folgen trägt. Deshalb ist das die Etage, die nicht wegautomatisiert. Welche Fragen ein Prototyp beantworten sollte, bevor echte Kundendaten darauf liegen, habe ich in den neun Fragen zur Produktionsreife gesammelt. Die kurze Version: Software, die funktioniert, und Software, die hält, sind zwei verschiedene Dinge.

Spezifikation: die langweiligste Disziplin wird zur wichtigsten

Wenn die Umsetzung billig wird, verschiebt sich alles auf die Frage davor: Was genau will ich, und woran erkenne ich, dass ich es bekommen habe. Das ist keine Dokumentationsaufgabe, das ist die eigentliche Denkarbeit. „Der Kunde soll eine Bestätigung bekommen“ klingt nach einer fertigen Anforderung. Bis jemand fragt, was passiert, wenn dieselbe Bestellung zweimal reinkommt. Und ausgerechnet diese Denkarbeit galt jahrzehntelang als der langweilige Teil.

Welches Berufsbild aus dieser Verschiebung entsteht und was davon konkret den Tag füllt, habe ich in „Der langsame Tod des Programmierers“ ausbuchstabiert. Hier interessiert mich die Etage darunter: warum die Rotation überhaupt in diese Richtung läuft.

Berufsanfänger:innen haben das Handwerk genau an der Übersetzungsarbeit gelernt, die jetzt automatisiert ist.

Russinovich und Hanselman nennen das Phänomen AI drag. KI hebt erfahrene Leute massiv an und zieht Berufsanfänger:innen nach unten, weil denen das Urteilsvermögen fehlt, um KI-Output zu steuern, zu prüfen und zu reparieren. Die Anreizfolge ist absehbar: Firmen stellen Seniors ein und automatisieren Juniors. Und die Pipeline, die die nächsten Seniors hervorbringt, kollabiert leise.

Ihr Beispiel dazu sitzt. Ein KI-Agent reagierte auf eine Race Condition, indem er einen sleep-Aufruf einbaute. Ein klassischer Masking-Fix: Das Symptom verschwindet, der eigentliche Fehler bleibt drin und schlägt irgendwann unter Last zu. Wer sowas dreimal in Produktion erlebt hat, sieht es sofort. Wer nie eine echte Race Condition debuggt hat, weil immer eine KI den Code geschrieben hat, sieht es nicht.

Die Autoren haben einen Begriff für das, was da verloren geht: systems taste. Die Intuition, die über Jahre echter Produktionserfahrung entsteht. Und dahin, schreiben sie, kann man sich nicht prompten.

Das ist der strukturelle Unterschied zu allen früheren Rotationen, und deswegen nehme ich ihn ernst. Bei Assembler zu C war das kein Thema, du hast weiterhin C geschrieben und dabei gelernt. Diesmal ist die Lernstrecke selbst wegautomatisiert. Forrester rechnet passend dazu mit einem Rückgang der Informatik-Einschreibungen um 20 Prozent (Quelle: Forrester, 2026).

Ich habe darauf keine gute Antwort. Der beste Vorschlag, den ich kenne, kommt von denselben Autoren: ein Preceptor-Modell nach Vorbild der Pflegeausbildung, bei dem Lernen ein gemessenes und vergütetes Organisationsziel wird statt ein Nebenprodukt des Lieferns. Ob das trägt, wird sich zeigen.

Und dies fügt sich nahtlos an eine weitere Herausforderung an: Strukturell ändert sich nichts, biografisch ändert sich alles. Frühere Rotationen gaben einer Generation Zeit, der Weg von Assembler zu Hochsprachen lief über fünfzehn, zwanzig Jahre. Diese hier drückt sich in drei bis fünf. Eine Rotation, die du innerhalb einer Berufsbiografie nicht schaffst, ist funktional eine Wand, auch wenn die Kurve von weit oben aussieht wie immer.

Am ehesten könnte man Stephan Schmidt gegen mich ins Feld führen. Er argumentiert, der Jevons-Rebound lande auf der Ideenseite und nicht auf der Arbeitsseite: Unternehmen seien durch Ideen begrenzt, nicht durch Entwicklerkapazität, und die größte neue Software-Welle werde von Leuten gebaut, die nie Entwickler:innen hatten und nie welche einstellen werden. Sein Fazit lautet: mehr Software, weniger Entwickler:innen.

Ehrlich gesagt lese ich das kaum als Gegenposition. Es ist dieselbe Beobachtung, nur anders gezählt. Er zählt Köpfe in der alten Kategorie, ich zähle die Arbeit. Dass die Übersetzungsschicht kollabiert, steht bei ihm genauso wie hier.

Wirklich auseinander gehen die beiden Lesarten an einer einzigen Frage: Wer macht das, was übrig bleibt? Schmidt tippt darauf, dass die Leute mit den Ideen es selbst mitmachen. Ich tippe darauf, dass Betreiben, Absichern und Warten eine eigene Sache bleibt, die man einkauft, weil dafür ein Gefühl für große Systeme nötig ist, und das eignet man sich nicht nebenbei an. Wenn also Coaches, Restaurantbetriebe und Lehrer:innen die nächste Software-Welle bauen, dann braucht genau diese Welle jemanden dafür. Welche der beiden Lesarten näher dran ist, wird sich zeigen.