Messen, was knapp bleibt

Irgendwo bei Meta gibt es ein Dashboard, das diesen Sommer eine großartige Geschichte erzählt hat. Die Code-Änderungen an den KI-Plattformen und der KI-Infrastruktur: plus 220 % im Jahresvergleich. Die Adoption der Coding-Werkzeuge: überall im Anstieg. Die Grenzkosten der Softwareproduktion: im freien Fall. Jeder Vorstand hätte angesichts dieser Zahlen auf die AI-native Transformation angestoßen.

Dann gibt es die zweite Zahl, die Reuters am 26. August zusammen mit dem Rest der Recherche veröffentlicht hat: die Features und Verbesserungen, die tatsächlich bei den Nutzern ankamen, wuchsen um 36 %. Und eine dritte: schwere technische und Sicherheits-Incidents, plus 40 %. Und eine vierte: die Zeit, die die Mitarbeiter mit deren Behebung verbrachten, plus 70 %.

Der Kontext verdient zwei Zeilen, weil er fast zu perfekt ist. Der Plan hieß Project OT, Organization Transformation, und entstand im Januar beim Führungsretreat auf Hawaii: ein „AI natives“ Unternehmen, Teams in manchen Szenarien um bis zu 60 % verkleinert, Populationen von Virtual Workers, beaufsichtigt von kleinen, talentdichten Gruppen von Menschen. Meta entließ im Mai 10 % der Belegschaft und sagte dann die zweite Welle ab, die für November geplant war. Auf Anfrage beschrieb das Unternehmen die aggressivsten Kürzungen als Szenarien in Prüfung, nicht als getroffene Entscheidungen. Und in einem Punkt hat es recht: wir kennen weder die internen Definitionen dieser Metriken noch den genauen Geltungsbereich noch das Gewicht der organisatorischen Variablen. Das Verhältnis zwischen 220 und 36 ist keine wissenschaftliche Messung der KI-Produktivität, und es wäre unredlich, es so zu verwenden.

Aber nicht die Zahl macht den Fall interessant. Es ist die Form. Auf der einen Seite ein Produktionsindikator, der explodiert; auf der anderen ein Ergebnisindikator, der sich kaum bewegt, während die operative Last wächst. Es ist nicht gesagt, dass die KI gescheitert ist. Gescheitert ist vielleicht unsere Vorstellung von Produktivität.

Goodhart hat nicht die KI erfunden

Bevor wir der KI ein Problem zuschreiben, das mit dem Management geboren wurde, räumen wir alles ein, was einzuräumen ist. Codezeilen sind seit Jahrzehnten ein miserables Maß für die Qualität eines Programmierers. Die Zahl geschlossener Tickets bläht sich auf, wenn man die Arbeit in kleinere Tickets zerlegt. Die Scrum-Velocity wächst durch Neukalibrierung der Story Points. Die Testabdeckung steigt mit Tests, die nie eine Regression finden würden. Incidents nehmen ab, wenn man aufhört, sie zu erfassen. Charles Goodhart schrieb es 1975, mit dem Understatement eines Zentralbankers: jede beobachtete statistische Regelmäßigkeit neigt dazu zu kollabieren, sobald man sie zu Kontrollzwecken unter Druck setzt. Die Version, die alle zitieren, „wenn ein Maß zum Ziel wird, hört es auf, ein gutes Maß zu sein“, stammt in Wirklichkeit von Marilyn Strathern, die zwanzig Jahre später die Evaluation der britischen Universitäten kommentierte. Das Problem der Proxy-Metriken ist fast so alt wie die Idee, Arbeit zu messen.

Die KI erfindet Goodhart nicht. Sie verändert den Maßstab. Solange die Optimierung der Proxy menschliche Arbeit verlangte, hatte das Gaming Kosten, und diese Kosten waren eine natürliche Grenze: du konntest die Tickets kleiner schneiden, aber schließen musstest du sie trotzdem selbst. Jetzt produziert ein System nahezu beliebige Mengen dessen, was die Metrik zählt, zu nahezu null Kosten. Die Maschine muss das Maß nicht fälschen. Es genügt ihr, billig zu machen, was das Maß zählt. Von da an kann der Indikator weiter wachsen, während das, was wir eigentlich verbessern wollten, stillsteht oder schlechter wird.

Die Knappheit war die Information

Es lohnt sich, zwei Phänomene zu unterscheiden, die sich nur an der Oberfläche ähneln. Beim traditionellen Gaming manipuliert eine Person absichtlich einen Indikator: man bewertet mich nach geschlossenen Tickets, also erzeuge ich kleinere Tickets. Das ist opportunistisches Verhalten, und eine Organisation kann es mit Kultur, Anreizen, Kontrollen korrigieren.

Mit der KI passiert etwas anderes, und es passiert ganz ohne Absicht. Ein Entwickler nimmt einen Coding-Agenten in Gebrauch. Der Agent produziert mehr Commits, mehr Tests, mehr Refactoring, mehr Dokumentation, mehr Pull Requests. Der Entwickler betrügt nicht: das System produziert wirklich mehr. Das Problem ist, dass die Knappheit verschwunden ist, die die Menge informativ machte. Niemand misst die Produktivität eines Managers an der Zahl der versendeten E-Mails, denn eine E-Mail zu versenden kostet nichts. Die Pull Request nimmt allmählich dieselbe Natur an. Das ist keine Krise der Manipulation: es ist eine Krise der Kommodifizierung des messbaren Outputs.

Die richtige Metapher kommt aus der Geldtheorie. Wenn sich die Geldmenge vervielfacht, ohne dass die Güter entsprechend zunehmen, trägt jede Einheit weniger Information über den Wert. Etwas Analoges geschieht mit den Artefakten der Unternehmen: mehr Code, mehr Berichte, mehr Analysen, mehr Folien, mehr Alternativen, mehr Findings. Ein fünfzigseitiger Bericht, in dreißig Sekunden generiert, repräsentiert nicht dasselbe epistemische Investment wie ein Bericht, der eine Woche Recherche verlangte. Das macht ihn nicht schlechter. Es bedeutet, dass die Länge des Berichts fast nichts mehr über die Menge an Wissen sagt, die er enthält. Das gilt für Berichte, und es gilt, Zeile für Zeile, für Code.

Jede Metrik ist eine Theorie

Hier liegt der Schritt, der mir am nützlichsten erscheint, um zu verstehen, was wirklich bricht. Wenn wir etwas messen, beobachten wir nicht nur: wir stellen eine Hypothese über die Welt auf. Codezeilen enthalten die Hypothese, dass mehr Code wenigstens grob mit mehr Softwarearbeit zusammenhängt. Gemergte PRs enthalten die Hypothese, dass mehr integrierte Änderungen mehr verarbeiteten Wert darstellen. Die Velocity enthält die Hypothese, dass das Volumen abgeschlossener Story Points Fortschritt bedeutet. Die Lead Time enthält die Hypothese, dass es im Allgemeinen gut ist, die Spanne zwischen Beginn und Delivery zu verkürzen.

Eine Metrik funktioniert, solange die zugrunde liegende Kausalbeziehung hinreichend stabil bleibt. Die KI bricht nicht die Zahl: sie bricht die Theorie, die die Zahl rechtfertigte. Wenn ich ein Feature in fünf Minuten generiere, die Review aber doppelt so lange dauert, verbessert sich die Lead Time der Coding-Phase, der Gesamtzyklus nicht. Wenn ich hundert nutzlose Tests generiere, steigt die Abdeckung, ohne dass die Fähigkeit steigt, Regressionen zu finden. Wenn ich fünf alternative Implementierungen produziere, wächst die „produzierte Arbeit“, und die Arbeit, eine davon auszuwählen, wächst mit. Die Zahl ist noch da, so präzise wie zuvor. Der Kausalpfeil unter der Zahl ist es nicht mehr.

Die Arbeit verschwindet nicht, sie wechselt den Zustand

Die Erzählung der KI-Produktivität schaut fast immer auf die Stelle, an der Arbeit eliminiert wird, und misst fast nie mit derselben Sorgfalt die Arbeit, die weiter unten in der Kette entsteht. Ein Agent generiert in fünf Minuten den Code, der zwei Stunden brauchte: nominale Ersparnis, 115 Minuten. Dann braucht der Entwickler zwanzig Minuten, um zu verstehen, was geschrieben wurde; der Reviewer braucht zehn Minuten länger, weil der Diff dreimal so groß ist; eine Regression taucht auf; zwei Iterationen folgen; die Dokumentation muss nachgezogen werden; jemand muss die implizite Architekturentscheidung bemerken, die in Absatz drei versteckt ist. Die Aufgabe kostet trotzdem weniger als vorher. Aber nicht 115 Minuten weniger. Der wirkliche Gewinn ist die eliminierte Zeit minus die neuen Verifikationskosten, minus die neuen Integrationskosten, minus das eingeführte Risiko. Die erste Komponente lässt sich mit der Stoppuhr messen. Die anderen misst in vielen Organisationen niemand.

Das ist nicht mein Eindruck: es ist, was DORA seit zwei Jahren dokumentiert. Der Report 2024 verzeichnete, dass die KI-Adoption die von den Einzelnen empfundene Produktivität erhöhte und zugleich Durchsatz und Stabilität der Delivery verschlechterte, mit einer berühmt gewordenen Schätzung: jede weiteren 25 % Adoption gingen mit einem Rückgang des Durchsatzes um 1,5 % und der Stabilität um 7,2 % einher. Der Report 2025, bei inzwischen 90 % Adoption unter den Entwicklern, beschreibt die KI als Verstärker: sie beschleunigt die anfängliche Generierung, aber ein Teil der gewonnenen Zeit wird in Auditing und Verifikation reinvestiert, und die höchste Adoption geht zugleich mit höherem Durchsatz und höherer Instabilität einher. Nennen wir es eine Verification Tax. Die KI senkt die Produktionskosten, also produzieren wir mehr; jeder nicht deterministische Output muss kontrolliert werden, also wächst eine Ökonomie der Kontrolle. Je weiter die Generierungskosten sinken, desto größer wird der Anteil der Gesamtkosten, der auf die Verifikation entfällt. Im theoretischen Grenzfall, bei Generierungskosten von null, liegt der Wert des Prozesses fast vollständig in Spezifikation, Auswahl, Verifikation und Integration. Für eine Branche, die ein halbes Jahrhundert lang die Produktion gemessen hat, ist das eine vollständige Umkehrung.

Die ehrlichste Analogie ist eine Fabrik. Wenn ich die Geschwindigkeit der ersten Maschine der Linie verdopple, ohne die nachgelagerten Stationen anzufassen, verdopple ich nicht die Produktion: ich erzeuge eine Warteschlange. In der Software ist die Schlange weniger sichtbar, und sie erscheint als wartende PRs, aufgeschobene Architekturentscheidungen, instabile Tests, Merge-Konflikte, Rework, Incidents. Die Lean Production hat einen exakten Namen für Material, das eine Stufe produziert und die nächste nicht absorbieren kann: Inventar. Und Inventar ist kein Asset, es ist ein Kostenfaktor. Es muss gelesen, aktualisiert, getestet, gewartet und am Ende oft gelöscht werden. Agentischer Output, den das System nicht absorbieren kann, ist keine Produktivität. Er ist Inventar.

Der Engpass wird sichtbar

So weit die pessimistische Lesart. Es gibt aber eine Kehrseite, und sie ist fast eine gute Nachricht: die Krise der Metriken zwingt uns zu entdecken, was wirklich Wert produzierte. Wenn Code schreiben billig wird und die Delivery nicht proportional beschleunigt, dann war Code schreiben nicht der Engpass, für den wir es hielten. Vielleicht waren es das Verstehen des Problems, die Entscheidung des Kunden, das Reduzieren der Mehrdeutigkeit in den Anforderungen, das Reviewen, Integrieren, Validieren, das Deployment, der Aufbau von Vertrauen. Die KI funktioniert wie eine Maschine, die die wahre Produktionsfunktion der Organisation freilegt: sie beseitigt einen Kostenblock und zeigt, was übrig bleibt.

Und was übrig bleibt, ist vor allem die Aufmerksamkeit. Ein Mensch kann eine begrenzte Menge an Code lesen, an PRs, an Alerts, an Dokumenten. Agenten teilen diese Grenze nicht, oder nicht im selben Maß. Wenn die Output-Rate der Maschine die Rate qualifizierter menschlicher Aufmerksamkeit übersteigt, muss die Organisation wählen: Warteschlange anhäufen, die Tiefe der Review senken, auch die Review automatisieren, den Output reduzieren oder gezielt Menschen hinzufügen. Die gefährlichste Wahl ist die dritte, wenn sie ohne unabhängige Kontrollen getroffen wird, denn sie erzeugt ein System, in dem Maschinen generieren, Maschinen genehmigen und der Mensch eine Zusammenfassung liest. Wenn ein Coding-Agent hundert PRs produziert und ein Review-Agent fünfundneunzig genehmigt, sagt die Zahl der genehmigten PRs noch weniger als zuvor. Man muss messen, wie viel der Reviewer wirklich findet, wie korreliert die Failure Modes von Generator und Reviewer sind, wie viele Probleme trotzdem die Produktion erreichen. Die Regression ist potenziell unendlich, wer kontrolliert den Kontrolleur, und die Antwort kann nicht die nächste quantitative Metrik sein: es braucht deterministische Gates, unabhängige Evals und reale Outcomes. Es ist dasselbe Argument, das ich über das proprietäre Urteil gemacht habe: der Vorteil liegt nicht im Motor, der generiert, er liegt in den Kriterien, mit denen du entscheidest, ob das Generierte Vertrauen verdient.

Der Zähler der Adoption

Die Werkzeuge vervielfachen unterdessen, was sich zählen lässt. GitHub hat sein Copilot-Metriken-Dashboard im Februar allgemein verfügbar gemacht, im Juni die verbrauchten AI Credits in die Reports aufgenommen, im Juli die Metriken pro Repository ausgeliefert, mit den vom Coding-Agenten erstellten und gemergten PRs und den Reviews des Review-Agenten, dazu ein Impact-Dashboard, das die Nutzer in Adoptions-Kohorten sortiert, code-first, agent-first, multi-agent, jede mit der durchschnittlichen Zahl gemergter PRs pro Nutzer und den Codezeilen pro Tag. Das sind sehr nützliche Daten, um zu verstehen, wie das Werkzeug benutzt wird, und ich habe keine Ironie übrig für die Leute, die sie bauen. Gefährlich werden sie in dem Moment, in dem jemand sie mit der Frage verwechselt, wie viel Wert das Werkzeug schafft. Verbrauchte Tokens sind keine Produktivität. Generierte Zeilen sind keine Produktivität. Aktive Nutzer sind keine Produktivität. Von einem Agenten erstellte PRs sind keine Produktivität. Sie sind Adoptions-Telemetrie, und Adoption ist die Voraussetzung von Wert, nicht der Wert.

Dass die Verwechslung schon im Gang ist, zeigt sich daran, dass DORA im Juni der Fehlentwicklung einen Namen geben musste: Tokenmaxxing, Unternehmen, die interne Ranglisten der Mitarbeiter führen, die die meisten KI-Tokens verbrauchen, und sie dafür belohnen. Als Anstoß, die Zögerlichen zum Experimentieren zu bringen, mag das sogar funktionieren; als Leistungsindikator ist es die Parodie auf alles, was dieser Essay zu sagen versucht, zumal dieselbe DORA-Forschung verzeichnet, dass rund 30 % der Entwickler dem Output der Modelle wenig oder gar nicht vertrauen. Die Szene ist in ihrer Absurdität fast perfekt: wir haben die Intelligenz billig gemacht, und jetzt belohnen wir Menschen dafür, dass sie mehr davon verbrauchen.

Den nächsten Schritt erkennt jeder, der eine Organisation aus der Nähe gesehen hat. Das Management stellt fest, dass die KI die Kapazität um 40 % erhöht hat, und aktualisiert die Ziele: plus 40 % Tickets, Story Points, Features. Das Team benutzt die KI, um das neue Ziel zu erreichen, der neue Durchsatz wird zur Baseline, ein besseres Modell erscheint, und alles beginnt von vorn. Der technologische Gewinn wird nicht in weniger Schulden, bessere Qualität, mehr Discovery, mehr Resilienz umgewandelt: er wird vollständig von der Metrik eingefangen. Es ist ein organisatorisches Laufband, und es hat eine individuelle Variante, die schlimmer ist. Wenn ich Menschen nach produziertem Code, geschlossenen Tickets, geöffneten PRs, abgeschlossenen agentischen Tasks bewerte, belohne ich genau das, was die Maschine fast kostenlos produziert, und bestrafe die ökonomisch rationalsten Verhaltensweisen: weniger Änderungen machen, eine bessere Spezifikation schreiben, die Aufgabe ablehnen, das System vereinfachen. Individuelle KPIs drohen, mit Präzision das falsche Verhalten zu selektieren.

Es gibt eine Parallele, die die Transformation lesbarer macht. Ich habe vor einiger Zeit geschrieben, dass die KI das Time & Materials tötet, weil die Zeit aufhört, eine akzeptable Proxy für den gelieferten Wert zu sein. Das Timesheet und der Productivity Score sterben aus exakt demselben Grund. Das Timesheet unterstellt, Zeit sei gleich Wert; die Durchsatzmetrik unterstellt, Output sei gleich Wert. Die KI bricht beide Gleichungen im selben Moment, weil es dieselbe Gleichung ist: die Arbeit ist nicht mehr so viel wert wie die Zeit, die sie verlangt, und das Ergebnis ist nicht mehr so viel wert wie der Output, den es enthält.

Die Absorption messen

Wenn dieser Essay einen operativen Vorschlag hinterlassen soll, dann diesen: die Messung von der Produktion zur Absorption verschieben. Die Fragen müssen getrennt bleiben, denn sie zu vermischen ist genau der Fehler. Wird das System benutzt? Das ist Adoption. Was produziert es? Das ist Aktivität. Wie viel von dem, was es produziert, kann die Organisation wirklich integrieren? Das ist Absorption. Wie schnell durchquert die Arbeit den Prozess? Das ist Fluss. Erzeugt sie die Wirkung, die wir wollten? Das ist Outcome. Und zu welchen Gesamtkosten, mit welchen Restschulden? Das ist Nachhaltigkeit. Ein Unternehmen, das 90 % Adoption, plus 80 % generierten Code und plus 50 % Pull Requests beobachtet und daraus schließt, „die KI funktioniert“, hat die ersten beiden Fragen beantwortet und geglaubt, die anderen vier beantwortet zu haben.

Die Maßeinheit, auf die man zusteuern sollte, sind die Kosten pro akzeptiertem Outcome. Nicht Kosten pro Token, nicht Kosten pro Zeile, nicht Zeit pro Generierung: das Compute, die menschliche Zeit für Spezifikation und Review, das Rework, der Anteil an Incidents und Rollbacks, der der Änderung zuzurechnen ist, geteilt durch die Ergebnisse, die Review, Tests, Delivery und eine Beobachtungsphase überstanden haben. Das ist viel schwerer zu messen, und genau deshalb zählt es: die Schwierigkeit einer Messung ist fast immer proportional zu ihrer Relevanz.

Mit einer Warnung: „akzeptiert“ darf nicht auf „gemergt“ zusammenschrumpfen, sonst haben wir nur eine bequemere Proxy eine Stufe weiter gebaut. Eine gemergte PR kann falsch sein, ein ausgeliefertes Feature kann ungenutzt bleiben, ein Refactoring kann nichts verändern, ein Dokument kann keine Entscheidung berühren. Der Outcome hängt von der Art der Arbeit ab: bei einem Feature sind es Adoption und eine geringere Supportlast, bei einem Bug die eliminierte Wiederholung, bei der Security das materiell reduzierte Risiko, bei einem Refactoring die Delivery-Kosten und die Incident-Rate in den Monaten danach.

Drei Kennzahlen scheinen mir einfach genug, um eine Vorstandssitzung zu überleben. Die Output Absorption Ratio: die akzeptierten und bis zum Ergebnis gebrachten KI-Artefakte, geteilt durch die produzierten KI-Artefakte. Wenn die Generierung um 300 % wächst und die OAR einbricht, hast du nicht das Unternehmen beschleunigt: du hast die KI in einen Generator von Downstream-Arbeit verwandelt. Die Verification Load Ratio: die menschliche Verifikations- und Rework-Zeit im Verhältnis zur gesamten menschlichen Zeit im Workflow. Sie muss nicht zwingend minimiert werden, in einem hochkritischen Sektor ist eine hohe Verifikationslast vollkommen rational; sie zeigt, ob die in der Generierung erzielte Ersparnis wirklich gewonnen oder nur woandershin verschoben wurde. Und die Autonomous Acceptance Rate: die ohne substanziellen Eingriff akzeptierten agentischen Tasks im Verhältnis zu den abgeschlossenen, immer zusammen mit Defect Escape und Rollbacks gelesen, denn 95 % Akzeptanz mit vielen Regressionen ist miserabel, und 40 % mit sehr hoher Zuverlässigkeit kann exzellent sein.

Keine der drei darf zum neuen universellen KPI werden, und wer bis hierher gelesen hat, weiß warum: sie würde Goodharts nächstes Ziel. Der Punkt ist, Metriken in Spannung zu bauen, nie eine einzelne Zahl zum Maximieren. Das ist auch die wichtigste methodische Lektion von DORA: die fünf Delivery-Metriken messen Durchsatz und Instabilität zusammen, umfassen seit 2024 die Rework Rate der Deployments, gelten für einen Service nach dem anderen und sollen nicht in individuelle Ziele verwandelt werden. Jede Metrik, die Menge belohnt, gehört mit der Metrik gekoppelt, die deren Kosten darstellt: Generierung mit Rework, Deployment-Frequenz mit Instabilität, Agenten-Autonomie mit menschlichen Eskalationen, Security Findings mit validierten Findings. Die Spannung ist es, die die Proxy davon abhält, gehorsam zum Ziel zu werden.

Lob der negativen Produktivität

Es gibt eine Kategorie von Arbeit, die fast kein zählbares Artefakt produziert: zu einem nutzlosen Feature nein sagen, eine Anforderung vereinfachen, den Widerspruch in den Anforderungen entdecken, den Kunden davon abbringen, etwas zu bauen, ein verfehltes Projekt stoppen, einen plausiblen, aber falschen Output zurückweisen, Code löschen. In einer Kultur, die Produktion misst, sind diese Tätigkeiten unsichtbar. Wenn Produzieren fast kostenlos wird, werden sie zum wertvollsten Teil der Arbeit. Der Agent schlägt fünf Microservices vor, und der Architekt antwortet: einen. Der Agent generiert zweihundert Tests, und der Ingenieur behält dreißig aussagekräftige. Der Product Owner streicht drei von vier Features, bevor sie existieren. Der Wert des Profis wird subtraktiv, und der wertvollste Senior ist vielleicht der, der dem Team erlaubt, weniger zu generieren. Wie misst man das? Wie zählt man das Feature, das man nicht gebaut hat und das einen sechs Monate gekostet hätte? Es bräuchte eine kontrafaktische Buchführung, vermiedene Schulden, vermiedene Incidents, eliminierte künftige Wartung. Präzise Zahlen zuzuweisen ist fast unmöglich. Die Blickrichtung zu ändern nicht.

Es gibt noch einen subtileren Grund, warum der Überfluss schadet, und er betrifft die Reibung. Gewöhnlich nehmen wir an, Reibung zu reduzieren sei immer gut, aber manche Reibungen erfüllten eine Funktion: eine Spezifikation zu schreiben zwingt zum Denken, einen Bericht vorzubereiten zwingt zum Auswählen, ein teures Meeting wird manchmal schlicht nicht einberufen. Wenn etwas drei Tage kostete, fragte sich wenigstens jemand, ob es die Mühe wert war. Wenn es dreißig Sekunden kostet, verschwindet diese Frage zusammen mit den Kosten. Die KI beseitigt die Kosten der Handlung und mit ihnen einen Teil des Filters, der entschied, ob die Handlung es verdiente, ausgeführt zu werden: das war eine epistemische Reibung, nicht bloß Widerstand. Deshalb glaube ich, dass manche Organisationen bewusste Reibungen wieder einführen müssen, Budgets für agentische Tasks, Grenzen für die PR-Größe, Quality Gates, Freigaben: nicht weil die Maschine schlecht produziert, sondern gerade weil sie zu gut zu zu niedrigen Kosten produziert. Das sind Entscheidungen dessen, was ich Productivity Governance nennen würde: welchen Anteil der gewonnenen Kapazität wir in mehr Output umwandeln und welchen in bessere Qualität, wie viel agentische Produktion das System absorbieren kann, ohne dass die Schlange wächst, welche Outputs es überhaupt verdienen, ins System zu gelangen. Die KI kann diese Entscheidungen nicht für uns treffen, denn sie betreffen genau das, was die Organisation als Wert betrachtet.

Daher auch die richtige Frage für einen CEO. Nicht „um wie viel ist die Produktivität dank der KI gestiegen?“, sondern: welche Beschränkung unseres Systems wurde beseitigt, und welche Beschränkung ist jetzt dominant? Wenn ein Feature früher drei Tage brauchte und jetzt drei Stunden, ausgezeichnet: was braucht jetzt am meisten Zeit? Die Review, die Entscheidung des Kunden, das Testing, die Compliance, das Deployment? Das ist der neue Ort, an dem zu arbeiten ist. Andernfalls schüttet die Organisation nur mehr Material auf denselben Engpass und nennt die Länge der Warteschlange Produktivität.

Derselbe Film, in anderen Abteilungen

Software ist nur der sichtbarste Fall. Die Compliance hat exakt dasselbe Problem: die KI generiert Hunderte Policies, Tausende dokumentierte Kontrollen, vollständige regulatorische Mappings, tadellos formatierte Berichte. Zahl der Policies, der Kontrollen, der Assessments: alles kann explodieren, ohne dass die reale Konformität sich einen Millimeter bewegt. Ich habe geschrieben, dass ein Score kein Konformitätsnachweis ist, und die AI-native Metrik-Krise ist derselbe Übergang, aus einer anderen Abteilung betrachtet: von Compliance-Output zu Compliance-Outcome, nicht produzierte Dokumentation, sondern nachweisbare Fähigkeit, wie viele Kontrollen wirklich funktionieren und welche Evidenzen es beweisen.

Die Cybersicherheit, dasselbe. Die KI findet mehr Schwachstellen, ausgezeichnet. Dann müssen die Maintainer sie deduplizieren, validieren, ihre Schwere bestimmen, sie beheben, den Patch testen, ihn ausliefern. Wenn die Findings um 1.000 % wachsen und die behobenen Schwachstellen um 20 %, haben wir die Security nicht verbessert: wir haben die Schlange verlängert. Die Produktivität der Maschine kann zur Last der Institution werden.

Und außerhalb der Software gilt es allgemein. Wenn es fast nichts kostet, Artikel, Bilder und Berichte zu produzieren, dann hören Publikationszahlen, Volumen, Frequenz und Länge auf, Indikatoren kultureller Fähigkeit zu sein, und der Wert wandert zu Auswahl, Glaubwürdigkeit, Originalität, Vertrauen. Die AI-native Metrik-Krise ist der Spezialfall einer Regel, die überall gilt: wenn die KI einen Output im Überfluss verfügbar macht, hören die Metriken, die auf der Knappheit dieses Outputs gebaut sind, auf, etwas zu bedeuten.

Messen, was knapp bleibt

Die Geschichte der Informatik hat diesen Film schon gesehen. Die Unternehmen investierten jahrelang in Computer, bevor die Produktivität in den aggregierten Statistiken auftauchte; Robert Solow hat es 1987 im meistzitierten Bonmot der Innovationsökonomie festgehalten, das Computerzeitalter sieht man überall, nur nicht in den Produktivitätsstatistiken. Der Grund war nicht, dass die Computer nutzlos waren: Prozesse, Organisationen und Kompetenzen waren noch für den vorherigen Rhythmus entworfen, und es dauerte Jahre, sie neu zu gestalten. Die KI kann eine beschleunigte Version desselben Missverständnisses produzieren, mit einem erschwerenden Umstand: diesmal erzeugen die Werkzeuge den Nachweis ihrer eigenen Adoption gleich selbst. Wir kaufen Werkzeuge, wir messen Nutzung, wir sehen den Output explodieren, wir erklären die Produktivität für explodiert. Dann entdecken wir, dass Review, Freigaben, Verantwortung und Architektur noch auf den alten Rhythmus geeicht waren und dass das System nicht absorbieren kann, was die Maschine produziert.

Den größten Teil der Industriegeschichte haben wir Arbeit gemessen, indem wir zählten, was teuer zu produzieren war: Stücke, Stunden, Dokumente, Zeilen, Tickets, Transaktionen. Solange etwas menschliche Zeit verlangte, trug die produzierte Menge wenigstens eine Spur der Kosten ihrer Produktion in sich, also eine Information. Die KI bricht diese Gleichung, leise, ein Artefakt nach dem anderen. Sie kann Code ohne Mühe produzieren, Tests ohne Mühe, Analysen ohne Mühe, und sie kann damit fortfahren, auch wenn niemand mehr in der Lage ist zu lesen, was sie produziert. Unsere erste Reaktion, verständlich, ist, diesen Überfluss zu messen und ihn Produktivität zu nennen. Es ist auch der schnellste Weg, Organisationen zu bauen, die zu beschleunigen scheinen, während sie Material anhäufen, das jemand anderes wird verifizieren, integrieren, warten oder löschen müssen.

Vor der KI waren die Schreibzeit knapp, die Coding-Zeit, die Fähigkeit, Analysen und Alternativen zu produzieren. Die Metriken maßen das, und sie hatten recht: man misst den Engpass, nicht den Überfluss. Jetzt werden die Aufmerksamkeit knapp, das Urteilsvermögen, das Vertrauen, die Stabilität, die Fähigkeit zu entscheiden und die, die Verantwortung für ein Ergebnis zu übernehmen. Die Metriken müssen dorthin umziehen, wohin die Knappheit umgezogen ist. Miss nicht, was die Maschine im Überfluss produziert: miss, was das System weiterhin begrenzt.

Die erste AI-native Krise, wenn sie kommt, wird nicht wie ein technologischer Kollaps aussehen. Sie wird wie ein Dashboard voller exzellenter Zahlen aussehen. Die Maschinen werden die Ziele erreichen, die wir ihnen gegeben haben, die Menschen werden die KPIs erreichen, die wir um die Maschinen herum gebaut haben, und erst danach werden wir bemerken, dass diese Indikatoren eine Knappheit beschrieben, die nicht mehr existiert. Dann werden wir das tun müssen, was die Metriken uns ein Jahrhundert lang aufzuschieben erlaubt haben: entscheiden, was wir als Wert betrachten. Vielleicht ist das die tiefste Folge der KI für die Arbeit. Nicht, uns produktiver zu machen. Uns zu zwingen, endlich zu verstehen, worin wir produktiv sein wollten.

Der Autor

Andrea MargiovanniKI

Ich verfolge das Verhältnis zwischen KI und europäischer Regulierung als politisches Faktum, nicht als technisches Spektakel. Ich arbeite mit Teams, die KI mit AI Act, CRA, NIS2 vereinbar machen müssen, ohne Compliance auf eine Checkliste zu reduzieren.

Zum Weg →