KI-gestützte Entwicklung: Warum KI kein Tool-Problem ist, sondern ein Organisationsproblem

KI-gestützte Entwicklung bedeutet mehr als GitHub Copilot einzuführen. Eine empirische Studie mit 99 professionellen Softwareentwicklern zeigt: 88 % nutzen KI-Tools täglich, aber ohne organisatorische Strukturen entsteht fragmentiertes „Vibe Coding" statt systematischer Integration. Das Drei-Schichten-Modell (System Teams, Platform Teams, Product Teams) bietet einen evidenzbasierten Ansatz, um KI-Assistenten als geteilte Infrastruktur zu organisieren – unabhängig von der Teamgröße.

Dein Team nutzt GitHub Copilot. Oder Cursor. Oder Claude. Vielleicht alle drei gleichzeitig, je nachdem, wen du fragst.

Das ist kein Sonderfall. In unserer Studie mit 99 professionellen Softwareentwicklern gaben fast 88 % an, täglich KI-Tools einzusetzen. Die Realität ist: KI-Coding-Assistenten sind keine Zukunftsmusik mehr. Sie sind Alltag. Aber genau hier beginnt das Problem.

Denn die meisten Unternehmen behandeln KI wie ein neues IDE-Plugin. Jeder Developer wählt sein eigenes Tool, konfiguriert es nach Belieben, schreibt eigene Prompts. Das Ergebnis? Fragmentierung. Jedes Teammitglied arbeitet in einer anderen KI-Umgebung. Wissen wird nicht geteilt. Governance existiert bestenfalls als Absichtserklärung. Und wenn etwas schiefgeht mit KI-generiertem Code, ist unklar, wer eigentlich verantwortlich ist.

Wir nennen dieses Muster Vibe Coding: unstrukturierte, opportunistische KI-Nutzung, die im Einzelfall funktioniert, aber keine organisatorische Lernfähigkeit aufbaut. Der eine Developer hat großartige Ergebnisse mit seinem Custom-Setup. Aber das Wissen bleibt in seinem Kopf. Wenn er das Team verlässt, geht die KI-Kompetenz mit.

Das eigentliche Problem ist nicht das Tool

Die gängige Erzählung lautet: „KI ist ein Produktivitätswerkzeug. Gib es den Leuten, und sie werden schneller." Das stimmt sogar teilweise. Kontrollierte Studien berichten von Produktivitätssteigerungen von bis zu 55 % bei abgegrenzten Coding-Aufgaben. Und unsere Umfrageteilnehmer bestätigen das: Der stärkste Wert in der gesamten Studie (M=+1,98 auf einer Skala von -3 bis +3) zeigt, dass Entwickler KI als fundamentale Veränderung ihrer Arbeitsweise erleben.

Aber hier liegt der Kategorienfehler: Individuelle Produktivität und organisatorische Integration sind zwei völlig verschiedene Dinge.

Forschung zeigt ein paradoxes Muster: Entwickler berichten hohe persönliche Zufriedenheit mit KI-Assistenten, während gleichzeitig die Team-Interaktion und der Wissensaustausch zurückgehen. In einem Workshop auf der XP 2025 identifizierten 73,3 % der Teilnehmer fragmentiertes Tooling als ihre größte Frustration. Governance-Unsicherheit und fehlende Prompt-Engineering-Kompetenz verschärfen das Problem.

Die Frage ist also nicht: Wie fügen wir KI-Tools in bestehende Teams ein? Sondern: Wie gestalten wir Teams und Infrastrukturen, die KI systematisch nutzbar machen?

Von Assistenten zu AI-Dev-Systems

Der erste Schritt ist ein Perspektivwechsel. KI-Tools wie Copilot oder Cursor sind nicht einfach „Assistenten". Wenn du sie ernsthaft einsetzt, konfigurierst du eine komplexe Umgebung: du wählst Agenten aus, definierst Workflows, bindest Wissensdatenbanken ein, legst Coding-Regeln fest.

Diese konfigurierten Umgebungen nennen wir AI-Dev-Systems: absichtsvoll gestaltete Systeme aus KI-Agenten, Tools, Workflows und Wissensdatenbanken für die systematische Softwareentwicklung. Beispiele reichen von Cursor mit projektspezifischen Regeln über Claude mit Model Context Protocol-Integrationen bis hin zu spezialisierten Umgebungen wie Design OS oder Agent OS.

Der entscheidende Punkt: Ein AI-Dev-System ist keine individuelle Tool-Wahl. Es ist geteilte Infrastruktur. Und wie jede Infrastruktur braucht es jemanden, der sie baut, wartet und weiterentwickelt. Wenn ein Foundation-Model-Update die Prompts deines Teams invalidiert, wenn ein neuer Agent bessere Code-Reviews liefert als der aktuelle, wenn Compliance-Anforderungen sich ändern: wer passt die Umgebung an? Wer testet, ob die Workflows noch funktionieren? Wer stellt sicher, dass das Wissen des Teams in die KI-Konfiguration zurückfließt?

Unsere Studie bestätigt das: Die Aussage „KI-Tools sollten als geteilte Infrastruktur verwaltet werden" erhielt mit M=+1,38 eine der stärksten Zustimmungen im gesamten Fragebogen. Entwickler wissen intuitiv, dass der aktuelle Zustand nicht tragfähig ist.

Das Drei-Schichten-Modell

In unserem XP-2026-Paper (Hinderks et al., 2026) schlagen wir ein konkretes Organisationsmodell vor, das sich an der bewährten Logik des Platform Engineering orientiert. Das Konzept der Team Topologies von Skelton und Pais hat gezeigt, dass Plattform-Teams komplexe Infrastruktur abstrahieren und als Self-Service-Fähigkeiten bereitstellen können. Wir übertragen dieses Prinzip auf KI-Infrastruktur.

Das Modell besteht aus drei Schichten:

	System Teams	Platform Teams	Product Teams
Rolle	Entwerfen & konstruieren AI-Dev-Systems	Betreiben & entwickeln AI-Dev-Systems weiter	Entwickeln Software innerhalb der KI-Umgebung
Team-Topologies-Typ	Complicated Subsystem Team	Platform Team	Stream-aligned Team
Kernaufgaben	Architektur-Entscheidungen: Agenten, Workflows, Wissensbasis	Bugfixes, Modell-Updates, Capability-Erweiterungen	Steuerung und Bewertung von KI-Outputs
Fokus	Orchestrierungskomplexität absorbieren	Betriebsstabilität bei schnellen Modell-Updates	Produktentwicklung statt Tool-Konfiguration
Beispiel	Evaluierung neuer Agenten, Prompt-Architektur	Regressions-Management nach Foundation-Model-Update	Feature-Entwicklung mit kuratiertem AI-Dev-System

System Teams entwerfen und konstruieren AI-Dev-Systems. Sie treffen die Architektur-Entscheidungen: Welche Agenten? Welche Workflows? Welche Wissensbasis? In der Sprache der Team Topologies sind sie Complicated Subsystem Teams, die Orchestrierungskomplexität absorbieren, damit nicht jeder Developer zum Prompt-Engineering-Experten werden muss.

Platform Teams betreiben und entwickeln die AI-Dev-Systems nach dem Deployment weiter. Bugfixes, Modell-Updates, Capability-Erweiterungen, Regressions-Management. KI-Infrastruktur erfordert dabei eine höhere Betriebsgeschwindigkeit als klassische Plattformen: Foundation-Model-Updates können das Systemverhalten unvorhersehbar verändern.

Product Teams entwickeln Software innerhalb der bereitgestellten KI-Umgebung. Statt selbst Tools auszuwählen und zu konfigurieren, konsumieren sie ein kuratiertes AI-Dev-System. Ihr Fokus verschiebt sich: weg von der Code-Produktion, hin zur Steuerung und Bewertung von KI-Outputs.

Was die Daten zeigen

Wir haben das Drei-Schichten-Modell in einer Querschnittsstudie mit 99 professionellen Softwareentwicklern empirisch überprüft. Die Teilnehmer wurden über die Plattform Prolific rekrutiert und bewerteten 28 Items auf einer 7-stufigen Likert-Skala (normalisiert auf -3 bis +3).

Die Ergebnisse bestätigen drei zentrale Aussagen:

1. Praktiker sehen KI-Integration als Organisationsproblem. Die Zustimmung zur Aussage, dass dedizierte Teams für KI-Entwicklungsumgebungen hilfreich wären, liegt bei M=+1,13. Die Forderung nach geteilter Infrastruktur erreicht M=+1,38. Und der Zusammenhang ist klar: Wer KI intensiver nutzt, bewertet die organisatorische Dimension signifikant höher (Cohens d=1,63, p<0,001).

2. Das Drei-Schichten-Modell wird als plausibel bewertet. Die Kernaussage „Das Drei-Schichten-Modell ist eine plausible Organisationsstruktur" erreicht M=+1,49. System Teams (M=+1,39) und Platform Teams (M=+1,27) werden jeweils einzeln als sinnvoll bewertet. Auch kleine Teams sehen Potenzial: Die Aussage, dass eine vereinfachte Version funktionieren könnte, erzielt M=+1,12.

3. Die Rollenverschiebung ist bereits Realität. Entwickler berichten, dass sie weniger Code schreiben und mehr reviewen und steuern (M=+0,72). Sie verbringen mehr Zeit mit Produktentscheidungen als mit Implementierung (M=+0,97). Teams iterieren spürbar schneller (M=+1,53). Und die Kernkompetenz verschiebt sich vom Coden zum Dirigieren von KI (M=+1,33).

Die Plausibility-to-Applicability Gap

Die vielleicht wichtigste Erkenntnis aus unserer Studie ist allerdings eine Spannung. Drei Items erzählen zusammen eine Geschichte:

• M1 (M=+1,49): „Das Modell ist plausibel." Starke Zustimmung.
• M5 (M=+0,76): „Das Modell würde in meiner Organisation funktionieren." Deutlich schwächere Zustimmung.
• M6 (M=+1,40): „Das Modell erfordert eine organisatorische Reife, die die meisten Unternehmen noch nicht haben." Wieder starke Zustimmung.

Wir nennen das die Plausibility-to-Applicability Gap: Praktiker akzeptieren die Logik des Modells, bezweifeln aber, dass ihre Organisationen bereit sind, es umzusetzen. Das ist kein Widerspruch. Es ist eine realistische Einschätzung, die an frühere Integrations-Herausforderungen in der Softwareentwicklung erinnert. Auch bei der Integration von UX in agile Prozesse vergingen Jahre zwischen konzeptioneller Akzeptanz und tatsächlicher organisatorischer Umsetzung.

Interessant ist dabei: Diese Gap ist nicht abhängig von der Teamgröße. Wir hatten erwartet, dass Praktiker in großen Teams (ab 10 Personen) das Modell plausibler finden als Kollegen in kleinen Teams. Das Gegenteil war der Fall: Beide Gruppen bewerteten das Modell praktisch gleich positiv. Das bedeutet, die Logik des Drei-Schichten-Modells überzeugt unabhängig von der Organisationsgröße. Die Hürde liegt nicht in der Größe, sondern in der Reife.

Was sich für agile Praktiken verändert

Ein Nebenergebnis, das genauso wichtig ist wie die Hauptergebnisse: KI löst agile Praktiken nicht ab, sondern transformiert sie.

Die beiden stärksten Werte in unserer gesamten Studie betreffen agile Governance: Continuous Integration wird als kritischer bewertet, weil KI-generierter Code stärkere Prüfungen braucht (M=+1,98). Test-Driven Development wird nicht mehr nur als Coding-Disziplin gesehen, sondern als Spezifikationsmechanismus, um der KI den eigenen Intent zu kommunizieren (M=+1,61).

TDD und CI bilden zusammen das, was wir einen Governance Envelope nennen: eine Kombination aus strukturierter Spezifikation und automatisierter Verifikation, die KI-generierte Arbeit umgibt. Und genau diese Governance-Infrastruktur wäre eine explizite Verantwortung der Platform Teams im Drei-Schichten-Modell.

Was du jetzt tun kannst

Du musst nicht sofort drei neue Teams gründen. Die Logik des Modells lässt sich auch schrittweise umsetzen:

Geteilte KI-Konfigurationen einführen. Statt dass jeder Developer seine eigene Cursor- oder Copilot-Konfiguration pflegt: Erstellt ein gemeinsames Setup mit Projekt-Regeln, Coding-Standards und geteilten Prompt-Templates. Das ist der erste Schritt von Vibe Coding zu einem AI-Dev-System.

KI-Governance in Retrospektiven aufnehmen. Unsere Studie zeigt starke Zustimmung (M=+1,29), dass Retrospektiven auch die KI-Entwicklungsumgebung evaluieren sollten. Macht es zum Thema: Welche KI-Workflows funktionieren? Welche nicht? Wo fehlen Guidelines?

Eine Person als KI-Infrastruktur-Owner benennen. In kleinen Teams braucht es kein dediziertes Platform Team. Aber jemand sollte die Verantwortung übernehmen, die KI-Umgebung zu kuratieren, statt das jedem Einzelnen zu überlassen. Unsere Studie bestätigt: Auch Praktiker in kleinen Teams sehen Potenzial in vereinfachten Varianten des Modells (M=+1,12).

CI/CD-Pipelines für KI-generierten Code verstärken. Wenn KI den Code schreibt, werden automatisierte Tests und Continuous Integration nicht weniger wichtig, sondern deutlich wichtiger. Investiere in dein Test-Harness, bevor du in mehr KI-Agenten investierst.

Fazit

Die Frage ist nicht mehr, ob dein Team KI-Tools einsetzt. Die Frage ist, ob dein Unternehmen die Organisationsstrukturen hat, um daraus mehr zu machen als individuelle Produktivitätsgewinne.

Unsere Forschung zeigt: Praktiker sehen das Problem klar. Sie wissen, dass KI keine reine Tool-Frage ist. Sie finden das Drei-Schichten-Modell plausibel. Aber sie sehen auch, dass die meisten Organisationen noch nicht bereit sind.

Das ist kein Grund zu warten. Es ist ein Grund, jetzt anzufangen, schrittweise, pragmatisch, mit den Ressourcen, die da sind. Wer die Strukturen heute nicht bewusst gestaltet, wird morgen die Fragmentierung reparieren müssen.