Geschlossene Welten und die Frage der Ersetzung

Dass sich die Softwareentwicklung durch KI verändert, habe ich Anfang September schon beschrieben. Die Frage, die danach oft kommt, ist eine andere: Werden wir alle ersetzt?

Meine kurze Antwort: Das vermischt zwei Dinge. Die eine Achse ist Fähigkeit — wo ein System zuverlässig scheitert, und warum? Die andere ist Arbeit — was passiert mit Stellen und Rollen, wenn es innerhalb eines begrenzten Bereichs oft genug klappt? Ein unsicheres Assistenzsystem kann trotzdem Stunden ersetzen. Ein beeindruckender Demo-Agent kann trotzdem neue Aufgaben schaffen. Der IMF spricht von hoher Exposure — rund 40 Prozent der globalen Beschäftigung, rund 60 Prozent in fortgeschrittenen Volkswirtschaften — und betont zugleich: Exposure ist keine beobachtete Massenarbeitslosigkeit.

Für mich hilft deshalb ein Bild: relativ geschlossene und relativ offene Welten.

Mit geschlossen meine ich nicht die logische Closed-World-Assumption aus Lehrbüchern. Ich meine: Wie vollständig und prüfbar ist der Zustand der Aufgabe?

Software ist ungewöhnlich gut maschinell beschreibbar. Quellcode, Konfiguration, Schemata und Versionsgeschichte sind diskret. Viele Erfolgskriterien sind automatisierbare Orakel: Compiler, Typchecker, Tests, Linter, CI. Unbekannte bleiben — Zero-Days, Produktions-Races, undefiniertes Verhalten. Sie werden oft als akzeptiertes Risiko geführt, nicht als permanente physische Überraschung.

Die physische Welt ist das Gegenteil: kontinuierlich, dynamisch, oft unvollständig beobachtbar. Tests erfassen nie alle Zustände. Ein Fehlschlag kann tödlich sein.

Das ist ein Spektrum, kein Schalter. Ein Unit-Test mit festen Eingaben ist geschlossener als eine Integration mit flaky Abhängigkeiten. Ein Lagerroboter in einer kartierten Gasse ist geschlossener als fußgängerreicher Stadtverkehr bei Regen. Auch Software ist nicht „fertig geschlossen“: Ambige Anforderungen, Organisationswissen und Security bleiben offen — auch wenn Code existiert.

Genau weil die Welt relativ geschlossen ist, kann KI hier extrem punkten. Benchmarks und Zeit-Horizonte steigen auf gut spezifizierten Softwareaufgaben. Gleichzeitig gilt: Score ist nicht Kompetenz in der Produktion. OpenAI argumentiert öffentlich, dass öffentliche SWE-bench-Verified-Zahlen durch Kontamination verzerrt sein können. Anthropic formuliert für Agenten: Wer einen Agenten bewertet, bewertet Harness und Modell zusammen.

Produktivität ist außerdem setting-abhängig. In einem engen Versuch mit GitHub Copilot waren Entwickler bei einem HTTP-Server in JavaScript im Schnitt deutlich schneller. In einer METR-Studie mit erfahrenen Open-Source-Maintainern an realen Issues dauerte die Arbeit mit KI-Erlaubnis im Mittel länger — bei weiterhin überschätzter eigener Beschleunigung. Der DORA-Report 2025 fasst den Stand zusammen: sehr hohe Nutzung, selbst berichtete Produktivität, zugleich Misstrauen gegenüber generiertem Code. KI verstärkt vorhandene Stärken und Schwächen. Tempo kann steigen. Stabilität kommt nicht gratis.

Kurz: KI schreibt viel. Sie ersetzt nicht die Verantwortung für „fertig und richtig“.

Wenn das Modell Code erzeugt und viele Routineprüfungen übernimmt, entfällt für mich nicht der Software Engineer. Es entfällt ein Teil der Arbeit, die früher Tippen und lokales Debuggen hieß.

Was bleibt und wächst:

1. Anforderungen aus der realen Welt so klar in die geschlossene Welt übersetzen, dass ein Agent sie umsetzen kann. Spec, nicht Wunsch.
2. Die Umgebung anpassen: Rules, Skills, Agent-Profile, Rechte, Prüfungen. Also den Harness so setzen, dass die Schleife nützlich und begrenzbar bleibt.
3. Tiefere Fehleranalyse. Es reicht nicht, „etwas ist kaputt“ zu erkennen. Jemand muss die Klasse des Fehlers verstehen, beheben und absichern, dass sie seltener wiederkehrt.

Frameworks helfen dabei, ersetzen die Arbeit aber nicht. So wie Spring Boot Entwicklung vereinfacht, ohne Entwickler überflüssig zu machen, vereinfachen Skillsets — etwa die von Matt Pocock — Agenten-Arbeit, ohne sie einem abzunehmen. Die Analogie ist für mich pädagogisch, keine Arbeitsmarktformel.

Der Stack-Overflow-Developer-Survey 2025 zeigt dieselbe Richtung in der Selbstwahrnehmung: hohe KI-Nutzung, viel Zeit mit „fast richtigen“ Antworten, und eine Mehrheit sieht KI (noch) nicht als Bedrohung für den eigenen Job. Das ist keine Garantie für die Zukunft. Es ist der aktuelle Ist-Zustand: Transformation und Review-Last, keine nachgewiesene Auslöschung der Profession.

Je offener die Welt, desto schwerer werden Tests und desto teurer Fehlklassifikationen. Assistenzsysteme werden besser. Der Mensch, der eingreifen muss, bleibt — zumindest so lange, wie das System nicht in einem klar begrenzten Betriebsbereich (Operational Design Domain, ODD) wirklich die Fahraufgabe samt Fallback übernimmt.

Die SAE-Norm J3016 ordnet das in Stufen 0 bis 5. Level 2 heißt: System steuert längs und quer, der Mensch überwacht. Level 4 ist hochautomatisiert innerhalb einer ODD. Level 5 wäre ohne ODD-Grenze. Die ODD ist für mich das offene-Welt-Gegenstück zu „die CI ist grün“: Grüne Tests beweisen nicht jede Straße.

Dazu kommt ein menschlicher Faktor. Wenn Automatisierung lange zuverlässig wirkt, sinkt die Überwachung. „Mensch in der Schleife“ ist keine kostenlose Sicherheitsgarantie.

Am 7. Mai 2016 kollidierte östlich von Williston, Florida, ein Tesla Model S mit aktivem Autopilot (Traffic-Aware Cruise Control und Autosteer) mit einem nach links abbiegenden Sattelzug. Das Auto fuhr unter den Auflieger; das Dach wurde abgerissen; der Fahrer starb. Das steht im Untersuchungsbericht der US-amerikanischen NTSB (HAR-17/02, Übersicht HWY16FH018).

Was die Daten und die NTSB dazu sagen:

• Autopilot-Funktionen waren aktiv. Das entspricht dem Charakter von SAE Level 2 — Fahrerassistenz mit Überwachungspflicht —, nicht einem fahrerlosen Level-4/5-Robotaxi.
• Vor dem Aufprall lag die Geschwindigkeit bei etwa 74 mph — bei einem Tempolimit von 65 mph.
• Frontalkollisionswarnung und automatische Notbremsung lösten nicht aus. Es gibt keinen Nachweis, dass das System den kreuzenden Lkw als Gefahr erkannt hat.
• Die wahrscheinlichste Ursache laut NTSB: Versäumnis des Lkw-Fahrers, Vorfahrt zu gewähren, plus Unaufmerksamkeit des Pkw-Fahrers durch Übervertrauen in die Automatisierung.
• Die NHTSA schloss ihre Defektprüfung ohne Autopilot-/AEB-Designdefekt und hielt fest: Die AEB jener Generation war nicht darauf ausgelegt, alle Crossing-Path-Unfälle zuverlässig abzufangen.

Tesla schrieb damals in „A Tragic Loss“, weder Autopilot noch Fahrer hätten die weiße Seite des Aufliegers vor hell erleuchtetem Himmel bemerkt, deshalb sei nicht gebremst worden. Das ist die Hersteller-Darstellung — nicht die NTSB-Ursachenformel.

Und jetzt die Folklore: In Erzählungen heißt es oft, das Auto habe den quer stehenden Auflieger für eine Brücke gehalten und sei ungebremst hineingefahren. Das ist Folklore. Weder im NTSB-Bericht noch in Teslas zitierter Primärformulierung steht eine Klassifikation „Brücke“. Wer den Vorfall erzählt, sollte die harten Fakten nennen: Nicht-Erkennung und Nicht-Bremsen in einer Crossing-Path-Geometrie, gepaart mit menschlichem Überwachungsversagen unter Level-2-Assistenz — und das Brücken-Bild ausdrücklich als ungeprüfte Legende markieren.

Genau deshalb begrenzt offene Welt die KI so stark: Ein Zustand, den Sensorik und Validierung nicht abdecken, wird oft gar nicht als die Gefahr behandelt, die er ist. Bessere Assistenzsysteme ändern die Statistik. Sie machen die Physik nicht geschlossen.

Dass der Mensch bei Störungen bleibt, heißt nicht, dass die Stellenanzahl gleich bleibt.

In der US-Industrieproduktion liegt die Beschäftigung weit unter dem Peak der späten 1970er Jahre. Ursachen sind gemischt: Produktivität, Offshoring, Automatisierung. Das Muster bleibt lehrreich: Weniger Köpfe, aber nicht null. Amazon berichtet über eine Million Roboter in der Fulfilment-Welt und gleichzeitig rund 1,58 Millionen Beschäftigte — mit wachsendem Bedarf an Zuverlässigkeit, Wartung und Engineering an robotisierten Standorten. Schwere Automatisierung und große menschliche Belegschaften für Ausnahmen, Flow und Instandhaltung koexistieren.

Dasselbe Muster gilt grob für Fahrassistenz: Bessere Systeme, begrenzte ODDs, weiterhin Menschen — und trotzdem können Stunden und Rollen schrumpfen, sobald Automation oft genug trägt.

Zwei Zahlen geistern durch Debatten. Frey und Osborne kamen auf rund 47 Prozent der US-Beschäftigung in Berufen mit hohem Computerisierungsrisiko. Die OECD hat später gezeigt, dass der berufsbasierte Ansatz überschätzt: Task-basiert liegen im Schnitt rund 9 Prozent der Jobs in 21 OECD-Ländern im hoch automatisierbaren Bereich.

Für mich heißt das: Aufgaben werden automatisiert, nicht ganze Berufsbezeichnungen auf einmal. Verdrängung bei automatisierten Tasks, mögliche Rückkehr von Nachfrage durch Produktivität und neue Tasks — das ist die brauchbarere Linse als die große Headline-Zahl.

Geschlossenheit ist ein Spektrum. Je besser Orakel und Spezifikation, desto weiter reicht KI — und desto teurer wird eine schlechte Spec.

In Software ersetze ich Tipparbeit, nicht Verantwortung. Spec, Harness, Skills und Review bleiben Menschenarbeit — oft mehr, nicht weniger.

In offenen Welten bleibe ich klar bei ODD und Überwachung. Level 2 ist keine Autonomie. „Mensch in der Schleife“ braucht Aufmerksamkeit, die Automatisierung gerade untergräbt.

Williston ohne Folklore erzählen. Nicht-Erkennung, kein AEB, Übervertrauen — und die Brücken-Story als Legende markieren.

Und: Fähigkeit ist nicht Arbeitsmarkt. Systeme können Stellen drücken, während sie unvollständig und riskant bleiben — und umgekehrt.

Die Frage „Werden wir alle ersetzt?“ ist deshalb die falsche Ja/Nein-Frage. Besser: Welche Tasks fallen weg, welche neuen entstehen, und wo bleibt die Haftung für die Klasse von Fehlern, die nur ein Mensch noch versteht?

Rückmeldungen, Fragen oder Hinweise sind wie immer herzlich willkommen.