Allein bauen, wofür früher ein Team nötig war – und warum das nicht das Ziel ist

Mit KI lässt sich heute in kurzer Zeit allein erarbeiten, wofür früher ein ganzes Team nötig war. Das habe ich zuletzt in einer Status-quo-Analyse nach einer Unternehmensübernahme erlebt, und seit dem Frühjahr erlebe ich es täglich in der eigenen Entwicklungsarbeit. Die Geschwindigkeit ist beeindruckend, und trotzdem halte ich das Arbeiten allein für das falsche Ziel. Mich beschäftigt deshalb die Frage, wie Teams aussehen, die diese Geschwindigkeit nutzen und dabei den Austausch behalten, den gute Entscheidungen brauchen.

Was möglich geworden ist

Nach der Übernahme eines Unternehmens durch einen Private-Equity-Investor haben wir eine Status-quo-Analyse durchgeführt. Zu dritt haben wir sie in drei Wochen abgeschlossen. Für eine Analyse dieses Umfangs sind üblicherweise vier bis sechs Wochen mit rund acht Spezialisten angesetzt. Die IT-Due-Diligence als Teil davon habe ich allein innerhalb einer Woche erstellt.

Seit dem Frühjahr habe ich mich bewusst darauf eingelassen, diese Arbeitsweise selbst zu erproben, als Ein-Personen-Team, das mit agentischen Werkzeugen Software entwickelt. Wer auf meine Git-Historie schaut, sieht deshalb sehr viele Commits und Aktivitäten. Ich wollte aus eigener Erfahrung verstehen, was in diesem Modus möglich ist und wo seine Grenzen liegen.

Was allein fehlt

Wer allein baut, verliert leicht den Markt aus dem Blick. Es fehlt der Input von außen, und es fehlt die Zusammenarbeit mit anderen. Gerade Architekturdenken lebt davon, dass Entwürfe auf Widerspruch treffen und durch die Ideen anderer besser werden.

Ein Sprachmodell stimmt einem latent zu. Bei vielen Vorschlägen, Richtungsimpulsen und Ideen, die man einbringt, wirkt ein starker Bias zur Zustimmung. Mit einem menschlichen Gegenüber in Architektur und Entwicklung ist das meistens nicht der Fall. Der Austausch führt häufig zu einer kritischen Auseinandersetzung und zum Neudenken eines Entwurfs, und genau daraus entstehen bessere Ergebnisse. Alle Entscheidungen ohne diesen menschlichen Sparringspartner zu treffen, ist schwer.

Kleine Teams mit einer klaren Rollenverteilung

Mein Zielbild sind kleine Teams mit drei bis vier Personen. Eine zentrale Rolle übernimmt ein Customer Ambassador aus dem Unternehmen des Kunden. Er setzt die Anforderungen, verfeinert und gestaltet sie und übernimmt damit die Aufgabe, die bisher bei Produktmanagement und Product Owner lag. Dazu kommen zwei Entwickler: einer mit Schwerpunkt Architektur, der das Gesamtsystem im Blick behält, und einer mit Spezialisierung, der Code-Reviews und Merges verantwortet. Ergänzt wird das Team durch jemanden, der die Prozesse der Anwender gestaltet.

Verantwortung für ein Ergebnis

Entscheidend ist, dass diese Teams Verantwortung für ein Outcome bekommen, etwa für eine messbare Verbesserung oder für Umsatz. Gemessen werden sie an diesem Outcome; die Zahl umgesetzter Features ist dafür kein Maßstab. Innerhalb eines definierten Handlungsspielraums treffen sie ihre Entscheidungen selbst, sie validieren ihr Ergebnis und verbessern sich und ihren Prozess fortlaufend. Die Geschwindigkeit, die KI ermöglicht, entfaltet ihren Wert erst in einem solchen Rahmen: wenn ein kleines Team gemeinsam Verantwortung für ein Ergebnis trägt und daraus lernt.