KI-Imposter-Syndrom: Warum dein Gefühl vielleicht recht hat

Wenn du dich in letzter Zeit wie ein Hochstapler fühlst, weil die KI den Code geschrieben hat, dann hab ich eine unangenehme Nachricht: Das ist wahrscheinlich kein Imposter-Syndrom. Es könnte einfach stimmen.

Klingt gemein. Ist aber die bessere von beiden Nachrichten. Ein Syndrom kann man dir nur wegreden. Ein Messergebnis kannst du benutzen.

Mir fällt in letzter Zeit auf, wie viele Leute dieses Gefühl mit sich rumtragen, und zwar Leute, die unterschiedlicher nicht sein könnten. Ich arbeite selbst jeden Tag mit Claude Code, das hier wird also kein Anti-KI-Artikel. Es geht um etwas, das mir dabei aufgefallen ist und das ich für die eigentlich interessante Nebenwirkung halte.

Wir schauen uns zuerst an, was der Begriff eigentlich bedeutet und warum er auf die halbe Situation nicht mehr passt. Dann, warum es gerade so viele trifft. Danach die Trennung, die im Moment kaum jemand macht, und zum Schluss die 60 Sekunden, mit denen ich bei mir selbst nachschaue.

Video zum Artikel: Das Thema gibt es auch als Video, mit denselben Beispielen zum Anhören. Auf YouTube ansehen →

Zwei Entwickler, ein Gefühl, entgegengesetzte Gründe

Der eine ist 2 Jahre dabei und denkt: Ich hab das nie richtig gelernt. Die KI kann das, ich tippe Enter und nicke. Wenn das Ding morgen weg ist, stehe ich da wie am ersten Tag, und dann merken es alle.

Der andere sitzt 2 Tische weiter, macht das seit 15 Jahren und denkt das genaue Gegenteil. Ich hab das alles mal richtig gelernt. Und es interessiert gerade keinen mehr. Ein Modell macht in ein paar Minuten, wofür ich mir Jahre erarbeitet habe. Wofür war das jetzt gut?

Zwei Leute, entgegengesetzte Gründe, dasselbe Gefühl. Und beide sagen nichts, weil beide denken, sie wären der Einzige damit.

Wenn zwei so verschiedene Leute am selben Punkt landen, dann liegt es meistens nicht an den Leuten.

Was Imposter-Syndrom eigentlich bedeutet

Der Begriff kommt aus einer Arbeit von Pauline Rose Clance und Suzanne Imes von 1978, erschienen in Psychotherapy: Theory, Research and Practice, Band 15, Heft 3. Die beiden beschreiben darin etwas sehr Bestimmtes, und dieses Bestimmte ist wichtiger, als es klingt.

Sie beobachteten Frauen mit ausgezeichneten akademischen und beruflichen Leistungen, die trotzdem überzeugt waren, nicht wirklich klug zu sein und alle anderen getäuscht zu haben. Der Satz, auf den es ankommt, steht schon in der Zusammenfassung:

“Numerous achievements, which one might expect to provide ample object evidence of superior intellectual functioning, do not appear to affect the impostor belief.”

Auf Deutsch: Zahlreiche Erfolge, von denen man annehmen würde, dass sie reichlich Beleg für herausragende geistige Leistungsfähigkeit liefern, scheinen den Hochstapler-Glauben nicht zu berühren.

Das Phänomen ist also über eine Lücke definiert: zwischen dem, was du nachweislich kannst, und dem, was du über dich glaubst. Du kannst die Sache. Du hast sie schon 20 Mal gemacht, es steht in deinem Lebenslauf, deine Kollegen fragen dich, wenn sie nicht weiterkommen. Und trotzdem sitzt da dieses Gefühl, dass du gleich auffliegst.

Das Entscheidende daran: Das Gefühl liegt daneben. Es ist ein Irrtum über dich selbst. Nicht “mir geht es gerade schlecht bei der Arbeit”, sondern “ich halte mich für schlechter, als ich nachweislich bin”.

Zwei Fußnoten, die das Bild abrunden. Erstens steht in der ganzen Arbeit kein einziges Mal das Wort “Syndrome”. Clance und Imes schreiben durchgehend vom impostor phenomenon. Zweitens hat Clance später gesagt, sie würde es heute anders nennen. In Amy Cuddys Buch “Presence” wird sie so zitiert: “If I could do it all over again, I would call it the impostor experience, because it’s not a syndrome or a complex or a mental illness, it’s something almost everyone experiences.”

Aus dem Phänomen ist im Alltagsgebrauch ein Syndrom geworden, und aus einem beschriebenen Irrtum eine Diagnose. Und da hab ich mich irgendwann gefragt: Passt das überhaupt auf das, was wir gerade fühlen?

Kein Syndrom. Ein Messergebnis.

Du hast gestern was ausgeliefert. Es läuft. Du weißt nicht genau, warum es läuft. Wenn dich morgen einer fragt, warum die Funktion so aussieht und nicht anders, kommt nichts.

Wo ist da der Irrtum? Da ist keiner. Da ist ein Gefühl, das ziemlich genau weiß, wovon es redet.

Das ist kein Imposter-Syndrom. Das ist ein Messergebnis. Und ein Messergebnis sagt nichts darüber, was du wert bist. Es sagt nur, wo du gerade stehst.

Genau daran hängt der praktische Unterschied. Ein Syndrom sitzt in dir, da kann man dir nur gut zureden. Ein Messergebnis zeigt auf etwas, und dann kann man da nachschauen.

Der Dienstag im Review

Du kennst den Moment, in dem das auffliegt. Er ist selten dramatisch. Meistens ist es ein ganz normaler Dienstag.

Guter Punkt, ich schau mir das nochmal an

Jemand hängt einen Kommentar an eine Zeile und fragt: Warum machst du das hier eigentlich so? Völlig freundlich gemeint, reine Neugier.

Und du scrollst durch deinen eigenen Pull Request wie ein Tourist. Du liest deinen eigenen Code und suchst die Antwort da drin, als hätte den jemand anders geschrieben. Ist ja auch so.

Dann tippst du irgendwas mit “guter Punkt, ich schau mir das nochmal an”. Übersetzt heißt das: Ich weiß es nicht. Ich hab es nur bis eben selbst nicht gemerkt.

Dabei ist gar nichts Schlimmes passiert, und das ist das Perfide daran. Es gab keinen Moment, in dem du beschlossen hast, das nicht zu verstehen. So einen Moment gibt es nie. Es kam ein Vorschlag, sah gut aus, Enter. Es kam der nächste, passt, Enter. Beim dritten hast du kurz drübergeschaut, sah plausibel aus, Enter. Tests grün. Fertig.

Und fertig ist ein verdammt gutes Gefühl. Da hat niemand geschlampt. Du warst nicht faul. Es hat dich nur keiner gefragt.

Vom Autor zum Zeugen

Wenn du drauf achtest, hörst du es sogar. Mir fällt gerade auf, wie Leute über ihre eigene Arbeit reden, ich eingeschlossen.

Früher hieß es: Ich hab das gebaut. Heute höre ich immer öfter: Das ist so rausgekommen. Oder: Das hat er mir so hingelegt.

Kleiner Unterschied im Satz. Großer Unterschied dahinter. Im ersten Satz steht ein Autor. Im zweiten steht ein Zeuge.

Der Nichtangriffspakt

Ich hab außerdem den Verdacht, dass in manchen Teams gerade eine stille Absprache entsteht. Keiner fragt mehr genau nach. Nicht aus Faulheit, sondern weil jeder ahnt, dass die Frage zurückkommt.

Wenn ich dich frage, warum dein Code so aussieht, dann fragst du mich morgen, warum meiner so aussieht. Und dann stehen wir beide da. Also winkt man sich lieber gegenseitig durch.

Zwei Leute, die sich stillschweigend einig sind, dass nicht nachgefragt wird: Das ist kein Review. Das ist ein Nichtangriffspakt.

Und dann gibt es diese eine Stelle im Projekt, um die alle einen Bogen machen. Läuft seit Monaten. Fasst keiner an. Wenn du ehrlich bist, hoffst du still, dass dafür nie ein Ticket aufgemacht wird. Sowas gab es immer, in jedem Projekt eine oder zwei. Ich hab nur den Eindruck, dass es gerade mehr werden, und dass sie schneller entstehen als früher.

Warum es gerade so viele trifft

Das Gefühl selbst ist nicht neu. Neu ist, wie leicht man da reinrutscht.

Verstehen war früher gratis. Nicht weil wir fleißiger waren oder disziplinierter, sondern weil es keinen Weg daran vorbei gab.

Wenn du früher 3 Stunden an einem Bug gesessen hast, hattest du am Ende nicht nur den Bug gefixt. Du hattest nebenbei verstanden, wie der Kram funktioniert. Nicht weil du lernen wolltest, sondern weil du da sonst nicht rausgekommen wärst. Das Verstehen war der Lohn fürs Durchhalten. Versprochen hatte ihn dir keiner. Du hast ihn trotzdem gekriegt.

Und deshalb sitzt das Zeug von damals bis heute. Was du dir mühsam erkämpft hast, vergisst du nicht mehr. Was dir jemand fertig hinlegt, ist am nächsten Tag weg. Das ist keine Moral von wegen früher war alles besser. So funktionieren Köpfe nun mal.

Jetzt ist der Kampf weg. Das ist erstmal großartig, und ich vermisse ihn kein bisschen. Ich hab in meinem Leben genug Abende an Dingen verloren, die heute in 2 Minuten erledigt sind. Nur: Mit dem Kampf ist auch der Lohn weg. Und ersetzt hat ihn keiner.

Früher konntest du nicht liefern, ohne zu verstehen. Das ging technisch nicht. Deshalb war “es läuft, also kann ich es” jahrzehntelang ein völlig vernünftiger Satz. Er war sogar wahr. Heute ist er es nicht mehr, und niemand hat uns Bescheid gesagt.

Zwei Gruppen, eine Antwort, ein Problem

Damit sind wir beim Kern. Es gibt zwei Gruppen, die gerade dasselbe fühlen, und im Moment trennt sie kaum jemand.

Gruppe A: Das Gefühl liegt daneben

Du verstehst den Code. Du hättest ihn auch selbst schreiben können, es hätte nur länger gedauert. Die KI hat getippt, gedacht hast du. Und trotzdem fühlst du dich wie ein Betrüger, weil es sich zu leicht angefühlt hat.

Das ist das echte Imposter-Phänomen, genau so, wie Clance und Imes es beschrieben haben: die Lücke zwischen belegter Kompetenz und falschem Gefühl. Dein Gefühl liegt daneben. Da hilft Zuspruch wirklich, und ich würde ihn an deiner Stelle annehmen.

Gruppe B: Das Gefühl hat recht

Du kannst nicht erklären, was du ausgeliefert hast. Nicht weil du dumm bist, sondern weil dich nie jemand in die Lage gebracht hat, es erklären zu müssen. Es lief ja.

Dein Gefühl ist hier kein Irrtum. Es hat einfach recht. Unangenehm, ja. Aber ich finde, das ist was anderes als: Mit dir stimmt was nicht.

Warum derselbe Satz einmal Medizin und einmal Gift ist

Zwei Gruppen, gegensätzliche Lage, dasselbe Gefühl. Und jetzt rate mal, wie viele verschiedene Antworten es da draußen für diese beiden Gruppen gibt.

Eine. Du gehörst hier hin. Alle benutzen KI. Sei nicht so streng mit dir. Du bist gut genug.

Für Gruppe A ist das Medizin. Die Leute quälen sich ohne Grund, und irgendjemand sollte ihnen mal sagen, dass sie ihre Sache gut machen.

Für Gruppe B ist derselbe Satz Gift. Da schaltet jemand freundlich lächelnd den einzigen Alarm ab, der noch funktioniert hat. Das Gefühl war das Einzige im Raum, das gemerkt hat, dass da was nicht stimmt. Und statt hinzuhören, kriegt es ein Beruhigungsmittel und ein Schulterklopfen.

Aber es läuft doch, und die Tests sind grün

Jetzt sagst du vielleicht: Moment mal. Wenn das Ding läuft und die Tests grün sind, warum ist es dann überhaupt wichtig, ob ich es erklären kann? Das Ergebnis zählt.

Und weißt du was? Für heute hast du völlig recht.

Das Problem ist: Läuft heißt nur, dass es einmal genau das getan hat, was du gesehen hast. Es heißt nicht, dass du weißt, was es am Montag mit echten Daten tut. Oder um 3 Uhr nachts unter Last. Oder wenn jemand die Zeile daneben ändert. Und es heißt schon gar nicht, dass es sicher ist: Wie oft KI-generierter Code an genau dieser Stelle Lücken hinterlässt, habe ich mir im Artikel zu Vibe Coding Security genauer angesehen.

Bis dahin ist alles ruhig. Und dann kommt der Moment, in dem jemand nachfragt. Meistens du selbst, ein halbes Jahr später, um 23 Uhr.

Da wird es richtig ungemütlich, weil du jetzt Code debuggst, den du nie geschrieben hast. Ohne das Bild im Kopf, das sonst beim Schreiben ganz von allein entsteht. Früher hattest du beim Suchen immer einen Vorteil: Du wusstest wenigstens, was du dir dabei gedacht hattest. Selbst wenn es Blödsinn war, war es dein Blödsinn, und du wusstest, wo du anfängst.

Der Vorteil ist weg. Du sitzt in deinem eigenen Projekt und bist der Neue.

Wo deine Grenze verläuft

Wenn du meine Artikel kennst, weißt du, dass jetzt der Teil kommt, in dem ich meine eigene Überschrift relativiere.

Ich könnte hier so tun, als müsstest du jede Zeile verstehen, die durch dein Repo läuft. Mach ich nicht, weil es Unsinn wäre. Kein Mensch versteht seinen ganzen Stack. Ich weiß nicht im Detail, was mein Compiler beim Optimieren anstellt. Ich hab den TCP-Stack nicht gelesen. Ich benutze Bibliotheken, in die ich nie reingeschaut habe, und das jeden Tag. Wir bauen alle auf Zeug, das wir nicht durchdringen. Das ist kein Versagen, das ist der ganze Trick an Software.

Der Unterschied ist nicht, ob du alles verstehst. Der Unterschied ist, ob du weißt, wo deine Grenze verläuft.

Bei einer Bibliothek weiß ich das. Ich weiß, was sie verspricht, ich weiß ungefähr, wo sie aufhört, und ich weiß, wo ich nachschlage, wenn es klemmt. Die Grenze ist markiert. Jemand hat sie hingeschrieben.

Beim KI-Code weißt du oft nicht mal, dass da eine Grenze ist. Der Code sieht aus wie deiner. Er liegt in deinem Repo. Er hat deinen Namen im Commit. Nichts an ihm sagt dir: Ab hier hat niemand nachgedacht.

Eine Abstraktion, die du kennst, ist ein Werkzeug. Eine Abstraktion, die du für deinen eigenen Code hältst, ist eine Falle.

An dieser Stelle muss ich ehrlich sein, sonst schreibe ich hier über dich statt über uns. Ich kenne die zweite Variante von diesem Gefühl ziemlich gut. Die von dem Kollegen, der schon länger dabei ist.

Es gab diesen Moment, da hab ich einer KI bei einer Sache zugeschaut, für die ich früher 2 Tage gebraucht hätte. Sie war in ein paar Minuten durch. Und mein erster Gedanke war nicht: stark. Mein erster Gedanke war: Und wofür habe ich das eigentlich alles gelernt? Das ist ein mieses, kleinliches Gefühl, und es ist mir unangenehm, das hier zu schreiben. Aber es war da.

Dann hab ich gemerkt, wo mein Denkfehler steckt. Ich hatte meinen Wert die ganze Zeit an der falschen Stelle gemessen. Ich hab ihn daran gemessen, dass ich es tippen kann. Getippt hat es jetzt jemand anders, und zwar schneller. Was danach übrig blieb, war die Frage, ob das Ding am Ende gut ist. Und die konnte ich beantworten. Die KI konnte es nicht.

Mehr Trost hab ich nicht anzubieten. Ich finde ihn trotzdem ziemlich gut. Die Jahre sind nicht weg. Sie sind umgezogen. Nicht mehr ins Schreiben, ins Beurteilen. Und Beurteilen ist genau die Sache, die gerade knapp wird, während Schreiben im Sekundentakt aus der Steckdose kommt. Wie sich die Rolle dabei insgesamt verschiebt, habe ich in KI in der Softwareentwicklung ausführlicher aufgeschrieben.

Der Erklär-Test: 60 Sekunden, kein Werkzeug

Für mich geht es deshalb nicht um Vollständigkeit, sondern darum, ob ich weiß, was ich nicht weiß. Dafür hab ich mir irgendwann was angewöhnt.

Ich nehm die letzte Sache, die die KI für mich gebaut hat. Der Code bleibt zu. Und dann erklär ich laut, was das Ding tut und warum es so gebaut ist und nicht anders. Keinem Menschen, der Wand reicht. Ich weiß, wie das aussieht. Es funktioniert trotzdem.

So läuft das bei mir ab:

1. Ich schließe den Editor. Nicht wegklicken, wirklich zu. Solange der Code sichtbar ist, lese ich ihn vor, statt ihn zu erklären. Das fühlt sich gleich an und ist es nicht.
2. Ich sage, was das Ding tut. Ein Satz, in der Sprache des Problems, nicht in der des Codes. Also nicht “die Funktion mappt über das Array”, sondern “sie sortiert offene Rechnungen nach Fälligkeit”.
3. Ich sage, warum es so gebaut ist und nicht anders. Das ist die eigentliche Frage. Da zeigt sich, ob eine Entscheidung getroffen wurde oder ob einfach etwas rausgekommen ist.
4. Ich beantworte eine Was-wäre-wenn-Frage. Was passiert, wenn die Liste leer ist? Wenn zwei Anfragen gleichzeitig kommen? Wenn das Feld null ist?

Und dann die Auswertung, die genauso simpel ist: Komm ich 3 Sätze weit, ohne zu stocken, war das Gefühl ein Lügner. Dann ist gut. Häng ich beim ersten Satz, hab ich kein Selbstwertproblem entdeckt. Ich hab eine Aufgabe entdeckt. Das ist kein Urteil über mich, das ist eine Messung, und sie dauert 60 Sekunden.

Warum laut und nicht im Kopf: Im Kopf klingt jede Erklärung vollständig. Das Stocken hörst du erst, wenn du es aussprichst. Genau dieses Stocken ist das Messgerät, sonst nichts.

Ob du das auch so machst, ist deine Sache. Ich erzähl das nicht, weil es die Lösung ist. Ich erzähl es, weil es das Einzige ist, was bei mir zuverlässig funktioniert hat.

Was ich seitdem anders mache

Der Test sagt dir, wo du stehst. Er ändert nichts. Geändert hat bei mir erst, wie ich vorher arbeite, und das sind vier ziemlich unspektakuläre Gewohnheiten.

Erst das Problem zerlegen, dann die KI öffnen

Ich schreibe mir vorher in zwei, drei Zeilen auf, was eigentlich passieren soll und in welchen Schritten. Erst dann prompte ich. Der Unterschied ist nicht die Antwort der KI, der Unterschied bin ich: Wer den Weg vorher im Kopf hatte, erkennt beim Lesen, wo davon abgewichen wurde. Wer ihn nicht hatte, sieht nur Code, der plausibel aussieht.

Der KI erzählen, wie das Projekt tickt

Konventionen, Verzeichnisstruktur, was wir bewusst nicht benutzen. Bei mir steht das in einer Projektdatei, die bei jeder Session mitgeht. Das spart nicht nur Korrekturschleifen, es macht den Output auch prüfbar: Ich weiß, gegen welche Regeln ich lese.

Den Diff lesen wie einen fremden Pull Request

Ich überfliege ihn nicht mehr daraufhin, ob er plausibel aussieht, sondern frage mich bei jeder Änderung, warum sie da ist. Das ist der langweiligste Punkt auf dieser Liste und der, der bei mir am meisten gebracht hat. Er kostet auch am ehesten Überwindung, weil ja alles grün ist.

Die Commit-Nachricht als Mini-Erklärung

Wenn ich nicht in einen Satz kriege, was dieser Commit tut und warum, dann hab ich es nicht verstanden. Der Commit ist die billigste Version des Erklär-Tests, weil er sowieso geschrieben werden muss.

Wenn du beim Erklär-Test merkst, dass du öfter in Gruppe B landest, als dir lieb ist: Mir hat da jedenfalls kein Zuspruch geholfen. Geholfen hat, anders zu arbeiten. Genau diese vier Punkte, also Denken vor dem Prompten, Kontext, ein Ablauf statt Einzelprompts, gehe ich im kostenlosen 5-Tage-Kurs KI Coding Partner der Reihe nach durch. Eine kurze Mail pro Tag, danach ist Schluss, und am Ende hast du einen Ablauf statt einer Sammlung von Prompt-Tricks.

Ich halte das nicht für einen Defekt

Ich glaube nicht, dass dieses Gefühl dein Feind ist. Bei allem, was gerade auf uns einprasselt, halte ich es eher für die letzte ehrliche Probe. Die, die noch zwischen grün und rot unterscheidet.

Die Tests sind grün. Der Build ist grün. Der Reviewer hat durchgewunken, nach 20 Sekunden. Und irgendwas in dir sagt trotzdem: Du weißt nicht, was du da gerade ausgeliefert hast.

Ich halte das nicht für einen Defekt. Ich halte es für den Teil von dir, der noch hinschaut, wenn alle anderen durchwinken. Und ich für meinen Teil lass es mir nicht mehr wegreden, bevor ich nachgeschaut hab, worauf es zeigt.

Zusammenfassung

• Imposter-Syndrom heißt per Definition, dass du dich irrst. Clance und Imes beschreiben 1978 die Lücke zwischen belegter Kompetenz und falschem Gefühl. Im Original steht übrigens nie “Syndrom”, sondern “Phänomen”.
• Wer seinen ausgelieferten Code nicht erklären kann, irrt sich nicht. Für den ist es kein Syndrom, sondern ein Messergebnis. Und das sagt nichts über seinen Wert, nur über die Lage.
• Zwei Gruppen fühlen gerade dasselbe. Bei Gruppe A liegt das Gefühl daneben, da hilft Zuspruch. Bei Gruppe B stimmt es, da schaltet derselbe Zuspruch den letzten Alarm ab.
• Verstehen war früher ein Nebenprodukt vom Kämpfen. Der Kampf ist weg, das ist gut. Nur ist mit ihm auch das Nebenprodukt verschwunden, und ersetzt hat es keiner.
• Es geht nicht um Vollständigkeit, sondern um markierte Grenzen. Bei einer Bibliothek weißt du, wo sie aufhört. Beim KI-Code sagt dir nichts, ab wo niemand mehr nachgedacht hat.
• Der Erklär-Test dauert 60 Sekunden: Editor zu, laut erklären, was und warum. Stocken ist keine Charakterfrage, sondern eine Aufgabe.

Falls du das hier bis hierhin gelesen hast, tippt der Verdacht wahrscheinlich schon auf eine bestimmte Stelle in deinem Projekt. Mich würde interessieren, ob du sie beim Lesen sofort vor Augen hattest, und wie du mit sowas umgehst.