Der Einsatz verschiedener KI-Tools funktioniert – bis er nicht mehr funktioniert

Das soll keine Kritik sein. Dieser Stack ist ein wirklich vernünftiger Einstieg. Ein „AI-first“-Editor übernimmt das tägliche Schreiben. Ein terminalbasierter Programmieragent übernimmt Aufgaben, die mehr Autonomie erfordern: ein vollständiges Feature, eine Migration, ein hartnäckiger Bug. Ein paar Skripte verbinden die Teile, lösen einen Lauf aus und veröffentlichen das Ergebnis irgendwo. Ein Observability-Tool überprüft im Nachhinein, was passiert ist.

Jeder Teil davon ist ein echtes, leistungsfähiges Tool. In den ersten paar Monaten funktioniert das in einem kleinen Team. Der Fehler liegt nicht in einem einzelnen Tool. Er liegt darin, was niemand zwischen ihnen aufgebaut hat.

Was an diesem Stack wirklich gut ist

Das Wichtigste auf einen Blick: Der Stack lässt sich schnell einrichten, da er vollständig aus Komponenten besteht, die ein kleines Team bereits kennt – keine neue Infrastruktur, keine neuen Anbieterbeziehungen.

Ein AI-First-Editor bietet dem einzelnen Entwickler einen schnelleren Entwicklungszyklus, Inline-Vorschläge, Chat und Refactorings – und das alles direkt dort, wo er ohnehin schon programmiert. Ein terminalbasierter Coding-Agent erweitert das noch weiter: Er übergibt eine klar abgegrenzte Aufgabe und erhält einen funktionierenden Versuch zurück. Skripte sind kostengünstig und schnell zu schreiben – hier ein Webhook, dort ein Cron-Job – und sie ermöglichen es einem kleinen Team, die offensichtlichen, sich wiederholenden Schritte zu automatisieren, ohne auf andere warten zu müssen. Ein Observability-Tool, das auf die richtigen Logs ausgerichtet ist, gibt dir die Möglichkeit zu sehen, dass etwas gelaufen ist und was es ungefähr gemacht hat.

Wo es hakt – und es liegt nicht an den Tools

Das Wichtigste zum Mitnehmen: Der Kompromiss zeigt sich, sobald mehr als ein oder zwei Personen gleichzeitig auf den Stack angewiesen sind – und zwar an drei konkreten Stellen: Kosten, Überprüfungsaufwand und gemeinsames Wissen.

• Kosten, die niemand erklären kann. Jedes Tool rechnet separat ab, nach seinen eigenen Bedingungen und in seiner eigenen Granularität. Ein Skript löst den Lauf eines Coding-Agents aus. Der Lauf versucht es erneut oder geht weiter als erwartet. Das sieht niemand, bis die Rechnung kommt – und selbst dann geht aus der Rechnung nicht hervor, welcher Workflow, welches Repo oder welche Aufgabe die Kosten tatsächlich verursacht hat. Das Observability-Tool wurde nicht entwickelt, um diese Frage zu beantworten; es wurde entwickelt, um die Infrastruktur zu überwachen, nicht um den Token-Verbrauch eines Agenten der Entscheidung zuzuordnen, die ihn verursacht hat.    
   
• Eine Überprüfungslast, die die Reviewer überfordert. Sowohl der Editor als auch der Programmier-Agent machen es einfach, schneller mehr Code zu generieren, als eine Person früher programmieren konnte. Nichts in diesem Stack ändert etwas daran, wer den Code überprüft oder wie. Die Review-Queue fängt den Unterschied auf – und zwar ungleichmäßig. Wer gerade Zeit hat, überprüft das, was gerade als Nächstes ansteht, unabhängig davon, wie viel Prüfung diese bestimmte Änderung tatsächlich erfordert.    
   
• Kein gemeinsames Handbuch. Jedes Skript wird von demjenigen geschrieben, der es verfasst hat – für das Problem, das er in dieser Woche hatte. Es gibt keine einheitliche Definition dafür, was ein Workflow eigentlich ist, was für einen Menschen angehalten werden sollte und was nicht. Wenn diese Person abwesend ist oder das Team wechselt, wandert der von ihr aufgebaute Workflow mit ihr – bestenfalls halbwegs dokumentiert, im Kopf von niemand anderem überhaupt.

Das sind keine Fehler im Editor, im Agenten oder im Observability-Tool. Jedes wurde entwickelt, um seine eigene Aufgabe gut zu erfüllen. Was fehlt, ist die Ebene dazwischen – und diese Ebene aufzubauen, gehörte von vornherein nie zu deren Aufgaben.

Man sollte es ehrlich sagen: Eine gemeinsame Ebene beseitigt nicht die Ermessensentscheidung, was als geringes und was als hohes Risiko gilt. Diese Entscheidung muss immer noch von jemandem getroffen werden. Was sich ändert, ist, wo sie angesiedelt ist – nämlich in einer Workflow-Definition, die jeder einsehen und wiederverwenden kann, statt bei dem Entwickler, der das Skript zufällig geschrieben hat.

Was eine gemeinsame Ebene tatsächlich leisten muss

Das Wichtigste auf einen Blick: Die Lösung ist kein viertes Tool. Es ist eine Ebene, die von Anfang an als Bindeglied zwischen den bereits genutzten Tools konzipiert wurde.

Die Lösung ist kein viertes Tool, das einfach an die anderen drei angehängt wird. Es ist eine Ebene, die von Anfang an als Bindeglied konzipiert wurde: ein definierter Workflow statt eines Skripts, eine menschliche Kontrollinstanz, die einen echten Entscheidungspunkt darstellt, statt einer queue, in die jeder einfach alles hineinwirft, und eine Aufzeichnung der Kosten und Maßnahmen, die dem jeweiligen Durchlauf zugeordnet sind, der sie verursacht hat – und nicht erst Wochen später anhand einer Rechnung rekonstruiert werden.

Upsun Dispatch™ ist als diese Ebene konzipiert. Es ersetzt weder den Editor, in dem eure Entwickler programmieren, noch den Coding-Agenten, der die Schwerstarbeit leistet. Es arbeitet unabhängig davon, wer die Änderung vorgenommen hat, wird durch dieselben Repo-Ereignisse ausgelöst, führt den Workflow aus, für den der Rest des Stacks nie ausgelegt war, und protokolliert dabei, was passiert ist.

Lies die Upsun Dispatch-Dokumentation, um zu sehen, wie die Workflow- und Gate-Ebene tatsächlich aufgebaut ist.

Häufig gestellte Fragen (FAQ)

Müssen wir unsere bestehenden Tools ersetzen, um Upsun Dispatch zu nutzen?
Nein. Upsun Dispatch arbeitet parallel zu eurem Stack, nicht an dessen Stelle. Es führt eigene Workflows für Planung, Programmierung und Review in Verbindung mit den Tools aus, die ihr bereits nutzt (GitHub, GitLab, Jira), und ihr müsst weder euren Editor noch euren Programmier-Agenten aufgeben, um es einzuführen.

Ab wann wird eine skriptbasierte Konfiguration tatsächlich zum Problem? Normalerweise
dann, wenn mehr als ein paar Leute gleichzeitig darauf angewiesen sind. Die eigenen Skripte eines einzelnen Entwicklers sind für diesen Entwickler in Ordnung. Die Lücken zeigen sich, wenn der Überprüfungsaufwand, die Kosten und das Workflow-Wissen über eine Person hinaus skalieren müssen.

Ist das eine Kritik an einem bestimmten Tool in diesem Stack?
Nein. Jedes Tool erfüllt die Aufgabe, für die es entwickelt wurde, gut. Keines davon wurde dafür konzipiert, die gemeinsame Ebene zu bilden, die ein Team braucht, sobald mehrere Leute auf dieselbe Konfiguration angewiesen sind – und das ist ein anderes Problem als das Versagen eines einzelnen Tools bei seiner Aufgabe.