Someone gets excited about a new tool. They read about it, watch a demo, maybe install it. Then they sit down at their desk on a Monday morning with a Jira ticket and think, should I try doing this with the new thing?

Almost every time, the answer is no. The ticket has a deadline. The code has tests that need to pass. There are stakeholders waiting. The familiar path is faster and safer today, even if the new path might be much faster in a month. So they do the work the way they always have, and the new tool stays in the tab they never open.

Multiply that across every person on every team, every week, and you get an organization that has “adopted” AI on paper while almost no one is actually using it.

How I did this for myself

I know this pattern well because I lived it.

A year and half ago I left a job running a game studio. Between that job and the next one, I had a stretch of time without a team to lead, without a roadmap to hit, and without anyone waiting on my deliverables. I spent almost all of it getting up to speed with the state of the art in LLMs and AI-driven development. It was one of the most energizing stretches of my career. I read papers, built things, tried every tool I could get my hands on, and followed my curiosity wherever it led. Ideas compounded on each other. I built a personal website, a portal for vibe coders, a multiplayer game, a tool for generating animated 3D avatars, and an entirely new rendering engine for hybrid 2D/3D scenes. I could feel whole categories of work getting easier in my head in a way I hadn’t felt since I was first learning to program.

Looking back on it now, nothing about that stretch would have been possible inside my old job. The kind of exploration I was doing didn’t look anything like the output a studio head is supposed to produce. It was open-ended, unpredictable, and hard to justify on any normal dashboard. The free time without consequences was the whole ingredient. Everything I can do now with these tools traces back to that window, and so does the shift in my own career, from running a game studio to working on the forefront of AI-driven game development.

I didn’t call it a sabbatical at the time, but that’s what it was. A deliberate stretch of time set aside for learning, with no other deliverable attached to it. It worked, and it transformed my career. The thing I want to argue in this piece is that you shouldn’t have to quit your job to get that window. Your employer should be the one handing it to you.

Training isn’t the bottleneck

The default response to this is training. Courses, lunch-and-learns, internal certification programs, microlearning curricula. Some of it works. Slack ran an experiment where ten minutes a day of AI microlearning nearly doubled participants’ comfort level with AI tools (from 43% to 72%), and programs like that have their place.

But they’re not the bottleneck.

The bottleneck is that learning a new tool requires making mistakes, and making mistakes at work is expensive. This isn’t a new observation. Amy Edmondson has been writing about psychological safety for twenty years, and the short version is that teams only learn when people feel safe enough to try things that might not work. AI adoption is a learning problem, and learning requires looking dumb in public for a while before you look smart.

Most workplaces aren’t structured to make that feel safe. If I spend three hours trying to get Claude to refactor a module and the output is worse than what I would’ve written myself, that’s three hours of unproductive time on someone’s dashboard. If I break the build because I trusted an agent’s fix without reading it carefully (which, uh, I have done), that’s a visible, embarrassing failure with real consequences.

So what actually happens is one of two things. People use AI tools in secret and don’t share what they learn, or they avoid the tools entirely under the cover of “being careful.” Neither builds a team that can actually use this stuff.

What I mean by an AI sabbatical

An AI sabbatical is a sanctioned, time-boxed break from your normal work duties for the express purpose of learning to use AI. Not a training course. A stretch of time, a week or two or a month depending on what you can afford, during which the expectation is that you’re not shipping your regular work. You’re experimenting. You’re building throwaway things, breaking stuff, and trying the tool on problems that don’t matter.

I chose the word “sabbatical” on purpose. A sabbatical isn’t a vacation. You’re still working, sometimes intensely, but you’ve been released from the ordinary performance frame. Academics take them to write books that might not pan out. Engineers sometimes take them to explore a technology their team will need later. The shared idea is that stepping back from producing is what lets you become someone who can produce differently.

The Zen tradition has a word for this, shoshin, beginner's mind. A sabbatical is a way of deliberately putting yourself back in that seat, where you don't know what the tool is good at, and that not-knowing is what makes you willing to try everything.

That’s the shape of the AI learning problem. You can’t learn to delegate to an agent while you’re under pressure to deliver, or learn what Claude is actually good at while you’re afraid of what happens if it’s bad at it, or build taste about when to trust model output when every interaction carries real consequences. You need low-stakes reps, and you need a lot of them.

The neighboring ideas

A few adjacent practices are already out there:

AI hackathons. A team gets two days to build something with AI. These work fine for what they are. STIM, a Swedish music licensing company, ran a two-day hackathon that produced three working AI systems, one of which went to production. But two days is a hackathon, not a sabbatical. You learn a specific thing; you don’t rewire your instincts.

“Friday AI playtime” and curiosity sessions. Some teams are pushing this: carve out a few hours a week for people to mess around with AI tools. It’s directionally right, but a few hours a week is a trickle. For most people, it isn’t enough to escape the gravity of their real work.

Microlearning. Ten minutes a day, consistent over weeks. Measurably effective at moving comfort levels. But comfort is not fluency, and fluency is what we actually need.

20% time. Google’s old idea. Still practiced here and there. Same direction, but 20% time usually ends up funneled into a side project with its own deliverables, so you’re still performing, just on a different stage.

An AI sabbatical is the biggest-dose version of this family. The shift we’re asking people to make isn’t a ten-minutes-a-day shift; it’s a rewiring of how they approach work, and rewiring takes time and permission to be unproductive.

What makes one actually work

A few things have to be true or it doesn’t work.

It has to be explicitly sanctioned. Not “if you have spare cycles, poke at this.” Sanctioned means your manager knows, your team knows, your quarterly goals reflect it, and nobody is silently judging your commit graph. If you can’t tell your skip-level you spent last Thursday trying to get Claude to build a Chrome extension for your cat, it isn’t really a sabbatical.

It has to be long enough for you to screw up, understand what happened, and take another swing at it. You need to do that loop a few times before anything really sinks in. My rough number is about a week minimum. The first two or three days you’re still thinking like someone trying to be efficient. Around day four you start taking bigger swings, building things you’d never greenlight for work, trying agent patterns that feel overly ambitious, letting the model drive for a while to see what happens. That’s when the learning actually kicks in.

It has to be oriented around projects you picked, not a curriculum someone else wrote. The whole point is to build things that don’t matter so you develop judgment about what does. Pick something you’re personally curious about. Build a silly app, rewrite an old side project, try the tool on a corner of your life it was never meant for. Build a game! Games are great for this because they have clear rules, immediate feedback, and nobody dies if the AI screws up. You’ll probably throw most of what you build away, which is fine, because what you’re really building underneath all of it is judgment about what these tools can and can’t do.

When you come back, you come back with something that’s harder to measure than a deliverable. You have a feel for the tool. You know when to reach for it, when not to, what a bad prompt looks like, when to trust the output versus verify it line by line. That’s the thing that makes the daily application stick.

When a whole team does it together

Everything I’ve said so far works for an individual. The effect is good. One person comes back with sharper instincts and starts using the tools more effectively, and over time some of that diffuses to the people around them.

But something different happens when an entire team takes the sabbatical together.

I’ve watched this play out a few times now, and the pattern is consistent. You take a team of five or six engineers, clear their calendars for a week, tell them the week is for learning, and something catalytic happens in the group that doesn’t happen in isolation. People see each other’s experiments. Someone figures out a prompting pattern in the morning, shares it in Slack at lunch, and by the afternoon three other people have tried it on their own problems. Somebody else’s dead end saves you from hitting it yourself; somebody else’s breakthrough becomes the starting point for your next attempt. The learning compounds inside the group in a way it just doesn’t when one person is off doing it alone.

The productivity shift on the other side is the part that surprised me the first time I saw it. It isn’t a linear improvement. The team doesn’t come back 10% faster or 20% faster. They come back working differently. They reach for agents on tasks they wouldn’t have considered automatable two weeks earlier, build small tools for themselves instead of filing tickets, and start having conversations about architecture that begin with “what if we let the agent own this part” instead of “who’s going to write this part.” The ceiling on what the team thinks is possible has moved, and that’s the thing that cascades into real throughput gains over the following months.

Why organizations should pay for this

The standard enterprise approach to AI adoption is to buy licenses, roll out training, and measure seat utilization. Six months later, leadership wonders why the productivity numbers haven’t moved.

The answer is structural. You’ve given people a tool and told them to use it in the same environment where using it badly is penalized and using it well requires skills they haven’t built yet. Of course adoption stalls.

A sabbatical changes the structure. For that week, nobody is expected to ship anything to production. The whole point is to learn. A week of an engineer’s time is cheap compared to the delta between an engineer who knows how to work with AI agents and one who doesn’t.

The usual advice for adopting a new tool is “just use it on your real work.” For most tools in most eras, that was fine. The learning curve was gentle enough that you could pay it down inside your normal job.

AI tools aren’t like that. Using them well means changing how you approach the work itself, not just learning a new interface. You have to figure out which parts of a problem to hand off, and how much of what comes back is worth keeping. That’s a different kind of learning, and it doesn’t happen under deadline pressure. You need room to be a beginner again.

The real payoff shows up on the Monday after. You sit down at your desk, look at the same Jira ticket that would have taken three days, and you already know where the agent will save you a day and where it will trip you up. You know which prompts to start with, when to let it run, when to drive it yourself. The hesitation is gone. The ticket ships faster, the next one ships faster still, and the tools you didn’t have time to get comfortable with three weeks ago are now just part of how you work.

What’s missing from most of the conversation is a clear picture of what the path looks like, where the industry sits on it today, and where it leads.

What the surveys tell us

The GDC 2026 State of the Game Industry survey had 2,300+ respondents. 36% of game industry professionals use generative AI tools. People at game studios specifically reported 30%, while publishing, marketing, and support roles came in at 58%. Upper management sits at 47%, individual contributors at 29%.

What they use it for provides more insight than the top-line number. Brainstorming and research: 81%. Code assistance: 47%. Asset generation: 19%. Procedural generation: 10%. Player-facing features: 5%.

AI usage is highest for thinking and lowest for shipping. Studios are learning what works in low-risk contexts before committing to production workflows, which is a reasonable way to approach any new technology. 78% of companies already have AI policies in place. About 30% of AAA studios are running proprietary AI systems. The foundation for broader adoption is already there.

Sentiment is more complicated. 52% of respondents say generative AI is bad for the games industry, up from 30% last year. But from the survey data and from conversations I had with developers and executives at GDC, adoption is growing and shows no signs of stopping. People can be skeptical and still be adopting. Both things are true at the same time.

Five stages of studio adoption

Watching how studios actually behave, they cluster into roughly five stages. Most are in Stages 2 and 3 right now, about where you’d expect for an industry in the middle of a technology transition.

Stage 1: Wait and see. “We have real games to ship.” No formal position on AI. For many of them it’s a reasonable posture given their project commitments and risk profile.

Stage 2: Individual experimentation. “Our devs are using ChatGPT on their own.” People tinker on their own initiative. No policy, no budget, inconsistent results. A lot of the brainstorming and code scaffolding usage lives here. People are building intuitions about what AI is good at and where it falls down, which matters more than the output at this stage.

Stage 3: Sanctioned pilots. “We’ve picked some use cases. Let’s see if this works.” Bounded experiments in code generation, concept art, localization, NPC dialogue, automated QA. Small team evaluates tools and reports back. Formal policy. Modest budget. Studios start getting real production data about what AI can actually do for them. The jump from here to Stage 4 is the hardest one, because it requires going from "some people use AI tools" to "AI is in the pipeline," which means governance, integration work, and buy-in from leads who may not have been part of the pilot.

Stage 4: Integrated tooling. “AI is part of how we build games now.” AI embedded in production workflows with governance: approved tools, review processes, dedicated budget, sometimes dedicated headcount. The compounding benefits show up here. Iteration cycles get shorter. Teams explore more ideas before committing. Content pipelines that used to take weeks start taking days.

Stage 5: AI-native development. “We design games around what AI makes possible.” Creative process built on AI from the start. Not just doing existing things faster, but also building experiences that weren’t possible before: games that adapt to how you play them, worlds that respond to individual players, narrative that branches in ways no team could hand-author. Almost nobody is fully here yet. But this is where it’s all headed, and the studios that arrive first will build things the rest of the industry didn’t think were feasible.

Code tools have their own adoption curve

AI adoption doesn’t move through a studio evenly. Engineering almost always leads, and code tooling has its own maturity curve.

Generated code has to compile, pass tests, and survive code review. Those quality gates already exist. Code has a built-in verification loop that art and narrative don’t have yet, making it a natural entry point.

Four levels:

Level 1: Autocomplete. Copilot-style inline suggestions. Accept, modify, or ignore. Feels like better tab-complete. Most studios start here.

Level 2: Chat-assisted. Developer describes a problem, AI generates a solution, developer reviews and integrates. The chunks get bigger: a function or component instead of a line.

Level 3: Task-level autonomy. Developer says “implement this feature” or “write tests for this module” and the AI works across multiple files. The developer shifts from writing code to specifying intent and reviewing output. The productivity multiplier really kicks in at this level. A single engineer can move through tasks that would have taken a team days.

Level 4: Agentic development. AI operates across the codebase with real autonomy. Coordinates multi-file changes, runs its own verification loops. The developer’s job looks more like a tech lead directing work than a programmer writing every line. Small teams start punching way above their weight.

A studio can easily be at Stage 3 overall while its engineering team is at Code Level 3 or 4. Engineering is the beachhead, and the patterns that work there (verification loops, review processes, incremental trust-building) tend to spread to other disciplines over time.

What slows studios down

A few things come up over and over.

IP and legal. The most common concern at every stage. Who owns AI-generated assets? What’s the training data exposure? Legal frameworks are still forming, but studios aren’t waiting for perfect clarity. They’re scoping usage to areas where the risk is manageable and expanding as norms solidify.

Content consistency. Can AI generate an asset that belongs in this game? Style coherence and lore consistency at production scale are hard problems. Studios investing in custom pipelines (style guides, fine-tuned models, human-in-the-loop review) are finding workable answers.

Culture. People have real concerns about how AI changes their work. Studios that handle it well don’t force adoption top-down. They let teams find the value themselves, starting with tools that make people’s existing jobs easier.

Ethics. There are legitimate concerns about how AI models get built. Training data includes copyrighted work, often without permission or compensation to the creators. The energy costs of running large models are real. Studios whose teams care deeply about craft and creative ownership feel these issues personally, and they're not wrong. Some studios treat this as a reason to hold off entirely. Others are looking for ways to adopt AI while supporting the creative ecosystem it draws from, whether that's licensing training data, using models trained on permissioned datasets, or contributing back to the communities whose work made the tools possible. The ethical questions won't stop AI adoption industry-wide, but they'll shape how thoughtful studios approach it.

Tool maturity. Still a gap between demos and production (for example, I generated the infographic in this article using Nano Banana 2, Google’s state of the art image model, and it has some obvious flaws). But that gap closes noticeably every quarter. The tools shipping today are meaningfully better than a year ago, and a year from now the jump will be bigger.

Where this is going

AI does three things for studios at once, and they compound.

Faster iteration. Prototyping that used to take months takes weeks or days. Ideas that would have died in pre-production because they were too expensive to test are now testable. Teams can try five approaches to a mechanic instead of committing to one early and hoping it works. Shorter cycles mean more learning, and more learning means better games.

More with less. A small team with good AI tooling can cover ground that used to require a much larger headcount. Not by replacing people, but by letting each person operate at a higher level. An engineer at Code Level 3 or 4 moves through work that would have taken a team days. An artist with a good AI pipeline can explore ten times more variations before committing to a direction. The constraint on what a studio can build shifts from team size to team taste.

Entirely new experiences. Games where every NPC has a real personality and remembers your interactions. Worlds that generate new content based on how the community plays. Narrative that branches in ways no team could hand-author. These aren’t separate from the speed and leverage benefits. They’re what becomes possible when you have both.

Studios at Stage 4 and 5 are already working on all three. The compounding is the point: faster iteration lets you experiment with new kinds of experiences, and smaller teams can take bigger creative swings because the cost of exploration is lower.

Studios will move through these stages at their own pace, and some may decide the journey isn’t for them right now. But the ones that get to the other side will build the next generation of games, and those games will be different from anything we’ve played before.

Subscribe now

Why This, Why Now?

When I was 16, I found a copy of Douglas Hofstadter’s Gödel, Escher, Bach (G.E.B) in my high school library. Whatever I had been looking for that day was instantly forgotten. The book is long and complex, and I didn’t understand most of it at the time. But that didn’t matter. I was hooked. Artificial Intelligence had captured my imagination.

Even the name sounded futuristic and full of possibility. I had already fallen in love with computers, spending hours playing games and writing simple programs (you guessed it, I was one of the popular kids). But AI felt like something bigger. It felt like the future.

My Early AI Journey

I devoured everything I could find on the topic. Inspired by G.E.B, I wrote a high school thesis on Alice in Wonderland as a formal system. In 1987, when Seattle hosted the Sixth National Conference on Artificial Intelligence (AAAI-87), I attended as a 17-year-old neophyte and became a member of, what was then called, the American Association for Artificial Intelligence.

My college entrance essay was a parable about an AI that ran out of storage space and realized it only needed to remember what truly mattered.

At Northwestern University, I studied Computer Science, Neuroscience, and Psychology. I worked on early AI projects, including training a rudimentary neural network to perform word stem completion on a NeXT cube.

While I was there, Northwestern recruited Roger Schank and his team from Yale to launch the Institute for the Learning Sciences (ILS), a major coup in the AI research community.

Then Everything Stalled

By the early 1990s, progress in AI slowed. The field entered what is now known as the AI Winter. Symbolic methods, which had dominated for years, were no longer delivering meaningful results. Researchers were exploring neural networks, but computing power was still limited. Learnings from The Bitter Lesson were decades away.

Funding disappeared. Interest waned. Industry jobs dried up. I pivoted to other areas, working in 3D graphics, medical imaging, and multimedia, and eventually found my way into the games industry, where I’ve spent the last two decades.

Still Watching & Learning

Even as I moved away from AI professionally, I never stopped following it. I watched as advances in GPUs and scalable computing led to a new era of deep learning.

In 2017, I built AI/ML systems for churn and payer prediction in games. And over the past five years, I’ve experimented with almost every new AI model or tool I thought could be relevant to game development.

It’s now clear that AI is transforming every industry. Game development will not be an exception. Two of my greatest interests, games and AI, are colliding in a big way.

That’s why I’m launching this newsletter.

What to Expect Here

This newsletter is for developers, designers, technologists, and creatives who want to understand how AI is reshaping the world of games.

You can expect:

• Practical insights into AI tools for code, assets, and workflows

• Breakdowns of new research, models, and trends

• Updates on laws and policies impacting games and AI

• Thoughtful discussion of workforce and studio changes

Above all, I want to build a community, one that shares knowledge, asks good questions, and explores both the opportunities and the challenges that come with these changes.

Let’s Explore Together

If you work in games, or want to, and you’re curious, excited, or overwhelmed by what AI might mean for your work, I hope you’ll subscribe.

This is just the beginning, and there’s a lot more to come.

Subscribe now