Eine Zäsur, kein Trend

Wer Software braucht, braucht Menschen, die Code schreiben können. Das galt über Jahrzehnte. Es war der langsamste und teuerste Teil der Prozesskette und meist knapp an personellen Ressourcen, weshalb viele Vorhaben an ihre Grenzen stießen. Anpassungen wurden verschoben, Integrationen vereinfacht und individuelle Lösungen vermieden, weil der Aufwand in keinem Verhältnis zum Nutzen stand. Diese Grenze verschiebt sich gerade.

Ein von einem Agenten gesteuertes Sprachmodell kann Programmcode schneller erzeugen, als ein Mensch ihn schreibt, vorausgesetzt, der Agent wird richtig geführt. Das ist keine graduelle Effizienzsteigerung, sondern eine grundlegende Veränderung der Situation: Wer die Software baut, wie schnell sie entsteht und wer sie sich leisten kann, hängt von anderen Parametern ab. Vorhaben, die Monate dauerten, können zur Sache von Tagen werden. Software, die zu teuer war, um sie maßzuschneidern, wird wirtschaftlich.

Was hat das mit PLM zu tun? Sehr viel. PLM ist zu großen Teilen in Software gegossene Entwicklungsmethodik. Es bildet ab, wie Unternehmen Produkte strukturieren, Anforderungen verfolgen, Änderungen steuern, Daten austauschen und Zusammenarbeit organisieren. Wenn sich verschiebt, wie Software entsteht, verschiebt sich damit auch, was im PLM möglich ist.

Systeme lassen sich stärker nach den eigenen Prozessen gestalten, statt sie über Jahre anzupassen. Integrationen müssen nicht mehr an jeder Stelle von Hand ausbuchstabiert werden. Zusammenhänge, die heute in getrennten Datenbeständen verborgen liegen, können systematisch erschlossen werden. Und Funktionen, die bisher zu speziell, zu teuer oder zu aufwendig waren, rücken plötzlich in den Bereich des Machbaren.

Die Fragen, die jetzt zählen

Sobald nicht mehr der Mensch den Code schreibt, verschieben sich die eigentlichen Probleme. Die zentrale Frage lautet dann nicht mehr, wie schreiben wir die Software schneller, sondern wie behalten wir die Kontrolle über das, was entsteht? Daraus ergeben sich mehrere Fragen, die die Softwareentwicklung der nächsten Jahre bestimmen werden:

• Wie behält man die Kontrolle über das Ergebnis, wenn man den Code nicht mehr Zeile für Zeile liest?
• Was muss so präzise beschrieben sein, dass ein Agent daraus verlässlich Software bauen kann?
• Wo soll KI entscheiden und wo richtet sie mehr Schaden als Nutzen an?
• Was wird wirtschaftlich möglich, wenn Individualsoftware nicht mehr automatisch teuer und langsam in der Entwicklung ist?
• Was wird aus Entwicklungsteams, Prozessen und Werkzeugen, wenn ein großer Teil der Umsetzung zur KI wandert?

Diese Serie behandelt diese Fragen der Reihe nach: mit Konzepten, konkreten Beispielen und den offenen Punkten. Vieles davon: Spezifikation statt Code, deterministisches Rückgrat, punktuelle KI, wird derzeit breit diskutiert. Der Unterschied hier ist, dass es bei PROSTEP keine These ist, sondern gebaut und im Einsatz: Aus diesen Ideen sind eine Methodik, eine kompilierte Prozesssprache samt Laufzeit und laufende Produkte entstanden und wir entwickeln unsere eigene Software täglich damit.

Eine Serie, die drei Fragen beantwortet

Wie wird Software gebaut? Wer eine KI einfach drauflosprogrammieren lässt, bekommt schnell Code und verliert ebenso schnell die Gewissheit, ob dieser Code das Richtige tut. Die Antwort liegt in einer Verlagerung des Prüfpunkts: Nicht mehr jede Zeile Code steht im Zentrum, sondern die Spezifikation. Das erste Kapitel zeigt, wie man die Kontrolle behält, ohne die Geschwindigkeit zu verlieren, indem man eine durchgängige Kette von Bedarf, Anforderungen, Zusicherungen und Code aufbaut. Damit wird KI-gestützte Individualentwicklung nicht nur schnell, sondern methodisch beherrschbar.

Wie wird KI industrietauglich? Die verbreitete Ernüchterung über KI ist berechtigt, nur liegt sie nicht an der KI, sondern daran, dass sie systematisch an den falschen Stellen eingesetzt wird. Für vieles ist die solide klassische Programmierung der KI überlegen, weil sie zuverlässig und reproduzierbar arbeitet. Das zweite Kapitel zeigt, wie man KI genau dort einsetzt, wo sie ihren eigentlichen Mehrwert hat, nämlich eingebettet in kontrollierbare Prozesse, mit einem deterministischen Rückgrat und mit Agenten, die direkt in den Anwendungen mitarbeiten, statt Ergebnisse in einem separaten Chatfenster zu erzeugen.

Wohin führt das? Das dritte Kapitel zeigt, welche Konsequenzen sich daraus konkret ergeben, von der Nachverfolgbarkeit technischer Zusammenhänge über die Analyse von Verträgen, Dokumenten und Lastenheften bis zur Frage, wie solche Fähigkeiten in PLM-Produkte und Kundenlösungen einfließen. Es geht nicht um Demonstratoren als Selbstzweck, sondern um ein Muster, das dieselbe Methodik, dieselbe Prozesslogik und dieselbe Agentenarchitektur über unterschiedliche Anwendungsfälle hinweg beinhaltet.

Eine Methodik, die sich weiterentwickelt

Die hier beschriebenen Methoden sind kein Schlusspunkt. Sie sind ein früher, notwendiger Schritt in eine Richtung, die sich bereits abzeichnet: Die Steuerung der Softwareentwicklung verlagert sich nach oben.

Heute geht es darum, Code nicht mehr selbst zu schreiben, sondern Spezifikationen, Anforderungen und Zusicherungen so präzise zu formulieren, dass ein Agent daraus verlässlich Software bauen kann. Der nächste Schritt ist bereits sichtbar: Agenten entwerfen Individualsoftware weitgehend selbst, erzeugen Oberflächen für konkrete Anwendungsfälle, leiten Bausteine aus bestehenden Mustern ab und passen sie nur noch dort an, wo es fachlich nötig ist.

Damit verändert sich auch die Rolle von PLM-Systemen. Unternehmen werden weniger Zeit darauf verwenden, Standardsoftware über Jahre an ihre Prozesse anzupassen. Sie werden mehr Software nach ihren Prozessen erzeugen lassen, mit standardisierten Schnittstellen dort, wo Austauschbarkeit zählt, und individueller Ausprägung dort, wo der eigene Entwicklungsprozess den Unterschied macht.

Womit man heute anfängt und worauf es hinausläuft, ist Gegenstand dieser Serie. Der nächste Beitrag beginnt bei der ersten Frage: 

Wie behält man die Kontrolle, wenn die KI den Code schreibt?