Vor wenigen Monaten ließ ich unbedacht meine alte Dokumentenmappe auf dem Tisch liegen. Ihr kennt das – diese Sammlung aus einem früheren Leben: Urkunden, Zeichnungen aus der Kindheit und Zeugnisse. Zeugnisse, die man eigentlich nie wieder sehen möchte.
Meine 12-jährige Tochter blätterte darin und kommentierte trocken:
„Papa, du warst eine Katastrophe.“
Sie hatte Recht.
Von Jürgen Schmidt
Zuerst erschienen auf Der Standard am 7. April 2026
Im Community-Artikel auf Der Standard gibt Jürgen Schmidt Einblick in die Entwicklung der Softwareentwicklung von den frühen Tagen des Programmierens am C16 über immer höhere Abstraktionsebenen bis hin zu KI-gestütztem, agentischem Coding und der Verschiebung hin zu natürlicher Sprache als zentraler Schnittstelle.
Der Hauptgrund für diese Katastrophe stand damals in meinem Kinderzimmer: ein Commodore C16, Weihnachten 1984, ich war 14. Für meine Eltern war es ein Gerät, für mich war es ein Portal. Während andere Kinder draußen spielten, tippte ich stundenlang Code aus Magazinen ab. Zeile für Zeile. Fehler für Fehler. Hoffnung für Hoffnung.
Das war damals der Weg, wie man an Spiele kam. Diese Magazine waren quasi unser App-Store. Wir nannten das „Programmieren“. In Wahrheit war es eher eine frühe Form konzentrierter Leidensfähigkeit.
Level 1: Maschinen sprechen
Ich lernte, ich übte, und irgendwann wurde ich gut. Ich programmierte maschinennahen Assembler Code. Ich schrieb also Code, den ich selbst eine Woche später nicht mehr verstehen konnte: „Write-only code“ nannten wir das. Ein Begriff, der erstaunlich langlebig ist. Die Welt war klein. Die Entwickler waren wenige. Und Computer verstanden ausschließlich ihre eigene Sprache. In den 1980er-Jahren war BASIC das Versprechen – und Assembler die Realität. Auf Systemen wie dem C64 (mein zweiter Computer) oder dem ZX Spectrum konnte man zwar schnell etwas zum Laufen bringen, aber sobald es schnell, schön oder überhaupt kontrollierbar werden sollte, führte kein Weg mehr an der Maschine selbst vorbei. Abstraktion war ein Luxus, den man sich erst später leisten konnte.
Wer mit diesen Maschinen spielen wollte, musste sich also anpassen. Der Computer machte keinerlei Anstalten, uns entgegenzukommen. Wir mussten seine Sprache lernen, seine Logik akzeptieren, seine Strenge aushalten. (Wer jemals versucht hat Assembler zu debuggen, weiß was ich hier mit Strenge meine)
Level 2: Wir lernen ihre Sprache
Dann kamen höhere Sprachen. C, später C++ und das unsägliche Basic. Diese Sprachen gab es schon eine Zeit, aber nun hatten wir Computer, mit denen wir sie auch verwenden konnten. Bei mir war es ein 286er von IBM, meine erste Intel-Architektur. Jede dieser Sprachen war ein Schritt weg von der Maschine – und ein Schritt hin zum Menschen. Speicher musste nicht mehr komplett manuell verwaltet werden, Strukturen entstanden, Abstraktionen wurden möglich. Und mit jeder dieser Abstraktionen passierte etwas Entscheidendes: Immer mehr Menschen konnten programmieren. Das ist der eigentliche (historische) Kern dieser Entwicklung. Höhere Sprachen machen Softwareentwicklung nicht nur schneller, sondern zugänglicher. Sie nehmen ihnen die Exklusivität. In gewisser Weise demokratisieren sie.
Mit jeder neuen Sprache kam dieselbe Kritik: zu weit weg von der Hardware, zu wenig Kontrolle, zu viel Bequemlichkeit. Diese Kritik zieht sich wie ein roter Faden durch die Geschichte der Softwareentwicklung. Und sie war immer falsch. Denn dieser Kontrollverlust war die Voraussetzung für Fortschritt.
Level 3: Interfaces für Menschen
Irgendwann reichte es nicht mehr, dass nur Entwickler:innen Software bedienen konnten. Die Welt wollte Interfaces. GUIs (Graphical User Interfaces) entstanden. Fenster. Buttons. Mauszeiger. Anfang der 1990er Jahre arbeitete ich bei Siemens in der PSE. Wir waren stolz darauf, keine grafischen Interfaces zu haben. Unsere Software wurde von Maschinen genutzt, nicht von Menschen. Das erschien uns damals als Zeichen technischer Ernsthaftigkeit. Dass die wesentliche Entwicklung aber genau an der Schnittstelle zwischen Mensch und Maschine liegt, habe ich erst später verstanden. Software wird nicht bedeutend, weil sie technisch exzellent ist. Sie wird bedeutend, wenn Menschen mit ihr arbeiten können, an ihr Freude haben.
Level 4: Das Web abstrahiert alles
Dann kam das Web. Der Browser wurde zur universellen Plattform. APIs ersetzten direkte Systemzugriffe. Infrastruktur wanderte in die Cloud.
Und wieder passierte dasselbe: mehr Abstraktion, mehr Geschwindigkeit, noch mehr Menschen, die Software erschaffen konnten. Nein, die Qualität wurde dadurch nicht besser. Viele Probleme, die man früher im Code gelöst hätte, wurden nun mit Rechenleistung erschlagen. Eleganz wurde an vielen Stellen durch Skalierung ersetzt. Das ist nicht immer schön, aber oft erstaunlich effektiv. Rückblickend ist es amüsant, wenn heutige Software-Entwickler:innen beim Anblick von Agentic Coding vom Verlust der Kontrolle sprechen. Diese Kontrolle ist nicht gestern verloren gegangen. Sie ist seit Jahrzehnten in geordnetem Rückzug. Aber dabei passiert noch etwas Wesentliches. Software wird nicht mehr für jeden Einsatz entwickelt und gebaut. Es gibt sie bereits oder anders und jetzt neu, sie kann sehr schnell entstehen. Malen wir uns dazu ein Bild aus einer anderen Industrie: Es gibt weltweit tausende Firmen, die Wasser verkaufen. Keine einzige produziert Wasser. Das Wasser ist bereits da. Diese Firmen filtern es, verpacken es, transportieren es und bringen es in einen Kontext, in dem wir es nutzen können.
In gewisser Weise ist genau das über Jahre auch mit der Software passiert. Wir produzieren sie immer seltener im ursprünglichen Sinn. Wir kombinieren, abstrahieren, orchestrieren. Der eigentliche Wert entsteht nicht mehr nur im Schreiben von Code, sondern darin, ihn nutzbar zu machen.
Level 5: Computer lernen unsere Sprache
Und jetzt passiert etwas fundamental Neues. Zum ersten Mal in der Geschichte lernen nicht mehr Menschen die Sprache der Computer. Die Computer sind dabei, unsere Sprache zu lernen. Natural Language wird zur Schnittstelle.
Was früher so aussah:
// dummy-code
for (int i = 0; i < n; i++) {
value = extract_feature(data, i);
score = evaluate(value);
aggregate(score);
}
sieht heute so aus:
“Write me a function that analyzes this data and shows me the anomalies.”
Das ist keine kleine Verbesserung. Das ist ein Paradigmenwechsel. Über Jahrzehnte bestand Fortschritt darin, die nächste Generation von Programmiersprachen eine Ebene höher zu legen. Jetzt wird aus der Sprache selbst eine Entwicklungsumgebung. Und damit sinkt die Hürde weiter, an Software mitzuwirken.
Level 6: Agentic Coding
Multi-Agent-Systeme sind in der Lage, in kurzer Zeit hervorragenden Code zu produzieren. Sie verstehen Modelle, diskutieren über Architekturprobleme und finden Lösungen. Nicht immer perfekt, aber welche Programmierer:innen könnten das von sich behaupten. Die viel gepriesene Eleganz, das Malen von Code, wie ich das selbst gerne nannte, diesen Akt des Schaffens verlieren wir dabei nicht. Er wird nur breiter zugänglich. Auch wenn das mancher Romantik widerspricht: Wirklich belastbares Assembler-Wissen findet man heute nur noch selten. Ohne die Entstehung höherer Sprachen wären viele nie Programmierer:innen geworden. Diese gesamte Industrie würde in ihrer heutigen Form gar nicht existieren.
Genau deshalb ist Agentic Coding keine Entwertung des Programmierens, sondern seine nächste Öffnung.
Ziele, Regeln, Kontext, Kontext, Kontext
In unserem Unternehmen wird das Onboarding von Projekten großgeschrieben. Nicht aus Sentimentalität, sondern aus Notwendigkeit. Jeder, der an einem Projekt mitarbeitet, muss verstehen, warum wir etwas tun, welche Ziele dahinter stehen und wie wir uns ihnen annähern wollen. Softwareentwicklung war immer eine Annäherung an Ziele, nie deren sofortige Erfüllung. Genau das wird jetzt wichtiger als je zuvor. Die Komplexität verschwindet nicht. Sie verlagert sich. Die Vorteile sind vielfältig. Mit deutlich größerer Sicherheit können wir einschätzen, wie lange die Entwicklung dauern wird. Das Budgetrisiko sinkt, die Planbarkeit steigt. Und wir können uns stärker auf jene Fragen konzentrieren, die wirklich zählen: Systemverständnis, Kausalität, Architektur und Verantwortung.
Im Software-Engineering verbringen wir 15 oder 20 Prozent unserer Zeit damit, Code zu schreiben. Der Rest ist Verstehen, Strukturieren, Abstimmen, Bewerten, Verwerfen und Neuansetzen. Die Gretchenfrage ist also nicht mehr: Kannst du programmieren? Die Gretchenfrage lautet: Verstehst du, was du hier baust?
We don't develop software anymore - We prompt software into life
Ich bin gespannt, was meine Tochter einmal in ihre eigene Mappe legen wird. Ihre Generation wird mit künstlich geschaffenen Wesen völlig selbstverständlich sozial interagieren. Die Software für diese Systeme werden die Computer selbst entworfen und entwickelt haben. Unsere Aufgabe wird dann darin bestehen, diese neue Form der Entwicklung so zu führen, dass sie dem Menschen dient und dem Wohl der Menschheit verpflichtet bleibt. Meine Tochter hat andere Interessen als ich, sie lebt für Sprache und sie lebt für Musik. Aber mit sehr hoher Wahrscheinlichkeit können wir sagen, sie wird programmieren. Früher mussten wir die Sprache von Computern lernen, heute lernen Computer unsere Sprache. Und das ist – bei aller berechtigten Skepsis – tatsächlich ziemlich schön.
Über den Autor:
Jürgen Schmidt ist Unternehmer im Bereich der Software-Entwicklung und KI-Forschung. Neben dieser Tätigkeit ist Schmidt häufiger Keynote Speaker auf Fachkonferenzen und lehrt als Gastdozent auf Universitäten.
