Baue nicht zuerst die autonome KI-Fabrik

Hier ist eine Szene, die sich gerade in Entwicklerteams abspielt: Ein Entwickler verbringt das Wochenende damit, vier oder fünf Programmier-Agents parallel laufen zu lassen. Am Montagmorgen öffnet ein Teamkollege seinen Laptop und sieht 53 geänderte Dateien mit über 2.000 Diffs und eine Nachricht, die sinngemäß lautet: „Sollte zum Zusammenführen in Ordnung sein.“ Niemand hat um so viel Output gebeten. Niemand hat Zeit, das ordentlich zu prüfen. Das Team hat nicht das Gefühl, schneller zu sein. Es fühlt sich überrumpelt.

Genau das passiert, wenn die individuelle KI-Produktivität die Bereitschaft auf Teamebene überholt – und das ist die deutlichste Beschwerde, die wir in Gesprächen mit den Entwicklern von Upsun Dispatch™ gehört haben. Deshalb muss die Einführung von KI schrittweise erfolgen, eine Phase nach der anderen, und Fabien Potenciers achtstufiges Reifegradmodell ist die klarste Übersicht darüber, wie diese Reihenfolge tatsächlich aussieht.

Teams, die aus dem Nichts direkt zur autonomen Fabrik springen, enden erschöpft, ungeschützt oder beides. Diejenigen, die echten Nutzen daraus ziehen, durchlaufen jede einzelne Stufe dazwischen. Hier ist der Grund, warum diese Reihenfolge wichtig ist.

Die Phasen sind eine Abfolge von Vertrauensproblemen.

Fabien Potencier, CTPO bei Upsun und der Kopf hinter Symfony, bringt es auf den Punkt: Man muss jede Phase der KI-Einführung durchlaufen, um zu verstehen, warum es die nächste gibt. 

Sein Modell reicht vom „Vakuum“ (Phase 1), in dem der KI-Einsatz noch keine echte Strategie hat, über die „Drift“, die „Inseln“, die „Standardisierungswette“, die „Neugestaltung der Arbeitsabläufe“ und das „Betriebssystem“ bis hin zur „Bright Factory“ (Phase 7), in der Ingenieure einen wachsenden Schwarm lokal laufender Agenten überwachen, und schließlich zur „autonomen Fabrik“ (Phase 8), in der Agenten auf einer gemeinsamen Infrastruktur laufen und die Aufgabe eher darin besteht, das System zu verwalten als das Programmieren.

Jede Stufe bedeutet nicht einfach nur „mehr KI“. Es geht um ein anderes Problem: Wie sehr vertraust du den Ergebnissen, wie anfällig sind deine Systeme und wie gut hält die Arbeit zusammen, sobald mehr als eine Person daran arbeitet? Du löst die Standardisierungsherausforderung (Stufe 4) – bei der sich die Führungsebene zu gemeinsamen Tools und Governance verpflichtet – nicht, indem du diese Tools einem Team aufzwingst, das noch in der „Drift“ (Stufe 2) feststeckt, wo der Arbeitsablauf einer Person nur in ihrem eigenen Kopf existiert. Das Tool übernimmt nicht die Aufgabe, Vertrauen aufzubauen. Das tut das Team selbst, indem es die Stufen durchläuft, die dieses Vertrauen schaffen.

Die oben beschriebene Szene am Montagmorgen zeigt, wie die „Bright Factory“ (Phase 7) aussieht, wenn niemand die Gewohnheiten entwickelt hat, die in den früheren Phasen vermittelt werden sollten.

Was schiefgeht, wenn man Phasen überspringt

Wir haben von mehreren Leuten unabhängig voneinander dieselben drei Fehlermuster gehört – was normalerweise ein Zeichen dafür ist, dass man auf etwas Reales gestoßen ist und nicht nur auf die Lieblingstheorie einer einzelnen Person.

1. Sicherheitsschulden häufen sich still und leise an. Patrick Dawkins, Principal Software Engineer bei Upsun, bezeichnet das Kernrisiko unbeaufsichtigter Agenten als „tödliches Dreigespann“: nicht vertrauenswürdige Daten, reale Aktionen und private Informationen – alles auf einmal in Reichweite. Teams erkennen das frühzeitig, indem sie jeden Befehl überprüfen. Diese Wachsamkeit lässt nach, wenn sich die Genehmigungen wiederholen und die Leute anfangen, ungelesen durchzuklicken – lange bevor sich jemand entscheidet, das System abzuschalten.
2. Technische Schulden häufen sich schneller an, als Teams erwarten. Es ist ein Muster, das in unseren Gesprächen mehr als einmal zur Sprache kam: Ein Projekt, bei dem früher fünf Jahre lang Schulden angehäuft wurden, bevor eine Neuprogrammierung nötig war, erreicht diesen Punkt nun schon nach sechs Monaten.
3. Die Produktivität einer einzelnen Person wird zum Engpass für alle anderen. Das ist das oben beschriebene Montagmorgen-Szenario. Die Vorteile durch den Einsatz von Agenten sind individuell. Ein einzelner Entwickler kann tatsächlich mehr leisten. Aber wenn man die Arbeitsergebnisse desselben Entwicklers einem Team aus drei oder vier Leuten übergibt, das noch keinen gemeinsamen Prozess zur Überprüfung der von Agenten generierten Arbeit aufgebaut hat, kann die Gesamtleistung des Teams stagnieren oder sogar sinken. 

Autonomie muss man sich verdienen, sie lässt sich nicht einfach einschalten

Wenn das Überspringen von Schritten der Fehlermodus ist, dann ist der Vertrauensregler der Mechanismus, der das verhindert. Agenten verdienen sich Autonomie genauso wie ein neuer Mitarbeiter. Am Anfang muss jede wichtige Aktion von einem Menschen überprüft werden. 

Im Laufe der Wochen, wenn sich ein bestimmter Arbeitsablauf immer wieder als korrekt erweist, wird die menschliche Kontrolle für diesen Ablauf aufgehoben, und der Agent wechselt zu einer Aufgabe, die weniger streng überwacht wird. Vertrauen wird nicht von vornherein gewährt. Es wird für jeden Arbeitsablauf einzeln verdient und nicht auf einen Schlag für „KI“ im Allgemeinen.

Modelle sind derzeit gerade noch langsam genug, dass ein Mensch mithalten kann, aber das wird nicht so bleiben. Der Sinn des stufenweisen Vertrauens lag nie darin, Menschen ewig mitlesen zu lassen. Es geht darum, sicherzustellen, dass die Autonomie, die dieses Mitlesen irgendwann ersetzt, tatsächlich verdient wurde und nicht einfach übersprungen wurde.

Die Stufen gelten unabhängig davon, wo ein Team anfängt

Man könnte das leicht so interpretieren: „Ihr braucht ein ausgereiftes Team, bevor sich der Einsatz von KI lohnt.“ Das ist nicht das Argument. Teams, die noch ganz am Anfang stehen (Stufe 1), können und sollten loslegen. Was nicht funktioniert, ist das Überspringen der Stufen, die die Grundlagen schaffen, von denen eine spätere Stufe voraussetzt, dass ihr sie bereits habt.

Bewusst im „Vakuum“ anzufangen ist besser, als sich direkt in die Standardisierung (Phase 4) zu stürzen und zu hoffen, dass sich die Arbeitsabläufe von selbst ergeben. Wenn dein Team noch dort ist, fang bewusst an – nicht, weil du die Neugestaltung der Arbeitsabläufe (Phase 5) noch nicht erreicht hast, sondern weil du gerade im „Vakuum“ die Überprüfungsgewohnheiten aufbaust, von denen diese Phase voraussetzt, dass du sie bereits hast.

Ein Beispiel vom Team hinter Upsun Dispatch™

Upsun Dispatch wurde mit einer frühen Version von sich selbst entwickelt, und genau diese frühe Version deckte genau die Art von Problemen auf, die eine schrittweise Einführung eigentlich aufdecken soll. Die erste Version des Pull-Request-Review-Workflows warf jedes einzelne Feedback in einen einzigen großen Kommentar. 

Erst als der Workflow tatsächlich ausgeführt wurde – und nicht nur auf dem Papier entworfen –, wurde klar, dass dies die Überprüfungen erschwerte statt vereinfachte. Er wurde neu gestaltet, sodass Kommentare nun inline neben dem Code erscheinen, auf den sie sich beziehen. Diese schrittweise Einführung verhindert nicht nur Katastrophen; sie deckt auch die alltäglichen Fehler auf, die erst sichtbar werden, wenn echte Arbeit durch das System läuft.

Was das für dich bedeutet

Nichts davon bedeutet, dass du warten sollst. Es bedeutet, Schritt für Schritt vorzugehen.

Wenn du bereits Agenten parallel laufen lässt und es sich langsam wie das oben beschriebene Montagmorgen-Szenario anfühlt, ist das kein Zeichen dafür, noch mehr Automatisierung hinzuzufügen. Es ist ein Zeichen dafür, eine Stufe zurückzugehen und den gemeinsamen Workflow aufzubauen, den du übersprungen hast.

Die Teams, die das richtig hinbekommen, werden nicht diejenigen sein, die als Erste die autonome Fabrik erreicht haben. Es werden diejenigen sein, die auf jede Phase verweisen können, die sie durchlaufen haben, um sich das zu verdienen.

Um euch ein umfassenderes Bild zu vermitteln, hat Fabien Potencier in einem separaten Beitrag alle acht Phasen – von der individuellen Gewohnheit bis zur organisatorischen Gewohnheit – dargestellt.

• Neu hier? Lies die Einführung zu Upsun Dispatch.
• Möchtest du beim Aufbau mithelfen? Bewirb dich für die Kohorte der Gründungs-Design-Partner.