In den schummrigen Ecken moderner Softwareentwicklungsbüros breitet sich still und leise eine neue Art der Sucht aus. Dabei geht es nicht um Substanzen oder traditionelle Laster, sondern um eine schleichende Abhängigkeit von künstlicher Intelligenz, die verspricht, jedes Programmierproblem mit einem einfachen Druck auf die Eingabetaste zu lösen. Große Sprachmodelle sind für Softwareentwickler zum digitalen Äquivalent einer leistungssteigernden Droge geworden, die sofortige Befriedigung und scheinbar unbegrenztes Wissen bieten, allerdings auf Kosten von etwas, das weitaus wertvoller ist, als wir zunächst gedacht haben.

Das Phänomen beginnt harmlos genug. Ein Softwareentwickler stößt auf eine besonders schwierige Algorithmusimplementierung und beschließt, ein LLM um Rat zu fragen. Die Antwort kommt innerhalb von Sekunden, komplett mit funktionierendem Code, detaillierten Erklärungen und sogar Optimierungsvorschlägen. Der Dopamin-Kick wirkt sofort und stark. Was Stunden der Recherche, des Ausprobierens und des intensiven Nachdenkens gekostet hätte, ist zu einem kurzen Gespräch mit einem künstlichen Assistenten komprimiert. Der Entwickler fühlt sich produktiv, effizient und bemerkenswert kompetent.

Diese erste Erfahrung schafft einen starken psychologischen Präzedenzfall. Das Gehirn, das immer den Weg des geringsten Widerstands sucht, beginnt, Problemlösungen eher mit der Konsultation eines LLM als mit unabhängiger Analyse in Verbindung zu bringen. Was als gelegentliche Unterstützung beginnt, verwandelt sich allmählich in eine primäre Problemlösungsstrategie. Der Entwickler greift zur LLM-Schnittstelle, bevor er überhaupt versucht, Herausforderungen selbstständig zu durchdenken.

Die Neurochemie der digitalen Abhängigkeit

Das Suchtpotenzial von LLMs wirkt über dieselben neurologischen Bahnen, die auch andere Formen der Verhaltenssucht steuern. Jede erfolgreiche Interaktion mit einem KI-System löst die Ausschüttung von Dopamin im Belohnungszentrum des Gehirns aus und schafft so eine starke Verbindung zwischen Problemlösung und externer Unterstützung. Im Gegensatz zum traditionellen Lernen, das mit verzögerter Befriedigung und allmählichem Aufbau von Fähigkeiten verbunden ist, bieten LLM-Interaktionen sofortige Belohnungen, die die natürlichen Lernmechanismen des Gehirns hijacken können.

Neurowissenschaftliche Untersuchungen haben gezeigt, dass die Erwartung einer Belohnung oft stärkere Dopaminreaktionen hervorruft als die Belohnung selbst. Dies erklärt, warum Entwicklerinnen oft einen Adrenalinstoß verspüren, wenn sie eine Anfrage für ein LLM formulieren, noch bevor sie die Antwort erhalten. Das Gehirn beginnt, sich nach diesem Zustand der Vorfreude zu sehnen, was zu einer erhöhten Häufigkeit der KI-Konsultation führt, selbst bei Problemen, die sich mit minimalem Aufwand selbstständig lösen lassen.

Der variable Verstärkungsplan, der den LLM-Interaktionen innewohnt, schafft ein besonders starkes Suchtpotenzial. Manchmal liefert die KI sofort perfekte Lösungen, manchmal sind mehrere Iterationen und Verfeinerungen erforderlich, und gelegentlich liefert sie Antworten, die erhebliche Modifikationen benötigen oder sich als gänzlich unbrauchbar erweisen. Diese Unvorhersehbarkeit spiegelt die psychologischen Mechanismen wider, die beim Glücksspiel süchtig machen, und erzeugt ein zwanghaftes Bedürfnis, „noch eine weitere Eingabe zu versuchen“, um die perfekte Antwort zu erhalten.

Betrachten wir den Fall eines erfahrenen Entwicklers, der an einem komplexen Problem zur Optimierung einer Datenstruktur arbeitet. In der Zeit vor LLM wäre er die Herausforderung angegangen, indem er zunächst die zugrunde liegenden Datenmuster verstanden, bestehende Algorithmen recherchiert, mögliche Lösungen skizziert und seinen Ansatz durch Experimente iterativ verfeinert hätte. Dieser Prozess wäre zwar zeitaufwendig gewesen, hätte aber sein Verständnis für algorithmische Komplexität, Kompromisse bei Datenstrukturen und Optimierungsprinzipien vertieft.

Mit der sofort verfügbaren LLM-Unterstützung beschreibt derselbe Entwickler nun sein Problem dem KI-System und erhält innerhalb weniger Minuten eine ausgeklügelte Lösung. Der Code funktioniert, die Leistungskennzahlen verbessern sich und das Projekt schreitet voran. Allerdings hat der Entwickler den entscheidenden Lernprozess umgangen, der sein grundlegendes Verständnis des Problemfeldes verbessert hätte. Er ist eher ein Konsument von Lösungen geworden als ein Schöpfer von Verständnis.

Das Spektrum der LLM-Suchtmuster

LLM-Sucht manifestiert sich in verschiedenen Formen, die jeweils unterschiedliche Merkmale und Verlaufsmuster aufweisen. Der Query Junkie stellt die offensichtlichste Form der Abhängigkeit dar, die durch zwanghaftes Prompting-Verhalten und die Unfähigkeit gekennzeichnet ist, Probleme ohne sofortige KI-Konsultation anzugehen. Diese Menschen halten oft mehrere LLM-Schnittstellen gleichzeitig offen und verspüren echte Angst, wenn sie gezwungen sind, ohne KI-Unterstützung zu arbeiten.

Der Solution Collector ist eine subtilere Form der Abhängigkeit, bei der man riesige Bibliotheken mit KI-generierten Code-Schnipseln und Lösungen ansammelt, ohne ein tiefes Verständnis für die zugrunde liegenden Prinzipien zu entwickeln. Solution Collectors sind sehr effizient darin, bestehende Lösungen zu finden und anzupassen, verlieren jedoch die Fähigkeit, neue Ansätze zu entwickeln oder die grundlegenden Kompromisse zu verstehen, die mit ihrer Umsetzung verbunden sind.

Das Suchtmuster des Pseudo-Experten ist besonders gefährlich, da es eine Illusion von Kompetenz erzeugt, während es tatsächlich echtes Fachwissen untergräbt. Die vermeintlichen Experten verstehen sich geschickt darin, anspruchsvolle Fragen zu stellen und KI-Antworten zu interpretieren, was sie zu der Annahme verleitet, dass sie über tiefgreifendes Wissen verfügen, obwohl sie tatsächlich nur ein oberflächliches Verständnis haben. Sie können komplexe Themen mithilfe von KI-basierten Erkenntnissen flüssig diskutieren, haben jedoch Schwierigkeiten, wenn sie eine Komponente mit neuen Problemen konfrontiert, die echte Kreativität oder tiefgreifende Analysen erfordern.

Der Validierungssuchende nutzt LLMs nicht in erster Linie zur Lösungsfindung, sondern zur ständigen Bestätigung seiner eigenen Ideen und Ansätze. Das mag zwar weniger problematisch erscheinen als eine vollständige Abhängigkeit von KI-Lösungen, untergräbt jedoch das Selbstvertrauen und das unabhängige Urteilsvermögen. Diese Menschen verlieren allmählich das Vertrauen in ihre eigenen analytischen Fähigkeiten und sind ohne die Bestätigung durch KI nicht mehr in der Lage, technische Entscheidungen zu treffen.

Die Sucht manifestiert sich auf immer subtilere Weise. Entwicklerinnen und Entwickler verspüren Angst, wenn sie gezwungen sind, ohne LLM-Zugang zu arbeiten, ähnlich wie das Unbehagen, das man empfindet, wenn man von seinem Smartphone getrennt ist. Sie entwickeln eine sogenannte Prompt-Abhängigkeit, bei der ihr Problemlösungsprozess vollständig auf die Formulierung von Anfragen für KI-Systeme ausgerichtet ist, anstatt sich mit einer unabhängigen Analyse zu befassen.

Der Verlust grundlegender Fähigkeiten

Die psychologischen Mechanismen, die dieser Abhängigkeit zugrunde liegen, spiegeln diejenigen wider, die auch bei anderen Formen der digitalen Sucht zu finden sind. Das variable Belohnungssystem von LLMs erzeugt einen starken Konditionierungseffekt. Manchmal liefert die KI sofort genau die richtige Lösung, manchmal sind Verfeinerungen und Iterationen erforderlich, und gelegentlich gibt sie Antworten, die erhebliche Modifikationen benötigen. Diese Unvorhersehbarkeit erzeugt die gleichen psychologischen Reize, die soziale Medien und Gaming-Plattformen so attraktiv machen.

Das Konzept des Flow-Zustands, das Softwareentwickler seit langem als Höhepunkt produktiver Programmiererfahrung schätzen, lässt sich für diejenigen, die auf die Unterstützung von LLMs angewiesen sind, immer schwerer erreichen. Flow erfordert eine intensive Auseinandersetzung mit herausfordernden Problemen, anhaltende Konzentration und den schrittweisen Aufbau von Verständnis durch beharrliche Anstrengungen. Die Abhängigkeit von LLMs stört diesen Prozess, indem sie externe Lösungen liefert, bevor der Entwickler die Möglichkeit hatte, sich intensiv mit dem Problemfeld auseinanderzusetzen.

Die Verschlechterung der Debugging-Fähigkeiten ist einer der besorgniserregendsten Aspekte der LLM-Abhängigkeit. Debugging diente traditionell als wichtiger Lernmechanismus in der Softwareentwicklung und zwang Developer dazu, das Systemverhalten zu verstehen, Ausführungspfade zu verfolgen und mentale Modelle der Programmfunktion zu entwickeln. Entwickler, die Debugging-Aufgaben an KI-Systeme delegieren, verpassen diese Lernmöglichkeiten und verlieren nach und nach die analytischen Fähigkeiten, die für die Diagnose komplexer Probleme erforderlich sind.

Dieses Phänomen geht über den Verlust individueller Fähigkeiten hinaus und wirkt sich auch auf grundlegende kognitive Prozesse aus. Developer, die von LLM-Unterstützung abhängig sind, erleben oft das, was Kognitionswissenschaftler als kognitive Entlastung bezeichnen, wobei externe Tools so sehr zu einem integralen Bestandteil des Denkprozesses verkommen, dass sich unabhängiges Denken als schwierig oder unmöglich erweist. Dies ähnelt der Art und Weise, wie die Abhängigkeit von GPS die räumlichen Navigationsfähigkeiten beeinträchtigen kann, aber die Auswirkungen auf die Softwareentwicklung sind weitaus tiefgreifender.

Die Gedächtniskonsolidierung, ein entscheidender Aspekt der Kompetenzentwicklung, zeigt sich beeinträchtigt, wenn Entwickler sich stark auf externe KI-Unterstützung verlassen. Der Prozess des Ringens mit Problemen, des Machens von Fehlern und des allmählichen Aufbaus von Verständnis schafft starke neuronale Bahnen, die eine schnelle Mustererkennung und intuitive Problemlösung ermöglichen. Die Abhängigkeit von LLM unterbricht diesen Prozess und führt zu Wissen, das sich umfassend anfühlt, aber nicht die für eine fachkundige Leistung erforderliche tiefe Integration aufweist.

Eine besonders besorgniserregende Ausprägung der LLM-Abhängigkeit ist die allmähliche Erosion der Debugging-Fähigkeiten. Debugging ist traditionell eine der wertvollsten Kompetenzen, die Developer entwickeln können, da es systematisches Denken, die Bildung von Hypothesen und methodisches Untersuchen erfordert. Wer von LLM-Unterstützung abhängig ist, beginnt oft damit, Debugging-Aufgaben an KI-Systeme zu delegieren und Fehlermeldungen und Symptome zu beschreiben, anstatt die analytischen Fähigkeiten zu entwickeln, die notwendig sind, um Probleme bis zu ihren Ursachen zurückzuverfolgen.

Auswirkungen auf die Disziplinen der Softwareentwicklung

Die Auswirkungen der LLM-Abhängigkeit variieren erheblich zwischen den verschiedenen Spezialisierungen der Softwareentwicklung, die jeweils einzigartige Herausforderungen und Risiken mit sich bringen. Frontend-Entwickler könnten feststellen, dass ihre Designkompetenz nachlässt, da sie sich zunehmend auf KI-generierte Benutzeroberflächenkomponenten und Styling-Lösungen verlassen. Das subtile Verständnis der Prinzipien der Benutzererfahrung, der visuellen Hierarchie und des Interaktionsdesigns, das Entwickler durch praktische Experimente erwerben, ersetzen LLMs durch algorithmische Vorschläge, die zwar technisch kompetent sind, aber keine menschliche Einsicht bieten.

Backend-Entwicklerinnen stehen vor anderen Herausforderungen, insbesondere in Bereichen, die ein tiefes Verständnis der Systemarchitektur und der Leistungsmerkmale erfordern. LLM-generierte Lösungen funktionieren oft gut für gängige Szenarien, können jedoch subtile Ineffizienzen oder architektonische Entscheidungen enthalten, die bei großem Umfang problematisch sind. Entwickler, die sich stark auf KI-Unterstützung verlassen, übersehen möglicherweise diese Nuancen, was zu Systemen führt, die anfangs gut funktionieren, aber mit zunehmender Komplexität oder Benutzerlast auf ernsthafte Probleme stoßen.

Datenbankspezialisten sind besonders gefährdet, da die Datenbankoptimierung ein tiefes Verständnis von Abfrageausführungsplänen, Indexstrategien und Datenverteilungsmustern erfordert. Diese Erkenntnisse entwickeln sich durch jahrelange praktische Erfahrung mit realen Leistungsproblemen. Von LLM generierte Datenbanklösungen folgen oft Standardmustern, übersehen jedoch möglicherweise die subtilen Optimierungen, die Datenbankarbeit von wirklich fachmännischer Leistung unterscheiden.

Security Engineers sind möglicherweise den größten Risiken durch LLM-Abhängigkeit ausgesetzt, da Sicherheit eine grundlegend kontradiktorische Denkweise erfordert, bei der sie darüber nachdenken, wie Eindringlinge Systeme angreifen oder kompromittieren. KI-Systeme, die in erster Linie auf öffentlich zugänglichem Code und Dokumentation trainiert sind, können möglicherweise nicht das kreative Denken angemessen repräsentieren, das erforderlich ist, um neue Angriffsvektoren zu identifizieren oder robuste Verteidigungsstrategien zu entwickeln. Security Engineers, die von KI-Unterstützung abhängig werden, können ein falsches Gefühl der Sicherheit entwickeln und dabei kritische Schwachstellen übersehen.

DevOps Engineers und Infrastrukturexpertinnen stehen vor besonderen Herausforderungen, da ihre Arbeit oft das Verständnis der komplexen Interaktionen zwischen mehreren Systemen, Tools und Umgebungen erfordert. Die für das Infrastrukturmanagement erforderlichen Fähigkeiten zur Fehlerbehebung entwickeln sich durch direkte Erfahrungen mit Systemausfällen und die schrittweise Aneignung von Wissen darüber, wie verschiedene Komponenten unter verschiedenen Bedingungen interagieren. LLM-Unterstützung kann Standardlösungen bieten, erfasst jedoch möglicherweise nicht das umgebungsspezifische Wissen, das den Unterschied zwischen angemessenem und exzellentem Infrastrukturmanagement ausmacht.

Dieses Phänomen erweist sich als noch problematischer, wenn man die kollaborative Natur der Softwareentwicklung berücksichtigt. Entwickler, die unter einer übermäßigen Abhängigkeit von LLM leiden, haben oft Schwierigkeiten in Pair-Programming-Sitzungen oder Code-Review-Diskussionen, weil sie nicht das notwendige tiefgreifende Verständnis entwickelt haben, um ihre Überlegungen zu erklären oder ihre Implementierungsentscheidungen zu verteidigen. Ihr Wissen wird oberflächlich und fragmentiert und besteht eher aus KI-generierten Lösungen als aus prinzipiellem Verständnis.

Nach mehreren großangelegten Angriffswellen auf das NPM-Ökosystem ergreifen dessen Betreiber nun Maßnahmen, um eine Wiederholung zu verhindern. Im August und September hatten Unbekannte nicht nur mehrere Entwicklerkonten übernommen, sondern auch einen Wurm eingeschleust, der selbstständig weitere Node-Projekte infizierte. Um sich zu verbreiten, nutzte „Shai-Hulud“ Authentifizierungs-Token, denen es jetzt an den Kragen geht.

Die ersten Schritte ist NPM-Betreiber GitHub bereits gegangen – seit dem 13. Oktober sind granulare NPM-Zugriffstoken nicht mehr unbegrenzt lange, sondern nur noch maximal 90 Tage gültig, die Standardlaufzeit beträgt nun 7 statt 30 Tage. Eine Zwei-Faktor-Authentifizierung mittels TOTP (Time-based One-Time Password) kann für NPM-Paketverwalter nicht mehr neu eingerichtet werde. Wer TOTP bereits als zweiten Faktor zur Anmeldung nutzt, kann dabei vorerst bleiben, wird aber bald auf WebAuthn/Passkeys umstellen müssen.

Classic Tokens werden sehr bald beerdigt

Die sogenannten „Classic Tokens“ zur Authentifizierung (etwa in Automatisierungen oder CI/CD Pipelines) trägt GitHub bis Anfang November vollständig zu Grabe. Bestehende Token für NPM-Paketherausgeber zieht das Unternehmen ein und auf npmjs.com lassen sich künftig keine neuen mehr erstellen. Betroffene müssen sich umgehend um neue, granulare Token kümmern und ihre Automatisierungen aktualisieren, damit diese nach der Umstellung nicht vor die sprichwörtliche Wand laufen.

Mit diesen Schritten setzt GitHub eine Ankündigung aus Ende September teilweise in die Tat um – Entwickler und DevOps sind gefordert. Deren Verantwortung unterstreicht GitHub ausdrücklich: „Wir verstehen, dass diese Änderungen Aufwand von der Gemeinschaft verlangen. NPM abzusichern, ist eine geteilte Verantwortlichkeit.“ Die Änderungen verursachten vorübergehend Reibungen, seien aber notwendig, um künftigen Angriffen begegnen zu können.

Und gegenüber der September-Ankündigung tritt die zu Microsoft gehörende Entwicklerplattform sogar noch etwas mehr aufs Gaspedal: War dort noch von Mitte November als Löschzeitpunkt für „Classic Tokens“ die Rede, spricht GitHub in einer an Entwickler verschickten E-Mail von Anfang desselben Monats. Kurios: Obgleich erste Schritte bereits am Montag, dem 13. Oktober starteten, erhielten einige npm-Paketverantwortliche den Newsletter erst drei Tage später.

Ausblick: Trusted Publishing

Künftig sollen, so GitHubs Wunsch, Paketverwalter auf den Ansatz des „trusted publishing“ schwenken und auf langlebige Zugriffstoken ganz verzichten. Stattdessen sollen anlassbezogene Zugriffsrechte über den CI/CD-Anbieter, also etwa GitHub Actions oder GitLab CI/CD vergeben werden. Das verhindere, dass Token abhandenkommen und führe auch zu besserer Nachvollziehbarkeit, so das Unternehmen im Blog.

(cku)

Wardley Maps sind ein visuelles Werkzeug, das dabei unterstützen kann, Systeme im strategischen Zusammenhang zu betrachten und Entscheidungen bewusster zu treffen. In dieser Episode von Eberhard Wolffs Videcoast zeigt Markus Harrer, wie sich mit Wardley Mapping Abhängigkeiten in Softwaresystemen nachvollziehbarer darstellen lassen und wie es helfen kann, Architekturentscheidungen besser einzuordnen.

Darüber hinaus macht Markus Harrer anhand von Beispielen aus der Legacy-Modernisierung deutlich, wie diese Technik genutzt werden kann, um Diskussionen über den Umgang mit gewachsenen Systemen anzuregen und neue Blickwinkel darauf zu eröffnen. Teilnehmende erhalten Anregungen, wie Wardley Maps im Alltag eine strukturiertere und entspanntere Auseinandersetzung mit Softwaresystemen ermöglichen können.

Livestream am Freitag, 17. Oktober

Die Ausstrahlung findet am Freitag, 17. Oktober 2025, live von 13 bis 14 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat, Bluesky, Mastodon, Slack-Workspace oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zur Folge finden sich auf der Videocast-Seite.

(mdo)