Blog
KI: So entkommen wir dem Dunning-Kruger-Effekt
Wer heute mit dem Programmieren beginnt, kommt kaum noch um sie herum: ChatGPT, Claude Code und Co. liefern als generative KI-Tools mit nur wenigen Prompts lauffähige Software direkt aus dem Stand. Natürlich erleben Junior-Entwickler:innen und Auszubildende dabei einen zwar trügerischen, aber mächtigen Glücksmoment: „Es funktioniert!“. Und das binnen Sekunden, ohne Vorkenntnisse, endloses Debugging und ohne mühseliges Stack-Overflow-Recherchieren. Das ist natürlich erstmal ein Adrenalinkick fürs Ego und, im positiven Sinne, guter Treibstoff für Neugier, Ehrgeiz und Motivation.
Was wie eine Revolution für Produktivität und Effizienz klingt, birgt jedoch erheblichen Sprengstoff fürs eigene Kompetenzgefühl und die tatsächliche Codequalität.
Vorweg zur Klarstellung: Dieser Blogartikel will mitnichten von der Nutzung solcher KI-Tools abraten, im Gegenteil. Vielmehr will er zur verantwortungsvollen und nachhaltigen Nutzung von KI auffordern, einer Technologie immerhin, die unsere Arbeit und unser Leben in den kommenden Jahren maßgeblich umkrempeln und prägen wird. Dazu gehen wir vor allem unseren eigenen Erfahrungen nach und dem Lernprozess, den wir im Umgang mit neuen KI-Tools durchlaufen haben.
Der Dunning-Kruger-Effekt
Den psychologischen Rahmen für den oben beschriebenen KI-Kick liefert der Dunning-Kruger-Effekt (DKE). Er beschreibt ein verbreitetes menschliches Muster: Wer (noch) wenig kann, überschätzt sich besonders stark. Der DKE spricht hier vom „Mount Stupid“, also dem Gipfel des Selbstbewusstseins, den gerade Einsteiger:innen schnell erklimmen und ebenso schnell wieder verlassen, wenn sie ins „Tal der Verzweiflung“ hinabstürzen. Während am Anfang noch Demut geherrscht hat („Ich weiß, dass ich nichts weiß“), folgt auf den ersten Erfolg (“So einfach geht das?!”) schnell illusorischer Übermut („Ich hab’s drauf!“). Wenn das Umfeld dann mit einem Realitätsabgleich zurückschlägt, bleibt eine schmerzhafte Kurskorrektur unausweichlich.
Vom Höhenflug ins Tal der Tränen
Die berühmte Kurve des Dunning-Kruger-Effekts verläuft steil: Anfangs wächst das Selbstvertrauen mit jeder kleinen Erkenntnis rasant. Der Mount Stupid ist so schnell erreicht. Je komplexer dann die Aufgaben werden, desto deutlicher werden die eigenen Wissenslücken. Das Selbstbewusstsein stürzt auf einen Tiefpunkt. Erst mit echter Übung und Erfahrung, durch intensive Auseinandersetzung und kontinuierliches Lernen steigt die Lernkurve langsam aber stetig wieder an. Nur wer langfristig dranbleibt, findet schlussendlich zu einer realistischeren, geerdeten Selbstwahrnehmung zurück und schreibt besseren, wartbaren und sicheren Code.
Wenn „Läuft“ schon ausreicht
In der Welt von heute entfaltet die DK-Kurve eine neue Dynamik. KI-Tools geben Einsteiger:innen die Macht, Code bzw. ganze Anwendungen in Sekunden zu erzeugen. Das passt gewissermaßen in unsere Zeit, in der jede:r alles sein will und gefühlt auch alles sein kann, wo der “schöne Schein” schon ausreicht, um zu überzeugen und erfolgreich zu sein. In der Welt der Softwareentwicklung können die Folgen eines so gesunkenen Anspruchs indes verheerend sein: Das Verständnis des Codes bleibt auf der Strecke und mit ihm die Codequalität, Wartbarkeit und Sicherheit von Software.
Die Verlockung ist natürlich groß: Wenn der Code läuft, genügt das schon als Qualitätsmerkmal. Doch was entsteht, sind oft toxische Codebasen: Lösungen, die in einfachen Tests bestehen, aber bei Sicherheitsanforderungen, Performancespitzen oder Wartungsaufgaben versagen. Tiefergehende Fragen zu Architektur, Testbarkeit oder Fehlerfällen werden schlicht ausgeblendet, indem sie gar nicht erst gestellt werden.
Willkommen im Code-Chaos
Die Gefahr heißt Blindes Vertrauen. Code-Reviews werden übersprungen, weil „die KI hat’s doch geschrieben, die weiß schon was sie tut“. Vermeintlich perfekte KI-Snippets werden ungeprüft direkt in die Codebasis übernommen, niemand fühlt sich mehr richtig verantwortlich, weil kein Mensch die Codezeilen mehr wirklich versteht, sie Schritt für Schritt durchdacht, erklärt oder auf Edge Cases getestet hat. Kritische Schwachstellen schleichen sich auf diese Weise ebenso unbemerkt ein wie ineffiziente Umsetzungen oder auch Compliance-Verstöße. Nicht selten wächst der technische Schuldenberg so ähnlich rasant in die Höhe wie der “Mount Stupid” selbst. Denn wer den Code nicht in all seinen Kausalitäten durchdringt, kann ihn auch schwer hinter sich aufräumen.
Unknown unknows oder die Illusion der Allmacht
Besonders gefährdet sind, wie gesagt, Einsteiger:innen. Der schnelle Erfolg mit KI fühlt sich schließlich so an, als habe man schon auf Level 1 den Endboss besiegt. Doch viele wissen so früh einfach noch nicht, welche Fragen sie stellen müssten und welche Risiken im Code lauern. Gemeint sind die berüchtigten „unknown unknowns“, von fehlendem Passwort-Hashing bis zu unsauberen DB-Abfragen. Häufig werden Grundlagen wie Sicherheit, Lesbarkeit oder Performance aus Unwissenheit übergangen.
Die böse Überraschung folgt …
Spätestens beim ersten echten Produktionsproblem erfolgt ein schmerzhaftes Erwachen: Plötzlich ist alle Euphorie verflogen, die eigenen Defizite treten zutage. Wartung, Skalierung oder ein harmloser Bug können jetzt zum Kryptonit für jede:n selbsternannten Codingexpert:in werden. Oder auch für das gesamte Team.
Denn ohne Codeverständnis und Dokumentation sind Fehleranalyse und Weiterentwicklung schnell ein Himmelfahrtskommando. Spätestens jetzt wird klar, wie hilfreich Code Reviews, Refactoring des KI Codes oder eine technische Dokumentation gewesen wären.
„Cognitive Debt“ (und ihre Grenzen)
Die Warnung vor einer solchen „KI-gestützten Inkompetenz“ basierte bisher auf Beobachtung. Jetzt liefert eine aktuelle Studie des MIT Media Lab (2025) erste neurobiologische Hinweise auf ihre nachweisliche Existenz. Mittels EEG verglichen die Forscher die Hirnaktivität beim Schreiben ohne KI, beim Schreiben mit KI-Unterstützung und beim fast vollständigen Übernehmen von KI generierten Texten. “Schreiben” kann hier äquivalent zu “Coden” verstanden werden.
Das Ergebnis: Wer die KI denken lässt, schaltet sein Gehirn in den „Sparmodus“.
- Hirnaktivität: Die Gruppe, die ohne KI arbeitete, zeigte starke neuronale Vernetzungen (Alpha-, Theta-Wellen), ein Zeichen für tiefes Verstehen und Gedächtnisbildung. Bei der Gruppe, die alles der KI überließ, brachen diese Netzwerke signifikant ein.
- Verlust der „Ownership“: Besonders alarmierend war, dass 83 % der letzten Gruppe kurz nach der Erstellung keine korrekten Zitate aus ihrem „eigenen“ Text wiedergeben konnten. Das Gehirn hatte den Inhalt schlicht nicht gespeichert bzw. gelernt.
- Cognitive Debt: Die Studie warnt darum vor einer „kognitiven Schuld“: Wer das Denken auslagert, zahlt später mit einem Verlust an Fähigkeiten, wenn die KI plötzlich nicht mehr zur Verfügung steht.
Disclaimer
So eindrücklich diese Ergebnisse sind, müssen wir sie kritisch betrachten. Die Studie ist mit 54 Teilnehmenden relativ klein und beschränkt sich geographisch auf Studierende aus dem Großraum Boston (MIT, Harvard etc.). Sie ist also (noch) nicht repräsentativ für die weltweite Bevölkerung. Dennoch liefert sie ein starkes Indiz dafür, dass der „Mount Stupid“ nicht nur psychologisch, sondern auch neurologisch messbar ist: Wir fühlen uns produktiver, sind aber kognitiv passiver.
So geht KI richtig: Vom Passagier zum Piloten
Wie also bewahren wir unsere Leute vor dem „Gipfel der Selbstüberschätzung“? Und wie verhindern wir, dass aus der kurzfristigen „Illusion der Allmacht“ eine dauerhafte Inkompetenz wird? Die Antwort liegt nicht in strengeren Regeln, sondern in einer grundlegend neuen Arbeitsweise.
1. Dual Burden: Den doppelblinden Fleck verstehen
Es gilt wie so oft: Erkenntnis ist der erste Weg zur Besserung.
Zuerst müssen wir begreifen, warum uns die Selbstkorrektur mit KI so schwerfällt. Es ist selten Arroganz. Die Psychologie beschreibt hier eine „doppelte Last“ (Dual Burden): Wenn wir neu in einem Thema sind, überschätzen wir unser Können massiv. Gleichzeitig fehlt uns genau jenes Wissen, um überhaupt zu erkennen, dass wir falsch liegen – wir wissen schließlich nicht, was wir nicht wissen.
Früher scheiterten wir am Compiler, der Fehler war damit offensichtlich. Mit KI läuft der Code heute sofort. Oft fehlt das nötige Tiefenwissen, um zwischen einer funktionierenden und einer wirklich guten Lösung zu unterscheiden.
Es ist, als würden wir versuchen, einen teuren Whisky von einem billigen zu unterscheiden, ohne je Whisky getrunken zu haben – wir können den Qualitätsunterschied schlicht nicht schmecken.
2. „Metacognitive Premium“: Das neue Kompetenzprofil
Das bedeutet für unseren Alltag: Die wichtigste Fähigkeit ist für uns heute nicht mehr nur das Schreiben von Code, sondern das Bewerten von Code. Wir nennen dies „Metacognitive Premium“: also die Fähigkeit, das eigene Denken und die Ergebnisse der KI kritisch zu hinterfragen.
Wir müssen lernen, Code zu reviewen, den wir unter Umständen sogar selbst noch gar nicht schreiben können. Unser Ziel verschiebt sich also: Weg vom reinen „Code-Produzenten“, hin zum „Redakteur“, der die volle Verantwortung für die Prüfung der Quellen übernimmt.
Leseempfehlung: Blogbeitrag Vom reinen Coden zum Mitdenken von Tung Ngo
3. Vorsicht falsche Imitation: Intuition ist nicht Raten
Hier lauert eine Falle, in die wir alle tappen können: Wir verwechseln Geschwindigkeit mit Kompetenz. Erfahrene Entwickler:innen lösen Probleme oft intuitiv, ohne in die Dokumentation zu schauen. Sie haben bereits das Stadium der „Unbewussten Kompetenz“ erreicht: Ihr Wissen ist so tief verinnerlicht, dass sie es mühelos abrufen können.
Einsteiger:innen sind noch lange nicht an diesem Punkt. Das Risiko entsteht, wenn sie versuchen, dieses Verhalten von Fortgeschrittenen mithilfe der KI zu imitieren. Eine Milchmädchenrechnung, denn:
- Die Intuition von Expert:innen basiert auf tausenden gelösten Problemen und dem Wissen, wie eine Antwort solide validiert wird.
- Die KI-Antwort der Einsteiger:innen ist demgegenüber ein reines Raten („Lass uns probieren, ob das geht“), ohne die Basis zu verstehen
Folglich müssen wir uns disziplinieren: KI-Tempo ersetzt kein Verständnis! Wir dürfen erst dann aufhören nachzuschlagen, wenn wir erklären können, warum der Code funktioniert.
4. Die Lösung Ein „Coaching-Pakt“ für das Team
Den Dunning-Kruger-Effekt können wir selten allein überwinden, da unsere Selbsteinschätzung oft trügt. Studien zeigen, dass nur 10 bis 15 % der Menschen wirklich selbstreflektiert sind. Darum wollen wir das „Ich“ durch ein „Wir“ ersetzen und folgenden Pakt schließen:
- “Loud Coding” Wir arbeiten transparent: Wir müssen aufhören, unser Wissen oder Nichtwissen zu verstecken. Wenn wir Code schreiben oder reviewen, müssen wir unsere Gedanken mitteilen. Statt still etwas zu entscheiden, machen wir unsere Entscheidungen transparent: „Die KI schlägt hier X vor, aber das könnte in unserer Architektur zu Problemen führen. Stattdessen entscheiden wir uns für Y“ So machen wir den Bewertungsprozess für alle sichtbar.
- Wir führen die KI, statt ihr zu folgen: Wir behandeln die KI wie einen fleißigen, aber unzuverlässigen Praktikanten. Unsere Aufgabe ist es nicht, seinen Code blind zu übernehmen, sondern ihn zu „coachen“. Ein Commit erfolgt erst, wenn wir jede Zeile erklären können. Auf dem Flug mit KI sind wir nicht die Passagiere, wir sind Piloten.
- Wir schaffen”Psychological Safety”: Der Weg durchs „Tal der Verzweiflung“ ist schmerzhaft. Wir leben zum Glück eine Kultur der psychischen Sicherheit, in der der Satz „Ich weiß nicht, ob dieser KI-Code sicher ist“ keine Schwäche, sondern eine Stärke ist. Auch Fehler werden bei Micromata nicht als Peinlichkeit oder Makel behandelt, sondern als willkommene Gelegenheiten, dazuzulernen. Gut, dass diese gelebte Praxis dazu führt, dass wir Fehler oder Unwissen ohne Angst zugeben können, weil das übliche Finger Pointing oder Blame Game nicht stattfindet. Ohne diese Sicherheit würden vielleicht auch wir Gefahr laufen, Kompetenzen vorzutäuschen, um unseren Status zu wahren („Fake it till you make it“). Wohin das führt, kann sich jede:r leicht ausmalen, toxischer Code ist nur eine Folge von vielen.
Leseempfehlung: Blogbeitrag Gutes Teamwork dank Psychological Safety von Eva Nenninger
5. Wir haben niemals ausgelernt
Wenn wir ehrlich zu uns sind, müssen wir unser Berufsbild neu definieren. Viele glauben noch immer, das Ziel sei es, Expertenwissen anzuhäufen, bis man irgendwann „ausgelernt“ hat. Der Dunning-Kruger-Effekt zeigt jedoch: Genau dieser Glaube, den Gipfel überhaupt erreichen zu können, ist schon der Anfang vom Abstieg.
Zumal die Realität in unserer VUCA-Welt (volatil, unsicher, komplex, mehrdeutig) kein Ausruhen auf vermeintlichen Lorbeeren duldet:
- Technologisch: Heute ist es ein neues Framework, morgen eine neue Cloud-Architektur, übermorgen ein völlig neuer Business Case, den es zu ergründen und zu verstehen gilt.
- Fachlich: Wir lernen ja nicht nur Technik. Mit jedem neuen Projekt und jedem neuen Kunden müssen wir uns in eine neue, spezifische Fachdomäne hineindenken, sei es Logistik, Finanzen oder E-Commerce. Wer hier nicht zu lernen bereit ist, baut technisch perfekten Code, der dann aber am individuellen Kundenbedarf vorbeigeht.
Das bedeutet: Der IT-Beruf ist im Kern ein Lernberuf. Wir sind keine „Wissensbesitzer“, wir sind professionelle „Wissensverarbeiter“. Wahre Seniorität zeigt sich nicht darin, dass wir keine Fragen mehr haben, sondern darin, dass wir – wie im Diagramm des „Slope of Enlightenment“ zu sehen – die Grenzen unseres Wissens akzeptieren und lernen, bessere Fragen zu stellen.
Der Ausweg aus der Kurve der Selbstüberschätzung ist die Akzeptanz, dass wir uns auf einem ewigen Pfad befinden. In diesem Fall stimmt es also: Der Weg ist das Ziel. Unser mentaler Proviant:
- Lernen statt Wissen: Wir müssen uns daran gewöhnen, dass unser Wissen von heute morgen veraltet sein kann. Das ist kein Scheitern, das ist der Job.
- Verstehen statt Abkürzen: KI verleitet dazu, das Lernen zu überspringen („Code läuft ja“). Aber in einer komplexen Welt bleibt es wichtig, Zusammenhänge, Wechselwirkungen und Strukturen zu verstehen, um Risiken für unsere Kunden und unsere Systeme zu vermeiden.
6. Unsere Haltung: Keine Illusionen!
Lassen wir uns von der KI helfen, schneller zu coden, aber lassen wir uns von ihr niemals in Versuchung führen, das Denken einzustellen. Wenn wir akzeptieren, dass wir jeden Tag neu lernen müssen – neue Technik, neue Kundenanforderungen, neue Prozesse –, dann verliert der „Mount Stupid“ seinen Schrecken. Wir werden immun gegen die Illusion der Allmacht, weil wir wissen: Der einzige Fehler ist nicht das Nicht-Wissen, sondern das Nicht-mehr-lernen-Wollen.
Fazit
Technische Toxizität entsteht aus Missverständnissen, nicht aus KI. KI kann das Entwicklungstempo erhöhen und ist ein mächtiges Werkzeug. Doch ohne solide Grundlagen, kritische Reviews und Verantwortung jedes Einzelnen wird sie zum Sherpa auf unserer ganz persönlichen Mount-Stupid-Tour, mit massivem technischem Schuldenaufbau und erhöhter Fehleranfälligkeit als Preis. Die Devise bleibt: KI ist ein Tool, kein Freibrief. Nur wer sich seiner eigenen Unkenntnis bewusst bleibt, kann die Talsohle produktiv durchschreiten und nachhaltig gute Software liefern.
