Wir messen Ingenieure immer noch an dem Teil, der automatisiert wurde.

Es gibt einen Satz, den Ingenieurinnen und Ingenieure mit zwanzig Jahren Erfahrung inzwischen leise sagen, als gestünden sie etwas: Ich schreibe eigentlich keinen Code mehr.

Meist hängt eine kleine Entschuldigung daran. Das sollte nicht so sein. Das Interessante an diesem Satz ist nicht, was er über die sprechende Person aussagt. Es ist, was er über die Instrumente aussagt, mit denen wir entscheiden, ob diese Person gut ist.

Die Anzeigetafel wurde weggeworfen, und kaum jemand hat es bemerkt

Rund ein Jahrzehnt lang benotete die Branche die Auslieferung anhand von vier Zahlen und sortierte Teams in low, medium, high und elite. Diese Stufen wurden in Vorstandspräsentationen von Leuten zitiert, die den zugrunde liegenden Bericht nie gelesen hatten, was üblicherweise das Zeichen dafür ist, dass eine Messung wirklich tragend geworden ist.

2025 hat DORA sie aufgegeben. Die Stufen sind verschwunden und durch sieben Team-Archetypen ersetzt, beschrieben über acht Messgrößen: Throughput, Stabilität, Teamleistung, Produktleistung, individuelle Wirksamkeit, Zeit für wertvolle Arbeit, Reibung und Erschöpfung. Die Archetypen tragen Namen statt Ränge, von der Art, die man nicht auf eine Folie setzen und als Note ausgeben kann.

Man kann mit Recht einwenden, dass das schwerer anzuwenden ist als vier Zahlen und eine Leiter. Ist es. Doch der Grund für die Änderung ist der Teil, bei dem es sich zu verweilen lohnt: Die Hälfte dieser acht Messgrößen handelt überhaupt nicht von Produktion. Reibung, Erschöpfung, Zeit für wertvolle Arbeit und individuelle Wirksamkeit messen, ob eine Organisation das Urteilsvermögen verschwendet, das sie beschäftigt.

Das ist ein sehr konkretes Eingeständnis. Es besagt, dass das alte Instrument das Arbeitsvolumen maß und das Interesse daran verlor, ob die Arbeit die richtige war, und dass diese Unterscheidung nicht länger tragbar war.

Was die Zahlen sagen, und warum sie unbequem sind

Die Daten von 2025 erklären die Dringlichkeit. Rund 90 % der Befragten gaben an, KI bei der Arbeit zu nutzen, im Median etwa zwei Stunden täglich, gegenüber 75 % im Vorjahr. Vergleicht man Personen mit sonst gleichen Merkmalen und Umfeldern, geht höhere KI-Nutzung einher mit höherer individueller Wirksamkeit, höherem Throughput, besserer Organisationsleistung und besser berichteter Code- und Produktqualität.

Und mit höherer Instabilität der Softwareauslieferung.

Es lohnt sich, dieses Paar langsam zu lesen, denn seine Form ist das Argument. KI hat fast jede Kennzahl in die richtige Richtung bewegt, außer jener, die sagt, ob das System stehen bleibt. Die verbesserten Größen zählen Produktion. Die verschlechterte Größe zählt Folgen.

Wenn Ihr Bild eines Ingenieurs aus den ersten fünf Zeilen entsteht, wirken die letzten zwei Jahre wie ein Triumph. Entsteht es aus der letzten, wirken sie wie eine Warnung. Beide Lesarten stammen aus demselben Datensatz, und genau deshalb musste die Anzeigetafel weg.

Das gab es schon einmal, und wir wissen, wie es ausgeht

Vor zwanzig Jahren war eine gute Systemadministratorin jemand, der einen Server gut konfigurieren konnte. Die Fähigkeit war echt und knapp, und sie wurde über eine Art Throughput gemessen: wie viele Maschinen, wie schnell, mit wie wenigen Fehlern.

Dann kam Konfigurationsverwaltung, danach Infrastructure as Code. Ingenieure schrieben nicht mehr die Konfiguration, sondern beschrieben den gewünschten Zustand. Heute hält niemand jemanden, der Terraform nutzt, für weniger fähig als jemanden, der Maschinen von Hand konfiguriert. Im Gegenteil: Wir betrachten Handkonfiguration als Risiko, weil sie sich nicht prüfen, nicht reproduzieren und nicht zurückrollen lässt.

Die Arbeit verschwand nicht. Sie stieg eine Ebene auf. Was ein Akt der Produktion war, wurde ein Akt der Spezifikation, und die Schwierigkeit wechselte den Ort: weg vom korrekten Ausführen, hin zum korrekten Entscheiden, denn ein Fehler in einem Modul erreicht nun vierhundert Maschinen statt einer.

Wir haben das nie einen Abstieg genannt. Wir nannten es Reife und hoben die Gehälter entsprechend an.

Dieselbe Leiter, in drei Sprossen:

Anwendungssoftware erklimmt gerade dieselben Sprossen, und wer es durchlebt, beschreibt es in der Sprache des Verlusts. Achten Sie darauf, welche Sprosse die Automatisierung jeweils nahm. Sie nahm die linke und ließ die rechte genau dort, wo sie war.

Was wirklich eine Ebene aufgestiegen ist

Es lohnt sich, genau zu benennen, welcher Teil der Arbeit sich geändert hat, denn die Antwort ist kleiner als die Begeisterung und größer, als Skeptiker zugestehen.

Billig wurde die Übertragung. Eine bereits getroffene Entscheidung in Syntax zu überführen, die eine Maschine akzeptiert. Das war immer der uninteressanteste Teil, und er verschlang einen großen Anteil des Tages.

Nicht billig wurde alles vor der ersten Zeile: ob dies ein Dienst oder eine Funktion sein soll, was der Fehlermodus ist, wenn der Dritte ausfällt, welches dieser beiden Datenmodelle in achtzehn Monaten wehtut, ob jene Integration eine Abhängigkeit erzeugt, aus der das Geschäft nicht mehr herauskommt. Über die Codequalitätsseite haben wir in die KI hat die Syntax gelöst, das Urteil nicht geschrieben. Dies ist die organisatorische Fassung derselben Grenze.

Ein Agent schreibt bereits den Code, erzeugt die Tests, öffnet den Pull Request und aktualisiert die Dokumentation. Das sind Produktionsaufgaben, und sie werden in dieser Reihenfolge automatisiert. Was kein Agent heute tut, ist Ihnen zu sagen, dass das eben sorgfältig Gebaute gar nicht existieren sollte.

Die rechte Spalte ist keine Liste von Dingen, die Modelle nie können werden. Sie ist eine Liste von Dingen, die verlangen, die Organisation zu kennen, ihre Geschichte, ihre Verträge und ihre Risikobereitschaft. Das sind keine Modellfähigkeiten. Das ist Kontext, der größtenteils nirgends aufgeschrieben ist, und deshalb sind die Menschen, die ihn tragen, wertvoller geworden und nicht weniger wert.

Die Entscheidungen ohne Autovervollständigung

In der Praxis fallen die Entscheidungen, die über das Überleben eines Systems bestimmen, bevor irgendetwas getippt wird, und es sind weniger, als man annimmt. In einem normalen Projekt zählen wir vielleicht ein Dutzend, die zählen.

• Wo die Grenze zwischen zwei Systemen verläuft, denn diese Grenze wird ein Vertrag, und Verträge sind teuer zu verschieben.
• Was geschieht, wenn eine Abhängigkeit nicht verfügbar ist, eine als technisch verkleidete Geschäftsentscheidung.
• Welche Daten das System der Aufzeichnung sind, denn alles Nachgelagerte erbt diese Wahl.
• Was das System ohne Menschen tun darf, inzwischen eine konkrete statt einer theoretischen Frage.
• Was man bewusst nicht baut, die am seltensten aufgeschriebene und am häufigsten bereute Entscheidung.

Jede passt in einen Satz, und keine lässt sich an etwas delegieren, das die letzten vier Jahre an Entscheidungen Ihrer Organisation nicht gelesen hat. Trifft man sie richtig, überlebt mittelmäßiger Code. Trifft man sie falsch, kommt hervorragender, schnell erzeugter Code schneller an einem Ort an, an dem Sie nicht sein wollten.

Ein aktuelles Beispiel, und bewusst ein glanzloses. Ein Team brauchte einen Freigabeschritt für Dokumente. Die naheliegende Umsetzung war ein Workflow in der Plattform, in der die Dokumente ohnehin lagen, und ein Assistent erzeugt das an einem Nachmittag, korrekt. Die Frage, die zuerst niemand stellte, war, ob die Freigabe eine Eigenschaft des Dokuments oder eine Tatsache des Geschäfts ist. Sie war eine Tatsache des Geschäfts: Dieselbe Freigabe musste für ein System sichtbar sein, das nie Zugriff auf die Dokumentbibliothek haben würde. Der Nachmittag korrekten Codes wäre binnen eines Jahres weggeworfen worden, und die Kosten wären nicht der Nachmittag gewesen. Es wären die sechs Monate gewesen, in denen zwei Systeme uneins darüber waren, was freigegeben worden war.

Jene Entscheidung dauerte zwanzig Minuten und keine Zeile Code. Sie ist zugleich der ganze Grund, weshalb das Projekt nicht neu gemacht werden musste, und sie erschiene in keiner Messung der Produktion jener Person in jener Woche.

Der Satz ist kein Geständnis

Wenn also eine erfahrene Fachkraft sagt, sie schreibe nicht mehr viel Code, ist die ehrliche Lesart meist das Gegenteil der beschämten.

Es ist derselbe Satz, den eine Systemadministratorin 2012 über die Handkonfiguration von Servern gesagt hätte, und heute hört ihn niemand als Abstieg. Er bedeutet, dass die Person vom Erzeugen von Artefakten dazu übergegangen ist zu entscheiden, welche Artefakte es sein sollen, und das ist die Richtung, in die jede Ingenieursdisziplin ging, sobald ihr Werkzeug reifte. Bauingenieure haben aufgehört, jede Linie von Hand zu ziehen. Das machte sie nicht zu Zeichnern mit weniger Können.

Das Risiko dieses Satzes liegt woanders und gehört benannt. Wer ganz aufhört, Code zu schreiben, kann irgendwann den Code nicht mehr beurteilen, den er freigibt, und Urteil ohne Kontakt zum Material wird zur Meinung. Wer das gut macht, schreibt nicht nichts. Er schreibt weniger, mit Absicht, und liest sehr viel mehr.

Was stattdessen zu messen ist

Wenn der Throughput stieg, während die Stabilität sank, hat der Throughput als Näherung für Wert ausgedient, und ihn weiter zu belohnen ist nicht neutral. Es selektiert aktiv genau das Verhalten, das die Instabilität erzeugt hat.

Die Messgrößen, über die sich zu streiten lohnt, sind jene, die die Automatisierung der Produktion überleben:

Jede Zeile rechts ist schwerer zu erheben als die links daneben, und das ist kein Zufall. Was das Überleben eines Systems vorhersagt, war immer teurer zu messen als das, was vorhersagt, wie beschäftigt alle wirkten. Die Automatisierung des Produktionsschritts hat die letzte Ausrede genommen, die billigen zu verwenden.

Der Teil, der gut altert

Die Werkzeuge werden sich weiter bewegen. Das heute produktive Modell wird zweimal ersetzt sein, bevor dies alt ist, und der Agent, der dieses Jahr Pull Requests öffnet, wird nächstes Jahr Ehrgeizigeres tun.

Was sich nicht bewegen wird, ist der Ort, an dem die Schwierigkeit wohnt. Sie ist in jeder je automatisierten Ingenieursdisziplin die Abstraktionsleiter hinaufgestiegen und nie wieder herunter. Jedes Mal geschah dasselbe Dreifache: Der Produktionsschritt wurde billiger, der Preis einer falschen Entscheidung wurde größer, weil sie weiter reichte, und der Berufsstand verbrachte einige unbequeme Jahre damit, das Falsche zu messen, bis die Instrumente nachzogen.

Wir befinden uns in den unbequemen Jahren. DORA hat sein Instrument 2025 gewechselt; die meisten Organisationen haben ihres noch nicht gewechselt.

Der Wert einer Ingenieurin war nie wirklich das Tippen. Er war nur so messbar, was eine andere Behauptung ist, und diese ist eben abgelaufen.