Der Traum, Entwickler zu ersetzen, der sich alle zehn Jahre wiederholt

• In den vergangenen mehr als 50 Jahren wurden Versuche, die Softwareentwicklung zu vereinfachen und die Abhängigkeit von Entwicklern zu verringern, immer wieder unternommen.
• Von COBOL in den 1960er-Jahren über CASE-Tools, Visual Basic, Low-Code und No-Code bis hin zu den jüngsten AI-Coding-Assistenten setzt sich dasselbe Muster fort.
• Jede dieser Technologien steigerte die Produktivität, doch der Denkprozess zum Umgang mit Komplexität bleibt weiterhin Aufgabe des Menschen.
• AI verstärkt die Fähigkeiten von Entwicklern, ersetzt aber nicht das Verständnis von Geschäftsproblemen und das Urteilsvermögen.
• Diese wiederholten Versuche zeigen nicht die Grenzen der Tools, sondern die Komplexität der Probleme auf – letztlich ist die Investition in menschliches Denkvermögen entscheidend.

---

Der Beginn eines wiederkehrenden Musters

• Alle zehn Jahre taucht das Versprechen auf: „Diesmal wird Entwicklung einfacher.“
  • Nach dem Apollo-Programm von 1969 rückte Software als Schlüsseltechnologie in den Mittelpunkt.
  • Zugleich zeigte sich jedoch, dass Entwicklung Fachwissen, Konzentration und Zeitinvestition erfordert.
• Von da an begann der anhaltende Traum, Entwicklung zu vereinfachen und den Personalbedarf zu senken.

COBOL: Der Glaube, dass Fachbereiche selbst programmieren könnten

• COBOL wurde – seinem Namen Common Business-Oriented Language entsprechend – so konzipiert, dass Business-Verantwortliche Code wie englische Sätze schreiben können.
• In der Praxis blieben jedoch die Komplexität von Logik, Datenstrukturen und Systemdesign bestehen, sodass sich am Ende eine eigene Schicht spezialisierter COBOL-Entwickler herausbildete.
• Die Vision, dass „jeder programmieren kann“, erfüllte sich nicht.

Die 1980er: Das Versprechen automatischer Generierung durch CASE-Tools

• CASE (Computer-Aided Software Engineering)-Tools traten mit dem Versprechen an, Code automatisch aus Diagrammen zu erzeugen.
• Unternehmen investierten in großem Umfang und erwarteten eine Verzehnfachung der Produktivität.
• Doch der erzeugte Code scheiterte an Leistungsproblemen, schwieriger Wartbarkeit und Inkonsistenzen zwischen Modell und Implementierung.
• Da weiterhin ein Verständnis für logische Komplexität erforderlich war, blieb das Grundproblem ungelöst.

Die 1990er: Der Ansatz von Visual Basic und Delphi

• Mit dem Drag-and-Drop-Ansatz sank die Einstiegshürde, um UI einfach zu erstellen.
• Einfache Anwendungen waren möglich, doch für komplexe Systeme mit Anforderungen an Integration, Sicherheit, Performance und Wartbarkeit wurden weiterhin erfahrene Entwickler benötigt.
• Im Ergebnis sank die Nachfrage nach Entwicklern nicht – sie nahm sogar zu.

Seit den 2000ern: Web-Frameworks, Low-Code und No-Code

• Ruby on Rails propagierte „Convention over Configuration“, Low-Code- und No-Code-Plattformen warben mit „Entwicklung ohne Code“.
• In bestimmten Bereichen wurden Geschwindigkeit und Beteiligung tatsächlich erhöht, doch der Bedarf an professionellen Entwicklern stieg weiter.
• Die wiederkehrende Frage lautet: „Warum wiederholt sich dieses Muster immer wieder?“

Das Wesen der Komplexität

• Software wirkt auf den ersten Blick einfach, doch in Wirklichkeit explodiert die Komplexität bei Detailsituationen und Ausnahmebehandlung.
  • Beispiele: Konflikte bei Lagerreservierungen, fehlgeschlagene Zahlungen, Ausfälle von E-Mail-Diensten.
• Genau diese Detailentscheidungen sind das Wesen der Entwicklungsarbeit, und kein Tool kann sie eliminieren.

Ein neues Kapitel im AI-Zeitalter

• AI-Coding-Assistenten erzeugen Code in natürlicher Sprache und unterstützen bei Erklärungen, Debugging und Verbesserungsvorschlägen.
• Das ist ein echter Fortschritt, aber Problemdefinition sowie Entscheidungen zu Sicherheit, Integration und Wartung bleiben weiterhin menschliche Aufgaben.
• AI verstärkt die Produktivität von Entwicklern, ersetzt aber nicht Urteilsvermögen und Kontextverständnis.

Nach wie vor zu wenig Entwicklungskapazität

• Die Technologie hat enorme Sprünge gemacht, doch die Nachfrage nach Software übersteigt das Angebot.
• Unternehmen suchen nach Wegen, „schneller und mehr zu bauen“, und setzen Hoffnungen in Tools zur Vereinfachung der Entwicklung.
• Der Engpass liegt jedoch nicht bei Tippgeschwindigkeit oder Syntax, sondern in der Fähigkeit, über Komplexität nachzudenken.

Die Fragen, die Führungskräfte stellen sollten

• Nicht: „Wird dieses Tool Entwickler ersetzen?“
  • Sondern: „Hilft es bei der Lösung komplexer Probleme?“
  • „Reduziert es Routinearbeit, damit man sich auf kreative Probleme konzentrieren kann?“
  • „Erfordert es den Erwerb neuer Fähigkeiten?“
• Diese Fragen machen die Grenzen der Tools und die Unvermeidbarkeit menschlichen Denkens sichtbar.

50 Jahre Lehre: Das Problem ist nicht mechanisch, sondern intellektuell

• COBOL vereinfachte die Syntax, CASE beseitigte das Tippen, und AI erzeugt ganze Funktionen – doch die grundlegende Schwierigkeit bleibt bestehen.
• Softwareentwicklung ist ein „Akt der Konkretisierung von Gedanken“, und das lässt sich nicht durch Tools ersetzen.
• Wie bei Architekturentwürfen oder medizinischen Diagnosen ist der Denkprozess selbst der zentrale Wert.

Die Richtung nach vorn

• Neue Tools werden weiter auftauchen, doch die Investition in menschliche Denkleistung ist am wichtigsten.
• AI, Low-Code und neue Frameworks sollten erprobt werden, aber die Fähigkeit, Komplexität zu verstehen, muss zur Kernkompetenz der Organisation werden.
• Wie beim Apollo-Programm ist nicht das Tool, sondern die Präzision des Denkens der entscheidende Erfolgsfaktor.

Warum der Traum weiterlebt

• Der „Traum, Entwickler zu ersetzen“, ist kein Scheitern, sondern ein Optimismus, der Tool-Innovationen antreibt.
• Jeder Versuch scheiterte an der vollständigen Ersetzung, brachte aber eine neue Generation nützlicher Tools hervor.
  • COBOL verbreitete die Entwicklung von Business-Systemen.
  • CASE trieb die visuelle Modellierung voran.
  • Visual Basic erweiterte den Zugang zur Entwicklung.
  • AI beschleunigt den Wandel der Entwicklungsweise.
• Letztlich liegt die Begrenzung nicht bei den Tools, sondern bei der Komplexität der Probleme, die wir lösen wollen.
• Es gibt keinen Grund, neue Tools abzulehnen; vielmehr sollten realistische Erwartungen und die Bedeutung menschlichen Urteils anerkannt werden.

[GN⁺]

Hacker-News-Kommentare

• Wenn man sich diese Welle der AI-Innovation ansieht, wird klar, dass ein großer Teil des Codings keine inhärente, sondern zufällige Komplexität ist
  Was für Menschen konzeptionelle Arbeit ist, wird für AI zu prozeduraler Arbeit
  Früher musste man zum Beispiel mehrere Konzepte lernen, um in Java public static void main(String[] args) zu schreiben, aber einer AI muss man nur den Prompt „Schreibe die Entry-Methode der Klasse“ geben, und sie erzeugt diesen Code nahezu sicher
  Prozedurale Arbeit, die für Menschen schwierig ist, ist für AI leicht; zugleich ist unsere Gesellschaft um genau diese Art prozeduraler Arbeit herum strukturiert, sodass sich bei der Verbreitung solcher Innovationen manche verbessern und manche leiden werden

  • Ich denke, dass die Erfahrung und Fachkenntnis, die nötig sind, um die richtigen Fragen zu stellen, unterschätzt werden

• Die Behauptung „No-Code ersetzt Entwickler“ kommt jedes Mal wieder, aber in der Praxis hat sie eher mehr Entwicklerjobs geschaffen
  COBOL, VB, Squarespace und jetzt AI — wenn Tools die Einstiegshürde senken, wollen mehr Menschen etwas bauen, und sobald sie an Grenzen stoßen, braucht man wieder echte Entwickler
  Einfache Routinearbeit verschwindet, aber zu definieren, was gebaut werden soll, und zu debuggen, bleibt weiterhin nötig

  • Ich hoffe ebenfalls, dass diese Ausweitung anhält, aber letztlich hängt es davon ab, ob neue Nachfrage entsteht
    Wenn AI komplexe Projekte selbst coden kann, könnten weniger Entwickler gebraucht werden, weil Menschen sich dann nicht mehr um Details kümmern müssten
    Früher gab es große Trends wie Internet, Cloud, Mobile und Machine Learning, aber ob auch künftig solche „großen Probleme“ weiter entstehen, ist ungewiss
  • Das ist ein klassischer Fall des Jevons-Paradoxons — wenn etwas billiger wird, wächst der Markt oft gerade deshalb
  • Natürlich könnte es dieses Mal anders sein. Wenn AI wirklich hält, was sie verspricht, könnte die Zahl der Entwickler auch sinken
  • Landmaschinen haben Bauern effizienter gemacht, aber heute gibt es im Gegenteil sogar mehr Bauern
  • Die Aussage „Die Zahl der Entwickler wird nicht sinken“ ist zu kategorisch. Wenn AI auch Debugging und Anforderungsinterpretation übernehmen kann, könnte sich die Lage ändern

• Dasselbe Muster ist in den letzten 20 Jahren auch im Systemadministrationsbereich zu sehen
  Das Versprechen, dass höhere Abstraktion die Arbeit von Spezialisten demokratisiert, kehrt ständig wieder, aber in der Praxis führt es zu teurer Neuerfindung
  Tools wie Kubernetes sollen Komplexität versteckt haben, aber am Ende lernen Entwickler dieselben Probleme auf teurere Weise noch einmal, ohne die grundlegenden Konzepte zu verstehen
  Excel ist ein typisches Beispiel — es hat schreckliche Fehler in Massen hervorgebracht, war aber dank seiner Zugänglichkeit erfolgreich
  Am Ende wollen wir zugleich „die Zugänglichkeit von Excel und die Zuverlässigkeit von Engineering“, aber beides zusammen ist nicht zu haben

  • Würden sich dann beim Einsatz nichtdeterministischer Software Versicherungsprämien oder Entschädigungsrichtlinien ändern?
  • Wenn Kubernetes keine Arbeit reduziert hätte, würde das bedeuten, dass 95 % der Großunternehmen dumm sind
    Tatsächlich ist mit wachsender Größenordnung einfach die Komplexität der Arbeit nach oben gewandert
  • Jede Abstraktion ist eine leckende Abstraktion. Selbst bei C fällt das Ergebnis je nach Compiler unterschiedlich aus

• Der Grund, warum sich dieses Muster wiederholt, sind Marktanreize
  Unternehmen müssen AI als universelle Wunderlösung verkaufen, damit der Aktienkurs steigt; dadurch entsteht eine Struktur, in der eher Glaube als tatsächliche Leistung verkauft wird
  Wenn sich die Realität am Ende zeigt, wird der Markt in Verwirrung geraten

  • Der Markt ist keine Gravitation. Märkte existieren nur innerhalb einer politischen Ordnung
  • Wenn das Produkt wirklich so funktioniert hätte wie versprochen, hätte man sich nicht auf „Kritik von Skeptikern“ konzentriert, sondern auf die Entwicklung

• Tatsächlich hätte man die Zahl der Entwickler auch senken können
  Wenn Unternehmen selektiver eingestellt und mehr in Ausbildung investiert hätten
  In der Realität war es aber umgekehrt, und Web-Frameworks wurden nicht primär zur Produktivitätssteigerung geschaffen, sondern um Schulungskosten zu senken und den Personalpool zu vergrößern

  • Stimme ich nicht zu. Gute Frameworks erhöhen Wartbarkeit und Produktivität

• Mittleres Management und Führungskräfte sehen technische Abteilungen nur als Cost Center
  Deshalb erwähnen sie AI in jeder Pressemitteilung und sprechen von sinkenden Personalkosten
  Tatsächlich werden Kosten nicht wegen AI gesenkt, sondern durch den Austausch gegen Offshore-Arbeitskräfte
  Die verbleibenden Onshore-Teams müssen mehr Arbeit übernehmen und steigern so ihre Produktivität

  • Aber auch in Offshore-Regionen kommt es zu denselben Entlassungen
    Nicht Lohnkostensenkung, sondern ein allgemeiner Rückgang der Investitionen ist die Ursache
    Letztlich absorbiert AI Kapital über Investitionen in Rechenzentren und reduziert dadurch Arbeitsplätze
  • Für die Behauptung „Vertrieb kann ohne Produkt nicht existieren“ gibt es historisch viele Gegenbeispiele

• Das Ziel von AI ist nicht, Entwickler zu ersetzen, sondern das Abstraktionsniveau anzuheben, damit komplexere Probleme bearbeitet werden können
  Beginnend bei der Verkabelungsprogrammierung früher Computer über Assembler, C, Python und Frameworks haben Entwickler sich immer weiter zu Problemen auf höherer Ebene vorgearbeitet
  Der Unterschied ist allerdings, dass alle vorherigen Stufen deterministische und überprüfbare Transformationen waren, während generative AI nichtdeterministisch ist
  Dazu passt als Lektüre The Story of Mel

  • Unternehmen einschließlich des CEO von Anthropic interessieren sich jedoch mehr für Kostensenkung und Ersetzung als für ein solches philosophisches Ziel
  • Trotzdem werden die Leute weiter über „Entwicklerersatz“ sprechen
  • Jede Abstraktionsstufe muss Einblick in ihr Inneres erlauben
    Bei LLMs kann man im Gegensatz zu Compilern keine Tokens, ASTs oder IRs sehen, deshalb sind sie undurchsichtig
  • Das eigentliche Ziel der AI-Unternehmen ist die Automatisierung aller intellektuellen Arbeit
  • Mit steigender Abstraktion sinken Genauigkeit und Kontrolle
    Nichtdeterministische, auf natürlicher Sprache basierende Systeme unterscheiden sich von den Abstraktionen früherer Generationen
    Deshalb ist die Analogie „von Assembler zu C“ nicht passend

• Wie Dijkstra sagte, wird Wissenschaft gehasst, weil sie schwierig ist, und ebenso werden Wissenschaftler gehasst, die diese Macht besitzen
  Link zum Original von EWD1041

• Umgekehrt haben Entwickler immer davon geträumt, Nicht-Entwickler-Berufe zu automatisieren
  AI ist die neueste Version dieses Traums

  • Kommt irgendwann eine Star-Trek-Welt, in der alle Berufe gute Berufe sind?

• Anfang der 2000er war Rational Rose UML an Universitäten ein Pflichtfach
  Damals sagte der CEO eines Startups: „Jetzt muss man nur noch Diagramme zeichnen, und der Code wird automatisch generiert, also braucht man keine Entwickler mehr.“
  Doch am Ende hat sich diese Prophezeiung nicht erfüllt

[kayws426]

Maschinen erzeugen Code für Maschinen.
Die Sandburg, die der Mensch über der Maschinensprache errichtet hat, ist letztlich zum Einsturz verdammt.
...so etwas kann man natürlich auch sagen, haha