Wird KI mich ersetzen? Der Wert unserer Expertise im KI-Zeitalter

Würde man im aktuellen KI-Hype versuchen, alle Beiträge zum Thema “Wird KI Softwareentwickler ersetzen?” zu verfolgen, die zu diesem Thema das Internet überfluten, hätte man darin vermutlich eine neue Vollzeitbeschäftigung gefunden. Social Media Posts, einzelne Vlogs oder gleich ganze Channels, sogar Keynotes… kein Tag vergeht ohne neuen Content.

Die Zukunft vorhersagen kann auch dieser Artikel nicht. Er kann jedoch Orientierung in der unübersichtlichen Debatte bieten, indem er sie strukturiert und ihre impliziten Fehlannahmen sichtbar macht. Denn möglicherweise liegt der größte Denkfehler nicht in der Überschätzung der KI – sondern in der Unterschätzung dessen, was Software-Engineering tatsächlich ausmacht.

I) Die Diskussion

Sollte mich KI ersetzen?

Ein eher philosophischer Teil der Debatte wird nicht erst seit ChatGPT geführt, sondern ist deutlich älter. Ein nennenswerter Beitrag ist das Werk des MIT Professors Joseph Weizenbaum von 1976: „Die Macht der Computer und die Ohnmacht der Vernunft“. Weizenbaum war Schöpfer von ELIZA, das ChatGPT der 60er, könnte man es überspitzt nennen. Die Reaktionen auf ELIZA verstörten ihn jedoch nachhaltig.

Das Programm war ein Vertreter klassischer „symbolischer KI“ in einer Zeit, bevor neuronale Netze praktisch relevant wurden. Verglichen mit heutigen LLMs möchte man es kaum als „Intelligent“ bezeichnen. Dennoch schrieben viele Nutzer schon damals ELIZA menschliche Eigenschaften wie Empathie zu… und spielten sogar mit dem Gedanken, den Beruf des Psychotherapeuten damit ersetzen zu können.

In seinem Buch kritisiert Weizenbaum diese unreflektierten Versuche, Maschinen zu vermenschlichen und Menschen durch Maschinen zu ersetzen. Tatsächlich lesen sich viele Passagen aus dem inzwischen 50 Jahre alten Text auch heute noch erstaunlich aktuell: Ob Sprachfähigkeit mit Intelligenz gleichzusetzen ist, ob Maschinen uns wirklich „verstehen“ können und wo menschliche Lebenserfahrung unersetzlich bleibt – vieles taucht in ähnlicher Form auch in heutigen Diskussionen wieder auf.

Das liegt daran, dass es in diesem Zweig der Debatte nicht darum geht, ob KI uns ersetzen kann, sondern inwieweit sie es sollte. Diese Fragestellung lässt sich nie pauschal beantworten und wird damit zwangsläufig immer wieder aktuell. Genau wie die Argumente Weizenbaums. Denn seine zentrale Kritik war nie: „Die aktuelle KI ist zu dumm, um uns zu ersetzen“, sondern vielmehr: „Unabhängig davon, wie intelligent eine Maschine wirkt, ist es problematisch, ihr Verantwortung zu übertragen.“ Diese Argumentation skaliert mit dem technologischen Fortschritt mit.

A Computer can never be held accountable
Therefore a computer must never make a management decision

Folie einer IBM Präsentation von 1979 aus einem viralen Post des MIT CSAIL.

Wird KI die Menschheit ersetzen?

In einem weiteren Teil der Debatte geht es um nichts weniger als das Überleben unserer gesamten Spezies. Begriffe wie AGI (Artificial General Intelligence) und Singularität tauchen auf und zeichnen ein düsteres Zukunftsbild, in dem sich KI-Systeme unserer Kontrolle entziehen und gegen die Menschheit verbünden. An dieser Stelle darf man also gedanklich einen dystopischen Soundtrack einspielen und sich paranoid nach den roten LED-Augen des Terminators umschauen.

Dass Diskussionen in sozialen Medien schnell in diese Richtung driften mussten, war eigentlich absehbar: Eine jahrzehntelang von Hollywood geprägte Popkultur trifft auf Systeme, die Geschichten wie den Claude Candy Shop und Moltbook hervorbringen. Die Frage, wann sich ein unterwürfiges „You’re absolutely right“ in ein „I’m sorry Dave, I’m afraid I can’t do that“ verwandeln wird, musste irgendwann aufkommen. Überraschender ist hingegen, dass bei diesem Thema durchaus ernstzunehmende Stimmen mitdiskutieren. Mit dem Nobelpreisträger Geoffrey Hinton und dem Turing-Award-Gewinner Richard Sutton erhält die Debatte ein ganz anderes Gewicht.

Sutton sieht in LLMs keinen realistischen Weg zu echter allgemeiner Intelligenz, da ihnen ein eigenes Weltmodell, kontinuierliches Lernen und eigenständige Zielorientierung fehlen. Sie imitieren lediglich menschliche Sprache, indem sie das jeweils nächste Token vorhersagen. Und das auch noch trainiert auf menschlichem Output statt eigener Erfahrung – einer Art Second-Hand Knowledge. Mit anderen Worten: In 50 Jahren werden wir vermutlich ähnlich amüsiert auf ChatGPT zurückblicken, wie wir heute auf ELIZA schauen, und uns fragen: „Das hat mal jemand für intelligent gehalten?“

Hinton hingegen warnt, dass aktuelle Systeme bereits heute in vielen Bereichen mächtiger sind als der Mensch. Er plädiert dafür, deutlich mehr in Sicherheitsforschung und Regulierung zu investieren… bevor es zu spät ist! Außerdem sieht er kurzfristig ein großes Risiko in steigender Arbeitslosigkeit: KI sei längst dabei, alle intellektuellen Routinetätigkeiten („mundane intellectual tasks“) zu übernehmen. Eine gute Überleitung zu einer deutlich bodenständigeren Frage, die viele beschäftigt: Was bedeutet all das für meinen Beruf?

Wird KI Softwareentwickler ersetzen?

Unser Einfluss auf das Schicksal der Menschheit fällt meistens eher gering aus. Bei der Frage nach unseren Jobs wird der Effekt von KI dagegen für jeden von uns unmittelbar erlebbar. Entsprechend breit und polarisiert wird diese Diskussion geführt.

Lager 1: „Vibe Coding“. Man beschreibt nur noch Feature-Wünsche und agentische Coding Tools übernehmen den Rest. Die Überzeugung ist, dass die Programmierung durch LLMs eine gesamte Abstraktionsebene nach oben verschoben wurde: „Vergiss, dass der Code überhaupt existiert“ oder „Code ist der neue Assembler“ sind die neuen Mantras.

Fehler im Code löst man mit derselben Methodik, die sie hervorgebracht hat: die KI wird sie fixen. Kein Folgeproblem, das man nicht lösen könnte, indem man es einfach mit noch mehr Tokens bewirft! Sollte das einmal nicht klappen, sucht man die Schuld beim Menschen: Der Prompt war zu schlecht, das Modell falsch gewählt – kurz: „Skill Issues“.

Konsequent zu Ende gedacht bedeutet das: jeder kann Software entwickeln, wenn er lernt, die KI richtig zu bedienen. Im Umkehrschluss braucht es keine Expertise in Softwareentwicklung mehr.

Lager 2: kategorische Ablehnung. LLMs sind statistische Inferenzmaschinen für das nächste Token, „Autocomplete auf Steroiden“, ohne echtes Verständnis – im Grunde exakt die Kritik von Sutton. Für Vertreter dieser Position folgt daraus: Solche Systeme sind für ernsthafte Softwareentwicklung wertlos. Verweise auf Halluzinationen, inkonsistente Architekturvorschläge oder gescheiterte „Vibe Coding“-Experimente gelten als Beleg. Und der aktuelle Hype ist sowieso nur eine große Aktienblase.

Alle diese Beobachtungen sind zwar nicht falsch, werden jedoch zur rhetorischen Verkleinerung: Wenn das System „nur Statistik“ ist, „nur ein besserer Taschenrechner“, kann man das Thema mit einer Handbewegung wegwischen und alles darf so bleiben, wie es schon immer war. Ob das eine gesunde (und karrierefördernde) Grundhaltung sein kann?

Wie finden wir nun also eine differenziertere Position zwischen übertriebener Euphorie und Realitätsverweigerung – eine Balance aus gesunder Skepsis und aufgeschlossener Neugier? Ich schlage folgenden Ansatz vor: Wenn wir die Fehlannahmen beider Extrempositionen verstehen, können wir daraus unsere eigene Position in der Mitte herleiten.

II) Zentrale Denkfehler

Eine kurze Geschichte der Versuche, Programmierer zu ersetzen

Um diese Gedanken einzuleiten, lohnt es sich, noch einmal in die Vergangenheit zu schauen. Der Versuch uns durch neue Werkzeuge zu ersetzen ist nicht neu.

  • Schon COBOL und SEQUEL (Structured English Query Language, später SQL) traten wohl mit dem Anspruch an, für Fachanwender verständliche Sprachen zu sein.
  • BPMN verfolgte den Traum, Sachbearbeiter könnten ausführbare Diagramme für Prozess-Engines erstellen.
  • No-Code Plattformen machten sich das „Demokratisieren von Softwareentwicklung“ zum Narrativ… mussten aber schnell zu „Low-Code“ erweitert werden!
  • Modellgetriebene Entwicklung und Code Generatoren haben nicht den Anspruch, Entwickler durch Fachanwender zu ersetzen. Wohl aber durch IT-Experten der nächsthöheren Abstraktionsebene: Diagramme und DSLs statt Code benötigen Architekten statt Entwickler.

Natürlich sind diese Projekte nicht wertlos. Sie schaffen für viele Entwickler einen großen Mehrwert. Aber die Vision einer flächendeckenden Demokratisierung oder Verschiebung der Abstraktionsebene, die eben diese Entwickler überflüssig macht, erreichten die Ansätze nicht.

Entwickeln ist mehr als der Code

Der Irrweg dieser Ideen beginnt mit einer falschen Problemstellung: „Wie werden wir den Code los?“. Die zugrunde liegende Fehlannahme liegt nicht auf der technischen Seite. Sie liegt in einem falschen Verständnis von Softwareentwicklung – vielleicht sogar in einem falschen Menschenbild.

Darin sind Programmierer diese teuren Spezialisten, die Sourcecode erzeugen. Dabei ist Softwareentwicklung so einfach, eigentlich könnte das jeder… wenn nur die Syntax nicht so seltsam wäre! Also entwickelt sich ein Plan:

„Wenn wir den Sourcecode loswerden, sind wir auch die Programmierer los!“

Programmierer werden reduziert auf „Personen, die Code generieren“.

Die Syntax ist aber deshalb seltsam, weil Computer seltsam sind. Der Code ist nur die sichtbare Spitze des Eisbergs. Unter der Wasseroberfläche liegt die Denkdisziplin, die sich damit beschäftigt, diese Seltsamkeit zu verstehen und nutzbar zu machen. Und dieser versteckte Teil des Eisbergs taucht plötzlich auf, wenn man dessen Spitze abschlägt.

Das Eisberg-Modell: "Code" ist der sichtbare Teil über Wasser, darunter liegen viele Begriffe von "algorithmic thinking" über "pattern recognition & transfer" bis hin zum "agile mindeset". Ganz unten fußt "CREATIVE PROBLEM SOLVING WITH COMPUTERS"

Vibe Coding: Déjà-vu in der No-Code Falle

„Vergiss, dass der Code existiert“… Vibe Coding in seiner Extremform tappt in genau diese Falle. Code ist nicht der neue Assembler. Der Übergang von z. B. Java zu Bytecode ist deterministisch; der Übergang vom Prompt zum Code ist es nicht. Irgendwann wird man immer prüfend in den Code schauen müssen. Spätestens dann, wenn auch die nächsten zehn Millionen Token den Bug nicht lösen konnten (in hinreichend komplexen Projekten übrigens regelmäßig zu beobachten). Die Abstraktion bleibt „leaky“ – so wie immer, wenn wir den Code verstecken wollten.

Doch selbst wenn ein Nicht-Techniker es schafft ohne Code anzurühren einen verteilten Webshop zu generieren: versteht er komplizierte Randfälle oder einen CAP-Trade-off? Kann die KI ihm solche Themen so vermitteln, dass er sie in seinem eigenen Interesse korrekt entscheidet? Wenn nicht… dann muss die KI solche potenziell geschäftskritischen Entscheidungen treffen. Und wenn wir genau diese Verantwortung nicht an eine KI delegieren wollen? Dann bleibt echte IT-Expertise eben notwendig!

Der Unterschied: LLMs greifen auch unter der Wasseroberfläche an

Wenn sich Lager 2 an dieser Stelle schon über einen Sieg freut, muss ich es leider enttäuschen. Denn ganz so einfach wie „Alles schon mal da gewesen, brauchen wir nicht!“ dürfen wir es uns auch nicht machen.

Warum sind agentische Coding Tools nicht dasselbe wie No-Code? Das offensichtlichste zuerst: der Code ist noch da (ihn sich nicht anzuschauen ist eine bewusste Entscheidung des Vibe Coders). Das ermöglicht jederzeit einen opt-out und re-opt-in in KI-getriebene Entwicklung (kontinuierliche, auf Wartbarkeit abzielende Reviews vorausgesetzt). Bei bisherigen Ansätzen bleiben opt-outs aus der Plattform defacto One-Way Tickets.

Viel wichtiger und subtiler ist jedoch: Mit Blick auf unseren Eisberg wird nicht mehr nur dessen Spitze attackiert! LLMs zitieren nicht einfach aus ihren Trainingsdaten. Sie reproduzieren nicht nur – sie generalisieren Muster. Dass das “aus versehen” passiert, aus einer statistischen Laune heraus, ist dabei irrelevant: der Effekt ist real.

Ist in den Trainingsdaten eine Folgerung „A->B“ vertreten, können sie ein ihnen unbekanntes Problem X mit „X->Y“ beantworten – ganz ohne Weltmodell mit dem sie die Logik hinter „A->B“ wirklich verstehen. Strukturelle Ähnlichkeiten zwischen A und X sowie B und Y reichen aus.

Stellt sich diese Übertragung dann als korrekt heraus, erkennen wir hierin eine „Intelligenz“ wieder, die wir uns selbst häufig erst im Laufe unserer Karriere aneignen mussten. Strukturerkennung, Übertragung von Mustern, Abstraktionsfähigkeit… ein großes Stück Eis unter der Wasseroberfläche wird angegriffen! Und ja: das ist ein bisschen unheimlich.

Stellt sich „X->Y“ als grober Unfug heraus, nennen wir es „Halluzination“. Das sind zwei Seiten derselben Medaille: Wer Generalisierungsfähigkeit akzeptiert, muss auch Fehlgeneralisierung akzeptieren.

III) Synthese

Zusammenfassung

Entwickeln ist also mehr als Code, die Effekte von LLMs mehr als Autocomplete. Und jetzt?

Eingeleitet hatten wir das Thema mit Hinton, der warnt: die „mundane intellectual Tasks“ werden automatisiert. Mit Fokus auf das Wort „mundane“ und einem Blick auf den Eisberg heißt das… wir dürfen uns freuen! Endlich mehr Zeit für die interessanten Dinge! Wer das Gegenteil behauptet, reduziert unseren Beruf auf den sichtbaren Teil des Eisbergs.

Oder frei nach Weizenbaum: Wenn du denkst einen Menschen durch eine Maschine ersetzen zu können, sagt das mehr über dein Menschenbild aus als über die Macht der Maschine.

Gleichzeitig gehen LLMs tiefer als alles bisher Dagewesene – wie tief genau, müssen wir noch ausloten. Auf keinen Fall übernehmen sie, neben Haftung oder Intuition, den kontinuierlichen Erkenntnisprozess, den ein Softwareprojekt immer auch darstellt! Krücken wie Memory Files zähle ich hier, ähnlich wie Sutton, nicht als ebenbürtig zu einem kontinuierlich lernenden neuronalen Netz (das es so zur Zeit nur in organischer Ausführung gibt).

Die neue Zukunftsskizze ist „K-Shaped“

Wenn ansonsten alles „Triviale“ automatisiert wurde, bleibt das „Nichttriviale“ als Skelett zurück. Die Essenz, die den Job wirklich ausmacht (was auch immer das genau sein wird). Das heißt auch: Wer bisher von trivialer Arbeit gelebt hat, bekommt ein Problem – wer im Komplexen arbeitet, bekommt einen Hebel.

So wird die Kluft zwischen diesen Personengruppen im Zeitverlauf immer größer und im Output-Graph entsteht ein „K-Shape“: der obere K-Strich steht für immer mehr Output der Teams, die Softwareentwicklung ganzheitlich begreifen, der untere für… den Rest.

Um nicht irgendwann ersetzt zu werden, müssen wir also ganzheitlich denken statt es uns in trivialen Aufgaben bequem zu machen. Mit anderen Worten, ebenfalls von Weizenbaum inspiriert: Wenn du dein Leben darauf reduzierst, eine Maschine mit organischen Bauteilen zu sein, dann machst du dich ersetzbar.

Eine Frage der Einstellung

Darin liegt auch eine optimistische Perspektive: Wir haben unsere Zukunft weiterhin selbst in der Hand. Nicht OpenAI, nicht Anthropic oder Google. Ich habe unsere Industrie als Ort leidenschaftlicher, intrinsisch motivierter Menschen erlebt. Und ich glaube, dass es in der digitalen Revolution immer genug Ideen für anspruchsvolle Projekte gibt. Auf der oberen K-Linie bleibt daher genügend Platz für jeden, der bereit ist, über den reinen Code hinauszuschauen.

Neugierig geworden?
Florian Sommer ist Speaker der JCON!
Dieser Artikel behandelt das Thema seiner JCON Session. Du konntest nicht live dabei sein? Kein Problem – das Video wird nach der JCON verfügbar sein. Anschauen lohnt sich!

Total
0
Shares
Previous Post

Die unbequeme Wahrheit über Code, 30 Jahre Java & Sovereign AI – die Keynotes der #JCON2026

Next Post

So wird JCON EUROPE 2026 zum individuellen Erlebnis

Related Posts