Zum Inhalt springen
Digitale Kumpel
Zurück zum Blog

Fullstack ist Pflicht – mit KI mehr denn je

Manuel·

In vielen Entwicklungsabteilungen sieht das Organigramm aus wie der Technik-Stapel: ein Team für die Oberfläche, eines für den Server, eines für die Datenbank, eines für den Betrieb, dazu Design und Qualitätssicherung. Jedes Team kennt seine Schicht sehr genau. Ein neues Feature braucht aber fast immer alle Schichten, also wandert es von Team zu Team.

Unsere These: Diese Aufteilung hat schon vor KI gebremst. Mit KI wird sie zum Engpass, weil KI genau die Grenzen zwischen den Disziplinen verwischt, nach denen diese Teams geschnitten sind.

Was davon belegt ist und was unsere Einschätzung ist, trennen wir in diesem Artikel ausdrücklich.

Kurz gesagt

  • Teams, die nach Technik geschnitten sind, erzeugen Übergaben und Warteschlangen. Das beschreiben die DORA-Forschung, Conways Gesetz und das Rahmenwerk LeSS übereinstimmend.
  • Ein Team aus allen Disziplinen zusammenzusetzen, reicht allein nicht. Es muss auch ohne fremde Erlaubnis ändern und ausliefern können.
  • KI verwischt die Grenzen zwischen Disziplinen messbar. In einer Studie bei Procter & Gamble erreichten Einzelne mit KI die Leistung von Teams ohne KI.
  • KI ist nicht überall gleich gut. Ohne Tests und Prüfung wird aus Tempo Instabilität.
  • Unsere Einschätzung: Je schneller programmiert wird, desto stärker bestimmt die Wartezeit zwischen Teams die Gesamtdauer. Wer nach Technik getrennt arbeitet, holt deshalb nur einen Teil des möglichen Tempos ab.
  • Bei uns läuft ein Feature in einem Durchgang von der Planung bis zur Auslieferung, mit einem Test, der es von außen prüft.

Was Fullstack hier heißt

Fullstack heißt hier nicht, dass jede Person alles können muss. Gemeint ist: Ein Team liefert ein Feature vollständig aus, von der Oberfläche bis zur Datenbank und vom Entwurf bis zum Betrieb, ohne auf andere Teams zu warten.

Die Betriebswirtschaft kennt den Gegenentwurf seit Langem. Wer nach Tätigkeiten gliedert, organisiert nach dem Verrichtungsprinzip. Das Gabler Wirtschaftslexikon nennt das Ergebnis Funktionalorganisation. In der Softwareentwicklung heißen die beiden Formen Komponententeams und Feature-Teams. Das Rahmenwerk LeSS beschreibt ein Feature-Team als langlebiges Team, das über Funktionen und Komponenten hinweg arbeitet und Kundenfeatures vollständig umsetzt, eines nach dem anderen.

Der Schnitt nach Technik erzeugt Warteschlangen

Melvin Conway hat 1968 beschrieben, dass Organisationen Systeme entwerfen, die ihre eigene Kommunikationsstruktur abbilden. Wer ein Oberflächen-Team und ein Server-Team hat, bekommt eine Oberfläche und einen Server und dazwischen eine Schnittstelle, über die zwei Teams verhandeln müssen.

LeSS beschreibt die Folgen von Komponententeams sehr konkret: Die Arbeit läuft nacheinander ab wie im Wasserfall, mit vielen Warteschlangen, viel angefangener Arbeit, vielen Übergaben und mehr Multitasking.

Das Forschungsprogramm DORA von Google kommt aus einer anderen Richtung zum selben Ergebnis. Teams, die kontinuierlich und zuverlässig ausliefern, können laut DORA größere Änderungen am Aufbau ihres Systems vornehmen, ohne jemanden außerhalb des Teams um Erlaubnis zu fragen oder von anderen Teams abhängig zu sein. Sie erledigen ihre Arbeit ohne kleinteilige Abstimmung mit Leuten außerhalb des Teams und liefern unabhängig aus, wann sie es brauchen. Solche Organisations- und Technikstrukturen sagen laut DORA voraus, ob ein Team kontinuierlich ausliefern kann.

Ein Team, das für jedes Feature auf zwei andere Teams wartet, erfüllt keine dieser Bedingungen.

Das heißt nicht, dass niemand mehr spezialisiert sein darf. Das Modell Team Topologies unterscheidet Teams, die einen Strom von Features vollständig liefern, von Plattform-Teams, die ihnen Infrastruktur als Dienst bereitstellen. Spezialwissen bleibt wichtig. Es sollte nur kein Tor sein, durch das jedes Feature hindurchmuss.

Funktionsübergreifend allein reicht nicht

Ein Team quer zu den Disziplinen zu besetzen, ist kein Erfolgsgarant. Behnam Tabrizi hat 2015 in der Harvard Business Review berichtet, dass 75 % der funktionsübergreifenden Teams dysfunktional sind. Und das Gabler Wirtschaftslexikon nennt für die Funktionalorganisation durchaus einen Vorteil: Bei einem einheitlichen Produktprogramm lassen sich Synergien je Funktion nutzen. Erst mit unterschiedlicheren Produkten und einem bewegteren Umfeld wird die Abstimmung zum Problem.

Eine Studie, die Organisationsformen in der Softwareentwicklung direkt gegeneinander antreten lässt und eine davon zur schlechtesten erklärt, kennen wir nicht. Auch DORA macht nicht die Zusammensetzung eines Teams zum Kriterium, sondern ob es ohne fremde Erlaubnis entwerfen, ändern und ausliefern kann. Ein Team mit allen Disziplinen, das trotzdem für jede Auslieferung drei Freigaben einholen muss, gewinnt wenig.

KI verwischt die Grenzen zwischen Disziplinen

Die bisher deutlichste Studie dazu stammt aus einem Feldexperiment bei Procter & Gamble. Forscher unter anderem aus Harvard und Wharton haben 776 Fachleute zufällig auf vier Gruppen verteilt: mit oder ohne KI, allein oder mit einer weiteren Fachkraft im Team. Die Aufgaben waren echte Produktentwicklungen des Unternehmens.

Die Ergebnisse: Einzelne mit KI erreichten die Leistung von Teams ohne KI. Ohne KI schlugen Fachleute aus Forschung und Entwicklung eher technische Lösungen vor, Fachleute aus dem kaufmännischen Bereich eher kaufmännische. Mit KI kamen beide zu ausgewogenen Lösungen, unabhängig von ihrem Hintergrund. Die Autoren folgern, KI zwinge Organisationen dazu, die Struktur ihrer Zusammenarbeit neu zu denken.

In der Softwareentwicklung zeigt sich dasselbe Muster. Anthropic, Hersteller des KI-Modells Claude, mit dem wir unter anderem arbeiten, hat Ende 2025 die eigene Belegschaft untersucht: eine Umfrage unter 132 Entwicklern und Forschern, 53 Interviews und rund 200.000 Protokolle aus der KI-gestützten Entwicklung. Die Entwickler werden laut Studie „mehr Fullstack“. Als Beispiel nennt sie einen Backend-Entwickler, der mit KI komplexe Oberflächen baut. 27 % der KI-gestützten Arbeit wäre ohne KI nach eigener Angabe gar nicht erledigt worden. Das sind Selbstauskünfte und sie stammen vom Hersteller, die Richtung ist trotzdem eindeutig.

Für Produktmanagement, Design, Infrastruktur und Betrieb gibt es noch keine vergleichbar sauberen Messungen. Bei uns liegen die Regeln für Gestaltung, Architektur, Datenmodell, Betrieb und Sicherheit als schriftliche Anleitungen vor, mit denen die KI-Agenten in jedem Ticket arbeiten. Wie gut das gelingt, entscheidet nicht die KI allein, sondern die Prüfung danach.

KI ist nicht überall gleich gut

Wer daraus schließt, KI könne einfach alles, unterschätzt die Grenzen. In einer Studie mit 758 Beratern der Boston Consulting Group erledigten die Teilnehmer mit KI 12,2 % mehr Aufgaben, arbeiteten 25,1 % schneller und lieferten 40 % höhere Qualität, solange die Aufgabe innerhalb dessen lag, was die KI gut kann. Bei einer Aufgabe knapp außerhalb dieser Grenze lösten Berater ohne KI sie zu 84 % richtig, mit KI nur zu 60 bis 70 %. Die Forscher nennen das die „gezackte Grenze“ der KI: Von außen sieht man nicht, wo sie verläuft.

Bei erfahrenen Entwicklern in ihren eigenen Projekten fand die Organisation METR Anfang 2025 sogar eine Verlangsamung: 16 Entwickler brauchten für 246 Aufgaben mit KI-Werkzeugen 19 % länger. Vorher hatten sie mit 24 % Zeitgewinn gerechnet, hinterher glaubten sie, 20 % schneller gewesen zu sein. Und in einer Studie der Stanford University schrieben Teilnehmer mit KI-Assistent unsichereren Code als ohne und hielten ihn häufiger für sicher.

Der DORA-Report 2025 mit fast 5.000 Befragten fasst es so zusammen: KI repariert kein Team, sie verstärkt, was schon da ist. KI-Einsatz geht dort mit mehr Durchsatz und besserer Produktleistung einher, aber auch mit mehr Instabilität. Ohne robuste Kontrollsysteme wie automatisierte Tests führt mehr Änderungsvolumen zu Instabilität.

Fullstack mit KI funktioniert also nur zusammen mit einem System, das prüft. Wie wir das aufbauen, steht in Verschiebt KI den Aufwand nur ins Code-Review?

Warum der Abstand mit KI wächst

Faros AI hat 2025 die Daten von rund 10.000 Entwicklern aus über 1.200 Teams ausgewertet. Teams mit viel KI-Einsatz erledigen 21 % mehr Aufgaben und führen 98 % mehr Änderungen in den Code zusammen. Das Review dauert aber 91 % länger, und auf Ebene des ganzen Unternehmens fand die Studie keinen messbaren Zusammenhang mehr zwischen KI-Einsatz und Ergebnis. Die beim Programmieren gesparte Zeit staut sich an der nächsten Station.

Ein Rechenbeispiel mit angenommenen Zahlen: Ein Feature braucht zehn Arbeitstage bis zur Auslieferung. An drei Tagen wird programmiert, an sieben wartet es auf andere Teams, auf Abstimmungen und Freigaben. Halbiert KI die Programmierzeit, ist das Feature nach achteinhalb Tagen fertig, 15 % schneller. Je schneller das Programmieren wird, desto mehr bestimmt die Wartezeit die Gesamtdauer.

Unsere Einschätzung: Wer nach Technik getrennt arbeitet, holt mit KI nur einen Teil des möglichen Tempos ab. Teams, die ein Feature ohne Übergaben liefern, bekommen dagegen fast die ganze Ersparnis. Mit jeder Verbesserung der Modelle wächst dieser Abstand. Dass nach Technik geschnittene Organisationen deshalb nicht mehr wettbewerbsfähig sind, belegt bisher keine Studie. Die genannten Daten zeigen aber in diese Richtung.

So arbeiten wir

Bei uns gibt es keine Abteilung für Oberfläche, Server oder Betrieb. Ein Feature ist ein Ticket, und ein Ticket läuft in einem Durchgang von der Planung bis zur Auslieferung. Wer dabei was tut, beschreiben wir ausführlich unter Agentic Engineering. Für den Schnitt sind vier Dinge wichtig:

  • Ein Bauauftrag für das ganze Feature. Für jedes Ticket entstehen vor dem Bau Szenarien und Tests. Ein frischer KI-Agent baut dann Oberfläche, Serverlogik, Datenmodell, Tests und Dokumentation in einem Zug. Ein Agent eines anderen Anbieters prüft das Ergebnis.
  • Fachwissen als Regeln statt als Abteilung. Was anderswo in Design-, Architektur-, Datenbank- oder Betriebsteams steckt, liegt bei uns als schriftliches Regelwerk vor. Die Planung nimmt die Regeln, die ein Ticket braucht, ausdrücklich in den Bauauftrag auf. Der Agent bekommt so das Wissen, das er für dieses Feature braucht, und nicht den ganzen Rest.
  • Geteilt wird nach Prüfbarkeit, nicht nach Disziplin. Ist eine Änderung zu groß, um sie in einem Stück sorgfältig zu prüfen, bauen wir sie in mehreren Läufen. Dabei kann ein Lauf den Server betreffen und ein anderer die Oberfläche. Das Ticket, die Szenarien und der Änderungsvorschlag bleiben aber eins, und ausgeliefert wird das Feature als Ganzes.
  • Jede sichtbare Funktion hat einen Test von außen. Er prüft das Feature so, wie ein Nutzer es erlebt, über alle Schichten hinweg, und muss bestehen, bevor das Feature auf die Testumgebung kommt. Vor jeder Auslieferung läuft die gesamte Testsuite. Zu jeder Planung gehört eine Pflichtliste mit Randfällen, von leeren Zuständen bis zur Darstellung auf dem Handy.

Was gebaut wird, ob es passt und wann es live geht, entscheidet bei uns weiterhin ein Mensch.

Was das an Tempo bringt, lässt sich an dieser Website nachzählen. Den Umzug der Website auf Next.js haben wir in einem Release mit elf Tickets erledigt: von der Prüfstrecke für jede Änderung über Design-System, Seiten, Kontaktformular und Suchmaschinen-Einstellungen bis zur neuen Test- und Produktionsumgebung im Cluster. Das Release haben wir am 12. Oktober um 8 Uhr angelegt, am 13. Oktober um 9:25 Uhr lief die neue Website geprüft in Produktion. Für zwei Blogartikel im Oktober lagen zwischen dem angelegten Ticket und dem Merge in den Live-Zweig 34 und 27 Minuten. Der Text war da schon fertig; gemessen ist die Strecke aus Plan, Bau, Tests, Prüfung durch den zweiten Anbieter, Testumgebung und Freigabe. Insgesamt gingen für diese Website im Oktober mindestens 19 Releases live.

Zwei Arten, Teams zu schneiden

MerkmalNach Technik geschnittenNach Feature geschnitten
Wer ein Feature liefertmehrere Teams nacheinanderein Team in einem Durchgang
Wo Zeit verloren gehtan jeder Übergabe und in jeder Warteschlangevor allem beim Bauen und Prüfen selbst
Was KI beschleunigteinzelne Schritte, die Wartezeit bleibtden ganzen Durchlauf
Wo Spezialwissen stecktin Abteilungenin Regeln, Plattformen und Prüfungen

Was das für Sie heißt

Ob KI in Ihrer Entwicklung Tempo bringt, hängt weniger vom Modell ab als vom Schnitt Ihrer Teams. Drei Fragen zeigen, wo Sie stehen:

  • Wie viele Teams muss ein kleines Feature durchlaufen, bis es live ist?
  • Welcher Anteil der Durchlaufzeit ist Arbeit, welcher ist Warten?
  • Kann ein Team ein Feature ausliefern, ohne jemanden außerhalb um Erlaubnis zu fragen?

Lauten die Antworten „mehrere“, „vor allem Warten“ und „nein“, wird KI bei Ihnen vor allem die Warteschlangen verlängern. Das zeigen die Zahlen von Faros.

Sie wollen wissen, wie ein Feature bei Ihnen am Stück laufen kann? Sprechen Sie uns an. Mehr zu unserem Vorgehen: Was ist Agentic Development?

Quellen