Hört auf, es «Software-Fabrik» zu nennen. KI hat die Softwareentwicklung nicht in eine Massenproduktion verwandelt. Sie hat fähigen Leuten bessere Werkzeuge gegeben, und das macht sie zu einer Werkstatt.
Der Begriff «Software-Fabrik» ist alt. Er kam vor Jahrzehnten auf, als man hoffte, Software wie Autos am Fliessband zu bauen. Jetzt ist er zurück. Jede Woche sehe ich eine neue «KI-Software-Fabrik»: Agenten in einer Pipeline, Anforderungen gehen hinein, Code kommt heraus. Das klingt modern und effizient. Aber es ist das falsche Bild, und das falsche Bild führt zu falschen Entscheidungen.
Fabriken kopieren. Wir entwerfen.
Eine Fabrik ist dafür gebaut, das gleiche Produkt immer wieder herzustellen. Das Design ist fertig, bevor die Produktion beginnt. Das Ziel ist, Abweichungen zu vermeiden, und die Arbeiter folgen einem festen Prozess. Man kann sie ersetzen, ohne dass sich das Ergebnis ändert.
Bei Software ist es genau umgekehrt. Wir bauen nie zweimal das gleiche System. Brauchen wir das gleiche System nochmals, kopieren wir es, und Kopieren kostet bei Software nichts. Jedes Projekt hat eine andere Domäne, andere Benutzer und andere Regeln. Die meiste Arbeit besteht darin, das Problem zu verstehen und eine Lösung zu entwerfen.
Ich mochte das Bild der Fabrik auch in DevOps nie. Seit Jahren wird die CI/CD-Pipeline «Software-Fabrik» genannt. Aber eine Pipeline entwirft nichts. Sie ist Automatisierung, eine sehr nützliche Maschine in der Werkstatt, gebaut und gewartet von fähigen Leuten. Daran ändert auch KI nichts. Was KI verändert, ist das Schreiben des Codes, und das war nie Fabrikarbeit.
Eine Werkstatt, keine Fabrik
Eine Werkstatt ist das bessere Bild. In einer Werkstatt findet man fähige Leute, gute Werkzeuge und Massarbeit. Jedes Stück wird für einen bestimmten Kunden und einen bestimmten Bedarf gefertigt.
Mit KI sind die Rollen klar:
- Der Agent ist das Werkzeug. Ein sehr mächtiges Werkzeug, das autonom arbeitet, aber trotzdem ein Werkzeug. Er weiss nicht, was er bauen soll, und es ist ihm egal, ob das Ergebnis stimmt.
- Die Spezifikation ist der Plan. Die Fachexperten schreiben sie. Sie beschreibt, was das Business braucht, und zwar so detailliert, dass das Werkzeug seine Arbeit machen kann.
- Der Software Engineer ist der Handwerker. Der Handwerker entwirft die Architektur, arbeitet mit den Fachexperten, bis die Spezifikation klar ist, baut den Harness, in dem die Agenten arbeiten, prüft die Arbeit und übernimmt die Verantwortung für das Ergebnis.
Ein besseres Werkzeug macht einen guten Handwerker schneller. Es macht ihn nicht überflüssig. Auch ein Schreiner mit einer Kreissäge muss wissen, wo er sägen muss.
Die Werkstatt des Weihnachtsmanns
Wenn man ein Bild für die KI-Entwicklung sucht, dann ist es die Werkstatt des Weihnachtsmanns. Sie muss unter hartem Termindruck viel Massarbeit liefern, und sie arbeitet mit vielen Helfern. Danke an James Ward für diese Analogie.
| Werkstatt des Weihnachtsmanns | KI-Entwicklung |
|---|---|
| Kinder | Fachexperten |
| Wunschzettel | Spezifikation |
| Weihnachtsmann | Orchestrator |
| Elfen | Agenten |
| Die Liste zweimal prüfen | Review und Tests |
Der Weihnachtsmann baut nicht jedes Spielzeug selbst. Er plant, teilt die Arbeit auf, gibt jeder Elfe eine klare Aufgabe und prüft das Ergebnis. Die Elfen sind schnell, und es gibt viele davon. Sie arbeiten parallel und selbständig, ohne dass ihnen der Weihnachtsmann über die Schulter schaut.
Der letzte Punkt ist der wichtigste. Der Weihnachtsmann schreibt den Wunschzettel nicht. Das machen die Kinder, denn nur sie wissen, was sie sich wünschen. Die Elfen kennen die Kinder nicht. Sie kennen nur den Wunschzettel. Alles, was sie bauen, kommt von dort.
Socken statt Velo
Ein vager Wunschzettel bringt Socken statt eines Velos.
Steht auf dem Zettel «etwas Warmes, vielleicht blau?», bauen die Elfen irgendetwas. Es wird warm sein, und vielleicht blau. Aber es wird nicht das sein, was sich das Kind gewünscht hat. Steht auf dem Zettel «rotes Velo, 20-Zoll-Räder, Vorder- und Hinterradbremse, für einen 10-Jährigen», können die Elfen genau das bauen.
Agenten funktionieren gleich. Gibt man einem Agenten einen Prompt mit nur einer Zeile, füllt er die Lücken mit Annahmen. Die Annahmen sehen gut aus, der Code kompiliert, und die Demo funktioniert. Aber die Geschäftsregeln sind falsch, die Randfälle fehlen, und niemand merkt es, bis es in Produktion ist.
Eine gute Spezifikation beantwortet die Fragen, die der Agent sonst raten würde:
- Wer nutzt die Funktion, und was ist sein Ziel?
- Wie sieht der Hauptablauf aus, Schritt für Schritt?
- Welche alternativen Abläufe und Fehler gibt es?
- Welche Geschäftsregeln gelten?
- Wie sehen die Daten aus?
- Woran erkennen wir, dass es funktioniert?
Das ist nicht neu. Es ist klassisches Requirements Engineering. Im AI Unified Process besteht der Wunschzettel aus Use Cases und einem Entitätenmodell. Die Use Cases beschreiben die Abläufe und die Geschäftsregeln. Das Entitätenmodell beschreibt die Daten. Neu ist, dass die Spezifikation kein Dokument mehr ist, das niemand liest. Der Agent liest sie, jedes Mal. Eine bessere Spezifikation ergibt besseren Code. Schreibt bessere Spezifikationen.
Der Handwerker ist für den Harness verantwortlich
Die Spezifikation allein genügt nicht. Rund um den Agenten braucht es einen Harness: die Umgebung, in der der Agent arbeitet, mit den Regeln, die er einhalten muss, und den Prüfungen, die seine Arbeit bestehen muss. Und dafür ist der Handwerker verantwortlich, nicht das Werkzeug.
Zum Harness gehören:
- Die Spezifikation, geschrieben von den Fachexperten, mit Use Cases, Geschäftsregeln und dem Datenmodell. Der Software Engineer sorgt dafür, dass sie für die Agenten vollständig genug ist
- Die Architektur und die Konventionen, damit jeder Agent auf die gleiche Weise baut
- Der Kontext, damit der Agent das Projekt, den Stack und die bereits getroffenen Entscheidungen kennt
- Automatisierte Tests, abgeleitet aus der Spezifikation, die fehlschlagen, wenn der Agent falsch liegt
- Review durch einen Menschen, der die Domäne versteht
- Nachvollziehbarkeit von der Anforderung über den Use Case bis zum Code und zum Test
In einer Fabrik kommt die Qualität aus dem Prozess. Niemand am Fliessband ist für das ganze Produkt verantwortlich. In einer Werkstatt steht der Handwerker mit seinem Namen für die Arbeit ein. Baut der Agent das Falsche, ist nicht der Agent schuld. Der Plan war unklar, oder niemand hat geprüft.
Genau das meine ich mit Spec-Driven Development, und das ist die Idee hinter dem AI Unified Process. Die Spezifikation ist die Source of Truth, der Agent macht die Implementierung, und der Software Engineer ist für den Harness verantwortlich, der beides in Einklang hält.
Fazit
Worte prägen unser Denken. Nennen wir es Fabrik, suchen wir einen Prozess, der Menschen überflüssig macht. Nennen wir es Werkstatt, investieren wir in Menschen, ihre Fähigkeiten und ihre Werkzeuge.
KI macht die Werkzeuge viel mächtiger. Das ist eine gute Nachricht für jeden Software Engineer, der weiss, was er bauen soll und wie er es prüft. Also hört auf, Fabriken zu bauen. Baut eine gute Werkstatt, helft den Fachexperten, einen klaren Wunschzettel zu schreiben, und übernehmt die Verantwortung für den Harness.
Sogar der Weihnachtsmann prüft seine Liste zweimal.
