Woran erkennst du, wer wirklich denkt?

In deinem Team sitzt gerade mindestens ein Engineer, der Arbeit ausliefert, die er an einem Whiteboard nicht nachbauen könnte.

Der Code kompiliert. Die Tests laufen durch. Der PR ist makellos. Nur stammt das Denken dahinter nicht von ihm, und er weiß es nicht. Von innen fühlt sich ein geliehener Gedanke exakt an wie ein eigener.

Du merkst es beim nächsten Mal, wenn jemand die Cache-Frage stellt. Das Architekturdiagramm ist an die Wand geworfen, das Design sieht sauber aus, und ein Staff Engineer beugt sich vor:

Erklär mir, warum du hier einen Write-through-Cache ausgeschlossen hast. Was passiert, wenn genau dieser Node unter Last neu startet?

Die Pause, die jetzt folgt, sollte eine Such-Pause sein: Der Engineer kramt in seinem eigenen mentalen Modell nach der Randbedingung, die er bedacht hatte, nach der Alternative, die er abgewogen hatte, nach dem Folgeeffekt, den er im Blick hatte, als er die Entscheidung traf.

Heute ist die Pause ein Loch.

Reibung war tragend

Das hier ist keine Trauerrede auf die alten Zeiten, in denen man sich durch Stack Overflow wühlte.

KI ist ein fantastischer Multiplikator. Sie ist ein unermüdlicher Reviewer um Mitternacht, der dein Design um 1 Uhr nachts liest, ohne zu murren. Sie ist ein Sparringspartner, der ein Gegenargument so lange hält, bis du eine echte Verteidigung aufgebaut hast. Sie sagt dir, was du übergangen hast. Engineers, die sie gut nutzen, sind nach jedem ehrlichen Maßstab schärfer als vor zwei Jahren. Ich nutze sie. Du nutzt sie. Der Beitrag wäre Betrug, wenn er so täte, als wäre es anders.

Aber wir haben einen leisen Kategorienfehler gemacht. Wir dachten, die Reibung in der Softwareentwicklung sei bloß ein Tempolimit. Das war sie nicht.

Reibung hat uns nicht nur gebremst, sie war tragend. Sie war eine Echtzeit-Geländekarte, die zeigte, wo die schweren Probleme lagen. Wir haben die Reibung wegoptimiert und dabei versehentlich die Karte gelöscht.

Wenn ein Problem wirklich hart war, hast du drei Stunden eine Wand angestarrt, am Whiteboard geschwitzt und deine Berufswahl infrage gestellt. Die Reibung war ein Kompass. Dieselbe Reibung, die die Arbeit so elend machte, zwang dich, das Modell in deinem Kopf aufzubauen: die Write-through-Semantik, die Fehlerfälle, das Read-after-write-Fenster. Du hast das alles im Schädel gehalten, bis du das Design ohne das Dokument verteidigen konntest.

Das Modell halluziniert in zwölf Sekunden ein perfekt formatiertes, syntaktisch zuckersüßes Architekturdokument. Reibung gibt es dabei keine. Du bekommst einen Dopaminschub und eine Lüge. Du hast die Antwort. Du hast nicht den Muskel.

Die gebrochene Achse

Eine Engineering-Organisation ist ein Stichprobenproblem. Du kannst nicht jeden Tastenanschlag beobachten, also liest du die Artefakte und schließt daraus aufs Denken. Pull Requests, Design Docs, Postmortems, gelegentlich ein Incident Review. Das sind die Messinstrumente. Leistungsbeurteilungen, Calibration, Beförderungsmaßstäbe und Hiring Loops beruhen alle auf der Annahme, dass Artefakt und Denken aus derselben Quelle kommen.

KI hat die Achse zwischen diesen beiden Rädern gebrochen.

Output ist jetzt eine Funktion von drei Variablen, dem Engineer, dem Modell und dem Prompt. Die Artefakte erzählen dir von allen dreien, wild durcheinander, und du kannst das Signal nicht trennen. Ein polierter PR passt zu einem durchdachten Engineer, zu einem gedankenlosen Engineer oder zu einem Tab, den jemand im Zug offen gelassen hat. Das Artefakt kommt immer noch pünktlich an. Es trägt nur nicht mehr das Signal, für das du es liest.

Am wichtigsten ist das bei den Engineers, die du fördern willst. Ein Senior, der flüssigen KI-Output produziert, ist im schlimmsten Fall gehebelt. Der Muskel ist da, das Modell bedient nur die Tastatur. Ein Junior, der denselben Output produziert, tut das, ohne je den Muskel aufgebaut zu haben, den die Arbeit eigentlich aufbauen sollte. Er liefert den Write-through-Cache aus, ohne je durchgespielt zu haben, was passiert, wenn der Node ausfällt. Er liefert das Read Replica für Analytics aus, ohne je beim Konsistenzfenster gesessen zu haben. Das Artefakt ist in Ordnung. Die architektonische Intuition, die darunter wachsen sollte, ist nie aufgetaucht.

Das METR-Paradox

Hier ist eine Zahl, die Engineering Leadern ins Gesicht starren sollte. METR hat 2025 eine sorgfältige Studie durchgeführt. Erfahrene Entwickler, die KI-Unterstützung nutzten, brauchten für ihre Aufgaben 19 % länger als ohne, glaubten aber, 20 % schneller zu sein.¹ Junioren in unbekanntem Code laufen in McKinseys separater Arbeit in die Gegenrichtung: 26 bis 39 % schneller.²

Das Gefälle läuft verkehrt herum für ein Organigramm. Warum sehen Junioren aus wie 10x Engineers, während Seniors flach wirken?

Die Seniors sind mit KI nicht schlechter. Die Arbeit, bei der KI hilft, ist nicht die Arbeit, die sie gemacht haben. Ihr Engpass war nie das Tippen, sondern die Entscheidung, was sie tippen sollen. Die Junioren wirken schnell, weil ihr Engpass das Tippen war, und Tippen ist jetzt gratis. Die Produktionsfunktion hat sich nicht nur verbessert, sie ist umgezogen. Sie ist komplett vom Artefakt weggewandert. Die Junioren produzieren Output, der nach Senior aussieht. Sie bauen, nach jedem messbaren Signal, kein Senior-Urteilsvermögen auf.

Die Junioren schließen Tickets so schnell, dass das Jira-Board wie ein Spielautomat im Auszahlungsmodus aussieht. Das Dashboard sagt, sie sind 39 % schneller. Das Dashboard ist begeistert. Das Dashboard muss allerdings nicht die State Machine warten, die sie gerade erfunden haben.

Drei Dinge, die in deinem Kopf schiefgehen

Drei psychologische Mechanismen springen gleichzeitig an, wenn du flüssigen KI-Output liest und für deinen eigenen Gedanken hältst. Sie sind dokumentiert, Jahrzehnte alt und kein bisschen gealtert.

Die Fluency-Illusion. Menschen beurteilen, wie gut sie etwas verstehen, danach, wie leicht es ihnen einfällt.³ KI-Output ist maximal leicht. Poliert, selbstsicher, genau so strukturiert, dass du es aufnehmen kannst. Beim Lesen entsteht das warme Gefühl von Verständnis, ohne dass du die Arbeit getan hast, die dieses Gefühl normalerweise erzeugt.

Die Wärme des Verstehens ist der Bug.

Das verlorene Anstrengungssignal. Den größten Teil deiner Karriere war das fühlte sich schwer an ein brauchbarer Stellvertreter für ich leiste echte kognitive Arbeit. Die Reibung hat die Kalibrierung für dich erledigt. Mit dem Modell in der Schleife ist das Denken ausgelagert, aber der Stellvertreter wurde nicht neu kalibriert. Du lieferst das Ding aus, es fühlte sich leicht an, du schließt daraus, dass es einfach war, dabei könnte es heißen, dass du nicht gedacht hast.

Autorschafts-Drift. Die Forschung zum Source Monitoring ist vierzig Jahre alt. Menschen können Ideen, die sie selbst erzeugt haben, nicht zuverlässig von Ideen unterscheiden, die man ihnen eingegeben hat.⁴ Bis Donnerstag ist die Drift komplett. Der Engineer sieht einen 400 Zeilen langen Regex-Block an, den er mit dem Modell “gepaired” hat, und denkt ernsthaft: Ah ja, ich erinnere mich, wie ich dieses negative Lookbehind sorgfältig von Hand gebaut habe. Hast du nicht. Du hast die Eingabebox gebeten, die kaputten Zeichen verschwinden zu lassen, und den ersten Schnipsel genommen, der keinen Fehler warf.

Die Cache-Frage landet mitten in diesem Dreieck. Der Engineer hat die Write-through-Schicht mit einem Modell in der Schleife geschrieben. Es fühlte sich leicht an. Der Code kompiliert. Die Tests laufen durch. Aber er hat nie durchdacht, was mit dem laufenden Schreibvorgang passiert, wenn der Node ausfällt. Er hat nie durchdacht, was die Datenbank sieht, wenn der Cache im Stampede zurückkommt, oder was der Lesepfad während des Warm-ups liefert. Er hat kein mentales Modell, aus dem er abrufen könnte, wenn jemand fragt. Am Code ist nichts falsch. Im Kopf des Engineers ist nichts.

Introspektion funktioniert nicht mehr

Die Summe der Effekte ist der Teil, der dich nachts wach halten sollte.

Der Engineer, der von der Erweiterung in den Ersatz gekippt ist, lügt nicht, wenn er sagt, er habe es durchdacht. Er hat sich souverän gefühlt. Die Arbeit fühlte sich leicht an, so wie gut verstandene Arbeit sich leicht anfühlt. Er erinnert sich an die Überlegung als seine eigene.

Der Selbstbericht ist unzuverlässig. Das Artefakt ist unzuverlässig.

Übrig bleibt, was er kalt kann, wenn du fragst.

Skepsis heißt nicht, der KI zu misstrauen

Skepsis bedeutet hier nicht Misstrauen gegenüber KI. Es ist Misstrauen gegenüber dem Fluency-Signal. Es ist die Disziplin, ich kann das lesen und habe das Gefühl, es zu verstehen von ich kann das morgen früh aus dem Nichts selbst herstellen zu trennen. Früher war das ungefähr dasselbe. Heute nicht mehr.

Dieser Schritt muss zuerst passieren, im Kopf des Engineers selbst, bevor ein Manager irgendetwas Sinnvolles damit anfangen kann. Wenn der Engineer ihn nicht auf sich selbst anwenden kann, rettet ihn kein Review-Prozess.

Wie Skepsis aussieht, wenn du sie auf dich selbst anwendest

Kalte Reproduktion. Klapp den Laptop zu. Geh zum Whiteboard. Rekonstruiere das Design aus dem Gedächtnis, einschließlich der Alternativen, die du ausgeschlossen hast. Die Pause, bevor du anfängst, sind die Daten.
Adversariales Selbstbefragen. Such dir die Annahme, bei der du dich am unwohlsten fühlst, und versuch sie zu knacken, ohne neu zu prompten. Wenn dein erster Griff der zum Chat ist, hast du deine Antwort.
Der 10x-Test. Was würde sich ändern, wenn sich die Lastannahme um das 10-Fache verschiebt? Wenn deine Antwort lautet ich würde das Modell fragen, gehört das Design dem Modell und nicht dir.

Und dann gibt es die Version der Cache-Frage, die du dir selbst stellst, in deinem eigenen Kopf, spätabends in deiner eigenen Küche:

Erklär mir, warum ich hier eine Message Queue ausgeschlossen habe. Moment. Habe ich die ausgeschlossen? Oder hat das Modell sie nur nicht erwähnt? Moment, bin ich das Modell?

Schreib einmal pro Woche deine Entscheidungen in drei Spalten auf: deine, die des Modells und nicht trennbar. Der dritte Eimer ist der interessante. Er sollte nicht der größte sein.

Die Version für Manager

Die Aufgabe des Engineering Managers ist nicht mehr, die Velocity zu verfolgen. Sie besteht darin, auf Tiefe abzuklopfen.

Das Gespräch als Review ist das fehlende Instrument. Die Daten, die die Organisation wirklich braucht, nämlich drei Momente pro Quartal, in denen dieser Engineer eine nicht triviale Entscheidung unter Live-Fragen verteidigt hat, stehen in keinem Kalender, in keiner Review-Vorlage, in keinem Dashboard. Sie existieren nur im Raum, und nur dann, wenn jemand im Raum auf die Idee kam zu fragen.

Der Wortwechsel, auf den du achten solltest:

“Erklär mir, warum du genau diese Indexierungsstrategie für die Datenbank gewählt hast.”

Schweigen.

“Okay, dann erklär mir, was ein Index ist.”

Längeres Schweigen.

Wenn ein Engineer das Design nicht mit geschlossenem Laptop verteidigen kann, hat er es nicht geschrieben.

Hiring hat sich verändert

Die dritte Stelle, an der das ankommt, ist das Hiring, und hier schlagen die Folgen am schnellsten ein.

Ich gehe davon aus, dass jeder Kandidat KI benutzt. Der Lebenslauf sieht großartig aus, die Take-home-Aufgabe ist sauber, und beides ist kein Signal mehr. Ich prüfe nicht mehr auf perfekte Syntax oder Debugging-Fähigkeit: Das kann das Modell beides, und der Kandidat weiß, dass ich es weiß.

Ich prüfe jetzt auf Entscheidungen, die dem Modell voraus sind. Der Kandidat, der beim Entwerfen sagt “Ich brauche das, aber ich weiß, dass das hier passieren wird, und wenn sich der Traffic verdoppelt, kippt es an dieser Stelle, also würde ich stattdessen das hier tun”, ist der Kandidat, der den Muskel aufgebaut hat. Der Kandidat, der ein sauberes Design reproduziert, mir aber nicht sagen kann, was bei 10x kaputtgeht, ist der Kandidat, den das Modell durch die Take-home-Aufgabe getragen hat.

Außerdem prüfe ich auf den Teil des Systems, den das Modell nicht sehen kann. Das horizontal skalierende Cluster hinter dem Service. Der Cache, der im Repo eines anderen Teams lebt. Der Downstream Consumer, der ein fehlerhaftes Event sechs Wochen lang kommentarlos schluckt, bis jemand deshalb alarmiert wird. Das Modell ist brillant innerhalb der Codebase, die vor ihm liegt. Für das System drumherum ist es blind. Der Kandidat, der nur je mit dem Modell gepaired hat, auch.

Es gibt kein Vortäuschen: Sie werden KI benutzen. Im Interview geht es nicht mehr darum, ob sie eine Funktion produzieren können. Es geht darum, ob sie das System im Kopf halten können.

Das Drei-Jahres-Problem

Wenn das System es nicht sehen kann, kann es es nicht bewerten. Wenn es es nicht bewerten kann, kann es danach nicht befördern. Wenn es danach nicht befördern kann, hört es auf, darauf auszuwählen.

Also befördern wir nach Velocity. Wir bauen eine ganze Generation von Staff Engineers heran, die alles ausliefern und nichts davon verteidigen können. Die Burndown-Charts werden wunderschön sein. Die Burndown-Charts werden das Einzige sein, was gerade nicht brennt.

Die Senior Engineers, die ein Design unter Befragung verteidigen können, werden nicht weg sein: Sie wurden nie eingestellt. Ihre Nachfolger sehen im Dashboard genauso aus. Sie können die Frage nur nicht beantworten.

Dreh es auf diesen Beitrag

Du nickst die ganze Zeit. Das Argument fühlt sich richtig an. Die Logik ist eingerastet.

Aber denk an den Bug: Die Wärme ist kein Beweis dafür, dass das Argument stimmt.

Dieser Beitrag begann als Widerspruch zu Koshy Johns AI should elevate your thinking, not replace it, das die Version dieses Arguments als persönliche Tugend vertritt. Er hat größtenteils recht. Teile dieses Essays habe ich mit einem Modell zusammen entwickelt. Manche Formulierungen kamen zu leicht. Es gibt hier Sätze, die ich morgen, kalt gefragt, kaum in derselben Form reproduzieren könnte.

Bin ich ein Genie, weil ich das so formuliert habe, oder habe ich einfach so lange auf Regenerate geklickt, bis der Roboter zynisch genug klang?

Klapp morgen früh deinen Laptop zu und versuch, diese These aus dem Gedächtnis zu reproduzieren. Geh die drei Variablen durch, die die Achse gebrochen haben. Geh den Unterschied zwischen Koshy Johns Argument und diesem durch.

Wenn du das nicht kannst, hast du es nicht gedacht. Du hast es nur gelesen.

Der Cache aber

In drei Jahren sind unsere Engineering-Dashboards komplett grün. Die Velocity ist durch die Decke. Die Organisation sieht auf dem Papier makellos aus.

Der Cache aber brennt.

METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025. ↩
McKinsey, Unleashing developer productivity with generative AI, 2023. Berichtet Zuwächse bei der Aufgabenerledigung für weniger erfahrene Entwickler im Bereich von grob 26 bis 39 %, je nach Aufgabentyp. ↩
Siehe Rozenblit, L. & Keil, F., The misunderstood limits of folk science: an illusion of explanatory depth, Cognitive Science, 2002. Der Effekt, Fluency als Stellvertreter für Verständnis zu nehmen, ist über Jahrzehnte der Forschung robust. ↩
Johnson, M. K., Hashtroudi, S. & Lindsay, D. S., Source monitoring, Psychological Bulletin, 1993. Die grundlegende Synthese. Das Ergebnis wurde in den letzten Jahren repliziert und auf die gemeinsame Autorschaft von Mensch und KI ausgeweitet. ↩