AI is evolving at a pace that puts even experienced technology organizations under pressure. New models are released every few months. Agent frameworks, coding tools, and skills sometimes change within weeks. Prompts are adjusted daily.
At the same time, it takes companies years to modernize their architecture, ensure reliable data availability, establish governance, train people, and realign responsibilities.
This is precisely where one of the biggest misconceptions of the current AI transformation lies: We talk about the speed of AI as if there were only one.
In reality, technology, software engineering, governance, organization, and culture move at completely different paces.
Anyone who tries to accelerate all these levels to match the pace of the latest models isn’t driving transformation. They’re creating friction, overwhelming teams, and introducing structural risks.
The concept of Pace Layers offers a surprisingly precise framework for thinking about this.
TL;DR
Pace Layers describe complex systems as overlapping layers with different rates of change. The fast layers experiment and learn. The slow layers preserve stability, knowledge, and continuity.
Applied to AI and software engineering, this means: Prompts and experiments can change daily. Skills, tools, and agents evolve over weeks. AI applications, workflows, and platforms take months or quarters. Architecture, governance, competencies, and organizational culture change over years.
For CTOs, CIOs, and tech decision-makers, this implies:
- Not every AI decision requires the same process and the same governance.
- Fast-moving technical components must be decoupled from stable enterprise layers.
- AI governance itself requires different speeds.
- Pilot projects must not only test technology but also generate learning in architecture, operations, and organization.
- Slow layers are not automatically obstacles. They ensure continuity and limit risks.
- The actual bottleneck of AI transformation is shifting from models and tools to data, processes, governance, skills, and organizational design.
AI transformation is therefore not a uniform change program. It is the deliberate coordination of a multi-speed system.
Why AI transformation seems so contradictory today
At AI conferences, one quickly gets the impression that fully autonomous software development and largely automated companies are just around the corner. Coding agents analyze repositories, modify code, run tests, and prepare pull requests. New models are solving tasks that, just a few months ago, were considered impossible to automate.
In many companies, the reality is quite different.
Data is stored in silos. Legacy systems are poorly documented. Security and data protection issues remain unresolved. There is a lack of accountability for AI applications. Pilot projects never make it into production. Employees are given access to tools, but neither a robust vision nor sufficient guidance.
Both observations are correct.
They simply stem from different layers of change.
Drew Breunig applied a concept by Stewart Brand to current AI developments in a blog post a few weeks ago—and that got me thinking. Because Brand’s central observation is relevant in many ways to changes in the technology sector and within organizations:
The visible upper layers of the ecosystem are moving extremely quickly, while the supporting lower layers react much more slowly.
This explains why technological possibilities and organizational reality seem to be drifting further and further apart.
What are Pace Layers?
Stewart Brand initially developed the Pace Layer concept based on his observations of buildings and later applied it to societies and other complex systems. According to this concept, a robust system consists of several layers, each with its own function and its own rate of change.
In his original model, Brand distinguishes six societal levels:
- Fashion and Art
- Commerce
- Infrastructure
- Governance
- Culture
- Nature
Fashion changes rapidly. Infrastructure moves more slowly. Culture and nature change over very long periods of time.
The fast layers produce variations, experiments, and innovation. The slow layers store experience, create stability, and prevent every short-term fluctuation from destabilizing the entire system. Brand describes this interaction as the foundation of systems that are both adaptable and robust. His paper was later published in the Journal of Design and Science by MIT Press.
The key idea is not that fast change is good and slow change is bad. A healthy system needs both.
Fast layers learn. Slow layers remember.
Problems arise when one layer imposes its speed on all the others. If governance is changed on a daily basis, it loses its binding force. If culture is expected to update itself like a software tool, resistance arises. Conversely, if experiments are governed by the rules of long-term, stable core systems, their ability to learn disappears.
The Pace Layers of AI and Software Engineering
For companies, this approach can be broken down into seven practical levels.
1. Prompts and Experiments – Days
Prompts, hypotheses, prototypes, and evaluations form the fastest layer. Here, ideas are tested, discarded, and recombined. Many decisions are reversible, and their costs are limited.
This level requires freedom, short feedback cycles, and a high tolerance for error. A cumbersome approval process would do more harm than good.
That doesn’t mean there can be no rules at all. Sensitive data, untested external services, and security-critical actions require clear boundaries even during experiments. Within these boundaries, however, learning should be able to take place quickly.
2. Skills, Tools, and Agents – Weeks
AI tools, agent skills, MCP integrations, coding agents, and orchestration components change rapidly, but not arbitrarily. As soon as multiple teams start working with them, dependencies, support needs, and security issues arise.
Individual experiments turn into reusable capabilities. This increases the demands on versioning, accountability, documentation, and evaluation.
This layer is particularly evident in agentic engineering: A prompt can be changed quickly. A skill used organization-wide that accesses repositories, ticket systems, or internal data is already a production-ready software artifact.
3. AI Applications and Workflows – Weeks to Months
At this level, technology becomes a business or engineering process. An agent no longer just analyzes test data but operates within the software development lifecycle. An AI assistant no longer just answers questions but accesses CRM, knowledge, or process data.
What matters now are integration, roles, escalation paths, human-in-the-loop decisions, and measurable benefits.
Many AI pilot projects fail during the transition to this layer. The prototype works, but the production workflow is missing. No one is permanently accountable. Interfaces are unstable. Quality is not systematically measured. The company has achieved a technical result but has not yet built organizational capability.
4. Models, Data, and Platforms – Months to Quarters
Models change faster than traditional enterprise platforms. Data models, integration architectures, permissions, observability, and evaluation systems, on the other hand, must be sustainable over the long term.
The strategic task, therefore, is not to permanently lock in the supposedly best model. It is to create a platform on which models can be evaluated in a controlled manner, exchanged, and deployed for different risk classes.
Complete model independence remains an illusion. Models differ in behavior, tool usage, context processing, costs, and security profile. Nevertheless, dependencies can be significantly reduced through clear interfaces, evaluation suites, routing, and versioned configurations.
5. Software Architecture and Infrastructure – Quarters to Years
AI exposes structural weaknesses in software organizations. Unclear module boundaries, missing tests, outdated documentation, and fragile deployment processes are not automatically improved by agents. They often simply become visible more quickly.
For AI and agentic engineering to scale, a stable foundation is required:
- clearly structured repositories,
- documented architectural decisions,
- automated tests and quality gates,
- robust CI/CD pipelines,
- secure development and runtime environments,
- identity and authorization models,
- traceable telemetry, and auditability.
This layer cannot be rebuilt in line with the release cycle of a foundation model. It requires a technical roadmap spanning several years and consistent modernization.
6. Governance, Security, and Operations – Quarters to Years
Governance is often implemented either too slowly or too quickly.
If it is too slow, shadow usage arises.
Teams solve real-world problems using unapproved tools because official processes do not offer a viable alternative. If, on the other hand, governance is too volatile, rules lose their credibility and no one knows which standard currently applies.
A sustainable AI governance framework therefore has multiple speeds of its own:
- Stable principles: risk appetite, accountability, data protection, information security, and human oversight.
- Adaptable procedures: approvals, risk classes, documentation requirements, and evaluation criteria.
- Dynamic technical controls: approved models, thresholds, filters, policy checks, and specific tool permissions.
The principles remain reliable. The technical implementation is allowed to evolve.
7. Organization, Competencies, and Culture – Years
The slowest layer of the organization ultimately determines the long-term success of the transformation.
Roles, career paths, leadership philosophies, budgeting practices, and cultural expectations cannot be changed simply by rolling out a tool. People must learn to structure tasks for AI systems, critically evaluate results, and assume responsibility even when part of the work is performed by machines.
In software engineering, this doesn’t just affect developers. Product management, requirements engineering, architecture, security, compliance, HR, finance, and leadership are also changing.
This is precisely why viewing Agentic Engineering merely as a productivity tool falls short. As described in the article “Agentic Engineering: Why This Transformation Is Bigger Than Agile”, it changes s
The biggest mistake: Treating all layers equally
Many transformation programs operate according to a uniform project logic. A central program defines the roadmap, governance, toolset, and rollout. All departments are then expected to follow suit as synchronously as possible.
For AI, this logic is too broad.
A prompt experiment and a company-wide data platform should not go through the same decision-making process. At the same time, an experimental tool should not automatically become integrated into production-critical processes.
The crucial leadership task lies in managing the transitions:
- When does an experiment become a reusable skill?
- When does a tool become a productive workflow?
- When does a workflow require a central platform?
- When does a local rule become a governance standard?
- Which insights from pilot projects change the architecture, roles, or skill requirements?
Without defined transitions, two problematic extremes arise: Either…
How Pace Layers Are Changing Things for CTOs and CIOs
Deliberately Define Different Rates of Change
Each layer requires its own review and decision-making cycle. Prompts and experiments can be evaluated on an ongoing basis. Tool and agent portfolios may require monthly reviews. Platforms, architecture, and governance belong in quarterly or semi-annual management cycles. Competency and organizational development require a multi-year horizon.
This creates speed without sacrificing stability.
Align architecture for interchangeability
Fast-moving components must be decoupled from stable core systems. This applies to model adapters, tool interfaces, prompt and skill repositories, policy enforcement, identity, logging, and evaluation.
The architectural question is not: Which model will we adopt for the next five years?
It is: Which parts of our system must remain stable while models and tools are replaced multiple times?
Tier governance based on risk
Not every AI deployment carries the same level of risk. An internal prototype using synthetic data requires different controls than an agent that processes customer data, modifies code in production repositories, or prepares decisions with legal implications.
Pace Layers help structure governance not only by risk but also by the speed of change. Fast-moving components require brief, automatable controls. Slow-moving foundational elements require binding decision-making authority and clear accountability.
Viewing Pilots as Organizational Learning Systems
A good pilot doesn’t just answer the question of whether a model can solve a task. It generates insights across multiple layers:
- What data is missing?
- Which interfaces are unstable?
- What quality criteria do we need?
- Where is human approval required?
- Who is responsible?
- What skills are missing from the team?
- What needs to be standardized for operations?
Only when this learning is transferred to the slower layers does transformation occur.
Don’t Measure Success by Usage
The number of licenses, prompts, or active users indicates activity, but not yet sustainable value. With each deeper Pace layer, different metrics must be added:
- Quality and success rate of AI outputs,
- Throughput time and degree of automation in workflows,
- review and rework effort,
- defect rate and change failure rate,
- cost per successful task,
- time to productive scaling,
- number of use cases operated under control versus those merely launched,
- skill development and acceptance among the affected roles.
AI transformation rarely fails because a company lacks access to powerful models or tools. The harder part begins afterward.
Prompts, skills, and agents change in a matter of days or weeks. Applications and platforms take months. Architecture, governance, competencies, and culture evolve over years. These differences cannot be eliminated; they must be managed.
Pace Layers help tech decision-makers move beyond a one-dimensional view of speed. They show where experiments should deliberately be fast, where stability is necessary, and at which junctures leadership is needed.
Therefore, what matters is not how the entire organization becomes as fast as AI, but how we align the speed of AI with our organization’s ability to learn and adapt.
If you want to align your AI strategy, software engineering, governance, and operating model into a robust vision, Buske Consulting offers strategic technology and AI consulting at the C-level.
Frequently Asked Questions About Pace Layers and AI Transformation
What Are Pace Layers?
Pace Layers is a model for complex systems coined by Stewart Brand. It describes several interconnected layers that change at different rates. Fast layers generate experiments and innovation, while slow layers ensure stability, knowledge, and continuity.
How can Pace Layers be applied to AI and software engineering?
Prompts and experiments form the fastest layer. These are followed by skills, tools, agents, AI applications, workflows, models, and platforms. Software architecture, governance, operations, organization, competencies, and culture change at an increasingly slower pace and form the stabilizing foundation.
Why are Pace Layers important for AI transformation?
The model prevents all parts of the transformation from being managed with the same processes and expectations. It helps enable rapid experimentation, protect critical foundations, and create clear transitions from prototype to productive, controlled deployment.
Which Pace Layer changes the fastest?
Prompts, hypotheses, and small experiments can change daily. AI tools and agent skills also evolve rapidly. Enterprise-wide platforms, architecture, governance, and competency models, on the other hand, take months or years.
Don’t rapid AI experiments require governance?
Yes, they do. However, they require a different kind of governance than production-critical systems. Clear data and security boundaries, isolated environments, traceable evaluations, and tiered approvals are essential. Controls should be commensurate with the risk and the pace of change.
How do Pace Layers differ from Wardley Mapping or Cynefin?
Pace Layers primarily focus on the pace of change in various system components. Wardley Mapping examines value creation, dependencies, and the degree of capability evolution. Cynefin helps select the appropriate decision-making logic for clear, complicated, complex, or chaotic situations. The methods complement one another.
How does a company get started with an AI Pace Map?
The company first identifies AI components, platforms, governance, roles, and competencies. It then classifies their pace of change, highlights dependencies and friction points, and defines, for each layer, responsible parties, review cycles, metrics, risks, and transitions to production.