AI: Beschleunigte Inkompetenz

 (slater.dev)
5 Punkte von GN⁺ 2025-05-29 | 1 Kommentare | Auf WhatsApp teilen
  • Eine übermäßige Abhängigkeit von LLMs in der Softwareentwicklung fördert Inkompetenz in hohem Tempo
  • LLMs haben Grenzen und können kritisches Denken und Problemlösungsfähigkeit nicht ersetzen
  • Der Einsatz von LLMs bringt verschiedene Risiken mit sich, darunter fehlerhafte Ausgaben, fehlerhafte Eingaben, sinkende Codequalität, abnehmende Entwicklerkompetenz und den Verlust der Freude am Schaffen
  • LLMs können keine essenziellen Entwicklungskompetenzen wie Programmtheorie und Programmentropie vermitteln
  • Langfristig sind technisches Können und tiefgehende Denkfähigkeit wichtiger denn je

Einleitung

Seit dem Auftreten von AI und LLMs, die Ende 2022 große öffentliche Aufmerksamkeit erhielten, wird viel darüber diskutiert.
Als erfahrener Softwareingenieur spreche ich über zwei zentrale Probleme, die ich bei LLMs beobachtet habe.

Die Sichtweise „LLM ist mein Freund“

Ingenieure, die LLMs als das ultimative Werkzeug betrachten, setzen Geschwindigkeit als höchsten Wert.
Mit LLMs lässt sich schnell viel Code erzeugen, doch das birgt langfristige Risiken.

Risiken beim Einsatz von LLMs

  • Risiko fehlerhafter Ausgaben: LLMs erzeugen offensichtlich falschen Code (nicht kompilierbar) sowie subtil fehlerhaften Code (z. B. Logikfehler).
    • Wenn Personen ohne ausreichende Bewertungskompetenz Quellcode anfordern, ist die Wahrscheinlichkeit hoch, dass sie ungeeignete Antworten erhalten.
  • Risiko fehlerhafter Eingaben: LLMs hinterfragen fehlerhafte Annahmen oder Prompts mit zu wenig Kontext nicht.
    • Sie können korrekte Fragen nicht sicher unterscheiden und verstehen auch das XY-Problem (das Verfehlen der eigentlichen Ursache) nicht.
  • Verlangsamung künftiger Entwicklungsgeschwindigkeit: Die Einführung von LLMs lässt technische Schulden schnell anwachsen und verwandelt die Codebasis intern in ein chaotisches und schwer wartbares System.
  • Risiko der Unreifmachung der Nutzer: Weil Gelegenheiten zur Problemlösung und zur Entwicklung des Denkvermögens verloren gehen, beschleunigt sich der Kompetenzabbau bei Entwicklungstalenten.
    • Senior-Entwickler sammeln keine tieferen Erfahrungen bei der Problemlösung, und Junior-Entwickler können ihre Fähigkeiten gar nicht erst aufbauen.
  • Verlust der Freude am Schaffen: LLM-basiertes Coding raubt den Flow-Zustand und die Freude an der Kreativität, und das Lesen und Verändern von von AI erzeugtem Code ist oft schmerzhaft.

Die Sorge „Werde ich wegen AI meinen Job verlieren?“

Die Wahrscheinlichkeit dafür ist sehr gering.
Es gibt zwei Entwicklungskompetenzen, die LLMs nicht ersetzen können: Programmtheorie und Programmentropie.

Programmtheorie

  • Wie Peter Naur argumentierte, ist „Programmieren eine Tätigkeit des Aufbaus einer Designtheorie“.
    • Der Quellcode ist nicht das eigentliche Ergebnis; wichtiger ist das kollektive Verständnis (die Theorie).
    • Gibt man zwei Teams mit gleicher Kompetenz dasselbe Problem und übergibt nur den Code, kann das Team, das ihn selbst geschrieben hat, Erweiterungen deutlich effektiver umsetzen.
    • In einer unbekannten Codebasis ist die Produktivität zunächst gering, steigt aber allmählich, je besser man die interne Designtheorie versteht.

LLMs und Programmtheorie

  • LLMs verfügen nur über Gedächtnis im Kontextfenster und können daher keine echte Programmtheorie oder tiefgehendes Design verinnerlichen.
    • Das eigentliche Wesen des Codings (Design und Theoriebildung) wird in der Praxis nur vom Menschen erworben.

Programmentropie

  • Fred Brooks bezeichnete Komplexität (Entropie) als die grundlegende Schwierigkeit des Programmierens.
    • Die Wartung von Programmen erhöht die Komplexität, und selbst die beste Ausführung treibt ein System in irreversible Alterung.

LLMs und Programmentropie

  • LLMs betreiben nur Token-Vorhersage auf Textebene und sind auf der Ebene von Ideen, Entwürfen oder Anforderungen zu semantischem Denken nicht fähig.
    • Je länger die Unterhaltung oder je größer die Codemengen sind, desto häufiger wiederholen sie unnötige oder merkwürdige Änderungen und erhöhen damit nur die Komplexität.
    • Aufgaben, die Komplexität verringern oder ihr widerstehen, sind nur für Menschen möglich.

Fazit

Auf Basis der Einsichten zweier Pioniere wird das Wesen von Softwaredesign und Komplexität erneut bestätigt.
Wer erwartet, dass AI die eigene Entwicklerkarriere verbessert, sollte aufpassen: Stattdessen kann sich Inkompetenz beschleunigen.
Als Entwickler mit reichhaltiger Erfahrung und ausgereiften Fähigkeiten sollte man erkennen, dass LLMs menschliche Ingenieure nicht ersetzen können.
Der geschäftliche Reiz der AI-Einführung liegt in Kostensenkung, tatsächlich entstehen jedoch neue Risiken, und bei übermäßiger Nutzung häufen sich langfristig zusätzliche Kosten und organisatorische Risiken an.
Die Bedeutung von technischem Können und tiefem Denken bleibt langfristig unverändert; AI sollte als Werkzeug genutzt werden, während weiterhin in die essenziellen Fähigkeiten investiert wird, die schon 2019 wichtig waren.

Ausblick auf den nächsten Beitrag

In einem späteren Post sollen konkrete Lösungsansätze für jedes der Risiken behandelt werden.

Literaturhinweise

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-29
Hacker-News-Kommentare
  • Es wurde die Erfahrung geteilt, dass Diskussionen über AI-Coding manchmal den Unterschied zwischen Softwareingenieuren und Data Scientists/Machine-Learning-Ingenieuren widerspiegeln.
    Von Softwareingenieuren wird stets erwartet, vorhersehbare Software zu bauen, die Tests besteht, und auch das Tooling ist deutlich weiter entwickelt.
    Für Machine-Learning-Ingenieure hingegen gehört die Arbeit mit probabilistischen Modellen zum normalen Alltag, und auch Tests sind dort oft eher metrikenbasiert als auf konkrete Ausgaben ausgerichtet.
    Deshalb sind sie stärker daran gewöhnt, dass AI nicht immer zuverlässig ist.
    Auch Coding-Assistenten werden mit der Haltung genutzt, dass 80 % korrekte Antworten ausreichen, solange man die übrigen 20 % selbst erkennt.
  • Nach eigener Erfahrung fühlte sich etwa die Hälfte davon ähnlich an.
    Während der Arbeit bei Amazon waren ML-basierte Lösungen sehr nützlich für Probleme, für die es keinen klassischen Ansatz gab.
    In einem Startup hingegen wurde ohne Verständnis für grundlegendes Filtering oder Mapping stur auf lernbasierte Ansätze gesetzt, was bei der Lageschätzung eines stillstehenden Flugzeugs wiederholt absurde Ergebnisse lieferte.
    Diese Kluft zwischen ML- und SW-Ingenieuren ist deutlich, und es wäre wünschenswert, wenn man sie im Recruiting besser sichtbar machen könnte.
  • In der aktuellen Stimmung wirkt es so, als würde das MLE-Mindset anderen Gruppen zwanghaft übergestülpt.
    In Unternehmen, die Produkte verkaufen, bei denen Genauigkeit und Korrektheit zentral sind, behaupten ML-Teams, 80–90 % seien ausreichend, worüber sich Architekten verständlicherweise beschweren.
    Das erinnert daran, dass auch kleine Prozentwerte große Auswirkungen haben können, wie bei den Diskussionen über 1 % Sterblichkeit während der Pandemie.
  • Es wurde der Unterschied zwischen deterministischem und probabilistischem Verhalten angesprochen.
    Der Beitrag richtet den Fokus auf eine Meta-Frage von AI und Software Engineering, nämlich das Management von Programmentropie.
    Das Management von Entropie ist ein sehr großer Teil des Aufbaus von Softwareprodukten, und AI könnte das irgendwann vielleicht leicht erledigen, derzeit verschlimmert sie die Entropie aber oft eher.
  • Jemand befindet sich aktuell in einem Masterstudium für AI, insbesondere ML, und trainiert als SWE neue Muskeln.
    MLE wird dabei aus einer breiteren SWE-Perspektive betrachtet, mit dem Bedarf, robuste Pipelines, Modellintegration, Deployment und das Gesamtbild zu verstehen.
    Die meisten rein auf MLE spezialisierten Absolventen haben jedoch wenig SWE-Perspektive und verstehen oft nur ML ohne rechnerisches Gespür.
    Um wirklich Full-Stack zu sein, müsse man Low-Level-Systeme, Architektur, Deployment und auch MLE verstehen.
    Der Markt sucht jedoch meist entweder SWE oder MLE-PhDs, weshalb scherzhaft gefordert wurde, man möge für dieses Gesamtwissen auch entsprechend bezahlen.
  • Auch Softwareingenieure wenden in der Praxis häufig probabilistisches Denken an.
    Beispiele sind das Neudesign von Race Conditions, Vorhersagen von p99 bei DB-Calls oder A/B-Tests.
  • Insgesamt wurde der These des Artikels zugestimmt, zugleich aber auch auf positive Veränderungen durch die Nutzung von LLMs hingewiesen.
    Für einen Senior-Entwickler mit 30 Jahren Erfahrung bedeutet das Lesen von AI-generiertem Code, dass sich Entwicklung in Richtung eines Code-Review-zentrierten Workflows verschiebt.
    Das hilft auch Einzelentwicklern, teamartige Verantwortung zu lernen und Erfahrung im Lesen von Code aufzubauen.
    Außerdem erfordert gute LLM-Nutzung zwingend ein Verständnis der hierarchischen Struktur eines Problems.
    Wenn man abschnittsweise detailliert entwirft und dann implementiert, hilft das ganz natürlich bei der Definition von Interfaces und Grenzen.
    LLMs seien ein Katalysator, der das Wachstum von Juniors zu Seniors beschleunige und ihnen ermögliche, die Lernprozesse erfahrener Entwickler mitzuerleben.
    AI werde Entwickler nicht ersetzen, sondern am Ende einfach als Werkzeug in den Alltag einsickern.
    • Es wurde die Ansicht vertreten, dass man immer mehr Code lesen als selbst schreiben sollte.
      LLM-generierter Code mag monoton sein, ist aber dennoch eine Lerngelegenheit.
      Gerade durch LLM-generierten Code lernt man viele neue Idiome oder Library-Calls kennen.
      Je senioriger jemand ist, desto bessere Prompts kann er geben, wodurch LLMs als Katalysator noch wirksamer werden.
    • Für den simplen Copy-paste-Einsatz, bei dem AI zunächst einen Prototyp erzeugt, sei sie hervorragend, aber zum ungeprüften Übernehmen und Committen ungeeignet.
    • Aus Unternehmenssicht dient AI nicht dazu, Juniors zu helfen, sondern eher dazu, Junior-Hiring abzuschaffen und von Seniors mit AI die zehnfache Produktivität zu verlangen.
      Big Tech, Mid Tech und Small Tech setzen den Personalabbau gleichermaßen fort.
  • Die AI-Debatte wurde mit früheren Vorstellungen verglichen, 3D-Druck werde die gesamte Fertigung ersetzen.
    Die Behauptung lautet, AI liege näher an solchen realistischen Veränderungen als an einer Singularität.
    • 3D-Druck ist eine wirklich großartige und innovative Technologie, aber Injection Molding existiert weiterhin.
    • 3D-Druck führt nicht zur Singularität, doch in der Hochschulbildung und anderer Wissensarbeit hat AI bereits enorme Auswirkungen.
      Es wurde berichtet, dass sich ehemals selbstverständliche Formen von Vorlesungen, Aufgaben und Unterricht durch das Aufkommen von LLMs weltweit schnell verändern.
    • 3D-Druck ist ein Beispiel für enorme Veränderungen und Innovationen in Branchen wie Luft- und Raumfahrt.
      Ohne SpaceX wären viele Bereiche praktisch nicht möglich gewesen.
    • Ähnlich war auch die Erwartung, Bitcoin werde Banken ersetzen.
      Am Ende verkaufen Banken nun eben Finanzprodukte auf Basis von Bitcoin.
    • 3D-Druck und AI haben völlig unterschiedliche Wachstumskurven.
      3D-Druck gilt nicht wirklich als Ersatz für bestehende Fertigung, sondern bleibt vor allem bei Prototypen, Mockups und PoCs.
  • LLMs schreiben gut Code, können aber nicht der Träger von „Verantwortung“ sein.
    Code zu übernehmen, ohne ihn zu verstehen, führt später bei der Wartung zu hohen Kosten in Form von Technical Debt.
    Das gleiche einer Illusion kostenloser Geschwindigkeit, tatsächlich aber mit einem Effekt, als würden technische Schulden mit 40 % Jahreszins anwachsen.
    AI kann das Tippen automatisieren, aber das Denken muss menschlich bleiben.
    • Da LLMs nicht wirklich „verstehen“, entsteht echte Comprehension nur dann, wenn ein Mensch den Kontext der Codebasis und des Systems versteht.
    • Als Mittel zur Senkung des „Zinssatzes“ der Technical Debt wurden Testing und die Strukturierung in isolierte Subsysteme (tdd, Microservices usw.) vorgeschlagen.
      Manche vertreten die Ansicht, dass tdd und Microservices, die in klassischer Entwicklung nicht immer nötig waren, im LLM-Zeitalter wertvoller werden.
    • Je nach Aufgabe kann AI sogar beim Codeschreiben sehr schlecht sein.
  • Als größter Schmerzpunkt wurde Input Risk genannt.
    Schon kleine Unklarheiten im Prompt können das Ergebnis vollständig entgleisen lassen, und wenn man das bemerkt, ist die Korrektur oft schwierig.
    Gerade wegen der Mehrdeutigkeit menschlicher Sprache sind letztlich formale Sprachen entstanden.
    Persönlich entstand beim Einsatz von AI-Tooling sogar das Gefühl eines starken Kompetenzabbaus; in manchen Fällen kostete es eher mehr Zeit und Energie.
    AI ist nützlich, aber es scheint zwei Lager zu geben: eines, das sieht, wie sich bei komplexen Problemen kleine Fehler aufaddieren, und ein anderes aus Managern und Nichttechnikern, das nur auf Ergebnisse schaut und sofort von „Rollenersatz“ spricht.
    [Detaillierte Erfahrung: früherer Kommentar]
    • Empfohlen wurde eine Struktur, in der AI als Assistent dient, während man selbst direkt für Qualität und Wartbarkeit verantwortlich bleibt.
      So wie Taschenrechner die Fähigkeit zum Kopfrechnen verringert haben, könnte AI auch Schreiben, Kommunikation und Problemlösung verschlechtern.
    • Es wurde eine Erfahrung geteilt, bei der die Eingabe mehrdeutiger Begriffe zu unlogischen Ergebnissen des LLM führte.
      Deshalb werde das LLM nur für kleine, klare Aufgaben oder Probleme eingesetzt, die man sonst auf StackOverflow suchen würde.
      Antworten würden nicht als absolute Wahrheit, sondern als Orientierung betrachtet.
    • AI hilft dabei, manche Probleme schneller zu lösen, kann aber Probleme, die unnötig komplex gemacht wurden, trotzdem nicht lösen.
      Die menschliche Fähigkeit, den Gesamtentwurf zu verstehen, bleibt der Schlüssel zum Widerstand gegen Entropie.
    • Eine oft genutzte Methode lautet, das LLM zunächst aufzufordern: „Stelle mir 3 Runden lang jeweils 5 klare Fragen.“
      Dadurch lassen sich Thema und Kontext klarer schärfen.
      Vielleicht hilft dieser Tipp auch anderen.
    • Es besteht die Ahnung, dass nach dieser Hype-Phase die Bedeutung von Qualitätsmanagement wiederentdeckt wird.
      Beispielhaft wurde der alte Krieg zwischen Coke und Pepsi genannt.
  • Der Ansicht, LLMs könnten nicht konzeptionell mit Ideen, Diagrammen und Spezifikationen arbeiten, wurde widersprochen.
    Wenn man ein LLM nach Design-Intentionen fragt, etwa mit der Bitte um „vereinfachten Code“, könne man durchaus eine gute zweite Meinung erhalten.
    Ohne Nachfrage gibt es natürlich auch keine Antwort, und Default-Einstellungen sind ebenfalls unsere Entscheidung; daher sei das kein Argument über das Wesen der zugrunde liegenden Technologie.
    • Es gebe bereits viele empirische Beispiele dafür, dass LLMs konzeptionelle Arbeit leisten können.
      In der Realität kann ohnehin niemand ein riesiges Programm vollständig im Kopf erfassen, weshalb Werkzeuge und Sprachen sich meist auf Basis partiellen Verständnisses entwickelt haben.
      LLMs teilen diese Grenze, daher haben Menschen und LLMs in diesem Rahmen ähnliche Beschränkungen.
    • Bei Code-Reviews von Juniors werde häufiger ein Problem der Richtung als der eigentlichen Codequalität beobachtet.
      Schade sei, dass LLMs kaum die Fähigkeit haben, zu dieser Richtung zu fragen: „Warum machst du das so?“
    • Es wurde gefragt, ob Tools zur automatischen Umwandlung von Code in Diagramme genutzt werden oder ob man sich solche Werkzeuge selbst baut.
  • Es wurde eine Parallele zu der Behauptung gezogen, Kartensoftware wie Google Maps oder Apple Maps lasse die menschliche Orientierungsfähigkeit verkümmern.
    Das stimmt in Teilen, doch die meisten Menschen konnten sich ohnehin nie besonders gut orientieren, und durch Kartentechnologie hat sich die durchschnittliche Fähigkeit, von A nach B zu kommen, eher verbessert.
    Selbst für die kleine Gruppe sehr fähiger Menschen ersetzt die Technik ihre Fähigkeit nicht unbedingt, sondern unterstützt sie eher.
    AI werde auf größerer Ebene wohl ähnliche Veränderungen bringen; einige Fähigkeiten gehen verloren, doch es gibt auch viel zu gewinnen.
    • Karten sind in puncto Zuverlässigkeit nicht mit LLMs vergleichbar.
      Karten liefern fast immer den erwarteten Wert, während LLMs selbst beim gleichen Prompt andere Ergebnisse liefern können und deshalb schwer vertrauenswürdig sind.
      Wie Menschen wegen Maps in Seen fahren, kann blindes Vertrauen in LLMs sogar größere Probleme auslösen.
    • Persönlich helfe Kartensoftware sogar beim räumlichen Gedächtnis.
      Man kann frei herumirren und bei Bedarf den Weg finden, wodurch die Erfahrung eher verstärkt wird.
    • Google Maps ist mehr als 90 % genauer als ein Taxifahrer.
      AI ist in manchen Bereichen nicht einmal besser als ein gewöhnlicher Mensch mit nur wenigen Tagen Erfahrung.
    • Es wurde bezweifelt, ob es Belege für die Behauptung einer „Verbesserung der durchschnittlichen Fähigkeiten“ gibt.
  • Der Aussage des Autors, „[AI] kann nicht auf konzeptioneller Ebene arbeiten“, wurde ebenfalls nicht zugestimmt.
    Neuere LLMs können ganz klar auf konzeptioneller Ebene arbeiten, etwa beim Übersetzen oder Anwenden von Konzepten.
    Es wurde sogar behauptet, sie verstünden Konzepte, die ein Mensch nie persönlich erfahren hat.
    • LLMs modellieren Konzepte über Token-Cluster.
      So liegen zum Beispiel um „dog“ herum verwandte Begriffe.
      Kombinationen, Intentionen oder kontrafaktische Logik können sie jedoch nicht modellieren.
      Bei Fragen, die den Trainingsdaten ähnlich sind, zeigen sie ihre Stärke.
      In Bereichen wie Software Engineering, in denen Konzeptualisierung gut definiert ist, sind sie daher nützlich.
    • Ergänzend wurde angemerkt, dass auch Menschen Konzepte verstehen können, die sie nicht selbst erlebt haben.
  • Realistisch gesehen erledigen 70 % der Beschäftigten ihre Arbeit nur halbherzig, und AI ist dann oft sogar besser.
    Wer ohnehin nicht ernsthaft arbeitet, ändert sich auch mit AI nicht, und nur wer wirklich lernen will, wächst gemeinsam mit AI.
    • Es wurde auf die Begrenztheit eines selbstzentrierten Narrativs hingewiesen, in dem man sich selbst zu den produktiven 30 % zählt.
    • Wer mit AI nur Arbeit schlampig durchschieben will, erhöht eher sein eigenes Entlassungsrisiko.
      Wenn AI die Arbeit besser macht, liefert man damit nur die Begründung für den eigenen Ersatz.
    • Für Großunternehmen wurde diese Sicht als die realistischste bezeichnet.
      Auch FSD ist für normale Fahrer ohne Expertenwissen deutlich besser als deren eigene Leistung.
  • Zuletzt wurde geteilt, dass zunehmend das Bedürfnis besteht, 90s.dev als nicht-AI-Community und Raum für Software-Handwerkskunst neu aufzubauen.
    Überlegt wird ein Format als Forum, Mailingliste oder Multi-Blog.
    Temporäre Mailingliste
    • Eine Struktur, der nicht jeder frei beitreten kann, sondern die auf Einladungen und einem Vertrauensbaum aus Empfehlungen beruht, wurde als geeigneter für langlebige Communities angesehen.
      In bestimmten Communities gebe es bereits erfolgreiche Beispiele dafür.
    • Auch die Nutzung klassischer Forumssoftware von damals mit einem Design im Retro-Stil wurde als gute Idee genannt.