For most enterprises, AI adoption still oscillates between two extremes. On one side, there is unstructured enthusiasm: teams experimenting with tools on their own, shadow AI spreading faster than governance can keep up. On the other, there is paralysis: long strategy documents, procurement delays, and cautious pilots that never quite escape the lab. Somewhere between these poles lies the hard, unglamorous work of making AI real at scale.
This is where the story of King offers an unusually concrete lesson.
King, best known for global franchises such as Candy Crush Saga, sits at an interesting intersection. It is a deeply creative company, a large-scale software operation, and part of the Microsoft ecosystem through its parent group. When generative AI tools like ChatGPT burst into the mainstream, King faced the same questions as every other modern enterprise, but with higher stakes. How do you enable thousands of people to use these tools productively without breaking trust, brand, security, or culture?
The answer that emerged at King was not a single tool, policy, or training program. It was a toolbox. More precisely, it was a way of thinking about adoption that reframed AI from a technology rollout into a craft-level capability shift. At the center of this approach lies what King internally came to call its “AI adoption toolbox, a system that combines data, community, enablement, and governance into a single coherent motion.
This article, inspired by Episode 154 of the weekly AIAW Podcast E154 recorder back in 2025 with Carl Carlheim-Gyllensköld & Patrick Juhl as guests, explores that toolbox in depth, drawing on King’s lived experience with enterprise-scale GenAI adoption. It unpacks why “vibe coding” and conversational programming are not toys but signals of a deeper paradigm shift, why crafts matter more than org charts, and why the real differentiator is not model quality but adoption design.
From Experiment to Paradigm Shift
When GenAI first entered the organization, it did so quietly. A few prototypes appeared. A browser-based chat interface. IDE integrations for developers. Lightweight experiments that mirrored what many individuals were already doing at home. At first glance, this looked like a familiar innovation pattern: a promising tool tested by early adopters.
Yet something felt different almost immediately.
The defining insight was not that people could generate text or code faster. It was that they could let go of the code itself. What King’s teams began to describe as “vibe coding” captured this shift succinctly. Coding became less about line-by-line authorship and more about intent, iteration, and outcome. The developer stayed in flow until the moment they had to step back, reorient, and validate.
This shift placed new pressure on everything around the code. Testing, documentation, interoperability, metadata, and governance suddenly mattered more, not less. The complexity did not disappear. It moved.
At low stakes, this was exhilarating. At high stakes, especially in a production-grade environment with millions of users, it was unsettling. That tension became the central question of King’s early AI journey: how do you scale this paradigm safely?
Why Pilots Fail and Data Matters
Most AI pilots fail for reasons that have little to do with model performance. They fail because they do not generate learning that can survive executive scrutiny. King’s early pilot avoided this trap by treating data as a first-class citizen from day one.
Hundreds of employees across roles and disciplines were invited in. Their interactions were logged transparently and ethically. Surveys captured confidence, usability, and perceived value over time. Diary studies added qualitative texture. Later, a controlled coding competition introduced experimental rigor, comparing outcomes between groups with and without AI assistance.
The results were striking, even accounting for methodological limits. Productivity gains were not marginal. In some narrowly defined tasks, performance differences reached double-digit multiples. More importantly, people with weaker formal coding backgrounds could suddenly solve problems that had previously been out of reach.
Yet the most valuable insights did not come from averages. They came from segmentation.
Stop Organizing by Teams. Start Organizing by Craft
One of the most consequential discoveries was that team-level analysis explained almost nothing. Cross-functional teams blurred any meaningful signal. When the data was reanalyzed through the lens of craft, patterns became obvious.
People used AI to do the work of their craft, not the work of their team. UX writers used it differently from UX researchers. Backend engineers differently from data scientists. Legal specialists differently from security engineers, even when they sat in the same org unit.
This insight became a turning point. AI adoption is not a departmental problem. It is a craft problem.
Once King reframed its approach around crafts, everything else aligned. Risks could be understood in context. Value could be articulated in domain language. Enablement could be targeted rather than generic.
Governance Without Paralysis
Legal and security concerns are often treated as brakes on AI adoption. At King, they became accelerators.
Instead of asking abstract questions about risk, the organization used AI itself to audit AI usage against agreed guidelines. Conversations were classified, assessed, and quantified. Risk profiles emerged not as anecdotes but as distributions.
This shifted the dialogue with stakeholders fundamentally. Rather than debating hypothetical worst cases, teams could point to real behavior. Issues were localized, understood, and addressed without punishing the majority for the actions of a few. Even surprising findings, such as security teams appearing as “high-risk users” due to penetration testing, reinforced trust in the method.
Governance stopped being a static policy document. It became a living feedback loop.
The CAKE Framework: Adoption as a System
Out of these experiences emerged what King formalized as its AI enablement framework, often referred to internally as CAKE, short for Cognitive AI King Enablement. While the acronym may be playful, the structure is anything but.
At its core are four mutually reinforcing elements.
- First, crafts. Adoption is anchored in the real work people do, at a level of granularity that respects specialization.
- Second, champions. Every craft has visible, credible super users who bridge between central enablement and local practice. These champions are not appointed by title but recognized by usage, curiosity, and influence.
- Third, human-centric enablement. Training starts with jobs to be done, not tools to be learned. The tool is always secondary to the problem it helps solve.
- Fourth, data-driven feedback. Usage, value, and risk are continuously measured and fed back into decisions, avoiding both blind optimism and excessive caution.
This system allowed King to scale from a few hundred pilot users to full enterprise rollout without losing coherence.
Training That Actually Changes Behavior
One of the most underestimated challenges in AI adoption is the blank-page problem. General-purpose tools intimidate as much as they empower. Many people simply do not know where to start.
King addressed this through a layered enablement approach. A mandatory foundational course established shared language, legal boundaries, and basic prompting literacy. This was not about turning everyone into prompt engineers. It was about lowering the first threshold.
The real transformation happened in workshops.
In-person, psychologically safe sessions brought people together by craft. Champions acted as peers, not instructors. Participants explored their own problems with real tools, supported by colleagues who understood their context. The format was simple by design, but deeply intentional.
This combination proved critical. Tools alone do not create capability. Communities do.
Vibe Coding and the Redistribution of Cognitive Load
As conversational programming and vibe coding gained traction, a deeper organizational implication surfaced. Cognitive load was being redistributed.
Individuals could move faster, but only if platforms absorbed more complexity. Testing frameworks, CI/CD pipelines, observability, and guardrails had to become easier, not harder. Platform teams and enablement teams quietly took on more responsibility so that value stream teams could stay in flow.
This rebalancing mirrors earlier shifts in software history, from monoliths to platforms, from on-prem to cloud. GenAI simply accelerates the pattern. The organizations that succeed will be those that recognize this redistribution early and invest accordingly.
Beyond Developers: The New Middle of the Venn Diagram
Perhaps the most profound implication of King’s journey is what it says about roles.
AI collapses the distance between technical and domain expertise. People who understand the business but not the syntax can now express intent directly to machines. This does not eliminate the need for deep engineers. It amplifies it. Hardcore platform engineers become enablers of a much broader creative class.
The new normal is not everyone becoming a developer. It is everyone operating closer to the intersection of domain knowledge and technical capability. AI makes that intersection accessible.
What Makes This a Toolbox, Not a Playbook
It is tempting to turn stories like this into prescriptive checklists. That would miss the point.
King’s AI adoption toolbox is powerful precisely because it is adaptable. It is a set of principles, feedback loops, and social structures that can evolve with tools, models, and risks. It treats adoption as an ongoing practice, not a one-time rollout.
In a landscape where models will continue to improve and interfaces will continue to change, this may be the only sustainable advantage.
Recommendations: Actionable Lessons for Leaders
As a closing synthesis, several practical recommendations emerge for organizations navigating their own GenAI journeys.
- Start with crafts, not org charts. Understand the real work people do and design enablement around those practices.
- Instrument your pilots. Treat data as a strategic asset from day one, capturing usage, value, and risk transparently.
- Use AI to govern AI. Let the technology help you audit, assess, and adapt your own guidelines.
- Invest in champions. Identify and support credible super users who can translate between central strategy and local reality.
- Design training around problems, not tools. Avoid generic one-size-fits-all programs that create compliance without capability.
- Acknowledge the redistribution of cognitive load. Strengthen platforms and processes so individuals can stay in flow safely.
- Finally, accept that adoption is a journey. Build systems that learn.
King’s experience shows that the secret to AI adoption is not hidden in the models. It is embedded in how organizations choose to learn, enable, and trust their people. The real toolbox is cultural, analytical, and human.
This article was enhanced with the help of AI tools, drawing on the podcast transcript and complementary online research. To go deeper into the source material, listen to the full episode and make your own learnings.
