In vielen Unternehmen läuft gerade derselbe Konflikt. Die Geschäftsführung will KI-Coding-Tools einführen. Die Junior-Entwickler sind begeistert. Und die Senior-Entwickler bremsen. Sie stellen kritische Fragen, melden Bedenken an, fordern mehr Tests. Im Flurfunk heißt es dann: „Die Senior-Entwickler wehren sich gegen die Veränderung." Wer den breiteren Kontext sucht, findet die Grundlagen zu KI-Coding-Agents.
Dieses Framing ist falsch. Die Skepsis Ihrer erfahrensten Entwickler enthält zwei verschiedene Signale, die normalerweise in einen Topf geworfen werden. Das erste Signal betrifft die Verlässlichkeit der KI-Werkzeuge. Erfahrene Entwickler sehen Fehlermodi oft früher als Juniors. Das zweite Signal ist persönlicher: Wenn die Kernkompetenz, auf der man seine Karriere gebaut hat, plötzlich teilweise automatisierbar wirkt, ist das nicht neutral. Wer beide Signale vermischt, baut Misstrauen in den Rollout ein. Wer sie trennt, bekommt zwei brauchbare Informationsquellen: eine für die technische Roadmap und eine für die Personalentwicklung.
Die Zahlen, die sich verändert haben
Im Juli 2025 veröffentlichte das Forschungsinstitut METR eine viel zitierte Studie: Erfahrene Open-Source-Entwickler arbeiteten mit KI-Unterstützung 19 Prozent langsamer als ohne. Für viele skeptische Senior-Entwickler war das ein Beleg. Die KI bremst, statt zu helfen.
Im Februar 2026 hat METR die eigene Studie neu eingeordnet. Für dieselbe Entwicklergruppe zeigen neuere Messungen einen Speedup statt einer Verlangsamung. Das Konfidenzintervall reicht jetzt von 38 Prozent schneller bis 9 Prozent langsamer. METR nennt auch die Gründe für die Revision: Die Entwickler, die am meisten von KI profitieren, weigerten sich, an einem Experiment teilzunehmen, das sie zeitweise ohne KI arbeiten ließ. Die ursprüngliche Messung hatte einen blinden Fleck.
Was bedeutet das für die Senior-Skepsis? Es bedeutet nicht, dass sie falsch lag. Es bedeutet, dass die Frage „Werde ich persönlich schneller?" von Anfang an die falsche Frage war. Ob jemand beim Tippen zehn Minuten spart, sagt wenig darüber aus, ob der Code, der dabei entsteht, das System langfristig stabiler oder fragiler macht. Senior-Entwickler sehen genau diesen Unterschied. Die Details zur METR-Revision und was sie für das Review bedeutet, stehen im vorigen Post dieses Blogs.
Was erfahrene Entwickler anders sehen
Im Oktober 2025 hat das Unternehmen Sonar eine Befragung unter 1.149 professionellen Entwicklern weltweit durchgeführt. Die Ergebnisse sind nach Jahren im Beruf aufgeschlüsselt, nicht nach Jobtitel. Die Gruppe mit zwanzig oder mehr Berufsjahren ist ein brauchbarer Stellvertreter für sehr erfahrene Entwickler. Die Gruppe mit zehn oder weniger Jahren enthält Juniors und Mid-Level-Entwickler gleichermaßen.
Wichtig: Sonar misst hier Wahrnehmungen und Zustimmung, nicht direkt beobachtetes Verhalten im Code. Die Zahlen sind eine Einladung zur Interpretation, kein fertiger Befund. In drei unabhängigen Fragen zeigt sich ein konsistentes Muster.
Zur Verlässlichkeit: 66 Prozent der jüngeren Gruppe stimmen zu, dass KI Code produziert, der „korrekt aussieht, aber unzuverlässig ist". Bei den erfahreneren Entwicklern nur 48 Prozent. Beim ersten Lesen klingt das, als wären erfahrene Entwickler entspannter. Eine plausible Lesart ist das Gegenteil: Sie setzen KI gezielter ein, für Prototypen und explorative Aufgaben, bei denen ein Fehler billig ist. Die kritischen Pfade behalten sie eher unter enger Kontrolle. Die Daten belegen das nicht direkt, aber sie passen zu dieser Lesart.
Beim Review-Aufwand dasselbe Bild. 40 Prozent der Jüngeren sagen, KI-Code zu reviewen koste mehr Aufwand als menschlichen Code zu reviewen. Bei den erfahreneren Entwicklern nur 29 Prozent. Eine naheliegende Erklärung: Erfahrene Entwickler entscheiden schneller, was gründlich geprüft werden muss und was nicht. Sie haben einen Erfahrungsfilter, den weniger erfahrene Kollegen gerade erst aufbauen.
Beim fehlenden Kontext wird der Unterschied am deutlichsten: 47 gegen 31 Prozent. Fast die Hälfte der jüngeren Entwickler sagt, KI erschwere komplexe Aufgaben, weil ihr Kontext fehle. Erfahrene Entwickler können den Kontext aus dem Kopf ergänzen. Juniors können das nicht, weil der Kontext genau das ist, was sie gerade lernen.
Drei Fragen, dieselbe Richtung. Erfahrene Entwickler melden weniger Probleme mit KI-Code. Nicht weil sie weniger kritisch wären. Sondern weil sie die Schwächen früher sehen und drumherum steuern. Diese Fähigkeit ist ein organisatorischer Aktivposten, aber auf keinem Velocity-Dashboard taucht sie auf.
Die zweite Schicht: Identität
Die Skepsis vieler Senior-Entwickler hat noch eine andere Quelle, die mit Verlässlichkeit wenig zu tun hat. Zwanzig Jahre lang war Coden die Kernkompetenz. Der Grund, warum man im Raum sitzt. Die Fähigkeit, auf die man stolz ist.
Die Distinguished Engineer Annie Vella beschreibt diesen Punkt in einem viel gelesenen Essay namens The Software Engineering Identity Crisis. Ihre These: KI-Assistenten verschieben die Rolle vom Hersteller zum Orchestrator, vom Bauen zum Überwachen. Das ist eine Verschiebung, die viele erfahrene Entwickler wiedererkennen dürften. Für manche fühlt es sich an wie ein Statusverlust.
Diese Beobachtung steht nicht allein. Eine im Mai 2025 vorregistrierte Studie mit 1.026 Teilnehmern hat gemessen, was passiert, wenn Ingenieure KI-Unterstützung sichtbar machen. Die Kolleginnen und Kollegen bewerten dieselbe Arbeit im Schnitt neun Prozent schlechter, wenn sie wissen, dass KI beteiligt war. Bei Ingenieurinnen sind es dreizehn Prozent. Das Stigma existiert. Es ist nicht eingebildet.
Die Management-Aufgabe ist, diese beiden Schichten zu trennen.
Wenn ein erfahrener Entwickler sagt „der Code ist schlecht", kann das heißen: der Code ist schlecht. Es kann aber auch heißen: Ich weiß nicht mehr, was mein Job ist, wenn das so weitergeht. Beides sind legitime Aussagen, aber sie brauchen verschiedene Antworten.
Die Verlässlichkeits-Skepsis gehört auf die technische Roadmap: benannte Reviewer für kritische Pfade, ausgewiesene Risiko-Zonen in der Codebase, klare Deployment-Gates. Mehr dazu im Post zum Review-Engpass.
Die Identitäts-Schicht gehört auf eine andere Spur. Klare Rollenentwicklung. Architektur-Ownership für erfahrene Entwickler. Und laut ausgesprochene Anerkennung, dass sich der Job in Richtung Orchestrierung und Urteilsvermögen verschiebt.
Wer beides vermischt, vor allem im Performance Review, produziert genau das Missverständnis, dass Senior-Entwickler bloß Widerstand leisten. Das lässt sich danach schwer korrigieren.
Was die Junior-Begeisterung verdeckt
Die Sonar-Befragung zeigt auch die andere Seite. 40 Prozent der jüngeren Entwickler melden höhere persönliche Produktivität durch KI, gegenüber 32 Prozent bei den Erfahreneren. 58 Prozent sagen, ihre Jobzufriedenheit sei gestiegen, gegenüber 49 Prozent. 62 Prozent berichten, mehr Zeit für die eigene Weiterentwicklung zu haben, gegenüber 51 Prozent.
Das klingt nach einem klaren Gewinner. Die KPI-Folie im Quartalsmeeting liebt diese Zahlen.
Aber Anthropic hat im Januar 2026 eine randomisierte Studie veröffentlicht, die ein mögliches Lernrisiko zeigt. 52 Entwickler, überwiegend als Junior eingestuft, lernten eine neue Python-Bibliothek. Die Hälfte durfte KI-Assistenz nutzen, die andere nicht. Am Ende schrieben alle denselben Verständnistest, diesmal ohne KI. Die KI-Gruppe schnitt 17 Prozent schlechter ab, etwa zwei Notenstufen. Der Produktivitätsunterschied während der Aufgaben war nicht statistisch signifikant.
In Anthropics Analyse zeigte sich ein Muster: Wer die KI hauptsächlich für konzeptionelle Rückfragen nutzte, erzielte 65 Prozent oder besser im Test. Wer hauptsächlich Code delegierte, landete unter 40 Prozent. Anthropic betont ausdrücklich, dass diese Musteranalyse keinen Kausalnachweis liefert. Als Warnsignal ist sie trotzdem relevant.
Die Gruppe, die die größten Produktivitätsgewinne meldet, ist auch die Gruppe, deren Skill-Aufbau am ehesten gefährdet ist. Das ist kein Argument gegen KI-Nutzung durch weniger erfahrene Entwickler. Aber es ist ein Argument gegen ungesteuerte Delegation. Die Skepsis erfahrener Entwickler enthält oft eine Lesart auf genau diese Dynamik: Wer soll in fünf Jahren den Code reviewen, den der Agent heute schreibt? Wer baut das mentale Modell auf, das ein sauberes Review braucht?
Die skeptischen Senior-Entwickler sind nicht nostalgisch. Sie sorgen sich um die Pipeline. Nicht die auf Jenkins. Die andere.
Was Sie konkret tun können
Skepsis als Signal lesen, nicht als Widerstand. „Die Senior-Entwickler wehren sich" ist die falsche Diagnose. Die interne Reformulierung lautet: „Die erfahrensten Leute im Team melden Bedenken zur Verlässlichkeit. Was sehen sie?" Diese Reformulierung verändert, welche Gespräche überhaupt möglich werden. Nach einigen Wochen erkennen Sie, welche Einwände echtes Signal sind und welche persönlicher Geschmack.
Erfahrene Entwickler die Risiko-Zonen definieren lassen. Nicht nur durchsetzen. Die Senior-Entwickler in Ihrem Team haben die beste Karte davon, welche Pfade in der Codebase einen Agenten vertragen und welche nicht. Lassen Sie sie diese Karte zeichnen, statt sie nur als Reviewer einzusetzen, nachdem jemand anders entschieden hat.
Verlässlichkeit und Identität trennen. Buchstäblich in getrennten Meetings. Das eine Gespräch ist technisch: Review-Tiefe, Test-Abdeckung, Deployment-Gates. Das andere geht um Rolle und Karriere: Architektur-Ownership, Mentoring-Aufgaben, die Frage, wie die Senior-Rolle in zwei Jahren aussieht. Beides in einem Gespräch zu vermischen, vor allem im Performance Review, kippt das Vertrauen.
Fraunhofer IESE hat dafür den Begriff AI Pair Review geprägt: Ein erfahrener Entwickler geht KI-generierten Code gemeinsam mit einem Junior durch und beschreibt laut, was er sieht. Das ist ein Mentoring-Ritual, das gleichzeitig auf die Anthropic-Lücke reagiert. Kein Budget nötig, kein neues Tool. Zwei Menschen und ein Review.
Der Wert der Skepsis
Die Skepsis in Ihrem Senior-Team ist kein Bug in Ihrem KI-Rollout. Sie zeigt früher als die meisten Dashboards, wo Review-Fähigkeit, Kontextwissen und Ownership erodieren könnten.
Ob sie das bleibt, hängt davon ab, ob das Management sie als Signal behandelt oder als Rauschen. Wer die Verlässlichkeits-Schicht auf die Roadmap holt und die Identitäts-Schicht auf eine eigene Spur, bekommt aus derselben Person zwei Dinge zurück: eine bessere Architektur und einen Rollout, der auch in zwölf Monaten noch funktioniert.
Wenn Sie den Rollout auf dem Boden halten wollen, auf dem Ihr Betrieb tatsächlich läuft, sprechen Sie mich an.
Quellen
- METR: We are Changing our Developer Productivity Experiment Design (Februar 2026)
- Sonar: State of Code Developer Survey Report 2026
- Anthropic: How AI Assistance Impacts the Formation of Coding Skills (Januar 2026)
- Annie Vella: The Software Engineering Identity Crisis
- Gai, Hou, Tu: Competence Penalty Is a Barrier to the Adoption of New Technology (SSRN Working Paper, Mai 2025)
- Fraunhofer IESE: KI in der Softwareentwicklung · Neue Erkenntnisse aus Forschung und Praxis (Oktober 2025)
