Auf Lobsters sammelte ein Beitrag mit dem Tag vibecoding 114 Upvotes und 71 Kommentare. Der Titel lautete schlicht „On AI“ und verlinkte auf einen Artikel bei jcs.org (derzeit nicht erreichbar). Dennoch wurde die Diskussion selbst zum Mittelpunkt einer Debatte über die Zukunft des Software-Engineering.
Ganz oben in den Kommentaren zog der Nutzer tmcb eine treffende Metapher:
„Es ist, als wäre man Sisyphos, aber auf einem Hügel nebenan heben die Leute mit einem Kran Felsen nach oben – mit fragwürdiger Genauigkeit, während ab und zu ein Zuschauer getroffen wird. Man muss sich Sisyphos stinksauer vorstellen.“
Dieser Kommentar erhielt 93 Upvotes, weil er ein Unbehagen traf, das immer mehr Entwickler verspüren: KI-Werkzeuge sind so komfortabel geworden, dass man sich zu fragen beginnt, ob man überhaupt noch etwas lernt.
Dieser Artikel untersucht, was passiert, wenn man die Codegenerierung an eine KI übergibt – und wohin der Prozess des „beiläufigen Lernens“ verschwindet.
Bild: In modernen Entwicklungsumgebungen gehört KI-Codegenerierung zum Standard. Doch hinter dem Produktivitätsgewinn wird der Preis für den Lernerfolg oft übersehen.
Der durch Magie weggewischte Lernschritt
Lobsters-Nutzer duck_tape brachte den Kern der Diskussion in einem Kommentar auf den Punkt, der 38 Upvotes erhielt:
„Worüber wir noch nicht wirklich gesprochen haben: Ein Großteil unseres Lernens passierte beiläufig, als Nebenprodukt der täglichen Arbeit. Beim Implementieren einer beliebigen Funktion oder beim Einrichten der CI für ein neues Build-Ziel konnte man gar nicht anders, als zu lernen. Jetzt können wir diese Schritte wie durch Magie wegwischen. Wir können Ideen direkt ‘erzeugen’. Aber wir können nicht mehr beiläufig lernen. Es ist verdammt schwer, engagiert zu bleiben, während das LLM einen Bug für einen durchkaut.“
„Beiläufiges Lernen“ (incidental learning) ist kein abgelegener Begriff aus der Pädagogik. Es beschreibt die natürlichste Form des menschlichen Lernens: Während man ein bestimmtes Ziel verfolgt, eignet man sich unbeabsichtigt weiteres Wissen an. Das Programmieren beruhte seit jeher auf diesem Prinzip.
Ein Nachwuchsentwickler soll einen Bug im Produktionscode beheben. Sein Ziel ist rein die Fehlerbehebung. Doch auf dem Weg dahin muss er die Architektur der Codebasis verstehen, den Debugger bedienen lernen, begreifen, warum der Fehler nur unter bestimmten Bedingungen auftritt, und ganz nebenbei API-Details verinnerlichen. Er hat diese Dinge nicht „bewusst gelernt“ – das Lernen geschah beiläufig.
Seit dem Start von GitHub Copilot im Jahr 2022 wuchs die Nutzerzahl bis 2025 auf über 20 Millionen. Nach Daten von Microsoft stammen mittlerweile 46 % des von Nutzern geschriebenen Codes aus KI-Generierung (in manchen Java-Projekten bis zu 61 %). Tendenz steigend.
KI bricht diesen Lernkreis auf. Ihr Interaktionsmodell umgeht genau die Schleife des „Learning by Doing“. Man gibt einen Prompt ein, und die KI gibt Code aus.
Wenn diese verpassten Gelegenheiten kumulieren, verschwindet genau jener Lernschritt, der durch die Magie der Automatisierung weggewischt wurde.
Bild: KI-Code-Vervollständigung verändert die Rolle des Entwicklers vom „Schöpfer“ zum „Prüfer“ – Prüfen geht schneller als Schreiben, aber die Lerntiefe nimmt ab.
Warum dies kein „Stack Overflow 2.0“ ist
Ein häufiges Gegenargument lautet: Als Stack Overflow aufkam, hieß es ebenfalls, Entwickler würden das Dokumentationslesen verlernen; als IDE-Auto-Completion erschien, warnte man vor dem Verlust von API-Kenntnissen. Und dennoch ist die Branche nicht zusammengebrochen.
Diese Analogie greift jedoch zu kurz. Der Nutzer bendmorris lieferte dazu eine entscheidende Unterscheidung:
„Natürlich gab es schon immer Entwickler, die durch Kopieren von Stack Overflow durchgekommen sind, ohne wirklich zu verstehen, was sie tun. Im Job-Boom der Nullzinsphase ging das vielleicht gut. Wenn diese Entwickler nun LLMs nutzen, steigt vielleicht ihre durchschnittliche Output-Qualität. Ich glaube aber nicht, dass das Ergebnis hervorragend sein wird – der Mensch trägt dabei kaum noch echten Wert bei.“
Stack Overflow und IDE-Vervollständigung waren Werkzeuge zur Effizienzsteigerung auf Basis bereits vorhandener Wissensstrukturen. Man musste die Suchergebnisse verstehen, um zu beurteilen, welcher Baustein passte; Auto-Completion funktionierte nur, wenn man den Namen der aufzurufenden Funktion bereits wusste. Sie beschleunigten die Ausführung, übersprangen aber nicht das Verstehen.
KI-Codegenerierung überspringt das Verstehen selbst. Man lernt die Logik eines Programms nicht automatisch nur dadurch, dass man ein Ergebnis ansieht – erst recht nicht, wenn dieses Ergebnis aus 30 Zeilen unbekannter Abstraktion besteht.
In der Kognitionspsychologie gibt es dazu zwei klassische Konzepte: die Flüssigkeitsillusion (fluency illusion) und wünschenswerte Erschwernisse (desirable difficulties). Die UCLA-Psychologen Elizabeth und Robert Bjork wiesen bereits in den 1990er Jahren nach: Lernmethoden, die sich mühelos anfühlen, führen zur schwächsten Langzeitnachwirkung. Im Gegensatz dazu sorgen anstrengende Lernwege – wie das aktive Erinnern und eigenständige Problemlösen – für eine weitaus dauerhaftere Verankerung im Gedächtnis.
KI-Coding-Tools bieten maximale Flüssigkeit bei minimaler Anstrengung. Das ist eine bewusste Entscheidung des Produktdesigns – doch der Lerneffekt bleibt dabei auf der Strecke.
Eine randomisierte kontrollierte Studie aus dem Jahr 2025 überprüfte diese Hypothese direkt. Forscher teilten Probanden in zwei Gruppen: Eine benutzte ChatGPT zur Aufgabenbewältigung, die andere traditionelle Methoden. Das Ergebnis: Die KI-unterstützte Gruppe schnitt bei der unmittelbaren Aufgabe besser ab, erzielte jedoch bei einem anschließenden unabhängigen Test deutlich schlechtere Ergebnisse. Dies deckt sich mit der Theorie des „Cognitive Offloading“ (kognitives Auslagern) – ein Gehirn, das Antworten zu mühelos erhält, verzichtet darauf, sie im Gedächtnis zu speichern.
„Ich will weiter lernen, aber nicht nur als Code-Reviewer enden“
Ein weiterer viel beachteter Kommentar (29 Upvotes) stammte von zetashift und beschrieb eine Resignation, die sich in Teilen der Entwicklergemeinschaft breitmacht:
„Sobald ich in einem GitHub-Repository Dateien wie
CLAUDE.mdoderAGENTS.mdsehe, schließe ich den Tab reflexartig. … Wenn ich mit LLMs codiere, empfinde ich keinerlei Bindung zu dem, was ich erschaffen habe. Ich habe nicht das Gefühl, dass die Ergebnisse mir gehören, und verspüre auch kein Bedürfnis, sie zu durchdringen.“
Dies ist kein Einzelfall. Nutzer gered antwortete, dass er sich nach dem Vibe Coding regelrecht „schmutzig“ fühle (dirty). Und Nutzer lake schilderte seine persönliche Erfahrung:
„Ich habe anderthalb Jahre an einem Open-Source-Projekt gearbeitet. Dann sah ich, wie andere mit KI in wenigen Monaten genau dorthin gelangten, wo ich hinwollte. Ich freue mich, dass diese Tools existieren, aber hätte es sie vor meinem Start gegeben, hätte ich das Projekt wohl nie begonnen. Ich sage mir: Es wird Leute geben, die handgeschriebenen Code schätzen. Ich sage mir: Open Source ist kein Wettrennen. Aber zuzusehen, wie andere mit Rückenwind an einem vorbeiziehen, ist definitiv ernüchternd.“
Hinter diesen Emotionen verbirgt sich ein strukturelles Problem. Wenn erfahrene Entwickler – mit 10 oder 20 Jahren Berufserfahrung – KI einsetzen, besitzen sie das Urteilsvermögen, um die Qualität zu bewerten, Halluzinationen zu erkennen und 50 Zeilen generierten Code in 10 Zeilen klare Logik zu refaktorn. Nachwuchsentwicklern fehlt diese Wissensbasis.
bendmorris brachte es scharf auf den Punkt:
„Jemand wie Andreas Kling kann problemlos auf LLMs umsteigen, weil er genügend Fähigkeiten aufgebaut hat, um die Qualität zu sichern. Diese Fähigkeiten schwinden nicht sofort. Aber wie soll die nächste Generation von Programmierern dieses Niveau erreichen, wenn sie von Anfang an LLMs nutzt? Die grundlegenden Arbeiten, die Kompetenz aufbauen, lassen sich am leichtesten automatisieren. Die Branche schießt sich kollektiv ins eigene Bein.“
Der Gegner ist nicht die KI, sondern der entkoppelte Workflow
Hier ist eine sorgfältige Differenzierung nötig. Es geht nicht darum zu behaupten, „KI sei ein schlechtes Werkzeug“ – diese Haltung ist weder zielführend noch sachgerecht. KI-Codierungsassistenten steigern die Produktivität enorm und ermöglichen kleinen Teams Ergebnisse, für die früher das Zehnfache an Personal nötig war. Auch Nicht-Entwickler können nun in natürlicher Sprache Anwendungen bauen. Diese Vorteile sind real.
Die entscheidende Frage lautet: Wenn die Funktionsweise des Werkzeugs die Lernschleife umgeht, wer sorgt dann dafür, dass das Lernen dennoch stattfindet?
Nahezu alle aktuellen KI-Coding-Tools folgen dem Interaktionsmuster Anforderung → Code → Übernahme. Das Ziel des Produkts ist die Erledigung der Aufgabe, nicht das Verständnis des Nutzers.
Das Forschungspapier Agents That Teach: Towards Designing Incidental Learning Back into AI-Assisted Software Development (arXiv:2607.06101) analysierte dieses Phänomen und prägte erstmals den Begriff der „Wissensschulden“ (Knowledge Debt):
Wenn KI-Agenten Codeänderungen vornehmen, die der Entwickler nicht vollständig versteht, summieren sich diese Verständnislücken im Laufe der Zeit. Heute löst die KI einen Bug, den man nicht versteht, morgen generiert sie eine Optimierung. Ein Jahr später läuft das System zwar einwandfrei, aber man kann es nicht mehr wirklich warten – weil man nicht weiß, wie es im Inneren funktioniert.
Wissensschulden sind schwerer zu erkennen als technische Schulden (Technical Debt). Technische Schulden zeigen sich in Metriken und Code-Qualitätsanalysen. Wissensschulden hinterlassen keine Spuren im Repository – sie liegen verborgen in den Köpfen der Entwickler und treten erst zutage, wenn Probleme eigenständig gelöst werden müssen.
Der Preis der ausgelagerten Denkarbeit
Die Frage des Nutzers pyj traf einen praktischen Nerv:
„Mein persönliches Problem mit KI ist, dass ich mir viel weniger merke. Die Aufgabe wird erledigt, aber das Gelernte und Behaltene ist geringer als früher. Gibt es gute Strategien, um beim Einsatz von KI-Tools den Lerneffekt aufrechtzuerhalten?“
Auf diese Frage gibt es bislang kaum tragfähige Antworten. Einige erfahrene Entwickler teilen ihre eigenen Ansätze – etwa das Vorgehen, Claude zunächst einen Prototyp generieren zu lassen und diesen anschließend manuell in eine sauberere Architektur zu überführen. Doch das setzt voraus, dass man bereits weiß, wie eine „saubere Architektur“ aussieht.
Die Debatte auf Lobsters spaltete sich schließlich in zwei Richtungen. Die eine Seite sieht manuelles Codieren als ein digitales Handwerk – vergleichbar mit Holzbearbeitung oder dem Spielen eines Instruments. Man kann Elektrowerkzeuge nutzen oder den Handhobel ansetzen; beides hat seine Berechtigung. Die andere Seite befürchtet, dass in einer Branche, deren Anreizstrukturen voll auf KI-Geschwindigkeit ausgerichtet sind, die Kosten für manuelles Codieren so hoch werden, dass es sich nur noch die Reichsten oder hartnäckigsten Idealisten leisten können.
Beide Sichtweisen enthalten Wahrheit, umgehen jedoch die Kernfrage: Wenn der Weg des „beiläufigen Lernens“ versperrt ist, wie viele Umwege muss die nächste Generation von Entwicklern gehen, um jene Kompetenz zu erreichen, die sich früher ganz beiläufig einstellte?
Niemand in der Diskussion hatte darauf eine fertige Antwort. Aber das Aufwerfen dieser Frage selbst besitzt bereits mehr Wert als die meisten PR-Versprechungen der KI-Industrie.
Referenzen:
- Lobsters: On AI (114△, 71 comments) (item?id=zljfgp/on_ai)
- Joshua Stein: On AI (jcs.org)
- Hacker News: On AI discussion
- Bjork & Bjork (2011): Desirable Difficulties in Theory and Practice
- Anthropic: ChatGPT as a Cognitive Crutch
- arXiv 2607.06101: Agents That Teach
- Bjork (1994): Memory and Metamemory Considerations in the Training of Human Beings
- GitHub Research: Quantifying GitHub Copilot’s Impact on Developer Productivity and Happiness
