Die Kosten, die AI Coding verursacht
(tomwojcik.com)- Die breite Nutzung von AI-Coding-Tools durch Entwickler hat die Produktivität erhöht, verursacht aber unsichtbare kognitive und organisatorische Kosten
- Von frühen assistiven Tools wie Copilot und Cursor hat sich die Entwicklung zuletzt zu autonomen Agenten verschoben, wodurch sich die Struktur dahin verändert, dass Menschen der AI helfen
- Eine vollständig delegierende Nutzung führt jedoch zu kognitiven Schulden (cognitive debt) und einer Verschlechterung der Debugging-Fähigkeiten, wodurch die Problemlösungskompetenz und das Codeverständnis von Entwicklern geschwächt werden
- Eine Struktur, in der AI Code schreibt und Menschen ihn nur noch prüfen, führt zum Zusammenbruch des Pfads zur Entwicklung von Seniors und zum Verlust des kreativen Flows, wodurch die technische Leistungsfähigkeit von Organisationen langfristig erodiert
- Der Einsatz von AI ist unverzichtbar, aber man muss die „angemessene Nutzungsschwelle“ selbst festlegen und die Nutzung so anpassen, dass menschliches Verständnis und Lernen erhalten bleiben
Die Entwicklung der Einführung von AI Coding
- Copilot, Cursor und ähnliche Tools, die 2022 bis 2023 auftauchten, indexierten Codebasen und boten kontextbasierte Autovervollständigung und Chat-Funktionen
- Googeln oder Suchen auf StackOverflow wurde unnötig, und die Verbreitung von IDE-Umgebungen mit integrierter AI nahm zu
- Die später aufgetauchten agentenbasierten Workflows bedeuteten den Wechsel von menschlicher Unterstützung zu AI-gesteuerter Entwicklung
- Allerdings verursachen Agenten Zuverlässigkeitsprobleme durch Schleifen, Halluzinationen und Abhängigkeitsfehler
- Seit Opus 4.5 ist der Automatisierungsgrad gestiegen, und in einigen Unternehmen gibt es bereits Fälle, in denen Entwickler selbst keinen Code mehr schreiben
- Beispiel: Der Co-CEO von Spotify erwähnte, dass Engineers Claude in Slack Anweisungen geben und damit bis zur Anpassung und Bereitstellung von Funktionen gelangen
Kognitive Schulden und technischer Abbau
- Es wird auf die Konzepte „Digital Dementia“ von Manfred Spitzer und „Cognitive Debt“ von Margaret-Anne Storey verwiesen
- Wenn wiederholtes Denken an AI delegiert wird, schwächen sich neuronale Pfade ab und das Codeverständnis nimmt ab
- Studie von Shen und Tamkin (2026): Unter 52 Entwicklern erzielte die Gruppe mit AI-Unterstützung 17 % niedrigere Werte beim konzeptionellen Verständnis, Debugging und Code-Lesen
- Besonders deutlich war der Rückgang der Debugging-Fähigkeit; schon eine Stunde passiver AI-Nutzung führte zu messbarer Erosion von Fähigkeiten
- Wenn AI anspruchsvolle Aufgaben übernimmt, entsteht ein Zustand von „dark flow“ statt „echtem Flow“, der Abhängigkeit verstärkt, ohne Lernen zu fördern
Das Code-Review-Paradox und der Zusammenbruch der Senior-Entwicklung
- Wenn AI den Code schreibt und Menschen ihn nur prüfen, entsteht das Paradox, dass die Grundlage der Prüfkompetenz verschwindet
- Entwickler, die sich vollständig auf AI verlassen, arbeiten schnell, erzielen aber die schlechtesten Bewertungsergebnisse
- Storey schlägt vor: „Vor dem Deployment müssen von AI erzeugte Änderungen vom Menschen vollständig verstanden werden.“
- AI liefert Einsteigern Ergebnisse auf Senior-Niveau, doch das ist nur Reproduktion ohne Verständnis
- Seniors schreiben Code nicht mehr selbst und verlieren dadurch Tiefe, Juniors wachsen nicht, weil sie keine Versuch-und-Irrtum-Erfahrung mehr machen
- Dadurch bricht die Pipeline zur Entwicklung von Seniors zusammen
Fehlurteile des Managements und organisatorische Nebenwirkungen
- Führungskräfte bei Microsoft, Anthropic und Google prognostizieren, dass AI innerhalb weniger Monate Engineers ersetzen werde
- Google berichtete Ende 2024, dass 50 % des neuen Codes AI-generiert seien
- Solche Zahlen seien jedoch Übertreibungen mit dem Ziel, AI zu verkaufen oder den Aktienkurs zu stützen, und auf gewöhnliche Organisationen nicht übertragbar
- Einige Unternehmen messen die AI-Nutzung als KPI und zwingen Entwickler dazu
- Beispiel Reddit: Entwickler manipulierten die AI-Nutzung mit bedeutungslosen Prompts
- In der Folge greift Goodharts Gesetz: Statt Produktivitätssteigerung bleibt nur formale Konformität
Menschliche Kosten und Verlust von Kreativität
- Das Schreiben von Code bietet Freude an Vertiefung und Schöpfung, während das Prüfen von AI-Code mentale Ermüdung verursacht
- Wenn die Dopamin-Belohnung des Erschaffens verschwindet, beschleunigt sich Burnout
- Entwicklung verkommt zu Qualitätssicherung (QA), und kreative Befriedigung verschwindet
- Verglichen wird dies mit einer Situation, in der AI jede Kunst übernimmt und Menschen nur noch „die Wäsche zusammenlegen“
Die angemessene Schwelle für AI-Nutzung
- AI ist ein mächtiges Werkzeug, aber weder viel noch wenig Nutzung ist automatisch gut
- Die Studie von Shen und Tamkin zeigt unter sechs Mustern der AI-Interaktion:
- vollständige Delegation, schrittweise Abhängigkeit und ausgelagertes Debugging behindern das Lernen
- Erklärungen anfordern, konzeptionelle Fragen stellen und nach eigenständigem Coden verifizieren erhalten das Lernen
- Die Studie von Shen und Tamkin zeigt unter sechs Mustern der AI-Interaktion:
- Entscheidend ist die Aufrechterhaltung kognitiver Beteiligung; wichtig ist nicht nur, ob AI genutzt wird, sondern wie sie genutzt wird
- Wer AI gar nicht nutzt, verliert Effizienz bei Suche, Boilerplate und Exploration; wer sie übermäßig nutzt, schädigt Verständnis, Senior-Entwicklung, Bug-Erkennung und Flow-Erleben
Stiller Niedergang
- In den Metriken verbessern sich zwar Anzahl der PRs, Anzahl der Features und Cycle Time,
doch die innere technische Stärke, Konzentration und Problemlösungskompetenz schwächen sich allmählich ab - Entwickler werden zu „Butter-Robotern“, die nur noch auf Genehmigen klicken, ohne die von AI geschaffene Struktur zu verstehen
- Auch Simon Willison erwähnte, dass er bei einem Projekt von AI erstellte Funktionen nicht überprüft habe und
deshalb „die internen Abläufe nicht mehr klar versteht“ - Am Ende degeneriert nicht das Werkzeug, sondern der Mensch, und diese Veränderung wird weder gemessen noch gesteuert
- AI-Abhängigkeit schreitet wie eine Sucht voran und birgt das Risiko eines stillen, aber realen technologischen Niedergangs
1 Kommentare
Hacker-News-Kommentare
Für mich gehört der Prozess, Code selbst zu schreiben und die Struktur im Kopf zu entwerfen, immer noch zu den Freuden meines Jobs
Sogar wiederholtes oder lästiges Refactoring ist für mich ein sinnvoller Prozess
Diese mühsamen Momente werden zum Lernmaterial, das mich beim nächsten Mal einen besseren Weg finden lässt
Es bleibt als Hoffnung, dass dieser Trend eines Tages wieder zurückkommt
Ich glaube, irgendwann wird der Wert derjenigen wieder anerkannt, die sich die Fähigkeit bewahrt haben, selbst zu wählen und zu urteilen
Wenn Code schwer zu testen ist, muss man Abstraktionen oder Interfaces ändern
Tests sind die erste Wiederverwendung von Code; wenn sie beim Testen unpraktisch sind, werden sie auch in der realen Nutzung unpraktisch sein
Je mehr der Code von mir stammt, desto leichter kann ich mir im Kopf ausmalen, wo Probleme entstehen könnten
Ein LLM kann diese Intuition nicht ersetzen, egal wie viele Logs man ihm hinwirft
Aber ich frage mich, ob dadurch nicht die Motivation zur Verbesserung des Frontend-Ökosystems verloren geht
Selbst Dinge, die andere gern an ein LLM abgeben würden, mache ich gern selbst
Es macht mich traurig zu sehen, wie Unternehmen uns diese kleinen Freuden nach und nach wegnehmen
Ich habe im vergangenen Jahr viel Claude Code verwendet und in letzter Zeit eine Stimmungsänderung unter Kolleginnen und Kollegen beim Einsatz von AI gespürt
Ich habe einen Text über die versteckten Kosten geschrieben, die bei übermäßigem AI-Einsatz entstehen, und dafür Daten aus mehreren Quellen zusammengetragen
Es gibt noch keine eindeutigen Daten, aber viele Entwickler scheinen ähnlich zu empfinden
Allerdings klingt die Formulierung „Software ist nur ein Werkzeug“ für mich immer seltsam
Wenn ein Werkzeug Denken ersetzen kann, kann man es dann noch immer „Werkzeug“ nennen?
Die ehrliche Formulierung „Prompt-Sucht“ fand ich gut. Es wäre aber auch interessant, die Seite der Verhaltenssucht zu untersuchen
Es wirkt schnell und kontrolliert, aber nach und nach verliert man die Kontrolle
Die eigentliche Schwierigkeit ist, herauszufinden, „mit welcher nachhaltig tragbaren Geschwindigkeit man es nutzen sollte“
Ich habe zu einem ähnlichen Thema auch einen Blogbeitrag geschrieben,
allerdings aus der Perspektive, wie Führungskräfte Organisationen helfen können, ein nachhaltiges Gleichgewicht zu finden
Ich habe nach Arbeiten gesucht, die den Einfluss von Arbeitsgedächtnis (working memory) und Belohnungssystem auf Lernen und Vertiefung behandeln
In dieser Nature-Arbeit wird zum Beispiel gesagt, dass das Arbeitsgedächtnis Dopamin-Reaktivität aufweist
Und dieser Scientific-American-Artikel sagt, dass handschriftliches Schreiben mehr Hirnareale aktiviert
Letztlich ist die Schlussfolgerung, dass es bei passiver Arbeit mit geringer Belohnung kaum solche kognitiven Vorteile gibt
Deshalb denke ich, dass der Maßstab für den AI-Einsatz sein sollte: „Wie schmerzhaft und wie wenig belohnend ist diese Aufgabe?“
Ich schreibe weiterhin selbst Code und verstehe das Ergebnis vollständig
Eine Geschwindigkeitssteigerung ist mir egal. Wichtig ist dieses Gefühl von Eigentümerschaft: Das ist mein Code
Früher hätte ich Arbeit auch auslagern können, aber das wäre der Weg gewesen, nur noch jemand zu sein, der Code liest
Ich und die meisten Entwickler in meinem Umfeld spüren genau diesen Druck
Nur weil man eine Tastatur benutzt, verlernt man nicht das Handschreiben, und nur weil man Kaffee kauft, vergisst man nicht, wie man Kaffee kocht
Anfang der 80er habe ich Programmieren mit LSI-11-Assembler gelernt und alle Oktal-Opcodewerte auswendig gekonnt
Aber als ich FORTRAN 83 lernte, war ich zehnmal produktiver, und ich bereue überhaupt nicht, dass diese damaligen Fähigkeiten verkümmert sind
Irgendwann werden auch Sprachen wie C++ oder Java genauso zu nicht mehr benötigten Fähigkeiten werden
Das logische Denkvermögen, das du beim Umgang mit Opcodes aufgebaut hast, hat das spätere Lernen anderer Sprachen erleichtert
Diese Denkweise beim Umgang mit formalen Sprachen (formal language) ist kognitiv viel tiefer als das Schreiben von LLM-Prompts
während Zusammenarbeit mit AI ein Prozess ist, bei dem man Absichten in mehrdeutiger natürlicher Sprache vermittelt
Wenn man nicht gerade Pseudocode auf Englisch schreibt, geht Präzision verloren
Dazu kommt diesmal auch noch die Angst, ersetzt zu werden
Wenn man sich an drei Muster für den richtigen AI-Einsatz hält, kann man sowohl Produktivität als auch Lernen gewinnen
Folgt man jedoch Anti-Patterns, führt das zu Werkzeugabhängigkeit, Angst, schlechterem Debugging und Sucht nach unmittelbarer Belohnung
Am Ende entsteht ein Teufelskreis kognitiver Verkümmerung
Ich bin vor Kurzem in ein AI-zentriertes Unternehmen eingetreten, in dem manuelles Coden fast tabu ist
Ich ließ Claude die API-Dokumentation lesen und einen Wrapper bauen; das Ergebnis war perfekt
Aber ich selbst habe kein Gefühl und kein Verständnis für die Struktur der API gewonnen
Dieser Zustand, in dem man „viel machen kann, aber nichts wirklich weiß“, fühlt sich unangenehm und leer an
Es baut sich kein reflexartiges Gedächtnis auf. Deshalb konnte ich mich mit dem Text stark identifizieren
Ich arbeite an mehreren von AI geschriebenen Side Projects
Trotzdem ist es ein merkwürdiges Gefühl von „Ich glaube, es ist gut, bin mir aber nicht sicher“
Am Ende kann man selbst mit AI nur dann echte Erfüllung spüren, wenn man eigene Spuren darin hinterlässt
Ich programmiere erst seit acht Monaten, und dank AI habe ich es gelernt
Wenn Claude Code schreibt, verstehe ich aber nur etwa 70 %, und über den Rest gehe ich einfach hinweg
Das Tempo macht süchtig, aber die Fähigkeit, die Gesamtstruktur im Kopf zu behalten, nimmt ab
Trotzdem hätte ich ohne AI meine heutigen Ergebnisse nicht erzielen können, also erkenne ich diesen Trade-off an
Zum Beispiel wird unnötiger Fallback-Code übermäßig verwendet
Ohne Erfahrung merkt man womöglich gar nicht, dass das falsch ist
Das aktuelle Niveau von LLMs liegt ungefähr bei Praktikant bis Junior-Entwickler
Der Engpass ist nicht das Modell, sondern unsere Fähigkeit zur Verifikation
TODO(human)hinterlässt und Erklärungen dazu gibtIch frage mich, ob man für die Automatisierung von Boilerplate wirklich unbedingt ein LLM braucht
Wäre das nicht auch mit klassischem Metaprogramming oder Skripten gut lösbar?
Außerdem kann es auch eine befriedigende Entscheidung sein, AI aus Prinzip abzulehnen
Der Umgang mit Maus und Tastatur, Dateinavigation, das Suchen nach Befehlen — bei den Grundlagen hapert es oft
Deshalb ist die Versuchung groß, einfach zu sagen: „Fragen wir doch einfach das LLM“
Die eigentliche Lösung ist aber bessere Werkzeugbeherrschung und das Erlernen von Template-Engines
Durch AI kann es zwar zu Kompetenzabbau kommen,
aber in Bereichen, auf die ich mich nicht konzentriere, finde ich das in Ordnung
Ich muss zum Beispiel nicht jede interne Optimierung eines Compilers verstehen
Um Interaktionen zwischen Systemen zu verstehen, muss man bis zu einem gewissen Grad auch die Funktionsweise von Compilern kennen
Die Teile, um die man sich nicht kümmern will, überlässt man dem LLM,
und auf die wirklich wichtigen Probleme konzentriert man die eigenen mentalen Ressourcen