
Frag irgendeinen technischen Leiter, wie KI sein Team verändert hat, und du bekommst eine optimistische Antwort. Bitte ihn, das mit Zahlen zu belegen, und die meisten verstummen.
Diese Kluft ist die Geschichte des Jahres 2026. Einzelne Entwickler arbeiten schneller als je zuvor. Teams sind es in vielen Fällen nicht. Wir haben mit unserem eigenen Entwicklerteam gesprochen – den Leuten, die das letzte Jahr damit verbracht haben, Upsun Dispatch™ zu entwickeln und auf den Markt zu bringen, und genau diesen Wandel hautnah miterlebt haben –, und immer wieder kam dieselbe Spannung zur Sprache: Was eine einzelne Person dramatisch produktiver macht, kann die Gruppe um sie herum langsamer, chaotischer und schwerer zu managen machen.
Hier ist, was sie uns erzählt haben.
Wenn man ein Entwicklerteam, das KI-Workflows entwickelt, nach der größten Überraschung dieses Jahres fragt, werden viele von ihnen die Rechnung nennen.
Patrick Dawkins, Principal Software Engineer, beschrieb, dass dieselbe Aufgabe zum Programmieren meistens einen Dollar und gelegentlich zehn Dollar kostete – ohne dass man vor Abschluss der Aufgabe wissen konnte, welcher Betrag anfallen würde. Guillaume Moigneu, Field CTO bei Upsun, erlebte, dass die Kosten für die Überprüfung eines einzigen Pull-Requests zwischen fünf Cent und vierzig Dollar schwankten.
Die Lösung liegt nicht darin, die Ausgaben zu kürzen. Es geht um Transparenz: Kosten, die in Echtzeit nach Workflow und Team nachverfolgt werden, mit Budgets, die vor der Überraschung festgelegt werden, statt erst danach erklärt zu werden.
Die meisten Unternehmen können die Produktivitätssteigerungen, von denen sie glauben, dass sie sie erzielen, gar nicht wirklich nachweisen, weil fast keines von ihnen vor dem Start irgendetwas gemessen hat.
Ohne einen „Vorher“-Wert ist jede Behauptung über KI-getriebene Geschwindigkeit nur eine Vermutung, die als Kennzahl getarnt ist. Teams, die frühzeitig in Basiswertmessungen investiert haben, sind diejenigen, die mit konkreten Beispielen in Budgetgespräche gehen können. Alle anderen argumentieren nur aus einem Gefühl heraus.
Guillaume Moigneu schreibt seit 28 Jahren Software. Er hat beobachtet, was passiert, wenn eine Person in einem kleinen Team Agents schneller einsetzt als alle anderen.
„Wenn du in einem Team von vielleicht drei oder vier Leuten bist und einen solchen Entwickler hast, würde das für die anderen eine Menge Probleme mit sich bringen“, erzählte er uns.
Wenn eine Person über das Wochenende 50 KI-gestützte Änderungen einpflegt, fühlt sich das für den Rest des Teams am Montagmorgen nicht wie ein Erfolg an. Es fühlt sich wie ein Rückstand an.
„Du wachst auf und siehst, dass Patrick das ganze Wochenende durchgearbeitet hat, und du siehst, dass er etwa 50 verschiedene Änderungen vorgenommen hat, und du denkst dir: ‚Oh, ich muss alles noch mal machen, ich muss sicherstellen, dass alles funktioniert.‘ Das ist ein Chaos.“
Individuelle Velocity und Team-Velocity sind nicht dieselbe Kennzahl, und die Optimierung der einen kann die andere still und leise belasten.
Patrick Dawkins hat ein internes Tool entwickelt, das Merge-Anfragen prüft, bevor ein Mensch sie zu Gesicht bekommt. Er hat dabei auch die Grenzen der gleichzeitigen Betreuung von mehr als einem Agenten kennengelernt.
Einen einzelnen Agenten zu betreiben, ist überschaubar. Sobald er eine Weile unbeaufsichtigt laufen kann, stellt sich Langeweile ein, und du startest einen zweiten. Dann einen dritten. „Du denkst über drei verschiedene Dinge gleichzeitig nach“, sagte Dawkins. „Ich glaube nicht, dass du das wirklich länger als ein paar Stunden am Tag durchhalten kannst, bevor du einfach ausbrennst.“
Das ist eine harte Einschränkung, kein Schulungsproblem. Teams, die „mehr Agenten laufen lassen“ als einfachen Produktivitätshebel betrachten, müssen das oft auf die harte Tour lernen.
Den größten Teil des späten Jahres 2025 über ließen Ingenieure Agenten auf ihren eigenen Laptops laufen. Im Nachhinein, so Dawkins, habe das ein echtes Risiko geschaffen.
„Nur du kannst sehen, was der Agent auf deinem Laptop macht. Für den Rest deiner Organisation ist das nicht sichtbar“, sagte er. „Wenn ein Entwickler Tausende von Dollar in sein KI-Tool steckt, siehst du die Ergebnisse nicht – oder du siehst vielleicht das Ergebnis, aber nicht, warum es so viel kostet. Und du siehst nicht, ob Kundendaten an den falschen Ort gesendet werden.“
Schließt man den Laptop, hört der Agent auf zu arbeiten. Und da alles lokal lief, hatte niemand außerhalb des Computers dieses einen Ingenieurs Einblick in die Ausgaben, die Ergebnisse oder das, was das Gebäude verließ.
Ein internes Rahmenwerk, auf das wir gestoßen sind, unterteilt die KI-Einführung in Phasen – und es ist ein nützlicher Anhaltspunkt, um zu prüfen, wo dein Team tatsächlich steht.
Es beginnt damit, dass Einzelpersonen KI auf eigene Faust einführen – ohne Führungsebene, ohne Richtlinien, jeder kauft sich sein eigenes Abonnement. Das ist als Ausgangspunkt normal, sogar gesund. Das Problem ist, was danach kommt: Einige Entwickler ziehen weit an den anderen vorbei und erstellen jeweils eigene Tools und Prompts, die nie geteilt werden. Dann industrialisieren ein paar Teams ihre Arbeitsabläufe, während andere weiterarbeiten, als wäre es noch 2024. Die Kluft zwischen den schnellsten und den langsamsten Teams wird sichtbar, und die Führungsebene kann meist nicht erklären, warum.
Das ist genau der Punkt, an dem sich die meisten Unternehmen gerade befinden – ob sie es nun zugeben wollen oder nicht.
Das klarste Denkmodell in unseren Gesprächen kam von Moigneu: Behandle einen Agenten wie einen neuen Mitarbeiter.
„Am Anfang erklärst du ihm, worum es bei der Arbeit geht, wie die Regeln lauten, und dann, in den ersten ein oder zwei Monaten, vertraust du ihm, überprüfst aber auch“, sagte er. „Bei Agenten ist das genauso. Am Anfang führen wir sogenannte ‚Human Gates‘ ein, bei denen nach jeder kritischen oder risikobehafteten Aufgabe ein Mensch überprüfen muss, was der Agent getan hat, und dies genehmigen, ablehnen oder besprechen muss.“
Das Gate ist nicht der springende Punkt. Es geht um die Feedbackschleife. Wenn sich ein Arbeitsablauf als zuverlässig erweist, werden die Gates aufgehoben. Änderst du die Farbe eines Buttons, brauchst du keine fünf Genehmigungen. Wenn es darum geht, wie du Steuern an den Staat meldest, willst du wahrscheinlich mehr als eine.
Jeder Entwickler, mit dem wir gesprochen haben, beschrieb denselben Wandel: weniger Zeit mit Tippen, mehr Zeit mit Überprüfen, Verifizieren und der Entscheidung, ob die von der KI erzeugte Arbeit tatsächlich korrekt ist.
Moigneu beschreibt es als einen Wandel vom Programmierer zum Architekten. „Du bist derjenige, der für alles verantwortlich ist, was von einem LLM geschrieben wird“, wie Patrick Dawkins es ausdrückte. „Jede einzelne Codezeile zu lesen und zu verstehen, was sie bewirkt, ist superwichtig.“
Lässt man die Einzelheiten außer Acht, zeigt sich in jedem Gespräch ein Muster.
Die Teams, die 2026 Probleme haben, optimieren für den einzelnen Entwickler, lassen Agenten laufen, ohne Einblick in Kosten oder Ergebnisse zu haben, und springen direkt zur vollständigen Automatisierung, ohne eine echte Phase des Vertrauensaufbaus zu durchlaufen.
Die Teams, die besser abschneiden, betrachten die Einführung von KI als ein Problem der Organisationsgestaltung: gemeinsame Standards statt individueller Konfigurationen, ein „Vertrauensregler“ statt blindem Vertrauen, Kostentransparenz statt Überraschungen am Monatsende.
Nichts davon ist ausgefallen. Es ist dieselbe Disziplin, die Entwicklerteams schon immer gebraucht haben, wenn sie über eine Person hinauswachsen. KI hat lediglich den Zeitrahmen für das Erlernen dieser Disziplin deutlich verkürzt.
Genau auf diesem Muster basiert Upsun Dispatch™, denn wir haben es selbst als Erste umgesetzt: Agenten, die in einer gemeinsamen Ebene statt auf einzelnen Laptops laufen, menschliche Kontrollinstanzen, die sich auflösen, sobald Vertrauen aufgebaut ist, statt für immer bestehen zu bleiben, und Kosten, die in Echtzeit nachverfolgt werden, statt erst am Monatsende entdeckt zu werden.