Produktivitätszahlen stammen aus dem Neubau, unsere Arbeit nicht
Ein Kunde zeigte uns eine Studie mit einem großen Produktivitätsgewinn und fragte, warum unsere Schätzung ihn nicht abbildet. Die Studie maß Menschen, die neuen Code ohne bestehende Randbedingungen schreiben — und unsere Arbeit ist in jeder relevanten Hinsicht das Gegenteil.
Die Frage und warum sie berechtigt ist
Der Kunde war nicht schwierig. Veröffentlichte Zahlen zu KI-gestützter Entwicklung sind groß und einheitlich genug, um danach zu fragen — und ein Anbieter, dessen Schätzung sie ignoriert, schuldet eine Erklärung statt eines Schulterzuckens.
Unsere Erklärung lautet, dass fast all diese Zahlen aus dem Schreiben neuen Codes stammen. Neuer Code hat keine bestehenden Konventionen zu achten, keine nachgelagerten Systeme, die von seinem heutigen Verhalten abhängen, und keine fünfzehn Jahre alten Annahmen in einem Modul, das seit 2014 niemand geöffnet hat.
Was Brownfield tatsächlich kostet
Sharma veröffentlichte Ende 2025 eine Arbeit mit dem Argument, dass Brownfield-Engineering eine eigene Kategorie ist und nicht Neubau mit Hindernissen, und schlägt einen Rahmen dafür vor, wo Unterstützung in bestehenden Systemen wirklich hilft.
Die Unterscheidung ist der nützliche Teil. In einem bestehenden System besteht die meiste Arbeit darin festzustellen, was gilt, bevor irgendetwas geschrieben werden kann: Welches Verhalten ist beabsichtigt, wer hängt daran, was bricht bei einer Änderung. Unterstützung hilft bei einem Ausschnitt davon — und nicht beim größten.
Wo sie wirklich hilft
Beim Lesen. Ein Assistent, der beantwortet, was diese Funktion aufruft und wo dieser Konfigurationswert genutzt wird, ersetzt eine langsame Suche durch eine schnelle — in einer großen unbekannten Codebasis eine echte Ersparnis, die wir mit rund einem Drittel der Orientierungszeit gemessen haben.
Tests für bestehendes Verhalten zu schreiben ist das Zweite. Charakterisierungstests sind mechanisch, mühsam und genau die Arbeit, die Menschen aufschieben — ein Assistent, der sie aus beobachteten Ein- und Ausgaben entwirft, macht aus einer Woche zwei Tage.
| Aufgabe | Wirkung der Unterstützung |
|---|---|
| Neuen Code ohne Randbedingungen schreiben | Großer Gewinn. Nicht unsere Arbeit |
| Bestehenden Code verstehen | Echter Gewinn, rund ein Drittel der Orientierung |
| Charakterisierungstests entwerfen | Großer Gewinn. Mechanische Arbeit |
| Entscheiden, was geändert werden darf | Keine. Das ist der Engpass |
Wo sie überhaupt nicht hilft
Bei der Entscheidung, was geändert werden darf. Das ist ein Gespräch mit denen, denen die nachgelagerten Systeme gehören, und es bewegt sich im Takt ihrer Verfügbarkeit und ihrer Risikobereitschaft.
In unseren letzten drei Brownfield-Projekten machte dieses Gespräch zwischen vierzig und sechzig Prozent der verstrichenen Zeit aus. Keine schnellere Codeproduktion verkürzt es, und ein Plan, der etwas anderes annimmt, erzeugt ein Team, das mit fertiger Arbeit auf eine Entscheidung wartet, die niemand getroffen hat.
Die Zahl, die wir nennen
Zwischen fünfzehn und fünfundzwanzig Prozent auf die verstrichene Gesamtprojektzeit, gegenüber den fünfzig und mehr, die manche veröffentlichten Zahlen nahelegen. Wir sagen, woher sie kommt: Lese- und Testphasen verdichten sich erheblich, Entscheidungsphasen nicht, und das Verhältnis dazwischen bestimmt die Summe.
Kunden reagieren gut auf die Zerlegung. Was sie ablehnen, ist eine Zahl ohne Struktur — meist, weil sie schon einmal eine bekommen und zugesehen haben, wie sie ausblieb.
Die Falle beim Messen
Codezeilen und Pull-Request-Zahlen steigen beide, was es leicht macht, einen Gewinn zu berichten, den es nicht gab. In einem Projekt stieg unser Durchsatz, gemessen an gemergten Änderungen, um ein Drittel, während sich der Liefertermin nicht bewegte — denn die zusätzlichen Änderungen lagen in Bereichen, auf die niemand wartete.
Wir messen heute die verstrichene Zeit bis zu einer gelieferten Fähigkeit — in jeder Hinsicht die schlechtere Kennzahl, außer darin, dass sie das ist, wofür der Kunde zahlt. Sie ist verrauscht, langsam zu erheben und schmeichelt niemandem.
Was das für den Zuschnitt bedeutet
Die Entscheidungen nach vorn ziehen. In den gut gelaufenen Projekten gingen die ersten zwei Wochen dafür drauf, die Eigner der nachgelagerten Systeme an einen Tisch zu bekommen und aufzuschreiben, was geändert werden darf — bevor jemand Code schrieb, der vielleicht nicht ausgeliefert werden darf.
Das ist eine unspektakuläre Empfehlung und der stärkste Vorhersagewert, den wir dafür haben, ob ein Brownfield-Projekt nahe seiner Schätzung endet. Der Assistent macht das Bauen schneller; die Erlaubnis macht das Bauen möglich.
Was wir nicht behaupten
Wir behaupten nicht, veröffentlichte Neubauzahlen seien falsch. Sie messen, was sie messen, die Methodik ist oft solide, und für ein Team, das einen neuen Dienst beginnt, sind sie vermutlich die richtige Erwartung.
Wir behaupten auch nicht, unsere fünfzehn bis fünfundzwanzig Prozent seien genau. Sie stammen aus einer Handvoll unterschiedlich geschnittener Projekte, haben eine große Streuung, und wir nennen sie als Spanne mit Begründung — nicht als Wert, um den herum jemand auf das Prozent genau budgetieren sollte.