In Workshops fällt mir auf, dass es spannend wird, wenn es nicht mehr um Produktivität, nicht um Lines of Code, nicht um Prompt-Tricks geht, sondern darum, welche Fragen Entwickler beginnen zu stellen. Wenn Menschen sich öffnen und wachsen.
Ein Backend-Entwickler, der seit Jahren in seinem Bereich arbeitet, fängt auf einmal zögerlich an, über den Business-Impact einer API-Entscheidung nachzudenken, weil die KI ihm Kontext liefert, den er vorher nicht auf dem Schirm hatte. Eine Frontend-Entwicklerin beginnt, Fragen zur Datenmodellierung zu stellen, weil sie bei der KI-gestützten Arbeit sieht, wie die Teile zusammenhängen.
Das ist keine Kleinigkeit! In vielen Teams sind diese Grenzen über Jahre gewachsen. Backend redet mit Backend. Frontend mit Frontend. Product mit Product. Jeder kennt seinen Bereich, niemand guckt drüber. Nicht aus Desinteresse, sondern weil der Alltag es nicht hergibt.
Diese ganz nette Anekdote hat jetzt eine Studie mit Daten unterfüttert, die mir Hoffnung gibt.
Was bei Procter & Gamble passiert ist
Das Team von Dell‘Acqua et al., 2025, von Harvard Business School und Wharton hat bei Procter & Gamble ein Feldexperiment durchgeführt, das dieses Phänomen direkt untersucht. Die Studie ist ein „NBER Working Paper“, also kein Peer-Reviewed Journal, aber methodisch ganz solide aufgestellt: 776 Professionals, randomisierte Zuweisung, verblindete Evaluatoren, pre-registriertes Design. Das Setup: Profis aus R&D und Commercial arbeiteten einen Tag an Produktinnovations-Aufgaben, entweder allein oder als Zweier-Team, jeweils mit und ohne KI-Zugang. Die Qualität wurde von Fachleuten bewertet, die nicht wussten, wer unter welchen Bedingungen gearbeitet hatte.
Drei Befunde sind für uns relevant.
-
Ohne KI produzierten R&D-Leute eher technische Lösungen und Commercial-Leute eher marktnahe. Klare funktionale Silos, wie man es erwarten würde. Mit KI verschwand dieser Unterschied weitgehend. Beide Gruppen generierten ausbalanciertere Lösungen, die sowohl technische als auch kommerzielle Aspekte abdeckten.
-
Eine Einzelperson mit KI erreichte ein Qualitätsniveau, das dem eines Zweier-Teams ohne KI entsprach (+0,37 SD vs. +0,24 SD über der Baseline). Das heißt nicht, dass Teams überflüssig werden — dazu gleich mehr. Aber es zeigt, dass KI den Output einer Person auf ein Niveau heben kann, das vorher Zusammenarbeit erforderte.
-
Zweier-Teams mit KI produzierten die meisten Top-10%-Lösungen — dreimal so häufig wie die Kontrollgruppe. Die Kombination Mensch + Mensch + KI schlug alle anderen Konfigurationen bei Spitzenleistungen.
Das war nur ein eintägiger Ideation-Workshop bei einem einzelnen Unternehmen und keine Langzeitstudie über Software-Engineering-Alltag. Man kann daraus nichts handfestes ableiten, dafür braucht man ein anderes Test-Setup, aber man kann das als Datenpunkt und Inspiration mitnehmen.
Was das für Software-Teams bedeutet
Die Studie untersucht zwar keine Softwareentwickler, sondern R&D- und Commercial-Profis, aber das Grundmuster finden wir bei uns auch: funktionale Silos gibt es auch bei uns, und die lassen sich durch KI vielleicht auflösen, oder zumindest öffnen.
Hier ein paar Ideen; nichts davon geschieht magisch oder automatisch. Man muss sich beim Prompten schon noch die Mühe geben, nicht bloß nach einem Fix für 10 Zeilen Code zu fragen. Aber in der Teamkultur ließe sich so etwas dergestalt etablieren, dass man persönliche blinde Flecken immer wieder mal aufgedeckt bekommt:
Backend denkt Frontend mit
Wenn ein Backend-Entwickler mit KI an einem Feature arbeitet, schlägt die KI Kontexte vor, die über den eigenen Scope hinausgehen; Vorschläge, die Frontend-Implikationen berücksichtigen, API-Design-Entscheidungen anders rahmen, oder Teststrategien vorschlagen, die er allein nicht in Betracht gezogen hätte.
Der Entwickler entscheidet weiterhin, was davon relevant ist. Aber sein Blickfeld hat sich erweitert.
Dev denkt Business-Impact mit
Das ist für mich der spannendste Transfer aus der Studie. Wenn ein Backend-Entwickler durch die KI dazu kommt, auch den Long-Term-Value einer technischen Entscheidung mitzudenken — eine Frage, die ihm persönlich vielleicht nicht liegt — dann hat das ganze Team gewonnen. Die KI ersetzt nicht die Product-Perspektive. Aber sie macht den Entwickler zu einem besseren Gesprächspartner für Product und Business. Welche Auswirkungen auf die Serverlast und Kostenstruktur hat die neue API? Was könnte man anders gestalten, um heute schon effizienter zu fahren und Kunden attraktivere Angebote machen zu können?
Ein Entwickler, der im Sprint Planning nicht nur die technische Machbarkeit beurteilt, sondern auch eine informierte Meinung zum Business-Kontext einbringt, verändert die Qualität der Diskussion. Das ist kein Alleinstellungsmerkmal von KI-Tools. Gute Teamkultur bewirken das gleiche. Aber KI senkt die Schwelle, weil der Kontext verfügbar wird, ohne dass man ihn sich vorher aneignen muss.
Entwicklern wird leichter gemacht, zwischendurch auch mal aus dem Kaninchenbau herauszugucken. Das Tagesgeschäft und technische Detailwissen liegt im Fokus, aber zwischendurch schaut man sich um, bevor man sich wieder vergräbt.
Die Regisseur-These
Wer den ganzen Stack überblickt (von der Planung über die Architektur bis zur Implementierung) hat mit KI den größten Hebel. Das ist meine Beobachtung aus der Arbeit mit Entwicklern, die als Selbstständige oder Tech Leads den gesamten Produktionsprozess verantworten. Das sehe ich in kleinen Teams, in denen ich mitarbeite, und in meiner eigenen Arbeit als unabhängiger Entwickler jeden Tag.
Wenn Code zunehmend selbst zum Kompilat wird — generiert aus Specs und Kontext statt Zeile für Zeile getippt — dann verschiebt sich die wertvolle Arbeit weg von der Implementierung, hin zu den Entscheidungen davor: Was bauen wir? Warum? Welche Constraints gelten? Das sind Fragen, die über Abteilungsgrenzen hinausgehen.
KI macht aus Spezialisten keine Generalisten. Aber sie erweitert den Kontext, in dem Spezialisten denken und entscheiden.
Was das für Teamstruktur bedeutet — und was nicht
Die naheliegende Reaktion auf „Einzelperson + KI = Team-Qualität“ wäre: Dann brauchen wir keine Teams. Das wäre eine Fehlinterpretation.
Die Studie zeigt auch: Teams mit KI liefern die besten Spitzenleistungen. Die Kombination aus menschlicher Zusammenarbeit und KI-Unterstützung schlägt alle anderen Konfigurationen, wenn es um die besten Ergebnisse geht — nicht nur um den Durchschnitt. Das heißt: KI ersetzt Teamarbeit nicht.
Die interessantere Frage ist nicht „Wie viele Leute brauchen wir?“, sondern „Wie teilen wir die Arbeit zwischen Mensch und KI auf — und was bedeutet das für die Zusammenarbeit im Team?“
Kent Beck erwähnte im Pragmatic Summit 2026, dass langsame LLMs prima für Pair Programming sind: Man hat genug Zeit, sich über nächste Schritte zu unterhalten. Wenn Antworten zu schnell kommen, muss man die Pausen selber machen. Wie alle Vorteile vom Pair Programming der letzten Jahrzehnte ist auch hier der Mehrwert in der menschlichen Abstimmung, wenn zwei Köpfe mit eigenen Geschmäckern, Ideen, Erfahrungen aufeinandertreffen und sich arrangieren und fördern. Dann kommt dazu noch ein Arbeitswerkzeug, um das Gespräch am Laufen zu halten und das Ausprobieren im Code abzugeben.
Wenn funktionale Silos durchlässiger werden, weil jeder mit KI-Unterstützung einen breiteren Kontext hat, dann verändert sich, worüber man im Team reden muss. Weniger „Erklär mir, was dein Teil macht“ und mehr „Lass uns zusammen entscheiden, was die richtige Lösung ist.“ Das erfordert aber auch, dass das Team darauf vorbereitet ist.