KI-Adoption ist nicht dasselbe wie KI-Nutzung

Jede Engineering-Organisation, mit der ich dieses Jahr gesprochen habe, hat irgendeine Version desselben Charts. Seat-Aktivierungen steigen. Token-Ausgaben steigen. Auf irgendeiner Folie steht 80 % wöchentlich aktiv. Dann sitzt man im Planning-Meeting dieses Teams, und an der Art, wie sie Software bauen, hat sich nichts geändert.

Diese Lücke ist das eigentliche Problem, und die Art, wie wir KI-Adoption meist messen, ist unabsichtlich genau darauf ausgelegt, sie zu verstecken.

Alles, was Sie messen, ist eine Nutzungsmetrik

Token-Ausgaben sagen Ihnen, dass jemand etwas in ein Feld getippt hat. Die Anzahl der Pull Requests sagt Ihnen, dass Commits gelandet sind. „Prozentsatz des von KI geschriebenen Codes" sagt Ihnen, dass ein Autocomplete-Vorschlag akzeptiert wurde. Nichts davon sagt Ihnen, dass die Arbeit besser geworden ist.

Goodharts Gesetz, pünktlich wie immer. In dem Moment, in dem eine Zahl zum Ziel wird, beschreibt sie nicht mehr die Realität, sondern den Anreiz.

Die klarste Version dieses Fehlers ist nicht mal KI-spezifisch. Jeder Engineer hat schon erlebt, wie ein Team ein Coverage-Gate mit Tests umgeht, die nichts prüfen. expect(true).toBe(true). Zeile abgedeckt, Zahl grün, nichts getestet. Die Metrik war erfüllt und das Ziel wurde aufgegeben, und das Dashboard hat keine Möglichkeit, den Unterschied zu erkennen.

KI-Nutzungsmetriken haben dieselbe Form. Wenn ich meinem Team sage, dass Nutzung ein Leistungssignal ist, steigt die Nutzung innerhalb einer Woche, und ich habe nichts gelernt, außer dass sie Anreize lesen können. Was ich schon wusste.

Bessere Frage: Wenn Sie diese Tools morgen entfernen würden, was würde kaputtgehen? Nicht, worüber Menschen sich beschweren würden. Was würde kaputtgehen. Wenn die ehrliche Antwort „nichts, die Leute wären leicht genervt" lautet, haben Sie keine Adoption. Sie haben ein Abonnement.

Drei Dinge werden Adoption genannt. Nur eines hält.

Wenn ich in einem bestimmten Team nachfrage, was „wir haben KI adoptiert" eigentlich bedeutet, ist es eines von drei Dingen, und sie sind in ihrem Wert nicht annähernd gleich.

Jemand ändert seine eigene Schleife. Schreibt Commit-Messages damit, oder nutzt es, um sich in unbekanntem Code zu orientieren. Real, nützlich, fast völlig unbeständig. Beim ersten harten Deadline fallen sie zurück auf den Weg, von dem sie schon wissen, dass er funktioniert. Das ist kein Disziplinproblem. Unter Druck wählen Menschen den Weg mit der geringsten Unsicherheit, und ein neuer Workflow ist per Definition der mit der höheren Unsicherheit.

Jemand delegiert dauerhaft eine wiederkehrende Aufgabe. Nicht „Ich habe heute KI benutzt", sondern „Ich mache das nicht mehr, ein Workflow tut es, und ich prüfe das Ergebnis." Das überlebt Deadlines, weil eine Rückkehr bedeuten würde, sich selbst zusätzliche Arbeit zu schaffen. Es geht aber auch mit dieser Person, wenn sie geht.

Oder das Team ändert bewusst, wie es etwas tut. Jemand hat entschieden, dass ein Schritt im Prozess nun auf eine bestimmte Weise läuft, hat es dokumentiert, und es hält, egal ob eine einzelne Person gerade begeistert ist oder nicht. Nur das Dritte überlebt Fluktuation und ein schlechtes Quartal.

Die meisten Organisationen feiern das Erste, erreichen gelegentlich das Zweite und kommen nie zum Dritten. Denn das Dritte ist kein Tooling-Problem. Lizenzen zu kaufen ist ein Budget-Gespräch. Eine Norm zu ändern bedeutet, laut zu sagen, dass der alte Weg schlechter war, und es dann zu verantworten, wenn der neue Weg in Woche drei etwas kaputt macht.

Bei Webflow war es Folgendes, das sich bei uns durchgesetzt hat: Prompts als gemeinsame, versionierte Artefakte zu behandeln statt als persönliches Eigentum. Früher hielt man sie in Scratch-Files, feilte wochenlang privat daran und verlor sie beim nächsten Rechnerwechsel. Jetzt liegen die guten im Repo, mit Owner, einem Hinweis, wann man sie einsetzt, und Review bei Änderungen, genau wie jeder andere Code. Es hat nichts an Tooling gekostet. Was es brauchte, war die Entscheidung, dass diese Art von Sache es wert ist, gepflegt zu werden.

Es hält, weil es nicht von der Begeisterung Einzelner abhängt. Neue Engineers erben die gute Version, statt einen Monat damit zu verbringen, sie neu zu entdecken. Findet jemand eine Verbesserung, bekommen alle sie, statt dass eine einzelne Person leise besser in ihrem Job wird.

Agenten starten gut, übernehmen schlecht

Hier ist das Muster, das Adoption tötet, bevor ein Team je die dritte Stufe erreicht.

Der Hebel konzentriert sich auf den Anfang einer Aufgabe. Von der leeren Seite zum plausiblen Entwurf geht es dramatisch schneller als früher. Vom plausiblen Entwurf zu korrekt und lieferbar geht es überhaupt nicht schneller, und diese Hälfte gehört immer noch Ihnen.

Also stellt ein Engineer fest, dass er fünf Dinge gleichzeitig starten kann, feuert sie alle ab und fühlt sich dabei produktiv. Dann kommen fünf Dinge zurück, die Review brauchen, und Review läuft single-threaded in einem einzigen Kopf ab, für Arbeit, die man nicht selbst geschrieben hat und von Grund auf rekonstruieren muss. Man hat nicht parallelisiert. Man hat auf der eigenen Aufmerksamkeit serialisiert, mit einer Warteschlangentiefe, die niemand bewusst so gewählt hätte.

Sie beenden diese Woche beschäftigter und unsicherer als die Woche davor, was eine wirklich schlechtere Erfahrung ist. Viele Menschen probieren agentenbasierte Workflows einmal aus, fühlen genau das, und hören still wieder auf. Wochen später zeigt sich das als Nutzungseinbruch und wird als Schulungslücke diagnostiziert.

Das ist es nicht. Es ist ein Problem der Arbeitsform. Delegieren an einen Agenten hat dieselbe Obergrenze wie Delegieren an eine Person: die Review-Kapazität der Person, die am Ende verantwortlich bleibt. Die Teams, die daraus echten Wert ziehen, haben sich konkret festgelegt, welche Arbeit sich mit einer leichten Prüfung sicher abgeben lässt und welche nicht, statt alles als gleich delegierbar zu behandeln.

Man kann keine Adoption managen, die man nicht bewerten kann

Wenn Sie die Ausgabe nicht bewerten können, ist jede Diskussion darüber, ob ein Workflow funktioniert, eine Bauchgefühl-Diskussion. Und Bauchgefühl-Diskussionen gewinnt, wer im Raum am selbstbewusstesten auftritt, eine furchtbare Art, Engineering zu betreiben.

Bewerten heißt nicht Benchmarks. Benchmarks sagen Ihnen, dass ein Modell allgemein gut ist. Sie müssen wissen, ob dieser Workflow bei der spezifischen Sache gut ist, die Ihr Team tut, das deckt kein Benchmark ab. Ein paar Dutzend echte Fälle aus Ihrer eigenen Domäne, bewertet gegen ein Raster, das Sie selbst festgelegt haben, erneut ausgeführt, jedes Mal wenn jemand einen Prompt ändert oder ein Modell wechselt. Klein ist in Ordnung. Es geht nicht um Präzision, sondern darum, eine Zahl zu haben, die sich aus Gründen bewegt, die Sie verstehen.

Ohne das können Sie einen Workflow, der sich verbessert hat, nicht von einem unterscheiden, dessen Fehler nur flüssiger geworden sind. In einer Demo sehen beide identisch aus.

Was ich tatsächlich tun würde

Streichen Sie pro Person eine wiederkehrende manuelle Aufgabe dauerhaft. Nicht „KI mal ausprobieren dafür". Nehmen Sie sie aus der Woche der Person heraus und machen Sie den Workflow zum offiziellen Verantwortlichen. Eine Aufgabe, die tot bleibt, schlägt zehn Experimente.

Machen Sie genau eine Team-Norm offiziell, schriftlich, in diesem Quartal. Eine. Klein genug, dass Sie sie tatsächlich durchsetzen, spezifisch genug, dass jemand sie brechen könnte.

Hören Sie auf, Nutzung nach oben zu berichten. Berichten Sie das Ergebnis, das die Nutzung eigentlich erzeugen sollte, auch in den Quartalen, in denen diese Zahl schlechter aussieht, als es die Nutzung getan hätte.

Nichts davon erfordert ein neues Tool, und genau das ist der eigentliche Punkt. Tools sind der billigste Teil davon und ziehen die meiste Aufmerksamkeit auf sich. Der teure Teil ist die Bereitschaft, die Arbeitsweise eines Teams bewusst zu ändern, öffentlich, mit dem eigenen Namen an der Entscheidung.