KI isst keine Pizza. Trotzdem beeinflusst sie mit, wie groß ein Entwicklungsteam zukünftig noch sein muss. Die bekannte Zwei-Pizza-Regel besagt, dass ein Team zu groß ist, wenn zwei Pizzen nicht mehr für alle reichen. Sie war immer eine Obergrenze und nie ein Ziel. Bei der Teamgröße in der Softwareentwicklung verschiebt sich gerade die Untergrenze, und das hat Folgen für Planung, Personal und Verantwortung.
Aus sechs Köpfen werden ein bis zwei
Bei uns haben früher zum Beispiel sechs Leute an einem Projekt gearbeitet, um zügig voranzukommen. Heute erledigen das ein bis zwei Personen mit KI-Unterstützung. Die anderen sind schon beim nächsten Projekt. Die Zahl der Köpfe bleibt gleich, aber es laufen mehr Vorhaben gleichzeitig.
Dass Teams dadurch kleiner werden, ist bekannt und im Beitrag Mensch vor Technik schon angerissen. Hier geht es um das, was danach kommt.
Weniger Abstimmung
Ein Team aus drei Personen hat drei Kommunikationswege, eines aus acht Personen hat 28. Jeder dieser Wege ist ein Termin, ein mögliches Missverständnis und eine Wartezeit. Kleine Teams sind schneller, weil sie weniger abstimmen müssen. Die KI macht es möglich, mit weniger Leuten dasselbe Ergebnis zu erreichen.
Die Rollen werden weicher
Gleichzeitig verschwimmen die Grenzen zwischen den Rollen. Jeder im Team hat weiter einen Schwerpunkt, kommt aber auch dort hinein, wo früher ein Spezialist saß. Wie sich das Profil des Entwicklers dadurch verändert, beschreibt der Beitrag Entwickler vs. Programmierer.
Die Verschiebung betrifft nicht nur Entwickler. Auch Product Owner und Business Analysten wachsen über ihre Rolle hinaus. Wer heute eine User Story schreibt, lässt morgen den klickbaren Prototyp dazu erzeugen. Wer einen Fehler findet, lässt ihn mit KI beheben, ohne je eine Entwicklungsumgebung geöffnet zu haben.
Daraus ergibt sich eine offene Frage. Werden Entwickler zu Product Engineers, oder werden Product Owner selbst zu Buildern? Dazu eine Hypothese: Die technischen Fachleute bauen das KI-Setup, also den Rahmen, die Werkzeuge und die Schutzregeln, damit Fachrollen selbst weiterbauen können. Wenn agentische Softwareentwicklung so gut wird wie behauptet, liegt die Hauptleistung der Techniker genau darin, diesen Zielzustand herzustellen. Danach kommt jeder mit dem Setup zurecht, und die KI erledigt den Rest. Die Kernfrage lautet dann weniger „Wer schreibt den Code?“ und mehr „Wer baut das System, in dem Code entsteht?“.
Drei Probleme hinter dem einfachen Teil
Kleinere Teams und weichere Rollen sind der einfache Teil. Drei Folgen sind schwieriger.
Mehr angefangene Arbeit
Wenn jeder überall ansetzen kann, fängt auch jeder überall an. Es entstehen mehr offene Aufgaben, als abgeschlossen werden. Der Engpass ist nicht mehr das Tippen, sondern das Zusammenführen. Bei uns wird heute mehr Code geprüft als selbst geschrieben. Wie belastend dieser Dauer-Review-Modus werden kann, zeigt der Beitrag AI Brain Fry.
Jeder Kopf wiegt mehr
In einem Dreierteam schlägt jede Entscheidung und jeder Urlaub stärker durch. Dazu kommt eine menschliche Seite. Der eine blüht mit der größeren Verantwortung auf. Der andere hat genau davor Respekt und sagt es nicht. Wer Teams verkleinert, sollte das aktiv ansprechen und nicht darauf warten, dass es jemand von selbst tut.
Wo kommt der Nachwuchs her?
Die Aufgaben, an denen Junioren früher gewachsen sind, übernimmt heute die KI. Woher kommen dann in fünf Jahren die Seniors? Eine fertige Antwort darauf haben wir nicht. Aber die Frage gehört in die Personalplanung, bevor die Lücke sichtbar wird.
Breite ist billig geworden, Tiefe nicht
Überall mitarbeiten zu können heißt nicht, überall gut zu sein. Für Standardfälle reicht die neue Breite. Bricht eine Anwendung unter Last ein, sieht es anders aus, denn dann braucht es jemanden, der genau diese Schicht wirklich kennt. Bei einem falsch geschnittenen Datenmodell gilt dasselbe.
Breite ist billig geworden. Tiefe nicht. Deshalb lautet die Frage nicht mehr, wie viele Leute ein Team braucht, sondern welche Fähigkeiten.
Was Geschäftsführer und IT-Leiter jetzt prüfen sollten
Aus der Beobachtung lassen sich vier praktische Schritte ableiten:
- Festhalten, wer in welchem Gebiet wirklich tief einsteigen kann, etwa bei Lastverhalten, Datenmodell oder Sicherheit. Gibt es für ein Gebiet nur eine Person, ist das ein Risiko.
- Die Zahl der gleichzeitig offenen Arbeiten begrenzen und Zeit für Review und Zusammenführung fest einplanen.
- Fragen, wer mit mehr Verantwortung gut zurechtkommt und wer sie als Last erlebt, bevor das Team schrumpft.
- Aufgaben für Nachwuchskräfte bewusst vergeben, auch wenn die KI sie schneller erledigen würde.
Fazit
KI senkt die Untergrenze der Teamgröße. Weniger Abstimmung macht kleine Teams schneller, aber sie schlagen mit mehr offener Arbeit, stärkerer Abhängigkeit von einzelnen Personen und der offenen Nachwuchsfrage zurück. Breite gibt es inzwischen fast geschenkt, Tiefe bleibt knapp. Wer die Teamgröße plant, sollte deshalb zuerst die Fähigkeiten betrachten und erst danach die Köpfe zählen.
