Die Produktivitätsgewinne durch KI-Coding-Tools sind real. Was sich bislang nicht zeigt, ist ein vergleichbarer Zugewinn bei Softwarequalität, Produktverständnis oder dem Lernen in der Organisation. Diese Lücke sollte man verstehen, bevor die Rechnung kommt.
Die wichtigsten Erkenntnisse:
- Anthropics CEO beziffert den Produktivitätseffekt von KI-Coding-Tools auf etwa 15–20 % – eine konservative Schätzung von jemandem, der allen Grund hätte, höhere Zahlen zu nennen. Anthropics eigene Engineers berichteten dagegen von einem Plus von 50 %. Die 30 Prozentpunkte Differenz zwischen beiden Zahlen sind der Ausgangspunkt für eine ehrlichere Diskussion darüber, was diese Tools tatsächlich leisten.
- Eine randomisierte kontrollierte Studie zeigt: Erfahrene Entwickler, die seit Jahren an komplexen Codebases mitarbeiten, waren mit KI-Tools messbar langsamer – obwohl sie selbst überzeugt waren, schneller zu sein.
- Goldman Sachs sieht auf gesamtwirtschaftlicher Ebene keinen nennenswerten Zusammenhang zwischen KI-Adoption und Produktivität, trotz realer Gewinne in spezifischen, eng umrissenen Anwendungsfällen.
- Das Risiko sind nicht die Tools. Es ist der Wettbewerbsdruck, der überlegte Einführung wie ein Risiko und unbedachte Einführung wie Mut aussehen lässt.
- Die Reibung des gemeinsamen Bauens – Grooming-Sessions, Code Reviews, der Entwickler, der sagt: "Diese Anforderungen widersprechen sich" – brachte etwas hervor, das über Software hinausging. KI-Agenten reproduzieren dieses Nebenprodukt nicht.
Was bedeutet "Vibe Coding" – und warum ist die Definition so wichtig?
Die Verwirrung beginnt schon beim Begriff. Im Februar 2025 prägte Andrej Karpathy den Begriff "Vibe Coding" in einem Tweet – als beiläufige Beschreibung eines Wochenend-Workflows, bei dem man sich vollständig der KI überlässt, alle Diffs ungelesen übernimmt und es einem egal ist, ob man den Code überhaupt versteht. Er bezog das Konzept ausdrücklich nur auf Wegwerfprojekte.
Was danach geschah, ist aufschlussreich. Karpathy selbst sagt inzwischen, dass er für ernsthafte Arbeit lieber von "Agentic Engineering" spricht – nicht weil er sich von KI-gestütztem Coding abgewandt hätte, sondern weil er findet, dass diese Praxis Aufsicht, Sorgfalt und Handwerk verdient. In einem Interview im No-Priors-Podcast vom März 2026 sagte er, er habe seit Dezember keine Zeile Code mehr selbst getippt.
Parallel dazu veröffentlichten Gene Kim und Steve Yegge Vibe Coding: Building Production-Grade Software (2025) und definierten unter demselben Namen eine rigorose professionelle Praxis – mit einem Vorwort von Dario Amodei. Andernorts kursiert der Begriff abwertend, als Stolzabzeichen, als Beschreibung von Demokratisierung und als nahezu synonyme Bezeichnung für KI-gestützte Entwicklung allgemein.
Das definitorische Chaos ist relevant, weil unter demselben Etikett sehr unterschiedliche Praktiken kursieren. Ein Team, das KI mit diszipliniertem Review, klaren Verantwortlichkeiten und sorgfältiger Verifikation einsetzt, klingt sprachlich ähnlich wie ein Team, das generierten Output ungeprüft übernimmt. Der Begriff ist schwammig; die Governance-Entscheidungen sind es nicht.
Dieser Beitrag ist kein Plädoyer gegen KI-gestützte Entwicklung. Er stellt die Frage, was passiert, wenn der kulturelle Druck, schnell, breit und lautstark KI einzuführen, Organisationen glauben lässt, sie täten das Sorgfältige, während sie tatsächlich das Unsorgfältige tun.
Was zeigt die Evidenz zur KI-Coding-Produktivität?
Die glaubwürdigsten Schätzungen fallen bescheidener aus, als die Schlagzeilen vermuten lassen – und die Lücke zwischen Wahrnehmung und Realität ist frappierend.
Dario Amodei lieferte im Februar 2026 im Dwarkesh Podcast wahrscheinlich die ehrlichste Schätzung von jemandem mit eigenem Interesse an höheren Zahlen. Er bezifferte den Produktivitätseffekt von KI-Coding-Tools auf rund 15–20 % – eine bewusst konservative Größenordnung von jemandem, der allen Grund hätte, mehr zu behaupten.
Eine separate interne Studie von Anthropic, Ende 2025 veröffentlicht und auf Befragungen von 132 unternehmenseigenen Engineers basierend, ergab selbstberichtete Produktivitätsgewinne von rund 50 %. Das sind unterschiedliche Messungen – einmal eine breite Produktivitätsschätzung, einmal die Selbstauskunft von Engineers eines KI-Unternehmens mit privilegiertem Frühzugang zu den Tools – aber die Lücke dazwischen lohnt einen genaueren Blick. Beide Zahlen messen Verschiedenes – und keine ist präzise. 30 Prozentpunkte Spannweite zwischen zwei groben Schätzungen, die in entgegengesetzte Richtungen weisen, sind dennoch aussagekräftig, gerade wenn die meisten KI-getriebenen Personalentscheidungen auf gefühlter Produktivität beruhen statt auf irgendetwas unabhängig Geprüftem.
METRs randomisierte kontrollierte Studie – eine der bislang strengsten unabhängigen Untersuchungen zu KI-Coding-Tools – konzentrierte sich genau auf den Kontext, der für Engineering-Verantwortliche am relevantesten ist: erfahrene Entwickler, die in großen, komplexen, ausgereiften Codebases arbeiten, an denen sie seit Jahren mitwirken. In diesem Setting waren Entwickler mit KI-Tools 19 % langsamer als ohne – obwohl sie vorab eine Beschleunigung um 24 % prognostiziert hatten. Noch aufschlussreicher: Nach Abschluss der Studie schätzten sie, KI habe sie 20 % schneller gemacht – während die objektiven Daten das Gegenteil zeigten.
METR weist sorgfältig darauf hin, dass dieser Befund sich möglicherweise nicht über das untersuchte Setting hinaus verallgemeinern lässt. Bei weniger erfahrenen Entwicklern, unbekannten Codebases oder Greenfield-Arbeit könnten KI-Tools anders abschneiden. Die Wahrnehmungslücke jedoch – die systematische Diskrepanz zwischen gefühltem und tatsächlichem Arbeitstempo – gilt deutlich breiter. Es ist diese Lücke, mehr noch als die Verlangsamung selbst, die einen Großteil der aktuellen Debatte um KI-Produktivität erklärt.
Goldman-Sachs-Ökonomen kamen in einer Analyse aus Q4 2025 zu dem Schluss, es gebe "keinen nennenswerten Zusammenhang zwischen Produktivität und KI-Einführung auf gesamtwirtschaftlicher Ebene". Dieselbe Analyse fand rund 30 % Produktivitätsgewinne in spezifischen, lokal begrenzten Anwendungsfällen – Softwarecoding und Kundenservice. Die KI-Produktivitätsstory ist real, aber punktuell. Sie ist noch nicht die breite Transformation, als die sie verkauft wird.
Was die aktuelle Evidenz stützt, ist enger gefasst als sowohl der Hype als auch die Gegenreaktion. KI-Coding-Tools können in bestimmten Kontexten substanzielle Gewinne bringen. Sie erzeugen zugleich eine wiederkehrende Wahrnehmungslücke, in der die subjektive Beschleunigung die gemessene Verbesserung übersteigt. Was die Evidenz noch nicht belegt, ist, dass schnellere Codeproduktion verlässlich in proportionale Gewinne bei Softwarequalität, Produktverständnis oder Teamlernen mündet.
Wie hält das Layoff-Narrativ der Evidenz stand?
Gerade die Unternehmen, die ihre Stellenstreichungen am lautesten mit KI-Produktivität begründen, sind oft jene, in denen die Evidenz am dünnsten ist.
Klarna ist der aufschlussreichste Fall – ausführlich von Fortune dokumentiert. Das Unternehmen behauptete, sein KI-Assistent leiste die Arbeit von 700 Kundenservice-Mitarbeitenden. Innerhalb weniger Monate beschwerten sich Kunden über generische Antworten und das Fehlen menschlicher Unterstützung, und das Unternehmen stellte wieder Personal ein. CEO Sebastian Siemiatkowski sagte unverblümt, was passiert war: "As cost unfortunately seems to have been a too predominant evaluation factor… what you end up having is lower quality." Klarna ist kein Beweis dafür, dass KI-Ersatzstrategien immer scheitern. Es ist ein anschauliches Beispiel dafür, was übersehen wird, wenn man bewältigtes Volumen mit gelieferter Qualität verwechselt.
Klarna ist der am besten dokumentierte Fall – aber kein Einzelfall. Über 2025 und 2026 hinweg verkündeten zahlreiche Unternehmen KI-bedingte Personalreduktionen, während Analysten und Insider auf Übereinstellungen während der Pandemie als die einfachere Erklärung verwiesen. Der Markt belohnte das KI-Framing trotzdem in nahezu jedem Fall.
Eine IBM-Studie unter 2.000 CEOs ergab, dass nur jedes vierte KI-Projekt den versprochenen Return on Investment liefert. Dennoch geben fast zwei Drittel an, die Sorge, den Anschluss zu verlieren, treibe sie zu Investitionen, bevor sie ein klares Bild vom Wert haben.
Diese letzte Statistik verdient genauere Beachtung. Der primäre Treiber für KI-Investitionen ist nicht Evidenz für Renditen – es ist die Angst davor, was passiert, wenn Wettbewerber schneller sind. Diese Angst ist nachvollziehbar und in manchen Kontexten rational. Aber sie schafft die Bedingungen für eine besondere Form kollektiver Selbsttäuschung: Organisationen verkünden KI-getriebene Transformationen nicht, weil die Transformation stattgefunden hat, sondern weil das Verkünden selbst wettbewerblich notwendig ist. Das Narrativ reist schneller als die Ergebnisse.
Und bis die Ergebnisse vorliegen, hat das Narrativ längst Personalentscheidungen, Investorenerwartungen und strategische Festlegungen geprägt, die sich nur schwer rückgängig machen lassen.
Die Tools sind real. Das Narrativ leistet Arbeit, die die Tools nicht leisten.
Warum ist schnellere Codeproduktion nicht dasselbe wie bessere Software?
Das ist die wichtigere Frage – und sie reicht weit über die Produktivitätsdebatte hinaus.
Öffnen Sie die Claude-App auf Ihrem iPad. Sie funktioniert. Wer sie regelmäßig benutzt, merkt aber auch: Hier hat offensichtlich niemand intensiv aus der Perspektive eines Menschen nachgedacht, der ein iPad in den Händen hält und sich wünscht, dass sich etwas richtig anfühlt.
Das ist primär kein Problem der Codegenerierung. Es ist ein Urteilsproblem: Jemand musste entscheiden, was die App sein soll, wie sie sich anfühlen soll und was Sie veranlasst, dazu zu greifen statt zum Browser. Bessere Codegenerierung kann die Implementierung beschleunigen, löst aber für sich genommen nicht diese Entscheidungsebene. Diese Ebene zu lösen, erfordert anhaltende Aufmerksamkeit dafür, was andere Menschen tatsächlich erleben – und diese Art von Aufmerksamkeit ist langsam, unsicher und lässt sich nicht herbeivibieren.
Wenn Produktion günstig und schnell wird, sinkt der wirtschaftliche Druck, vor dem Bauen sorgfältig nachzudenken. Sie können in wenigen Tagen etwas Plausibles ausliefern und dann iterieren. Der kumulative Effekt: Diese Logik schreckt aktiv von der Investition in echtes Nutzerverständnis ab, die Software erst lohnenswert macht. Warum Wochen in sorgfältige User Research stecken, wenn man launchen und schauen kann, was passiert? Das Problem: "Schauen, was passiert" liefert nur dann nützliche Erkenntnisse, wenn Sie vorher festgelegt haben, wonach Sie suchen und warum. Ohne das offenbart das, was Sie launchen, weniger als erwartet, und das Beheben dessen, was Sie finden, kostet mehr als geplant. Bis das klar wird, sind die Entscheidungen längst gefallen. Es ist derselbe Reflex in anderer Gestalt: optimieren auf das Sichtbare und Schnelle, aufschieben, was langsam und schwer messbar ist.
Diese Tendenz – die spannende Kennzahl zu optimieren und den ermöglichenden Mechanismus dabei zu vernachlässigen – ist nicht neu. Als sich in den 1920er-Jahren ein Kunde über die Bremsen seines Type-35-Rennwagens beschwerte, soll Ettore Bugatti geantwortet haben: "Ich baue meine Autos zum Fahren, nicht zum Anhalten." Das Zitat ist rund 100 Jahre alt. Die Denkhaltung dahinter ist offenbar zeitlos. Bugattis Wagen waren schön, kraftvoll und notorisch unterbremst. Sie fuhren sehr schnell – bis sie es nicht mehr taten.
2023 veröffentlichten Gene Kim und Steven Spear Wiring the Winning Organization, eine Studie über High-Performance-Organisationen, die das Gegenmittel benannte: Slowification. Sich Zeit zu nehmen, um zu planen, vorzubereiten und gemeinsames Verständnis aufzubauen, bevor man ausführt, ist nicht das Gegenteil von Geschwindigkeit – es ist das, was Geschwindigkeit nachhaltig macht. Die Organisationen, die in bewusste Vorbereitung investierten, hängten jene durchgängig ab, die jeden Moment des Abwägens als zu eliminierenden Kostenpunkt betrachteten. Kim war später Co-Autor von Vibe Coding: Building Production-Grade Software – und plädiert dort für genau diese Art rigoroser, bewusster Praxis. Das Prinzip, das er 2023 identifizierte, gilt unmittelbar dafür, wie auch diese Form der Entwicklung anzugehen ist.
Die Decke der Produktion ist nach oben gerückt. Die Decke des Verstehens hat sich nicht bewegt.
Das ist kein neues Muster. Jede Generation besseren Toolings – ausdrucksstärkere Sprachen, reichhaltigere Frameworks, Cloud-Infrastruktur – machte es billiger und schneller, Dinge zu bauen, ohne sie zu verstehen. Die Low-Code-Bewegung versprach, Softwareerstellung zu demokratisieren, und lieferte überwiegend Software, die schnell zu erstellen und frustrierend zu nutzen war. KI-Coding-Tools sind die bislang mächtigste Ausprägung dieses Musters, nicht seine Erfindung.
Die Lücke zwischen dem, was Organisationen bauen können, und dem, was sie wirklich verstehen, hat sich auf jeder Abstraktionsebene reproduziert. Sie reproduziert sich jetzt schneller als je zuvor.
Was geht verloren, wenn KI-Agenten menschliche Entwickler ersetzen?
Das Urteilsvermögen, das Software gut macht, lag nie nur bei Product Managern. Es war verteilt – über das Team, durch die Reibung des gemeinsamen Bauens.
Nicht jede Reibung ist wertvoll. Manches davon ist Bürokratie, Latenz und vermeidbarer Ballast. Aber ein Teil davon ist der Ort, an dem kollektives Verständnis entsteht – und die aktuelle Automatisierungswelle macht es leicht, beides auf einmal zu entfernen.
Das ist nicht rein theoretisch. In Engineering-Communitys zeigt sich gerade durchgängig dasselbe Muster in der Art, wie Entwickler ihre eigene Erfahrung beschreiben: schneller ausliefern, sich produktiver fühlen und leise den Überblick darüber verlieren, was das System eigentlich tut und warum. Die oben genannte Forschung bestätigt das auf Makroebene. Die Gespräche aus der Praxis ebenso.
Wenn ein Entwickler in einer Grooming-Session einwarf – "Ich kann das nicht bauen, weil zwei dieser Anforderungen sich direkt widersprechen" –, wurde die Organisation gezwungen, sich mit etwas auseinanderzusetzen, was sie erfolgreich vermieden hatte. Dieses Unbehagen war kein Versagen des Planungsprozesses. Es war der Planungsprozess, der funktionierte. Die Anforderung war so geschrieben worden, dass sie kohärent aussah, bis jemand tatsächlich versuchte, sie umzusetzen. Die Verwirrung des Entwicklers war der Spiegel der Organisation.
Wenn ein Code Review zwischen einem Senior und einem Junior Engineer stattfand, gingen beide mit etwas heraus, das sie vorher nicht hatten. Der Junior lernte, wie er über eine ganze Klasse von Problemen denken sollte. Der Senior musste etwas in Worte fassen, das er zuvor nur stillschweigend wusste – und das Aussprechen schärfte es. Das Gespräch war das Lernen. Der Code war nur sein Niederschlag.
Diese Unterscheidung ist wichtiger, als sie scheint. Michael Polanyi hat sich eine Karriere lang darum bemüht, sie präzise zu fassen. "Wir wissen mehr, als wir sagen können", schrieb er in The Tacit Dimension – und die logische Folge lautet: Was wir sagen können, ist immer weniger als das, was wir tatsächlich wissen.
Verständnis, das durch Praxis aufgebaut wird, ist von anderer Art als Information, die durch Lesen oder Unterweisung erworben wird. Sie können sich nicht in das Wissen hineinlesen, wie ein komplexes System unter Last versagt oder wie ein bestimmter Nutzertyp einer bestimmten Art von Verwirrung begegnet. Sie müssen dabei gewesen sein – das Modell im Kopf gehabt, gesehen haben, wie es bricht, und das überarbeitete Verständnis aus den Trümmern des vorherigen aufgebaut haben.
Genau das brachten die Grooming-Session und das Code Review hervor – als Nebenprodukt der Reibung, ob es jemand benannte oder nicht.
Ein KI-Agent erzeugt diese Nebenprodukte nicht. Er macht klaglos weiter. Die Folgsamkeit des Agenten ist kein Beweis dafür, dass Ihre Anforderungen klar waren. Sie ist ein Beweis dafür, dass der Agent sich nicht beschwert.
Sie können den Code eines KI-Agenten reviewen. Sie können dieses Gespräch nicht mit ihm führen. Der Agent wird das Review nicht als Verständnis weitertragen. Der Junior-Entwickler, der durch Jahre solcher Austausche geformt worden wäre, wird zunehmend gar nicht mehr eingestellt. Und die Organisation, die diese Austausche durch generierten Code ersetzt hat, hat einen Mechanismus entfernt, von dem sie vielleicht nicht wusste, dass sie auf ihn angewiesen war – einen Mechanismus, der etwas ganz anderes tat, als Software zu produzieren.
Die Frage, die es zu stellen lohnt
Die relevante Kennzahl ist nicht nur, wie viel schneller Sie ausliefern. Sie ist, ob die Produktionsgewinne von Gewinnen an Klarheit, Urteilsvermögen und Lernen begleitet werden.
Das ist kein Plädoyer gegen KI-Tools. Gut eingesetzt – mit der Aufsicht, dem Handwerk und dem Urteilsvermögen, auf denen Karpathy, Kim und Yegge gleichermaßen bestehen – sind diese Tools wirklich wertvoll. Die Frage ist, ob das aktuelle Umfeld die Bedingungen für diese Art der Nutzung schafft. Die Wettbewerbsangst, der Druck, vor dem Nachdenken auszuliefern, das wachsende Gefühl, dass Verlangsamen, um etwas zu verstehen, eine Form von Underperformance sei: nichts davon erzeugen die Tools selbst. Es ist die kulturelle Luft, die sie derzeit umgibt.
Rennfahrer wissen: Bremsen sind nicht zum Verlangsamen da. Sie sind dazu da, Commitment zu ermöglichen – härter in Kurven gehen zu können, weil man darauf vertraut, im Notfall stoppen zu können. Die Reibung, die Teams derzeit im Namen der Velocity entfernen, war oft genau das: kein Overhead, keine Ineffizienz, sondern der Mechanismus, der schnelles Fahren überhaupt erst ermöglichte. Wer KI-gestützte Entwicklung rigoros betreibt, weiß das. Die Organisation, die von Wettbewerbsangst mitgerissen wird, oft nicht.
Mehr Code auszuliefern ist nicht dasselbe wie bessere Software zu bauen – und war es nie. Code war immer ein Artefakt – der sichtbare Niederschlag des Verständnisses, das ihn hervorbrachte, nicht das Verständnis selbst. Was sich geändert hat, ist nicht die Verwechslung von Artefakt und Verständnis. Es ist, wie schnell und billig es geworden ist, diese Verwechslung im großen Maßstab aufrechtzuerhalten.
Die Frage, die es zu stellen lohnt – ehrlich, konkret, in Bezug auf Ihr eigenes Team – ist, welche Art der Einführung Sie tatsächlich praktizieren. Diese Frage profitiert meist von einer Außenperspektive – von jemandem, der beide Arten gesehen hat und weiß, worauf zu achten ist.
Auf diese Fragen gibt es keine sauberen Antworten – und wer das Gegenteil behauptet, stellt sie wahrscheinlich nicht ernsthaft genug. Bei DoiT haben wir mit Hunderten von Engineering- und Technologie-Verantwortlichen gearbeitet, die sich genau in diesem Spannungsfeld bewegen – und herausfinden mussten, was sie behalten, was sie verändern und was sie unbemerkt zu verlieren drohten. Unsere Erfahrung: Die richtigen Fragen, mit den richtigen Leuten gestellt, bringen meist bessere Antworten hervor als jedes Framework. Wenn Sie etwas sehen, das wir übersehen, oder einen Weg gefunden haben, der für Sie funktioniert, freuen wir uns, davon zu hören.
Häufig gestellte Fragen
Welche unterschiedlichen Bedeutungen hat "Vibe Coding"? Der Begriff hat aktuell mindestens drei verschiedene Bedeutungen. In seinem ursprünglichen Sinn – geprägt von Andrej Karpathy im Februar 2025 – beschrieb er einen lockeren Workflow nach dem Motto "sich der KI hingeben", geeignet für Wegwerfprojekte. Gene Kim und Steve Yegge definierten in ihrem Buch Vibe Coding: Building Production-Grade Software (2025) anschließend unter demselben Namen eine ernsthafte professionelle Praxis und betonten Rigorosität, Aufsicht und Handwerk. Im allgemeinen Sprachgebrauch dient er außerdem als generelles Synonym für KI-gestützte Entwicklung und alternativ als abwertende Bezeichnung für unbedachte KI-Adoption. Das definitorische Chaos ist relevant: Wenn derselbe Begriff sowohl gedankenloses Akzeptieren von KI-Output als auch diszipliniertes Agentic Engineering bezeichnet, wird ein sinnvolles Gespräch darüber, was ein bestimmtes Team eigentlich tut, sehr schwierig.
Können KI-Coding-Tools die Produktivität steigern, ohne die Softwarequalität zu verbessern? Ja. Die Evidenz legt nahe, dass sie das im großen Maßstab bereits tun. KI-Tools können den Code-Output messbar erhöhen und Lieferzyklen verkürzen, ohne das Urteilsvermögen darüber, was gebaut werden sollte, die Klarheit der Anforderungen oder die Tiefe des Nutzerverständnisses hinter dem Produkt zu verbessern. Goldman Sachs sieht reale Produktivitätsgewinne im Softwarecoding als spezifischem Anwendungsfall. Was sich nicht zeigt – und was die breitere Evidenz noch nicht belegt – ist, dass diese Gewinne sich in proportionale Verbesserungen bei Softwarequalität oder Produktergebnissen niederschlagen.
Was hat die METR-Studie zu KI-Coding tatsächlich gezeigt? METRs randomisierte kontrollierte Studie aus 2025 testete 16 erfahrene Entwickler an 246 realen Aufgaben in großen, ausgereiften Open-Source-Codebases, die sie gut kannten. Entwickler mit KI-Tools brauchten 19 % länger als ohne – obwohl sie vorab eine Beschleunigung um 24 % prognostizierten und auch danach noch glaubten, schneller gewesen zu sein. METR weist darauf hin, dass der Befund spezifisch für diesen Kontext ist und sich möglicherweise nicht auf weniger erfahrene Entwickler oder unbekannte Codebases übertragen lässt. Die Wahrnehmungslücke – systematisch zu glauben, KI helfe, während die Daten das Gegenteil zeigen – ist der am breitesten anwendbare Befund.
Warum ist die Lücke zwischen selbstberichteter und gemessener KI-Produktivität so groß? Zwei Datenpunkte beleuchten die Lücke aus unterschiedlichen Blickwinkeln. In seinem Podcast-Auftritt im Februar 2026 schätzte Dario Amodei den Produktivitätseffekt von KI-Coding-Tools auf rund 15–20 %. Eine separate interne Anthropic-Studie von Ende 2025 ergab, dass die hauseigenen Engineers von Anthropic einen Produktivitätsschub von 50 % berichten – eine andere Messung, aber die Lücke zwischen beiden ist aufschlussreich. METRs Studie zeigte ein ähnliches Wahrnehmungsmuster: Entwickler glaubten, KI habe sie um 20 % beschleunigt, während die objektive Messung eine Verlangsamung von 19 % auswies. METRs eigene Analyse der Lücke nennt mehrere Faktoren: KI-gestütztes Coding erfordert weniger kognitive Anstrengung und fühlt sich schneller an, selbst wenn es das nicht ist; Entwickler verwechseln möglicherweise Leichtigkeit mit Geschwindigkeit; und die Zeit, die für das Reviewen, Korrigieren und Aufräumen KI-generierten Codes draufgeht, fließt in Selbstauskünfte typischerweise nicht ein.
Was geschah, als Klarna Kundenservice-Mitarbeiter durch KI ersetzte? Klarna ersetzte rund 700 Kundenservice-Stellen durch einen mit OpenAI entwickelten KI-Assistenten und behauptete, die KI leiste gleichwertige Arbeit. Innerhalb weniger Monate beschwerten sich Kunden über generische Antworten und das Fehlen menschlicher Unterstützung, weil die KI-Agenten mit komplexen, nuancierten und emotional aufgeladenen Interaktionen kämpften. CEO Sebastian Siemiatkowski räumte den Fehler offen ein: "As cost unfortunately seems to have been a too predominant evaluation factor… what you end up having is lower quality." Das Unternehmen begann 2025 wieder mit der Einstellung menschlicher Kundenservice-Mitarbeitender. Der Fall ist nicht nur als Misserfolgsgeschichte aufschlussreich, sondern auch als Beispiel dafür, was verloren geht, wenn die Kennzahl bewältigtes Volumen statt nachgewiesenes Verstehen ist.
Was ist Slowification und warum ist das für Software-Teams relevant? Slowification ist ein Konzept aus Gene Kim und Steven Spears Buch Wiring the Winning Organization (2023). Es beschreibt die bewusste Investition in Planung, Vorbereitung und gemeinsames Verständnis vor der Ausführung – das Verlangsamen, um nachgelagert schneller und verlässlicher voranzukommen. Ihre Forschung in High-Performance-Organisationen zeigte, dass dies ein konsistenter Differenzierer war: Teams, die slowifizierten, hängten jene durchgängig ab, die jeden Moment des Abwägens als Kostenpunkt behandelten. Das Prinzip lässt sich unmittelbar auf Softwareentwicklung übertragen: die Grooming-Session, die sorgfältige User Research, das Code Review, das sich langsam anfühlte, taten oft genau dies – sie produzierten das gemeinsame Wissen, von dem selbstbewusste Ausführung abhängt.
Können KI-Tools den Output erhöhen und gleichzeitig das Verständnis verringern? Ja – und das ist wohl die wichtigere Frage als die, ob sie die Produktivität erhöhen. Output und Verständnis werden durch unterschiedliche Mechanismen erzeugt. Code entsteht durch Ausführung; Verständnis entsteht durch die Reibung, sich gemeinsam durch Probleme zu arbeiten – durch den Entwickler, der widersprüchliche Anforderungen zurückweist, durch das Code Review, in dem ein Senior Engineer etwas in Worte fassen muss, das er zuvor nur stillschweigend wusste, durch die Grooming-Session, in der ein Team feststellt, dass das, was wie eine klare Spezifikation aussah, es eben nicht ist. KI-Agenten erzeugen diese Nebenprodukte nicht. Sie beschweren sich nicht, klären nicht und tragen das Gespräch nicht als Lernen weiter. Eine Organisation kann mehr Software ausliefern und dabei den Überblick darüber verlieren, was ihre Systeme tun, warum sie so gebaut wurden und was ihre Nutzer tatsächlich brauchen. Der Output steigt. Das Verständnis, das ihn begleiten sollte, hält nicht Schritt.
Sagt Goldman Sachs, dass KI keinen Produktivitätseffekt hat? Nicht ganz. Goldman-Sachs-Ökonomen sehen in derselben Analyse aus Q4 2025 keinen nennenswerten Zusammenhang zwischen KI-Einführung und Produktivität auf gesamtwirtschaftlicher Ebene. Dieselbe Analyse fand rund 30 % Produktivitätsgewinne in spezifischen, lokal begrenzten Anwendungsfällen – Softwarecoding und Kundenservice waren die beiden meistgenannten. Das Bild ist eines realer Gewinne in spezifischen Kontexten, die sich noch nicht in eine breite gesamtwirtschaftliche Produktivitätsverbesserung übersetzt haben. Diese Unterscheidung ist relevant dafür, wie Organisationen über ihre KI-Investitionen nachdenken sollten: gezielte Einführung in Kontexten, in denen die Gewinne gut belegt sind, ist etwas anderes, als KI als allgemeinen Produktivitätsmultiplikator zu behandeln.