KI kann die Arbeit eines Ingenieurs beschleunigen, ohne dass dadurch die Produktentwicklung schneller voranschreitet.
Das war die Spannung, die im Mittelpunkt meines Gesprächs mit Marc Osofsky, Geschäftsführer von Jama Software. Anforderungen lassen sich schneller formulieren. Code lässt sich schneller generieren. Überprüfungen lassen sich automatisieren. Doch nichts davon beweist, dass ein Produkt schneller auf den Markt kommt.
Ich habe das Problem in einem Satz zusammengefasst:
“Produktivität ist lokal, aber echte Geschwindigkeit ist systemisch.”
Michael Jastram
Marc hatte denselben Effekt auch im Softwarebereich beobachtet. Entwickler produzieren mit KI mehr Code, doch dieser zusätzliche Output fließt in die Testphase und andere nachgelagerte Phasen ein.
“Die Produktgeschwindigkeit in Unternehmen hat tatsächlich abgenommen.”
Marc Osofsky
Die KI hat in dieser Situation nicht versagt. Sie hat genau das getan, was sie versprochen hat. Sie hat eine Aufgabe beschleunigt und den Engpass verlagert.
Beurteilen Sie das Produkt, nicht die KI
Eine Kennzahl wie die pro Stunde erarbeiteten Anforderungen zeigt, ob eine bestimmte Tätigkeit schneller geworden ist. Über die Produktgeschwindigkeit sagt sie jedoch wenig aus.
Marc beschrieb das interne Bewertungsverfahren bei Jama wie folgt: Man betrachte die im Laufe der Zeit bereitgestellten Funktionen und anschließend deren Akzeptanz als Indikator für den Wert. Außerdem stellte er Ergebnisse aus der spezifikationsgesteuerten Entwicklung bei Jama vor.
“Wir haben auf Projektebene bewiesen, dass wir fünfmal schneller arbeiten können.”
Marc Osofsky
Später erklärte er, dass Jama auf Teamebene eine Steigerung um das 2,5-Fache erreicht habe. Dabei handelt es sich um interne Software-Ergebnisse von Jama, nicht um einen Maßstab für die Entwicklung physischer Produkte. Die Einheit liefert Funktionalität, keine KI-Aktivitäten (oder, Gott bewahre, Tokenmaxxing).
Ein Teilnehmer fragte, wie man KI quantifizieren könne. Meine Antwort darauf war, dass die beste KI-Kennzahl vielleicht gar keine KI-Kennzahl ist.
Wenn KI die Testphase verkürzt, messen Sie die Testdauer. Wenn sie eine Änderungsentscheidung beschleunigt, messen Sie die Zeit bis zum Treffen dieser Entscheidung. Achten Sie darauf, wie schnell ein Mehrwert für die Beteiligten entsteht, und nicht auf die lokale Optimierung.
Andernfalls laufen wir Gefahr, eine neue Version des Wassermelonenmuster. Das KI-Dashboard ist grün, obwohl das Produkt immer noch langsam ist.
Kostenloses Webinar zum Thema „Anti-Patterns“ am 6. Oktober mit Marc Löffler (auf Deutsch)
Der Produktkontext spielt eine Rolle
Marc war ungewöhnlich direkt:
“Dateien sind schlecht für KI, sie sind schlecht für Menschen. Man muss im Grunde einen Kontextgraphen erstellen.”
Marc Osofsky
Das Problem ist nicht die Existenz von Dateien. Das Problem ist, dass das Produktwissen über diese Dateien verstreut bleibt. Eine Datei allein sagt einer KI nicht, ob sie die aktuelle Antwort enthält oder in welchem Zusammenhang sie zu einem anderen Artefakt steht.
Marcs Antwort ist eine Produktkontext-Ebene, die auf einem Graphen aus technischem Wissen basiert. Der Graph macht Zusammenhänge explizit, während die Entwurfsartefakte in ihrer ursprünglichen Umgebung verbleiben. Die tiefgreifendere Veränderung betrifft nicht die Datenbank, sondern das, was mit dem technischen Wissen geschieht.
“Wir stellen auf ein Produktionssystem um, in dem all dieses implizite Wissen explizit gemacht werden muss.”
Marc Osofsky
Ein Großteil der Ingenieursarbeit hängt davon ab, dass die Beteiligten wissen, was ein Dokument wirklich bedeutet, welche Version maßgeblich ist oder an wen sie sich wenden müssen. KI macht die Kosten dieses impliziten Wissens deutlich, da die Automatisierung den Kontext benötigt, den erfahrene Ingenieure im Kopf haben.
Was gewinnt an Wert, wenn die Stromerzeugung billig wird?
Hier ist, wo Spezifikationsgesteuerte Entwicklung wird interessant.
Marc beschrieb ein Modell, bei dem Spezifikationen die Absicht erfassen, während die Neuerstellung nachgelagerter Artefakte kostengünstiger wird. In der Softwareentwicklung lässt sich bereits erkennen, wie dies aussehen kann. Wenn Code schnell neu erstellt werden kann, wenden Entwickler weniger Aufwand dafür auf, jede einzelne Implementierung zu bewahren, und konzentrieren sich stattdessen stärker darauf, die Spezifikation korrekt zu halten.
Seine Formulierung war bewusst provokativ:
“In einer von KI geprägten Welt werden die einzelnen Artefakte fast schon zu Wegwerfartikeln.”
Marc Osofsky
Diese Aussage lässt sich nicht wörtlich auf jedes heutige technische Produkt übertragen. Ein CAD-Modell oder ein validierter Hardware-Entwurf ist nicht so leicht zu entsorgen wie generierter Software-Code.
Aber die Richtung ist entscheidend. Je programmierbarer die technischen Werkzeuge werden, desto mehr Arbeit bei der Generierung kann die KI übernehmen. Der bleibende Wert verlagert sich dann auf das Wissen, das dem System vorgibt, was es generieren soll und wie es das Ergebnis bewerten soll.
Dadurch werden Spezifikationen Teil eines dynamischen Produktkontexts und sind nicht mehr nur Dokumente, die frühzeitig erstellt und übergeben werden.
Die schnellsten Unternehmen waren schon vor der Einführung von KI schnell
Marc wies darauf hin, dass einige Unternehmen, die heute mit schneller Entwicklung in Verbindung gebracht werden – wie Tesla, SpaceX und BYD –, diese Geschwindigkeit bereits vor dem Aufkommen der generativen KI erreicht hatten. Die KI hat ihr Entwicklungssystem nicht geschaffen.
Meiner Ansicht nach sind die Produktarchitektur und die Organisationsarchitektur Teil der Erklärung. Im Gespräch habe ich es so formuliert:
“Sie müssen die Architektur Ihres Unternehmens an die Architektur Ihres Produkts anpassen.”
Michael Jastram
Ein Unternehmen mit stabilen Plattformen und kontrollierten Abweichungen hat einen anderen Ausgangspunkt als eines, in dem jede Veränderung Organisationsgrenzen überschreitet. Die KI übernimmt diese Rahmenbedingungen.
Marc argumentierte, dass der bislang etablierteste Weg die softwaredefinierte Entwicklung sei. Bei physischen Produkten bedeute dies, Variationen in die Software zu verlagern, sofern dies aus technischer Sicht sinnvoll sei, und Schnittstellen zu schaffen, die eine stärkere Automatisierung des Arbeitsablaufs ermöglichten. Die KI werde dann in eine Architektur integriert, die bereits auf Geschwindigkeit ausgelegt sei.
KI sollte den Prozess verändern
In einer Frage aus dem Publikum wurde gefragt, ob ein Unternehmen KI auf bestehende Aufgaben anwenden oder den Prozess entsprechend der neuen Möglichkeit neu gestalten sollte.
Marc führte die Halbleiterentwicklung als Beispiel an. Anstatt jede manuelle Übergabe ein wenig zu beschleunigen, beschrieb er einen Ablauf, bei dem KI Simulationen auslösen kann, indem sie CI/CD-Pipelines und die Ergebnisse auszuwerten, ohne dass für jeden Arbeitsschritt eine Person erforderlich ist, die das jeweilige Werkzeug bedient.
Das verändert die Rolle des Ingenieurs.
“Die Menschen stehen an vorderster Front und im Hintergrund, sie geben die Richtung vor und lenken das Geschehen. Aber sie müssen nicht bei jedem einzelnen Schritt selbst Hand anlegen.”
Marc Osofsky
Dies ist ein anderes Ziel als die Einbindung eines KI-Assistenten in den aktuellen Arbeitsablauf. Es geht darum, welche Teile des Arbeitsablaufs weiterhin bestehen müssen, sobald die KI zwischen den Entscheidungen des Menschen kontinuierlich Aufgaben übernehmen kann.
Viele KI-Piloten behalten den alten Prozess bei und beschleunigen nur eine Komponente darin. Das ist für den Anfang einfach. Das ist auch der Grund, warum der Gewinn oft nur lokal bleibt.
Die Frage, die mir im Gedächtnis geblieben ist
Gegen Ende kam Marc noch einmal auf das Thema Messung zurück. Sein Rat lautete, sich auf das Endergebnis zu konzentrieren, anstatt sich auf lokale Optimierungen zu beschränken.
Das wirft für mich bei jeder Initiative zur Entwicklung von KI im Ingenieurwesen eine Frage auf:
Wenn diese KI genau so funktioniert, wie versprochen, welche End-to-End-Verzögerung wird dann kürzer?
Michael Jastram
Auch wenn es keine eindeutige Antwort gibt, kann die Initiative dennoch nützlich sein. Sie kann Entwicklungsaufwand einsparen oder mühsame Arbeit ersparen. Das ist jedoch etwas anderes als die Produktvelozität.
Die interessanteren KI-Anwendungen verändern den Arbeitsablauf im Entwicklungssystem. Sie machen Produktwissen explizit und beseitigen Wartezeiten, die früher fester Bestandteil des Prozesses waren.
Wir wissen bereits, dass KI Aufgaben beschleunigen kann.
Die schwierigere Frage ist, ob sich das Produkt schneller verkauft.
