How I AI: John Kim's Playbook for AI Transformation with Quests, Skills, and 'AI Gods'

John Kim, co-founder and CEO of Delight.ai, has turned AI adoption into an internal product with its own marketplace, incentives, onboarding flow, and metrics. Employees post automation requests as quests, non-engineers build on top of approved templates, and managers track adoption through shared dashboards instead of waiting for quarterly transformation updates. See How to Create an Internal AI Marketplace to Crowdsource Automations.

What makes the system interesting is not just the tooling. John connected motivation, visibility, and production infrastructure into one loop. Employees can spot useful problems, recruit collaborators, ship something real, and get recognized for it without opening a ticket and hoping engineering prioritizes the work months later.

In this episode of How I AI, John walks through Delight.ai's internal Automators marketplace, the quest system that pairs subject matter experts with builders, and the token usage dashboard that managers use to coach adoption. He also shares two personal AI systems he uses constantly: an AI "Gardener" for maintaining Obsidian notes and custom learning websites generated around topics like neuroscience and fusion energy. You can follow the full implementation in How to Build a Personal AI-Generated Learning Center on Any Topic. See How to Build a Personal AI-Generated Learning Center on Any Topic.

Turning internal automation requests into quests

At Delight.ai, anyone in the company can create a quest for an automation or internal tool. A finance employee might request help automating accounts receivable workflows. A recruiter might want a sourcing assistant. The request becomes visible across the company inside the Automators platform, where other employees can volunteer to help build it.

The important shift is organizational, not technical. Instead of every useful idea competing for roadmap space inside engineering sprint planning, employees can self-organize around smaller, high-leverage projects. John described these as the kinds of side projects people naturally gravitate toward when they have a little free time and can directly see the user pain inside the company.

How quests move from idea to shipped tool

Each quest follows a lightweight workflow that keeps the request tied to a real business need while making it easier for builders to jump in:

1. Create a quest: Any employee can request an automation or internal tool. John used finance workflows as one example, but the same structure works across recruiting, sales, support, or marketing.
2. Define the need: The quest giver explains the workflow, pain point, and desired outcome. The person asking for the tool does not need to know how to code. They provide the operational context and subject matter expertise.
3. Form a party: Engineers and AI-enabled teammates from other departments can volunteer for quests that interest them. Some projects become collaborative builds between technical and nontechnical employees.
4. Build and submit: Teams submit a working result, which could be a GitHub repository, an internal AI skill, or another operational workflow that employees can start using immediately.

Each quest also includes context like estimated business impact, time savings, and risk level. I pointed out that this effectively creates a "shadow AI roadmap" inside the company: a visible marketplace of unmet operational needs where employees can choose problems worth solving instead of waiting for centralized prioritization.

'You're kind of like building this shadow AI roadmap that works really efficiently. Basically a marketplace of AI needs and AI builders inside your company where anybody can just pop in and say, oh, I, I think I know how to do that.'

Making internal AI work visible and rewarding

The platform includes a lightweight rewards system designed to make experimentation public and socially reinforced instead of invisible side work.

• Experience points: Employees earn XP for completing quests and contributing useful automations or workflows.
• Rewards: XP can be exchanged for gift cards, tea with an executive, or opportunities to demo completed work during the company's weekly standup.

One of the most effective parts of the system is who ends up presenting. John said the demos are often led by recruiting, marketing, or sales teams rather than engineering. That visibility signals that building with AI is not reserved for technical specialists.

Giving non-engineers a secure path to production

The clearest example was a marketing-built swag store called Big S Energy. The team built it in a day or two without engineering support, complete with Stripe payments, custom design work, and a hidden conference announcement unlocked through the Konami Code.

My reaction to the demo gets at why these projects matter. Before AI tooling, a campaign microsite like this probably would have lost a prioritization fight. It would have been labeled too temporary or too playful to justify engineering resources. Instead, marketing built exactly the experience they wanted, including the jokes, easter eggs, and brand personality that usually get stripped out of corporate tooling.

That was John's broader point about AI-native teams. When marketers, recruiters, or salespeople can build directly, they stop settling for generic workflows and start creating software tailored to how their teams actually operate.

The internal template that keeps experimentation safe

The reason non-engineers can ship these projects safely is that Delight.ai created an internal application template with the difficult infrastructure already configured. Builders start from a vetted foundation instead of wiring together random tools from scratch.

• Authentication and security: Core access controls and security reviews are already built into the template and maintained with the security team.
• Environments and databases: Employees inherit approved infrastructure instead of choosing hosting, databases, and deployment setups themselves.
• Compliance and operations: An internal AI operations group helps vet tools, logging requirements, and data access policies so employees are not improvising production architecture on public infrastructure.

I emphasized how practical this is for companies right now. Employees are already vibe coding internal tools and deploying them somewhere. Creating a templated "happy path" to secure production gives people enough freedom to build while reducing the chance that sensitive company workflows end up exposed on the public internet.

Tracking AI adoption like a product metric

John's internal dashboard tracks AI usage by employee, team, and model. Managers use it less as a productivity score and more as a coaching tool to understand where employees are in the adoption curve and what support they need next.

From beginner to "AI God"

The dashboard groups employees into five usage tiers based on daily token consumption, from beginner through "AI God." John said the goal is not maximizing tokens for their own sake. The company specifically wanted to avoid repeating old mistakes like measuring engineering quality by lines of code.

1. Beginner
2. Intermediate
3. Expert
4. Architect/Catalyst
5. AI God (over 100 million tokens a day)

Instead, the tiers create a shared language for adoption. Managers can see who is still learning, who is experimenting successfully, and who may be ready to mentor others. John also noted that some of the heaviest users are company leaders, including the CTO and other executives. That visibility matters because employees can see leadership using the tools directly instead of merely mandating adoption from above.

Why John watches the shape of the usage curve

One detail I highlighted was John's focus on the smoothness of the token usage curve. Large dips on weekends or vacations signal that AI systems are still dependent on humans actively driving every workflow. His longer-term goal is for agents to continue handling appropriate tasks asynchronously so work does not completely stop when employees log off.

Personal AI systems for learning and knowledge management See How to Automate Personal Knowledge Management with an AI 'Gardener'.

Beyond the company systems, John also shared two personal workflows that show how he thinks about AI as an ongoing collaborator rather than a one-time assistant.

The Gardener for Obsidian notes

John built and open-sourced a project called The Gardener for maintaining his Obsidian knowledge base. Instead of manually organizing notes later, the agent revisits the vault every day and continuously improves it.

• Fix typos and grammatical errors so rough notes stay readable over time.
• Enrich notes by researching people, companies, and concepts mentioned throughout the knowledge base.
• Create headings, clusters, and cross-links between related ideas so disconnected notes become easier to navigate.
• Nurture lightweight "seedling" notes into more complete documents as additional context accumulates.

The metaphor is intentional. John described the system as a gardener continuously tending the knowledge base instead of leaving organization and synthesis for a future cleanup session that never happens.

Building custom AI-generated learning websites

John also uses Claude Code and Codex to generate small educational websites around subjects he wants to study deeply. His neuroscience example included linked pages covering researchers, neurological disorders, neurotransmitters, and conceptual maps connecting topics together.

The workflow starts with a detailed research-oriented prompt instructing the model to behave like a domain expert and generate both the content structure and the website itself.

```

You're like a PhD, neuroscience researcher. Here's what you're trying to create...

```

In roughly 10 to 20 minutes, he ends up with a navigable knowledge base he can explore offline and continuously expand. He has built similar systems for quantum mechanics and fusion energy research.

The useful part is not just speed. John likes that the curriculum becomes fully customizable. He can reorganize concepts, reshape the learning path around his own questions, and keep extending the system as his understanding grows. I connected this to a broader shift in AI-assisted learning: instead of consuming static educational material designed for everyone, people can increasingly build adaptive knowledge environments tailored to how they think.

What to copy

The strongest part of John's approach is how tightly the system connects demand, infrastructure, and recognition. Employees can see useful work, safely build on top of approved templates, and publicly demonstrate what they ship. That combination creates momentum much faster than executive mandates alone.

Most companies do not need to recreate the entire platform to get started. A visible queue of automation requests, a vetted internal template, and a lightweight way to celebrate shipped work are enough to unlock a surprising amount of experimentation. The usage dashboards and adoption tiers are useful when they help managers coach people through the learning curve. They become counterproductive if they turn into performative rankings disconnected from actual outcomes. The part worth copying is the operating model: treat AI adoption like a product with users, onboarding, incentives, infrastructure, and feedback loops. Human judgment still matters most in deciding which automations deserve trust, where security boundaries belong, and which experiments are genuinely improving the company instead of just generating activity.