AI-Dev#1: Warum KI kein Tool-Problem ist, sondern ein Organisationsproblem

Kurzfassung: KI-Tools wie Copilot oder Claude Code werden oft als individuelle Assistenten behandelt und entwickeln sich dabei zu geteilter Infrastruktur. Eine Umfrage mit 99 Entwicklerinnen und Entwicklern zeigt: 73,3 Prozent leiden unter fragmentierten Tool-Landschaften, und die klare Mehrheit (+1,38 auf einer 7-stufigen Skala) will KI wie CI-Pipelines zentral verwaltet wissen. Dieser Artikel erklärt, warum das ein Organisationsdesign-Problem ist, und kein Tool-Problem.

Es ist kurz vor zehn, die Kaffeemaschine läuft. Vier Entwicklerinnen und Entwickler stehen in der Küche, und das Gespräch dreht sich wie fast jeden Morgen um Tools. Die eine ist vergangenen Monat komplett auf Cursor umgestiegen, weil der Editor endlich ihren Codestil gelernt habe. Der zweite nutzt seit letzter Woche Claude Code für Refactorings und erklärt, warum das alles verändert. Der dritte darf nur Copilot einsetzen, weil die Rechtsabteilung die anderen Tools noch prüft. Die vierte hat am Wochenende ein Agenten-Setup aus drei Komponenten gebastelt und ist überzeugt, dass das der einzig vernünftige Weg sei.

Vier Personen. Vier völlig unterschiedliche Arbeitsumgebungen. Alle produktiver als vor einem Jahr. Und alle in verschiedenen Universen.

Wenn dir diese Szene bekannt vorkommt, bist du nicht allein. Sie beschreibt ziemlich genau den Zustand, in dem sich ein Großteil der Softwareentwicklung gerade befindet. Und sie ist der Ausgangspunkt für diese neue Blog-Reihe. In den nächsten sechs Beiträgen geht es nicht darum, welches KI-Tool gerade das beste ist. Es geht um eine These, die unbequem ist, aber empirisch immer besser abgestützt: KI-Integration ist kein Tool-Problem, sondern ein Organisationsproblem.

Die Copilot-Metapher führt in die Irre

Die Sprache, die wir rund um KI im Engineering benutzen, hat uns in eine Denkfalle manövriert. „Assistent". „Copilot". „Pair Programmer". Jeder dieser Begriffe suggeriert dasselbe Bild: Ein Mensch macht die eigentliche Arbeit, eine Maschine hilft freundlich dabei. Das Team bleibt, wie es ist. Die Prozesse bleiben, wie sie sind. Nur jede Einzelperson bekommt einen kleinen Produktivitätsschub.

Dieses Bild ist nicht nur unvollständig. Es ist irreführend.

Ein Assistent hilft. Infrastruktur ermöglicht. Das ist ein kategorialer Unterschied. Wenn in einem Unternehmen jede Person ihr eigenes Wiki führt, sagt niemand, man habe eine „Wissens-Infrastruktur". Wenn alle dasselbe Confluence nutzen, auf das sich Prozesse, Onboarding und Governance beziehen, dann hat man eine. KI-Tools sind gerade dabei, in genau diese zweite Kategorie zu rutschen. Sie werden zu dem Ort, an dem Code entsteht, an dem Spezifikationen formuliert werden, an dem Architekturentscheidungen geschliffen werden. Nur behandeln wir sie weiterhin, als wären sie eine besonders schlaue Form von IntelliSense.

	KI als Assistent	KI als Infrastruktur
Entscheidung	Jede Person wählt selbst	Team entscheidet gemeinsam
Scope	Einzelplatz-Abo	Geteilte Umgebung
Governance	Keine	Explizite Regeln (Datenzugriff, Prompts, Reviews)
Lerneffekt	Individuell	Kumulativ auf Organisationsebene
Analogie	Privates Dropbox-Konto	Gemeinsames Confluence

Im XP 2025 Workshop zu KI und Agilität haben Herda und Kolleginnen über 120 Schmerzpunkte von Praktikerinnen und Praktikern gesammelt. Die häufigste Frustration, genannt von 73,3 Prozent der Teilnehmenden: fragmentierte Tool-Landschaften. Menschen, die alleine gut mit KI zurechtkommen, aber im Team nicht mehr zueinander finden. Das XP 2026 Position Paper, das den Ausgangspunkt für unsere Forschung bildet, nennt dieses Muster Vibe Coding: eine Arbeitsweise, in der die KI-Nutzung opportunistisch, unstrukturiert und individuell geschieht. Mit isolierten Erfolgen, aber ohne kumulativen Lerneffekt auf Organisationsebene.

AI-Dev-Systems: Wenn aus Werkzeugen Infrastruktur wird

Um dieser Falle zu entkommen, braucht es einen anderen Begriff. Im XP 2026 Paper führen wir dafür den Ausdruck AI-Dev-System ein. Ein AI-Dev-System ist eine konfigurierte Umgebung aus KI-Agenten, Tools, Workflows und Wissensdatenbanken, die bewusst für systematische Softwareentwicklung entworfen wurde.

Das klingt abstrakt, also konkret: Ein AI-Dev-System ist es, wenn ein Team gemeinsam festlegt, welches Basismodell genutzt wird, welche Prompt-Konventionen gelten, welche internen Dokumente per Model Context Protocol verfügbar sind, welche Test- und Review-Workflows automatisch greifen und welche Daten die KI niemals sehen darf. Es ist nicht „wir haben alle Copilot gekauft". Ein Einzelplatz-Abo in jeder IDE ist genauso wenig eine gemeinsame Infrastruktur wie fünf private Dropboxen eine gemeinsame Datenablage sind.

Das entscheidende Wort in der Definition lautet intentional design: bewusste Entscheidungen über Fähigkeiten, Interaktionsmuster und Domänenwissen, die für das ganze Team gelten. Genau hier wird aus einem Werkzeug etwas anderes. Nämlich der Rahmen, in dem gearbeitet wird.

Was 99 Entwicklerinnen und Entwickler dazu sagen

Für unsere ISD 2026 Studie haben wir 99 professionelle Entwicklerinnen und Entwickler über Prolific befragt. Auf einer Skala von −3 (starke Ablehnung) bis +3 (starke Zustimmung) haben sie eine Reihe von Aussagen zur organisatorischen Dimension von KI bewertet. Drei Ergebnisse greifen die These dieses Beitrags direkt auf.

Erstens: Geteilte Infrastruktur wird klar bevorzugt. Die Aussage „KI-Tools sollten wie CI-Pipelines oder Versionskontrolle als geteilte Infrastruktur verwaltet werden" kam auf einen Mittelwert von +1,38. Das ist eine deutliche moderate Zustimmung und eines der stärksten Signale im gesamten Block. Übersetzt: Die Befragten wollen genau nicht, dass jede Person ihr eigenes Setup zusammenklickt.

Zweitens: Dedizierte Teams für KI-Entwicklungsumgebungen werden als hilfreich gesehen. Die Aussage „Es wäre hilfreich, wenn dedizierte Teams die KI-Entwicklungsumgebungen verwalten würden" erreichte +1,13. Auch das ein klares, moderat zustimmendes Signal. Man will nicht, dass jedes Team diese Arbeit nebenbei mitmacht.

Drittens, und das ist der spannendste Befund: Es gibt keinen Konsens darüber, ob KI hauptsächlich ein technisches Problem ist. Die entsprechende Frage (umgepolt formuliert) landete bei einem Mittelwert von +0,08, also praktisch neutral, und das Konfidenzintervall schließt die Null ein. Das ist kein Widerspruch zu den beiden anderen Ergebnissen. Es ist eine ehrliche Zwischenposition: Ja, KI hat eine gewichtige technische Seite. Aber nein, allein auf der technischen Ebene ist das Problem nicht mehr zu lösen. Praktikerinnen und Praktiker sehen die Doppelnatur der Herausforderung.

Der überraschende Teil: Der Schmerz ist noch nicht akut

Hier wird es interessant. Man könnte jetzt erwarten, dass die Fragmentierung auch im konkreten Arbeitsalltag als schmerzhaft empfunden wird. Ist sie aber nur begrenzt.

Die Aussage „Die unabhängige Tool-Auswahl führt in meinem Team bereits zu Fragmentierung" erreichte einen Mittelwert von +0,46. Das ist neutral. Das Konfidenzintervall reicht von +0,14 bis +0,78. Also leicht ins Positive, aber weit weg von echtem Leidensdruck.

Es entsteht ein bemerkenswertes Bild: Die Befragten wollen geteilte Infrastruktur (+1,38), bevor sie den Schmerz fehlender geteilter Infrastruktur wirklich spüren (+0,46). Das ist weitsichtig. Und das ist die eigentliche Botschaft dieses Beitrags.

Wir befinden uns in einem Zeitfenster, das so nicht bleiben wird. Die allermeisten Unternehmen stehen gerade erst am Anfang breiter KI-Nutzung. Die Tools sind noch neu genug, dass jeder Workaround als Lernphase durchgeht. Die Teams sind noch klein genug, dass fünf unterschiedliche Setups noch nicht in einem unauflösbaren Knoten enden. Aber die Fragmentierung kommt, genauso sicher, wie sie bei Testwerkzeugen, bei CI-Systemen oder bei Monitoring-Stacks gekommen ist. Jedes Unternehmen, das in den 2010er Jahren überlebt hat, hat irgendwann gelernt: Individuelle Tool-Entscheidungen funktionieren, bis sie es nicht mehr tun. Dann kommt der Konsolidierungsschmerz mit voller Wucht.

Bei KI ist die Chance, diese Phase nicht erst durchleiden zu müssen, sondern sie zu überspringen. Nicht weil jemand die Warnung ernst nimmt, sondern weil man die Antwort schon kennt, bevor das Problem richtig anfängt wehzutun.

Warum das die Perspektive ändert

Wenn du die Copilot-Metapher loslässt und KI stattdessen als Infrastruktur denkst, stellen sich plötzlich andere Fragen. Nicht mehr „Welches Tool sollen wir kaufen?", sondern:

• Wer entscheidet, welche KI-Umgebung wir bereitstellen?
• Wer pflegt diese Umgebung, wenn sich das Basismodell monatlich ändert?
• Welche Workflows sollen automatisch greifen, welche bleiben menschlich?
• Wie gehen wir mit Wissen um, das in Prompts und Kontextfenstern liegt?
• Was dürfen Modelle sehen, was nicht?
• Wie messen wir überhaupt, ob unsere KI-Infrastruktur funktioniert?

Das sind keine Tool-Fragen. Das sind Organisationsdesign-Fragen. Und sie führen ziemlich direkt zu einer Frage, der wir im nächsten Beitrag nachgehen werden: Wenn KI Infrastruktur ist, wer baut und betreibt diese Infrastruktur?

Die Antwort, die wir im XP 2026 Paper vorgeschlagen haben, ist ein Drei-Schichten-Modell mit System Teams, Platform Teams und Product Teams. Ob dieses Modell trägt, ob es praxistauglich ist, wo es hakt, das wird Thema von AI-Dev#2. Hier reicht vorerst die Feststellung: Der Boden, auf dem dieses Modell steht, ist empirisch deutlich tragfähiger, als wir beim Schreiben des Position Papers vermutet hatten.

Die Reihe im Überblick

Diese Reihe besteht aus sechs Beiträgen. In AI-Dev#2 stellen wir das Drei-Schichten-Modell im Detail vor und zeigen, wie es sich an Team Topologies (Skelton und Pais) anlehnt. In AI-Dev#3 geht es um den Rollenwandel der Entwicklerinnen und Entwickler selbst: vom Code-Schreibenden zum Steward, zur Person, die KI-Outputs bewertet und lenkt. AI-Dev#4 widmet sich TDD und CI als neuen Governance-Mechanismen für KI-generierten Code. In AI-Dev#5 nehmen wir uns den spannendsten Befund der Studie vor: Die Praktikerinnen finden das Modell überzeugend, bezweifeln aber, dass ihre eigene Organisation reif genug ist. Und AI-Dev#6 stellt die provokanteste Frage: Braucht der Zwei-Wochen-Sprint überhaupt noch ein Update?

Wer schon einen Vorgeschmack möchte, wie sich diese Perspektive auf den individuellen Arbeitsalltag auswirkt, findet im älteren Beitrag UX-AI#1: „Wie ich AI-Tools als UX-Professional einsetze" die Tool-Sicht. Diese Reihe ist das Gegenstück dazu: der Blick auf die Organisation, in der diese Tools eingebettet sind.

Was du aus diesem Beitrag mitnehmen solltest

1. Die Copilot-Metapher unterschätzt, was gerade passiert. Assistenten helfen, Infrastruktur ermöglicht. KI-Tools kippen gerade in die zweite Kategorie.
2. Ein AI-Dev-System ist eine bewusst konfigurierte Umgebung, nicht eine Sammlung von Einzelplatz-Tools.
3. Praktikerinnen wollen geteilte Infrastruktur (+1,38) und dedizierte Teams (+1,13) für KI. Die Richtung ist empirisch klar.
4. Der Schmerz fehlender Infrastruktur wird noch nicht akut erlebt (+0,46). Genau deshalb ist jetzt der richtige Moment, die Antwort zu bauen.
5. Die produktive Frage lautet nicht „Welches Tool?", sondern „Wie designen wir Teams und Umgebungen, damit KI systematisch nützlich wird?"

Im nächsten Beitrag geht es konkret um das Drei-Schichten-Modell. Wer baut? Wer betreibt? Wer nutzt? Und welche Erkenntnisse aus Team Topologies helfen uns dabei, diese Rollen sinnvoll zu trennen?

Bis dahin.

Quellen

Dieser Beitrag basiert auf den folgenden Quellen:

• Hinderks, A., Thomaschewski, J., & Schön, E.-M. (2026). From AI Assistants to AI-Dev-Systems: A Three-Layer Model for Human-AI Collaboration in Agile Software Development. Position Paper, XP 2026 Workshop, São Paulo, Brazil.
• Hinderks, A., Thomaschewski, J., & Schön, E.-M. (2026). Prolific-Umfrage mit n=99 professionellen Softwareentwicklerinnen und -entwicklern.
• Herda, T. et al. (2025). XP 2025 Workshop on AI and Agile Software Development. Synthese von über 120 Praktiker-Schmerzpunkten
• Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
• Kudina, O., & van de Poel, I. (2024). A Sociotechnical Perspective on AI.

Die konkreten Umfragewerte (Mittelwerte, Konfidenzintervalle) stammen aus Block O der ISD 2026 Studie. Die Skala reicht von −3 (starke Ablehnung) bis +3 (starke Zustimmung), n=99.