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

Es ist spät. Links auf dem Bildschirm: Software kollabiert. Die Bewertungen im freien Fall. Bauen ist gratis geworden, ein funktionierendes Produkt entsteht an einem Wochenende, und übrig bleibt nur die Frage, ob dich überhaupt noch jemand hört. So steht es in einem Post, der gerade durch alle Feeds geht.

Rechts läuft ein kleines Tool, das die Person vor diesem Bildschirm sich vor drei Monaten mit KI gebaut hat. Und es funktioniert. Nicht so lala. Es funktioniert wirklich.

Beides fühlt sich wahr an. Und beides ist es auch. Kann KI Software entwickeln? Ja. Genau da fängt das Missverständnis an. Denn die Doom-Fraktion misst völlig korrekt, sie misst nur im falschen Bezugssystem. Legst du das Lineal an die Schicht an, also an den Quellcode, das Artefakt, den Jobtitel, dann stirbt tatsächlich alles. Legst du es an die Funktion an, also daran, Maschinen dazu zu bringen, verlässlich Nützliches zu tun, dann hat sich seit sechzig Jahren nichts geändert.

Ich nenne das Schrödingers Doomer. Beide Zustände sind gleichzeitig wahr, solange niemand festlegt, wo gemessen wird. Der Fehler der Doom-Seite ist deshalb kein Beobachtungsfehler. Es ist ein Koordinatenfehler. Sie halten ein bewegtes Bezugssystem für ein kollabierendes Universum. Und wo du das Lineal anlegst, entscheidet, was du als Nächstes tust: bauen, abwarten oder umlernen.

Zu der Frage, was KI mit der Softwareentwicklung macht, gibt es inzwischen viele saubere Übersichten. Fraunhofer hat eine, die IHK hat eine, IBM auch. Was mir darin fehlt, ist eine Position. Ich komme aus der Software-Architektur und arbeite mit Betrieben, die am Ende mit dem leben müssen, was gebaut wurde. Deshalb hier keine Übersicht, sondern eine These.

Kann KI Software entwickeln?

Ja. Code erzeugen ist im Wesentlichen gelöst. Und genau deshalb ist die Frage falsch gestellt: Sie misst die eine Schicht, die gerade billig wird.

Meine These dazu ist: Source Code ist das neue Assembler. Den Satz habe ich vor ein paar Monaten schon in einem Podcast gesagt, und seitdem ist er 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: Wenn eine Ressource billiger wird, sinkt der Verbrauch nicht, er explodiert. Jede frühere Kostensenkung in der Entwicklung hat 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).

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. Es ist genau die Illustration.

Wie lange gibt es noch Software-Entwickler?

Den Namen vermutlich länger, als gerade viele glauben. Den Inhalt darunter nicht. Ob am Ende trotzdem ein neuer Titel steht, ist offen und wird gerade ausgefochten.

Es gibt historisch zwei Muster, und von außen sehen sie gleich aus. Manche Titel sterben wirklich: Setzer, Lochkartenoperator. Andere überleben und werden von innen ausgetauscht. Die Buchhaltung gibt es noch, aber niemand addiert dort Spalten per Hand.

Was darüber entscheidet, welches Muster greift, ist die Funktion dahinter. Der Setzer ist verschwunden, weil das Setzen verschwunden ist. Die Buchhaltung ist geblieben, weil Bücher weiterhin geführt werden und sich nur die Methode geändert hat. Das ist dieselbe Frage wie oben, angewendet auf ein einzelnes Wort: Misst du den Titel an der Schicht oder an der Funktion?

Bei „Softwareentwickler“ löst sich das allerdings nicht sauber auf, und ich will hier nicht so tun, als hätte ich die Antwort. Zwei Strömungen ziehen gleichzeitig, in entgegengesetzte Richtungen.

Die eine zieht in Richtung Bleiben. Am Titel hängen Gehaltsbänder, Studiengänge, Visa-Kategorien, Steuerklassifikation, HR-Level. Das ist tragende Wand, und die reißt niemand wegen einer Methodenänderung ein. Dazu kommt ein Argument aus meinem eigenen Fach: Ein Berufstitel ist eine Schnittstelle nach außen und keine Beschreibung der Arbeit. Kundschaft, Recruiting, Behörden und Jobbörsen brauchen einen stabilen Namen zum Andocken, und Schnittstellen benennt man zuletzt um, lange nachdem die Implementierung dahinter eine andere geworden ist.

Die andere Strömung zieht in Richtung Neuanfang. Wenn sich Anforderungen und Profil weit genug verschieben, passt das alte Etikett irgendwann nicht mehr, und dann entsteht ein neuer Name für eine Rolle, die es vorher nicht gab. Dass das bereits läuft, sieht man an den Ausschreibungen: Stellen für die klassischen Entwicklerprofile wie Android, Java, .NET, iOS und Web liegen 60 Prozent oder mehr unter dem Niveau von 2020, während Ausschreibungen für ML-Engineers um 59 Prozent gestiegen sind (Quelle: Cloud Perspectives, 2026).

Welche Strömung gewinnt, weiß ich nicht. Das ist ein zähes Tauziehen, und beide Seiten haben gute Argumente. Ich würde mich auf keine von beiden verlassen. Verlassen kannst du dich auf die Bewegung darunter: Egal welches Etikett am Ende draufsteht, die Arbeit verschiebt sich in dieselbe Richtung. Das ist der Teil, mit dem sich planen lässt.

Was tatsächlich wegfällt, ist die Mitte. Oben bleibt das Denken: entscheiden, was gebaut werden soll und woran man erkennt, dass es stimmt. Weg fällt die Schicht darunter, die übersetzt: fertig spezifiziertes Ticket rein, Code raus. Das war schon immer die mechanischste Etage, und die geht als erste. Für einen Betrieb, der Software einkauft, ist das die praktisch relevante Stelle. Genau diese Schicht stand bisher auf der Rechnung als Umsetzung.

Und die Etage ganz unten, das Handwerk am echten Code? Da lasse ich meine eigene Analogie gegen mich gelten. In Assembler steigt heute niemand mehr, außer in ein paar sehr speziellen Ecken wie Compilerbau, Embedded oder Security. Wenn Quellcode wirklich das neue Assembler ist, dann wird Handarbeit am Code genauso zur Spezialität. Was heute noch danach aussieht, ist meistens schon etwas anderes: den Agenten enger führen, ihm die richtige Spur zeigen, das System so instrumentieren, dass der Fehler überhaupt sichtbar wird. Von Hand debuggen wird die Ausnahme.

Es gibt eine Stelle, an der die Doom-Seite trotzdem recht behält. Ich komme am Ende darauf zurück, weil ich sie nicht wegmoderieren will.

Wohin wandert der Wert, wenn Code billig wird?

In drei Richtungen: Verifikation, Verantwortung über Zeit und Spezifikation. 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).

Und dazu gehört eine unbequeme Beobachtung, sonst klingt das zu glatt: Der Wert ist bereits dorthin gewandert, die Praxis noch nicht. 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 Arbeitslosigkeit, 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

Der dritte Ort ist fast komisch. 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.

Kann ich eine Software mit KI entwickeln?

Bauen kannst du sie. Die eigentliche Frage ist, ob du sie danach verantworten kannst. Das entscheidet sich nicht am Tag 1, sondern in Monat 14.

Ich benutze dafür gern ein Bild. Jeder kann eine Hütte im Wald bauen. Ein sechsstöckiges Haus ist etwas anderes. Und der Unterschied ist keine Größenfrage, es ist ein Regimewechsel. Bei der Hütte kippt das Dach ein und kostet dich einen Nachmittag. Beim Haus sind Menschen drin. Ab einer bestimmten Höhe greift andere Physik: Lastabtragung, Fluchtwege, Brandschutz. Jede Zeile Bauordnung ist geronnene Erfahrung aus eingestürzten Häusern.

Das Bild klingt nach Analogie, steht aber inzwischen so in der Fachliteratur. Mark Russinovich, CTO von Microsoft Azure, und Scott Hanselman schreiben in einem peer-reviewten Beitrag für die Communications of the ACM den Satz: Programming is not software engineering (Quelle: Communications of the ACM via InfoQ, 2026).

Das Muster sieht dann ungefähr so aus. Ein kleiner Betrieb baut sich mit KI die eigene Auftragsverwaltung. Und sie funktioniert. Am Tag 1 fühlt sich die Hütte an wie ein Haus.

Die Rechnung kommt in Monat 14. Keine Backups. Niemand weiß mehr, wie es funktioniert. Die Person, die es gebaut hat, ist nicht mehr da. Der Feedback-Loop ist kaputt, weil die Quittung so spät kommt, dass sie niemand mehr mit der ursprünglichen Entscheidung verknüpft.

Daraus folgt eine Einkaufsfrage, die sich verschoben hat. Ein kleiner Betrieb kauft keine Features. Er kauft Verlässlichkeit über Zeit. Wer heute individuelle Software entwickeln lässt, fragt deshalb weniger „wie viel Kapazität brauche ich“ und mehr „wessen Urteilsvermögen kaufe ich ein“. Der Markt für Hände fällt im Preis. Der Markt für Verantwortung nicht.

Und jetzt kommt der Teil, den ich kleinen Teams gern mitgebe, weil er in der ganzen Untergangsdebatte untergeht. Kleine Betriebe sind hier strukturell im Vorteil. Die Person, die entscheidet, ist meistens dieselbe, die es später verantwortet. Genau diese Nähe zwischen Entscheidung und Konsequenz müssen große Organisationen gerade mühsam wiederherstellen. In einem Betrieb mit fünf Leuten ist sie einfach da.

Was fehlt, wenn die unterste Sprosse verschwindet?

Die Lernstrecke. Berufsanfänger:innen haben das Handwerk genau an der Übersetzungsarbeit gelernt, die jetzt automatisiert ist. Darauf hat im Moment niemand eine gute Antwort.

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 damit auch die zweite unbequeme Stelle, die ich nicht überspringen will. 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.

Was bleibt

Ein Berufsstand hat sechzig Jahre lang die Arbeit aller anderen automatisiert. Jetzt steht er zum ersten Mal selbst im Radius. Und die, die es überstehen, sind dieselben wie damals: diejenigen, die sich über das Ergebnis definiert haben und nicht über das Artefakt.

Wer sagt „ich schreibe Code“, verliert gerade den Beruf. Wer sagt „ich sorge dafür, dass Maschinen verlässlich Nützliches tun“, hat ihn nie an den Code gebunden.

Und deshalb ist die Frage, wo du das Lineal anlegst, keine akademische. Sie entscheidet darüber, ob du den nächsten Schritt überhaupt siehst.