Software hat sich immer nach oben abstrahiert

9 Min. Lesezeit

Die Arbeit ist nicht verschwunden. Sie ist umgezogen.

Die Vorstellung, Softwareentwicklung bestehe vor allem aus Tippen, war immer ein Missverständnis. Man schaut dabei auf die falsche Schicht.

Tippen war früher deutlich mühsamer, keine Frage. Es gab physische Schalter, Maschinenbefehle, Lochmedien, Felder fester Breite, Compilerfehler ohne jeden Charme und genug zufällige Komplexität, um aus einem kleinen Fehler einen ganzen Nachmittag zu machen. Diese Reibung abzubauen, war wichtig.

Ist es noch immer.

Aber jede erfolgreiche Abstraktion nahm eine Klasse von Arbeit weg, damit Menschen weiter oben folgenreichere Entscheidungen treffen konnten. Die Details verschwanden nicht. Sie wurden zu verlässlicher Maschinerie von jemand anderem, bis sie wieder durchsickerten und Aufmerksamkeit verlangten.

KI-Coding-Agenten sind das jüngste Beispiel. Sie sind weder ein übernatürlicher Bruch noch eine schickere Autovervollständigung. Sie sind eine neue Schnittstelle zum Stack. Dieser Unterschied zählt, besonders für Unternehmen, die eine gelungene Demo jetzt als Beweis behandeln, dass Verantwortung für Software optional geworden sei.

Zuse machte die Maschine zur Schnittstelle

Konrad Zuse vollendete die Z1 1938. Sie war eine frei programmierbare mechanische Maschine mit binären Schaltelementen, Rechenwerk, Speicher, Ein- und Ausgabe sowie Programmleser. Der Nachbau im Deutschen Technikmuseum Berlin ist eine nützliche Korrektur der glatten Computergeschichte, die Menschen sich gern erzählen: Bevor Software unsichtbar wurde, war sie schmerzhaft physisch. Die Geschichte der Z1 im Museum ist deshalb sehenswert.

Auf dieser Ebene konnte niemand so tun, als sei Logik von der Maschine getrennt. Datenrepräsentation, Kontrollfluss, Speicher, Ein- und Ausgabe waren nah genug, um sie anzufassen. Ein Programm war kein Produktbriefing. Es war eine explizite Folge von Anweisungen für einen konkreten physischen Apparat.

Das war kein goldenes Zeitalter. Kein vernünftiger Mensch möchte dorthin zurück.

Es war der Ausgangspunkt. Jede folgende Schicht schob ein Stück Maschinendetail unter ein nützlicheres Vokabular. Das bedeutet Abstraktion, wenn sie ihren Job macht: Realität nicht zu leugnen, sondern einen stabilen Teil davon so verlässlich zu machen, dass man nicht jede Minute daran denken muss.

COBOL brachte Geschäftssprache in den Code

Das Komitee, das 1959 COBOL schaffen sollte, wollte eine gemeinsame Geschäftssprache mit lesbaren Programmen und möglichst großer Maschinenunabhängigkeit. Das war ein ehrgeiziges und praktisches Ziel, kein naives. Der Bericht des Computer History Museum beschreibt die Absicht klar: Geschäftsdatenverarbeitung brauchte eine Sprache, die eine Maschine und einen Anbieter überdauern konnte.

COBOL verlagerte das Gespräch nach oben. Statt vor allem in Maschinenoperationen zu sprechen, konnte ein Programm von Datensätzen, Berichten, Konten und Lohnabrechnung sprechen. Grace Hopper prägte diese Richtung mit. Das Ergebnis wurde zu einer der erfolgreichsten Sprachen der Wirtschaftsinformatik, weil Unternehmen nicht von Algorithmen im Abstrakten leben. Sie leben von Namen, Kategorien, Regeln, Ausnahmen und Büchern, die irgendwann jemand kodieren muss.

Der wichtige Punkt ist, was nicht geschah.

COBOL machte Geschäftssysteme nicht einfach. Es machte es möglich, weit mehr Geschäftslogik auszudrücken, in einem Maßstab, der Teams, Hardwaregenerationen und Managementmoden überdauerte. Der Quelltext konnte näher am Geschäft aussehen, während das tatsächliche System zu einer dichten Abhängigkeit wurde, die Gehälter zahlte, Geld bewegte und Behörden am Laufen hielt.

Die Abstraktion funktionierte. Die Verantwortung zog um. Ein Entwickler musste nicht mehr jeden Maschinenbefehl verwalten, aber weiterhin die Geschäftsregel verstehen, die für zehntausend Kunden falsch wäre, wenn ein Feld falsch ausgelegt wird.

Dieses Muster kommt immer wieder.

Objektorientierung gab Struktur einen Namen

Als Simula und später Smalltalk die objektorientierte Programmierung prägten, hatte sich das Problem erneut verschoben. Programme waren nicht mehr nur schwierig, weil Maschinen unbeholfen waren. Sie waren schwierig, weil die Software selbst groß genug geworden war, um das Arbeitsgedächtnis eines Einzelnen zu besiegen.

Simula machte Klassen und Objekte zu zentralen Begriffen. Smalltalk trieb die Idee mit Objekten, Nachrichten und einer interaktiven Umgebung weiter. Das löste kein Entwurfsproblem. Es gab dem Entwurf eine bessere Sprache.

Ein gut gewähltes Objekt kann Zustand und Verhalten zusammenhalten. Es kann sichtbar machen, wofür ein Teil des Systems verantwortlich ist, und zugleich Implementierungsdetails verbergen, von denen andere Teile nicht beiläufig abhängen sollten. Das ist eine nützliche Abstraktion. Sie lässt einen Entwickler über einen Kunden, eine Rechnung, eine Buchung oder eine Preisregel nachdenken, ohne ständig jede Datenbankspalte und jeden Kontrollzweig vor Augen zu haben.

Und weil Menschen Menschen sind, brachte Objektorientierung auch Ozeane dekorativer Klassendiagramme hervor, Vererbungshierarchien wie Stammbäume aus einem schlechten Königsdrama und Abstraktionen, deren einzige Verantwortung darin bestand, eine einfache Änderung zu drei Meetings zu machen.

Der Missbrauch widerlegt die Idee nicht. Er beweist den Punkt. Höhere Abstraktion gibt Menschen mehr Hebel, auch den Hebel, aufwendigen Unsinn schneller zu bauen. Die knappe Fähigkeit war nie, das Wort „Kapselung“ zu kennen. Sie bestand darin zu entscheiden, welche Grenze das System klärt und welche nur Verwirrung hinter einem respektablen Substantiv versteckt.

Ward Cunninghams Arbeit über gemeinsames Verständnis steht in dieser Tradition. Es ging nicht darum, mehr Vokabular zu schaffen. Das Vokabular sollte der Arbeit Rechenschaft ablegen.

Frameworks schafften Wiederholung ab, nicht Urteilskraft

Nachdem Sprachen, Betriebssysteme, Bibliotheken und Objektmodelle mehr der alten mechanischen Arbeit aufgenommen hatten, gingen Frameworks die Wiederholung an.

Nicht jede Anfrage von Hand verdrahten. Nicht jedes Datenbank-Mapping von Grund auf bauen. Nicht zum zwanzigsten Mal dasselbe Grundgerüst für die Authentifizierung schreiben. Nicht jedes Team erneut entdecken lassen, wie ein gewöhnlicher Service paketiert, bereitgestellt, protokolliert und überwacht wird.

Gut so. Dafür sind reife Werkzeuge da.

Die Framework-Ära erzeugte gelegentlich dieselbe Täuschung, die jetzt KI umgibt: Wenn das Werkzeug mehr erledigt, können die Menschen vielleicht weniger verstehen. Diese Logik brachte Unternehmen hervor, die einen Stack kauften, bevor sie ihr Produkt definiert hatten, Architekturdiagramme als Ersatz für operative Verantwortung behandelten und Teams, die Services schnell erzeugen konnten, aber nicht erklären konnten, wo eine Geschäftsregel lebte.

Die nützliche Antwort war nie, Frameworks abzulehnen und alles von Hand zu schreiben wie ein Verein für historische Nachstellungen. Die Antwort war zu erkennen, wohin die Arbeit gezogen war.

Wenn Spring wiederkehrende Infrastrukturarbeit in Unternehmensanwendungen übernimmt, lautet die Frage des Entwicklers, ob die Servicegrenze Sinn ergibt. Wenn eine Cloud-Plattform Infrastrukturbausteine übernimmt, lautet die Frage, was beobachtbar, wiederherstellbar, sicher und verantwortlich betrieben werden muss. Wenn ein Web-Framework Rendering und Routing übernimmt, lautet die Frage, ob der Ablauf einem echten Menschen hilft, etwas zu erledigen.

Der Stack steigt. Die Entscheidungen werden weniger, größer und teurer, wenn sie falsch sind.

KI-Agenten heben die Schnittstelle über den Code

Codevervollständigung war bereits eine kleine Abstraktion: Ein Werkzeug erriet die nächsten Token, damit der Entwickler weniger tippte. Ein Agent ist qualitativ anders, weil er über eine Aufgabe hinweg arbeiten kann. Moderne Coding-Agenten können Dateien lesen, eine Codebasis durchsuchen, Dokumentation heranziehen, Code ändern, Prüfungen ausführen und sich anpassen, wenn eine Prüfung fehlschlägt. Die Agent-Dokumentation von VS Code beschreibt diesen Ablauf nüchtern.

Die neue Arbeitseinheit ist nicht mehr nur eine Zeile oder eine Funktion. Sie besteht aus einer Absicht, Einschränkungen und Nachweisen.

„Unterstütze diese Kundenregel, bewahre den bestehenden Vertrag, aktualisiere die Tests und zeige mir, was sich geändert hat“ ist keine Anforderung an Syntax. Es ist die Aufforderung, auf einer höheren Ebene des Stacks zu arbeiten. Der Agent erledigt einen Teil der Übersetzungsarbeit zwischen dieser Anforderung und dem Repository.

Das ist echter Hebel.

Genau deshalb ist der Satz „KI schreibt den Code, also brauchen wir keine Entwickler mehr“ so kindisch. Der harte Teil ist weiter vom Tippen weggezogen, nicht im Modell verschwunden. Jemand muss weiterhin entscheiden, ob die Kundenregel schlüssig ist, ob der bestehende Vertrag es wert ist, bewahrt zu werden, ob ein Test Verhalten statt Zeremonie beweist und ob die Änderung überhaupt ins System gehört.

Der Agent kann Antworten vorschlagen. Er kann die Organisation nicht für sie verantwortlich machen.

Tests schlagen Anweisungen für KI-Coding-Agenten – genau aus diesem Grund. Ein langer Prompt kann beschreiben, was das Team zu erreichen hofft. Ein ausführbarer Test gibt dem Agenten eine Grenze, an der er sich nicht vorbeireden kann.

Das neue Versagen ist schnellere Gewissheit

Der alte Fehlermodus war langsame Entwicklung. Ein Unternehmen konnte Monate damit verbringen, vage Absichten durch Meetings, Dokumente, Tickets, Übergaben und Code zu übersetzen, bevor jemand merkte, dass die Prämisse nicht stimmte.

KI macht ein anderes Scheitern leichter.

Jetzt kann jemand aus dem Betrieb einen Ablauf in ein Chatfenster schreiben, einen funktionierenden Bildschirm bekommen, eine echte Datenquelle anschließen und einen reibungslosen Ablauf demonstrieren, bevor der Lenkungskreis seine Untergruppen zu Ende benannt hat. Das ist beeindruckend. Es ist auch der Moment, in dem Organisationen sichtbares Ergebnis am leichtesten mit verstandenem Verhalten verwechseln.

Ein Ablauf hört nicht auf, Software zu sein, weil er als Anfrage aus dem Betrieb begann. Sobald er echte Daten zusammenführt, einen Kundendatensatz verändert oder eine Freigabe auslöst, trägt jemand Verantwortung für sein Verhalten in Produktion.

Was passiert, wenn die Daten unvollständig sind?

Wer darf die Regel ändern?

Wie lässt sich zurückrollen?

Welche Aktion braucht eine Freigabe?

Was muss protokolliert werden?

Woher weiß das Team, dass die morgige Version noch das tut, was die Demo heute tat?

Diese Fragen sind keine Reste eines älteren Handwerks. Sie sind die Arbeit, die bleibt, nachdem das Handwerk mächtiger geworden ist.

Die Gefahr ist nicht, dass KI-Agenten nur Schrott produzieren. Oft liefern sie plausible, nützliche Arbeit. Die Gefahr ist, dass sie sie so schnell liefern, dass Menschen ohne Modell für Softwarefolgen vom Zuschauer zum Systemverantwortlichen werden, bevor sie den Unterschied kennen.

Der Stack braucht Menschen, die ihn überblicken

Jede Schicht in dieser Geschichte versprach Entlastung.

Zuses Maschine machte Berechnungen zu wiederholbaren mechanischen Schritten. COBOL machte Geschäftsverarbeitung zu einer Sprache, die wandern konnte. Objektorientierung gab komplexen Systemen Namen und Grenzen. Frameworks machten wiederkehrende technische Aufgaben zu Konventionen. KI-Agenten machen mehr der Übersetzung zwischen Absicht und Code zu einem ausführbaren Gespräch.

Nimm die Entlastung an. Nutze die Werkzeuge. Niemand bekommt eine Medaille dafür, die unteren Schichten von Hand zu polieren.

Aber hören wir auf, jedes Mal denselben Managementfehler zu machen: eine Abstraktion als Beweis zu behandeln, dass Verständnis nicht mehr nötig sei.

Abstraktionen schaffen Komplexität nicht ab. Sie konzentrieren sie dort, wo Entscheidungen sichtbar werden. Die Details der unteren Ebene sind noch da und warten auf den Tag, an dem eine Annahme bricht. Die Organisation braucht weiterhin Menschen, die den Weg einer Geschäftsanforderung durch Code, Daten, Integrationen, Bereitstellung und betriebliche Folgen verfolgen können, ohne so zu tun, als sei eine dieser Schichten das Problem von jemand anderem.

Das ist es, was ernsthafte Entwickler im Zeitalter der Agenten mehr werden, nicht weniger.

Der Bediener der Z1 musste über die Maschine nachdenken. Der COBOL-Entwickler musste über Geschäftsregeln nachdenken. Der objektorientierte Entwickler musste über Grenzen nachdenken. Der KI-gestützte Entwickler muss über das ganze System nachdenken – und hat jetzt weniger Ausreden, sich hinter Tippen zu verstecken.