AI entwickelt sich in einem Tempo, das selbst erfahrene Technologieorganisationen unter Druck setzt. Neue Modelle erscheinen im Abstand weniger Monate. Agent Frameworks, Coding Tools und Skills verändern sich teilweise innerhalb von Wochen. Prompts werden täglich angepasst.
Gleichzeitig brauchen Unternehmen Jahre, um ihre Architektur zu modernisieren, Daten verlässlich verfügbar zu machen, Governance aufzubauen, Menschen zu qualifizieren und Verantwortlichkeiten neu zu ordnen.
Genau darin liegt eines der größten Missverständnisse der aktuellen AI-Transformation: Wir sprechen über die Geschwindigkeit der AI, als gäbe es nur eine.
In Wahrheit bewegen sich Technologie, Software Engineering, Governance, Organisation und Kultur in völlig unterschiedlichen Takten.
Wer versucht, alle diese Ebenen auf das Tempo der neuesten Modelle zu beschleunigen, erzeugt keine Transformation. Er erzeugt Reibung, Überforderung und strukturelle Risiken.
Das Konzept der Pace Layers bietet dafür ein überraschend präzises Denkmodell.
TL;DR
Pace Layers beschreiben komplexe Systeme als übereinanderliegende Schichten mit unterschiedlichen Veränderungsgeschwindigkeiten. Die schnellen Schichten experimentieren und lernen. Die langsamen Schichten bewahren Stabilität, Wissen und Kontinuität.
Übertragen auf AI und Software Engineering bedeutet das: Prompts und Experimente können sich täglich ändern. Skills, Tools und Agenten entwickeln sich in Wochen. AI-Anwendungen, Workflows und Plattformen benötigen Monate oder Quartale. Architektur, Governance, Kompetenzen und Organisationskultur verändern sich über Jahre.
Für CTOs, CIOs und Tech-Entscheider folgt daraus:
- Nicht jede AI-Entscheidung braucht denselben Prozess und dieselbe Governance.
- Schnelle technische Komponenten müssen von stabilen Unternehmensschichten entkoppelt werden.
- AI Governance benötigt selbst unterschiedliche Geschwindigkeiten.
- Piloten müssen nicht nur Technologie testen, sondern Lernen in Architektur, Betrieb und Organisation erzeugen.
- Langsame Schichten sind nicht automatisch Blockaden. Sie sichern Kontinuität und begrenzen Risiken.
- Der eigentliche Engpass der AI-Transformation wandert von Modellen und Tools zu Daten, Prozessen, Governance, Skills und Organisationsdesign.
AI-Transformation ist deshalb kein einheitliches Veränderungsprogramm. Sie ist die bewusste Koordination eines Systems mit mehreren Geschwindigkeiten.
Warum AI-Transformation heute so widersprüchlich wirkt
Auf AI-Konferenzen entsteht schnell der Eindruck, vollständig autonome Softwareentwicklung und weitgehend automatisierte Unternehmen stünden unmittelbar bevor. Coding Agents analysieren Repositories, verändern Code, führen Tests aus und bereiten Pull Requests vor. Neue Modelle lösen Aufgaben, die wenige Monate zuvor noch als nicht automatisierbar galten.
In vielen Unternehmen sieht die Realität anders aus.
Daten liegen in Silos. Legacy-Systeme sind schwach dokumentiert. Security- und Datenschutzfragen sind ungeklärt. Verantwortlichkeiten für AI-Anwendungen fehlen. Pilotprojekte kommen nicht in die Produktion. Mitarbeitende erhalten Zugriff auf Tools, aber weder ein belastbares Zielbild noch ausreichend Orientierung.
Beide Beobachtungen sind richtig.
Sie stammen nur aus unterschiedlichen Veränderungsschichten.
Drew Breunig hat in einem Blogpost vor einigen Wochen ein Konzept von Stewart Brand auf die aktuelle AI-Entwicklung angewendet – und das hat mich beschäftigt. Denn Brand’s zentrale Beobachtung ist in vielerlei Hinsicht für Veränderungen im Technologiebereich und Organisationen relevant:
Die sichtbaren oberen Schichten des Ökosystems bewegen sich extrem schnell, während die tragenden unteren Schichten deutlich langsamer reagieren.
Das erklärt, warum technologische Möglichkeit und organisationale Realität immer weiter auseinanderzulaufen scheinen.
Was sind Pace Layers?
Stewart Brand entwickelte das Pace-Layer-Konzept zunächst aus der Beobachtung von Gebäuden und übertrug es später auf Gesellschaften und andere komplexe Systeme. Ein robustes System besteht demnach aus mehreren Schichten, die jeweils eine eigene Funktion und eine eigene Veränderungsgeschwindigkeit besitzen.
In seinem ursprünglichen Modell unterscheidet Brand sechs gesellschaftliche Ebenen:
- Mode und Kunst
- Handel
- Infrastruktur
- Governance
- Kultur
- Natur
Mode verändert sich schnell. Infrastruktur bewegt sich langsamer. Kultur und Natur verändern sich über sehr lange Zeiträume.
Die schnellen Ebenen produzieren Varianten, Experimente und Innovation. Die langsamen Ebenen speichern Erfahrung, schaffen Stabilität und verhindern, dass jede kurzfristige Bewegung das gesamte System destabilisiert. Brand beschreibt diese Wechselwirkung als Grundlage anpassungsfähiger und zugleich robuster Systeme. Seine Ausarbeitung erschien später im Journal of Design and Science des MIT Press.
Die entscheidende Idee lautet nicht, dass schnelle Veränderung gut und langsame Veränderung schlecht ist. Ein gesundes System benötigt beides.
Schnelle Schichten lernen. Langsame Schichten erinnern.
Problematisch wird es, wenn eine Schicht ihre Geschwindigkeit auf alle anderen überträgt. Wird Governance täglich verändert, verliert sie Verbindlichkeit. Wird von Kultur erwartet, sich wie ein Softwaretool aktualisieren zu lassen, entsteht Widerstand. Werden Experimente dagegen mit den Regeln langfristig stabiler Kernsysteme gesteuert, verschwindet ihre Lernfähigkeit.
Die Pace Layers von AI und Software Engineering
Für Unternehmen lässt sich der Ansatz in sieben praxisnahe Ebenen übersetzen.
Die oberen Schichten verändern sich in Tagen oder Wochen. Die unteren Schichten geben Stabilität, benötigen aber Monate oder Jahre.
1. Prompts und Experimente – Tage
Prompts, Hypothesen, Prototypen und Evaluationen bilden die schnellste Schicht. Hier wird ausprobiert, verworfen und neu kombiniert. Viele Entscheidungen sind reversibel und ihre Kosten begrenzt.
Diese Ebene braucht Freiraum, kurze Feedbackzyklen und eine hohe Fehlertoleranz. Ein schwergewichtiger Freigabeprozess würde mehr Schaden als Nutzen erzeugen.
Das bedeutet nicht, dass es keinerlei Regeln geben darf. Sensible Daten, ungeprüfte externe Dienste und sicherheitskritische Aktionen benötigen auch im Experiment klare Grenzen. Innerhalb dieser Grenzen sollte Lernen jedoch schnell stattfinden können.
2. Skills, Tools und Agenten – Wochen
AI-Tools, Agent Skills, MCP-Integrationen, Coding Agents und Orchestrierungsbausteine verändern sich schnell, aber nicht beliebig. Sobald mehrere Teams damit arbeiten, entstehen Abhängigkeiten, Supportbedarf und Sicherheitsfragen.
Aus individuellen Experimenten werden wiederverwendbare Fähigkeiten. Damit steigen die Anforderungen an Versionierung, Verantwortlichkeit, Dokumentation und Evaluation.
Gerade im Agentic Engineering zeigt sich diese Schicht besonders deutlich: Ein Prompt ist schnell geändert. Ein organisationsweit verwendeter Skill, der auf Repositories, Ticketsysteme oder interne Daten zugreift, ist bereits ein produktives Softwareartefakt.
3. AI-Anwendungen und Workflows – Wochen bis Monate
Auf dieser Ebene wird aus Technologie ein Geschäfts- oder Engineering-Prozess. Ein Agent analysiert nicht mehr nur Testdaten, sondern arbeitet im Software Development Lifecycle. Ein AI-Assistent beantwortet nicht mehr nur Fragen, sondern greift auf CRM-, Wissens- oder Prozessdaten zu.
Jetzt zählen Integration, Rollen, Eskalationswege, Human-in-the-loop-Entscheidungen und messbarer Nutzen.
Viele AI-Piloten scheitern beim Übergang in diese Schicht. Der Prototyp funktioniert, aber der produktive Workflow fehlt. Niemand ist dauerhaft verantwortlich. Schnittstellen sind instabil. Die Qualität wird nicht systematisch gemessen. Das Unternehmen hat ein technisches Ergebnis, aber noch keine organisationale Fähigkeit geschaffen.
4. Modelle, Daten und Plattformen – Monate bis Quartale
Modelle wechseln schneller als klassische Unternehmensplattformen. Datenmodelle, Integrationsarchitekturen, Berechtigungen, Observability und Evaluationssysteme müssen dagegen länger tragen.
Die strategische Aufgabe besteht deshalb nicht darin, das vermeintlich beste Modell dauerhaft festzuschreiben. Sie besteht darin, eine Plattform zu schaffen, auf der Modelle kontrolliert bewertet, ausgetauscht und für unterschiedliche Risikoklassen eingesetzt werden können.
Vollständige Modellunabhängigkeit bleibt dabei eine Illusion. Modelle unterscheiden sich in Verhalten, Tool-Nutzung, Kontextverarbeitung, Kosten und Sicherheitsprofil. Trotzdem lassen sich Abhängigkeiten durch klare Schnittstellen, Evaluation Suites, Routing und versionierte Konfigurationen deutlich reduzieren.
5. Softwarearchitektur und Infrastruktur – Quartale bis Jahre
AI legt strukturelle Schwächen in Softwareorganisationen offen. Unklare Modulgrenzen, fehlende Tests, veraltete Dokumentation und fragile Deployment-Prozesse werden durch Agenten nicht automatisch besser. Sie werden häufig nur schneller sichtbar.
Damit AI und Agentic Engineering skalieren können, braucht es stabile Grundlagen:
- klar strukturierte Repositories,
- dokumentierte Architekturentscheidungen,
- automatisierte Tests und Quality Gates,
- belastbare CI/CD-Pipelines,
- sichere Entwicklungs- und Laufzeitumgebungen,
- Identity- und Berechtigungsmodelle,
- nachvollziehbare Telemetrie und Auditierbarkeit.
Diese Schicht lässt sich nicht im Release-Takt eines Foundation Models umbauen. Sie benötigt eine mehrjährige technische Richtung und konsequente Modernisierung.
6. Governance, Security und Betrieb – Quartale bis Jahre
Governance wird häufig entweder zu langsam oder zu schnell gestaltet.
Ist sie zu langsam, entsteht Schattennutzung. Teams lösen reale Probleme mit nicht freigegebenen Tools, weil offizielle Prozesse keine praktikable Alternative anbieten. Ist Governance dagegen zu volatil, verlieren Regeln ihre Glaubwürdigkeit und niemand weiß, welcher Standard aktuell gilt.
Eine tragfähige AI Governance besitzt deshalb selbst mehrere Geschwindigkeiten:
- Stabile Prinzipien: Risikobereitschaft, Verantwortlichkeit, Datenschutz, Informationssicherheit und menschliche Kontrolle.
- Anpassbare Verfahren: Freigaben, Risikoklassen, Dokumentationspflichten und Evaluationsanforderungen.
- Dynamische technische Kontrollen: zugelassene Modelle, Grenzwerte, Filter, Policy Checks und konkrete Toolberechtigungen.
Die Grundsätze bleiben verlässlich. Die technische Umsetzung darf lernen.
7. Organisation, Kompetenzen und Kultur – Jahre
Die langsamste Unternehmensschicht entscheidet langfristig über den Erfolg der Transformation.
Rollen, Karrierepfade, Führungsverständnis, Budgetlogiken und kulturelle Erwartungen lassen sich nicht per Tool-Rollout verändern. Menschen müssen lernen, Aufgaben für AI-Systeme zu strukturieren, Ergebnisse kritisch zu beurteilen und Verantwortung auch dann wahrzunehmen, wenn ein Teil der Arbeit maschinell ausgeführt wird.
Im Software Engineering betrifft das nicht nur Entwicklerinnen und Entwickler. Product Management, Requirements Engineering, Architektur, Security, Compliance, HR, Finance und Führung verändern sich ebenfalls.
Genau deshalb greift die Betrachtung von Agentic Engineering als Produktivitätswerkzeug zu kurz. Wie im Beitrag „Agentic Engineering: Warum diese Transformation größer wird als Agile“ beschrieben, verändert sich nicht nur die Zusammenarbeit von Menschen. Es verändert sich die Arbeitsteilung zwischen Menschen, Maschinen und Organisationen.
Der größte Fehler: Alle Schichten gleich behandeln
Viele Transformationsprogramme arbeiten mit einer einheitlichen Projektlogik. Ein zentrales Programm definiert Roadmap, Governance, Toolset und Rollout. Danach sollen alle Bereiche möglichst synchron folgen.
Für AI ist diese Logik zu grob.
Ein Prompt-Experiment und eine unternehmensweite Datenplattform dürfen nicht denselben Entscheidungsprozess durchlaufen. Gleichzeitig darf ein experimentelles Tool nicht automatisch in produktionskritische Prozesse hineinwachsen.
Die entscheidende Führungsaufgabe liegt an den Übergängen:
- Wann wird aus einem Experiment ein wiederverwendbarer Skill?
- Wann wird aus einem Tool ein produktiver Workflow?
- Wann benötigt ein Workflow eine zentrale Plattform?
- Wann wird aus einer lokalen Regel ein Governance-Standard?
- Welche Erkenntnisse aus Piloten verändern Architektur, Rollen oder Qualifizierung?
Ohne definierte Übergänge entstehen zwei problematische Extreme: Entweder bleibt die Organisation in einer endlosen Pilotphase. Oder Experimente gelangen unkontrolliert in produktive Systeme.
Was Pace Layers für CTOs und CIOs verändern
Unterschiedliche Veränderungstakte bewusst festlegen
Jede Schicht braucht einen eigenen Review- und Entscheidungsrhythmus. Prompts und Experimente können kontinuierlich bewertet werden. Tool- und Agentenportfolios benötigen vielleicht monatliche Reviews. Plattformen, Architektur und Governance gehören in quartalsweise oder halbjährliche Steuerungszyklen. Kompetenz- und Organisationsentwicklung benötigen einen mehrjährigen Horizont.
Das schafft Geschwindigkeit, ohne Stabilität aufzugeben.
Architektur auf Austauschbarkeit ausrichten
Schnelllebige Komponenten müssen von stabilen Kernsystemen entkoppelt werden. Das betrifft Modelladapter, Tool-Schnittstellen, Prompt- und Skill-Repositories, Policy Enforcement, Identity, Logging und Evaluation.
Die Architekturfrage lautet nicht: Welches Modell gewinnen wir für die nächsten fünf Jahre?
Sie lautet: Welche Teile unseres Systems müssen stabil bleiben, während sich Modelle und Tools mehrfach austauschen?
Governance risikobasiert staffeln
Nicht jeder AI-Einsatz besitzt dasselbe Risiko. Ein interner Prototyp mit synthetischen Daten benötigt andere Kontrollen als ein Agent, der Kundendaten verarbeitet, Code in produktiven Repositories ändert oder Entscheidungen mit rechtlicher Wirkung vorbereitet.
Pace Layers helfen, Governance nicht nur nach Risiko, sondern zusätzlich nach Veränderungsgeschwindigkeit zu gestalten. Schnelle Komponenten benötigen kurze, automatisierbare Kontrollen. Langsame Grundlagen benötigen verbindliche Entscheidungsrechte und klare Verantwortlichkeit.
Piloten als organisationale Lernsysteme verstehen
Ein guter Pilot beantwortet nicht nur die Frage, ob ein Modell eine Aufgabe lösen kann. Er erzeugt Erkenntnisse für mehrere Schichten:
- Welche Daten fehlen?
- Welche Schnittstellen sind instabil?
- Welche Qualitätskriterien brauchen wir?
- Wo ist menschliche Freigabe erforderlich?
- Welche Rolle trägt die Verantwortung?
- Welche Kompetenzen fehlen im Team?
- Was muss für den Betrieb standardisiert werden?
Erst wenn dieses Lernen in die langsameren Schichten übertragen wird, entsteht Transformation.
Erfolg nicht über Nutzung messen
Anzahl der Lizenzen, Prompts oder aktiven Nutzer zeigen Aktivität, aber noch keinen nachhaltigen Wert. Mit jeder tieferen Pace-Schicht müssen andere Kennzahlen hinzukommen:
- Qualität und Erfolgsrate der AI-Ausgaben,
- Durchlaufzeit und Automatisierungsgrad von Workflows,
- Review- und Rework-Aufwand,
- Defect Rate und Change Failure Rate,
- Kosten pro erfolgreicher Aufgabe,
- Zeit bis zur produktiven Skalierung,
- Zahl kontrolliert betriebener statt nur gestarteter Use Cases,
- Kompetenzaufbau und Akzeptanz in den betroffenen Rollen.
AI-Transformation scheitert selten daran, dass ein Unternehmen keinen Zugang zu leistungsfähigen Modellen oder Tools besitzt. Der schwierigere Teil beginnt danach.
Prompts, Skills und Agenten verändern sich in Tagen oder Wochen. Anwendungen und Plattformen benötigen Monate. Architektur, Governance, Kompetenzen und Kultur entwickeln sich über Jahre. Diese Unterschiede lassen sich nicht auflösen. Sie müssen gestaltet werden.
Pace Layers helfen Tech-Entscheidern, Geschwindigkeit nicht länger eindimensional zu betrachten. Sie zeigen, wo Experimente bewusst schnell sein sollten, wo Stabilität notwendig ist und an welchen Übergängen Führung gebraucht wird.
Daher ist es nicht entscheidend, wie die gesamte Organisation so schnell wie AI wird, sondern wir wir die Geschwindigkeit der AI mit der Lern- und Veränderungsfähigkeit unserer Organisation verbinden.
Wenn Sie AI-Strategie, Software Engineering, Governance und Operating Model in ein belastbares Zielbild bringen möchten, bietet Buske Consulting strategische Technologie- und AI-Beratung auf C-Level.
Häufig gestellte Fragen zu Pace Layers und AI-Transformation
Was sind Pace Layers?
Pace Layers sind ein von Stewart Brand geprägtes Modell für komplexe Systeme. Es beschreibt mehrere miteinander verbundene Schichten, die sich unterschiedlich schnell verändern. Schnelle Schichten erzeugen Experimente und Innovation, während langsame Schichten Stabilität, Wissen und Kontinuität sichern.
Wie lassen sich Pace Layers auf AI und Software Engineering übertragen?
Prompts und Experimente bilden die schnellste Schicht. Danach folgen Skills, Tools, Agenten, AI-Anwendungen, Workflows, Modelle und Plattformen. Softwarearchitektur, Governance, Betrieb, Organisation, Kompetenzen und Kultur verändern sich zunehmend langsamer und bilden die stabilisierende Grundlage.
Warum sind Pace Layers für eine AI-Transformation wichtig?
Das Modell verhindert, dass alle Teile der Transformation mit denselben Prozessen und Erwartungen gesteuert werden. Es hilft, schnelle Experimente zu ermöglichen, kritische Grundlagen zu schützen und klare Übergänge vom Prototyp zum produktiven, kontrollierten Einsatz zu schaffen.
Welche Pace Layer verändert sich am schnellsten?
Prompts, Hypothesen und kleine Experimente können sich täglich verändern. Auch AI-Tools und Agent Skills entwickeln sich schnell. Unternehmensweite Plattformen, Architektur, Governance und Kompetenzmodelle benötigen dagegen Monate oder Jahre.
Brauchen schnelle AI-Experimente keine Governance?
Doch. Sie benötigen jedoch eine andere Governance als produktionskritische Systeme. Sinnvoll sind klare Daten- und Sicherheitsgrenzen, isolierte Umgebungen, nachvollziehbare Evaluationen und abgestufte Freigaben. Die Kontrollen sollten zum Risiko und zur Veränderungsgeschwindigkeit passen.
Wie unterscheiden sich Pace Layers von Wardley Mapping oder Cynefin?
Pace Layers betrachten vor allem die Veränderungsgeschwindigkeit verschiedener Systembestandteile. Wardley Mapping untersucht Wertschöpfung, Abhängigkeiten und den Evolutionsgrad von Fähigkeiten. Cynefin hilft, die passende Entscheidungslogik für klare, komplizierte, komplexe oder chaotische Situationen zu wählen. Die Methoden ergänzen sich.
Wie startet ein Unternehmen mit einer AI Pace Map?
Das Unternehmen erfasst zunächst AI-Komponenten, Plattformen, Governance, Rollen und Kompetenzen. Danach ordnet es deren Veränderungstakt ein, markiert Abhängigkeiten und Reibungspunkte und definiert pro Schicht Verantwortliche, Review-Zyklen, Metriken, Risiken und Übergänge in den produktiven Betrieb.