Wenn dein Imposter-Syndrom recht hat

Du hast den Pull Request geöffnet, die Tests sind grün und alles funktioniert. Dann erscheint im Review eine harmlose Frage:

Warum hast du das an dieser Stelle so gelöst?

Du scrollst durch deinen eigenen Code – und liest ihn wie ein Tourist. Du suchst die Antwort zwischen den Zeilen, als hätte jemand anderes sie geschrieben.

Was streng genommen sogar stimmt.

Also tippst du: „Guter Punkt, ich schaue mir das noch einmal an.“ Gemeint ist eigentlich: Ich weiß es nicht. Und bis gerade eben wusste ich nicht einmal, dass ich es nicht weiß.

Wer mit KI programmiert, kennt vielleicht dieses unangenehme Gefühl: Bin ich überhaupt noch ein richtiger Entwickler, wenn das Modell den Code schreibt? Viele nennen es Imposter-Syndrom. Doch manchmal ist diese Diagnose zu bequem. Manchmal ist das Gefühl keine verzerrte Wahrnehmung, sondern ein ziemlich genaues Messergebnis.

Das klingt zunächst hart. Tatsächlich ist es die bessere Nachricht. Ein diffuses Selbstwertproblem lässt sich nur schwer greifen. Ein festgestelltes Wissensloch dagegen kann man schließen.

Zwei Entwickler, dasselbe Gefühl

Das Interessante ist, dass die Unsicherheit längst nicht nur Anfänger betrifft.

Da ist der Entwickler, der seit zwei Jahren im Beruf ist. Er denkt: Ich habe das Programmieren nie richtig gelernt. Die KI macht alles, ich drücke nur noch Enter. Wenn sie morgen verschwindet, stehe ich da wie am ersten Tag – und dann merken es alle.

Zwei Tische weiter sitzt jemand mit 15 Jahren Erfahrung. Sein Gedanke klingt genau entgegengesetzt: Ich habe mir das alles mühsam beigebracht. Jetzt erledigt ein Modell in wenigen Minuten, wofür ich früher Tage gebraucht habe. Wozu waren all diese Jahre gut?

Verschiedene Lebensläufe, gegensätzliche Gründe – und trotzdem dasselbe Gefühl: austauschbar zu sein.

Wenn so unterschiedliche Menschen am gleichen Punkt ankommen, liegt das Problem vermutlich nicht nur bei ihnen. Es hat auch damit zu tun, wie KI die Arbeit selbst verändert.

Nicht jede Unsicherheit ist ein Imposter-Syndrom

Der Begriff Imposter-Syndrom beschreibt eine ziemlich konkrete Situation: Du kannst etwas nachweislich. Du hast es oft getan, andere verlassen sich auf dein Urteil, vielleicht kommen Kollegen sogar zu dir, wenn sie nicht weiterwissen. Trotzdem hast du Angst, jeden Moment als Hochstapler aufzufliegen.

Das Entscheidende daran: Dein Gefühl liegt falsch. Deine tatsächlichen Fähigkeiten widersprechen deiner Selbstwahrnehmung.

Doch passt das wirklich auf eine Situation, in der du Code ausgeliefert hast, den du nicht erklären kannst?

Wenn du nicht weißt, warum eine Funktion so aufgebaut ist, welche Annahmen darin stecken oder was bei veränderten Eingaben passiert, dann täuscht dich dein Gefühl nicht. Es weist auf eine echte Lücke hin. Das sagt nichts darüber aus, wie intelligent du bist oder welchen Wert du als Entwickler hast. Es beschreibt nur deinen aktuellen Kenntnisstand.

Diese Unterscheidung ist wichtig, weil beide Fälle eine völlig andere Reaktion brauchen.

• Du verstehst den Code und hättest ihn selbst schreiben können, nur langsamer? Dann ist die KI ein Werkzeug – und dein schlechtes Gewissen wahrscheinlich unbegründet.
• Du kannst nicht erklären, was du gerade ausgeliefert hast? Dann brauchst du kein Schulterklopfen, sondern einen zweiten Blick auf den Code.

Der Satz „Alle benutzen inzwischen KI, sei nicht so streng mit dir“ kann für die erste Gruppe befreiend sein. Für die zweite Gruppe wirkt er wie ein Beruhigungsmittel, das den einzigen funktionierenden Alarm ausschaltet.

Wie man unbemerkt zum Zuschauer der eigenen Arbeit wird

Niemand setzt sich morgens an den Schreibtisch und beschließt, den eigenen Code heute möglichst nicht zu verstehen. Der Verlust von Verständnis geschieht viel unspektakulärer.

Die KI macht einen Vorschlag. Er sieht gut aus – Enter. Der nächste passt ebenfalls – Enter. Beim dritten prüfst du kurz, ob alles plausibel wirkt. Die Tests laufen durch. Fertig.

Und „fertig“ ist ein verdammt gutes Gefühl.

Du warst nicht faul. Du hast nicht absichtlich geschlampt. Der Arbeitsprozess hat nur an keiner Stelle verlangt, dass du erklärst, was gerade entstanden ist.

Diese Verschiebung hört man inzwischen sogar in der Sprache. Früher hieß es: „Ich habe das gebaut.“ Heute hört man öfter: „Das ist dabei herausgekommen“ oder „Die KI hat mir das so hingelegt.“

Das klingt nach einer Kleinigkeit. Doch im ersten Satz spricht ein Autor, im zweiten ein Zeuge.

Vielleicht entsteht in manchen Teams sogar eine stille Übereinkunft: Niemand fragt zu genau nach, weil jeder ahnt, dass die Frage schon morgen zurückkommen könnte. Wenn ich wissen will, warum dein Code so aussieht, musst du mich möglicherweise bald dasselbe fragen. Also winken wir uns gegenseitig durch.

Das ist dann kein Code-Review mehr, sondern ein Nichtangriffspakt.

Früher war Verstehen ein Nebenprodukt

Warum passiert das gerade so leicht? Nicht, weil Entwickler früher grundsätzlich fleißiger oder gewissenhafter waren. Der Weg zum Ergebnis war einfach ein anderer.

Wer früher drei Stunden an einem Bug saß, hatte danach meistens nicht nur den Fehler behoben. Nebenbei hatte er verstanden, wie dieser Teil des Systems funktioniert. Nicht aus besonderer Lernmotivation, sondern weil es ohne dieses Verständnis keinen Ausweg gab.

Verstehen war der Lohn fürs Durchhalten.

Was wir uns mühsam erarbeiten, bleibt häufig lange hängen. Was uns fertig vorgelegt wird, verschwindet dagegen schnell wieder aus dem Kopf. Das ist keine nostalgische Behauptung, dass früher alles besser gewesen sei. Niemand muss die verlorenen Abende romantisieren, an denen ein winziger Fehler stundenlang nicht zu finden war. Dass KI solche Aufgaben heute in Minuten lösen kann, ist ein enormer Fortschritt.

Nur ist mit dem Kampf auch sein bisheriges Nebenprodukt verschwunden. Früher konnte man oft nicht liefern, ohne zu verstehen. Heute geht das sehr wohl.

Der alte Schluss „Es funktioniert, also weiß ich, was ich tue“ gilt nicht mehr automatisch.

„Es läuft“ ist nur eine Momentaufnahme

Man könnte einwenden: Wenn der Code funktioniert und alle Tests grün sind, warum muss ich ihn überhaupt erklären können? Am Ende zählt doch das Ergebnis.

Für heute stimmt das sogar.

„Es läuft“ bedeutet allerdings nur, dass der Code unter den gerade geprüften Bedingungen das erwartete Ergebnis geliefert hat. Es bedeutet nicht, dass du weißt, was am Montag mit echten Daten passiert, nachts unter hoher Last oder nachdem jemand eine scheinbar harmlose Zeile daneben verändert hat.

Der schwierige Moment kommt oft Monate später. Es ist 23 Uhr, irgendwo ist ein Fehler aufgetaucht und du musst Code debuggen, den du zwar eingecheckt, aber nie wirklich durchdrungen hast. Früher hattest du beim Suchen wenigstens einen Vorteil: Du wusstest, was du dir beim Schreiben gedacht hattest. Selbst wenn die Entscheidung schlecht war, war es deine Entscheidung – und damit ein möglicher Ausgangspunkt.

Bei unverstandenem KI-Code fehlt dieses innere Modell. Du sitzt im eigenen Repository und fühlst dich wie der neue Kollege.

Der Wert verschiebt sich vom Schreiben zum Beurteilen

Für erfahrene Entwickler kann der Umgang mit KI besonders irritierend sein. Wenn ein Modell in wenigen Minuten erledigt, wofür man früher zwei Tage gebraucht hätte, liegt die Frage nahe: Wofür habe ich das alles gelernt?

Die Antwort lautet: um beurteilen zu können, ob das Ergebnis gut ist.

Der Wert jahrelanger Erfahrung ist nicht verschwunden. Er ist umgezogen – vom reinen Schreiben zum Prüfen, Einordnen und Entscheiden. Code lässt sich heute im Sekundentakt erzeugen. Gutes Urteilsvermögen nicht.

Die entscheidenden Fragen bleiben bei uns:

• Passt diese Lösung wirklich zum Problem?
• Welche Annahmen macht sie?
• Welche Fehlerfälle fehlen?
• Ist die Abstraktion sinnvoll oder nur kompliziert?
• Können wir den Code in sechs Monaten noch sicher verändern?

Die KI kann eine Antwort produzieren. Verantwortung dafür, ob sie trägt, übernimmt sie nicht.

Das bedeutet allerdings nicht, dass jeder Entwickler jede Zeile des gesamten Stacks verstehen muss. Niemand liest vor der Arbeit den kompletten TCP/IP-Stack oder untersucht jede intern verwendete Bibliothek. Softwareentwicklung funktioniert gerade deshalb, weil wir auf Abstraktionen aufbauen.

Der entscheidende Unterschied liegt darin, ob wir die Grenze unseres Wissens kennen. Bei einer Bibliothek wissen wir ungefähr, was sie verspricht, wo ihre Zuständigkeit endet und wo wir bei Problemen nachschlagen können. Die Grenze ist sichtbar.

Bei KI-generiertem Code fehlt diese Markierung oft. Der Code sieht aus wie unserer, liegt in unserem Repository und trägt unseren Namen im Commit. Nichts daran verrät, an welcher Stelle niemand die Entscheidung wirklich durchdacht hat.

Eine bekannte Abstraktion ist ein Werkzeug. Eine unbekannte Abstraktion, die wir für unseren eigenen Code halten, kann zur Falle werden.

Der 60-Sekunden-Test

Zum Glück lässt sich das Problem erstaunlich einfach überprüfen.

Nimm die letzte Funktion, Komponente oder Änderung, die eine KI für dich erstellt hat. Schließe den Code – und erkläre laut, was sie tut und warum sie so aufgebaut ist. Du brauchst dafür kein Publikum. Eine Wand reicht.

Kannst du drei klare Sätze sagen, ohne ins Stocken zu geraten? Dann hat dich dein Unsicherheitsgefühl wahrscheinlich getäuscht. Die KI hat geschrieben, aber du hast gedacht.

Scheiterst du bereits am ersten Satz, hast du kein Selbstwertproblem entdeckt. Du hast eine konkrete Aufgabe gefunden: Öffne den Code erneut, stelle Fragen, prüfe die Annahmen und verändere die Lösung so lange, bis sie auch in deinem Kopf existiert.

Diese Prüfung dauert kaum länger als eine Minute. Sie verlangt nicht, dass du alles weißt. Sie zeigt dir nur, ob du weißt, was du nicht weißt.

Das Warnsignal nicht vorschnell abschalten

Vielleicht ist das unangenehme Gefühl beim KI-gestützten Programmieren nicht grundsätzlich unser Feind. Vielleicht ist es die letzte ehrliche Prüfung zwischen „grün“ und „wirklich verstanden“.

Die Tests sind grün. Der Build ist grün. Das Review wurde nach 20 Sekunden freigegeben. Trotzdem sagt etwas in dir: Ich weiß nicht genau, was ich hier ausgeliefert habe.

Das muss kein Defekt sein. Es kann der Teil von dir sein, der noch hinschaut, während alle anderen Signale längst zum Weitergehen auffordern.

Deshalb sollten wir uns dieses Gefühl weder schönreden noch dafür verurteilen. Wir sollten es testen.

Kannst du deinen Code erklären, obwohl die KI ihn geschrieben hat? Dann bist du kein Hochstapler. Du nutzt ein leistungsfähiges Werkzeug.

Kannst du es nicht? Dann bist du ebenfalls kein Hochstapler. Aber du bist noch nicht fertig.

Und genau das ist vielleicht die wichtigste neue Fähigkeit beim Programmieren mit KI: nicht jede Zeile selbst zu tippen, sondern zuverlässig zu erkennen, wann aus erzeugtem Code wirklich der eigene geworden ist.