Was AI-first in der Entwicklungspraxis wirklich verändert.

Fragt man eine Entwicklungsorganisation, woraus ihr AI-first-Programm besteht, hört man meist eine Liste von Werkzeugen. Diese Liste ist nicht falsch, sie ist nur der billigste Teil. Werkzeuge sind an einem Nachmittag beschafft. Ein Jahr dauert es, zu ändern, welches Artefakt die Organisation als Quelle der Wahrheit behandelt.

Die Spezifikation wird zum Artefakt, das zählt

Sobald ein Modell aus einer Beschreibung eine plausible Implementierung erzeugt, ist die Implementierung nicht mehr der teure Teil. Teuer wird die Beschreibung — präzise genug, um daraus zu bauen, vollständig genug, um die Fälle zu enthalten, die niemand aufschreibt, und stabil genug, dass zwei Leser zum selben Schluss kommen.

Genau dafür ist spezifikationsgetriebene Entwicklung da: die Spezifikation als versioniertes, prüfbares Artefakt zu behandeln, aus dem sowohl die Implementierung als auch die Abnahmekriterien abgeleitet werden. Das klingt nach einer Dokumentationsübung. Ist es nicht. Es verlagert den Engpass.

Und hier kommt die Wirkung, die fast niemand einplant: Der Druck wandert von der Entwicklung ins Produktmanagement. Wenn Implementierung schnell und Spezifikation langsam ist, sind unscharfe Anforderungen nicht mehr überlebensfähig. Die Produktseite muss plötzlich bei Randfällen genau sein, die sie früher dem Urteil eines Entwicklers überlassen hat. Manche Organisation stellt an dieser Stelle fest, dass ihre eigentliche Begrenzung nie die Entwicklungskapazität war.

Modellunabhängigkeit ist eine Einkaufsentscheidung, keine technische Vorliebe

Wer ein Produkt an einen Modellanbieter bindet, bindet es an dessen Preisliste, dessen Datenhaltung und dessen Fahrplan für das Abkündigen dessen, worauf man gebaut hat. Nichts davon ist eine Entwicklungsfrage; alles davon landet in der GuV.

Eine dünne Abstraktionsschicht zwischen Produkt und Modell kostet im ersten Release Zeit und spart im dritten ein Umbauprojekt. Für europäische Kunden kommt ein zweiter Grund hinzu: Wo Daten verarbeitet werden, ist in einer Ausschreibung kein technisches Detail, sondern ein Vergabekriterium. Eine Last zu einem anderen Anbieter verschieben zu können — oder in die Umgebung des Kunden — ist eine kommerzielle Fähigkeit, kein Komfortmerkmal.

Der Ertrag liegt in der Wartung, nicht im Neubau

Die beeindruckenden Vorführungen zeigen immer, wie neuer Code entsteht. Das Geld liegt an einer weit weniger fotogenen Stelle: im Bestand. Eingehende Fehler klassifizieren, reproduzieren, den Regressionstest schreiben, Dokumentation aktuell halten, Abhängigkeiten nachziehen — die Arbeit, die erfahrene Kapazität verbraucht, ohne dass am Ende etwas entsteht, das man einem Kunden zeigen kann.

Die vorbereitende Schicht dieser Arbeit zu automatisieren, ist unspektakulär und wirkt sofort. Es ersetzt keine Entwickler. Es gibt ihnen die Stunden zurück, die vorher im Sortieren verschwanden — und das waren die Stunden genau der Leute, bei denen man es sich am wenigsten leisten kann.

Was sich nicht ändert

Entscheidungsrechte, Qualitätsschranken, Verantwortung. Wer ausliefern darf, was vor dem Ausliefern belegt sein muss, wer antwortet, wenn es schiefgeht. Eine Organisation, die leistungsfähige Werkzeuge verteilt, ohne diese drei Linien neu zu ziehen, bekommt schnellere Pilotprojekte und keinen schnelleren Betrieb — und wird daraus fälschlich schließen, die Technologie habe nicht geliefert.

AI-first ist kein Werkzeugprojekt mit Organisationsanteil. Es ist ein Organisationsprojekt mit Werkzeuganteil. Die Reihenfolge ist entscheidend, weil sie bestimmt, wer mit am Tisch sitzen muss.

Fragen oder eine andere Sicht? Ich lese jede Mail. kehrein@swkconcept.com