CONFIG Not CODE: Why Bloom’s Akasha Is the AI Game Builder Everyone Else Got Wrong

Every AI game builder racing to market in 2026 is betting on the same horse. I think that horse is going to lose, and a team I advise just shipped the proof.

The bet almost everyone made is that an AI should generate code. Describe your game, the model writes scripts, the scripts run the game. It sounds elegant until you look at what actually happens when a large language model writes code at scale: hallucinated functions, security holes, physics that violate their own rules, runtime crashes nobody can reproduce. The industry has started calling the end result gameslop. Steam got flooded with thousands of AI-flagged titles in the last few months, and the reviews and refund rates are exactly what you’d expect.

I serve as an advisor to Bloom (sometimes called BloomOne or Bloomverse), a frontier project sitting at the intersection of Blockchain, Gaming, Commerce, and AI. Bloom just launched Akasha, and the bet is different. You speak. You get a playable Unity WebGL game in your browser. No code written, no code generated, nothing for the AI to get wrong at the script level.

Before I tell you why it matters, do yourself a favor and play the sample game. The whole thesis hinges on the output speaking for itself.

What Bloom calls CONFIG not CODE (configuration over generated source) isn’t just a clever architecture slogan. It’s a design principle that maps almost perfectly onto what I’ve been teaching about human motivation and system longevity for over a decade. That’s the real reason I wanted to write this post. Not to summarize a launch (you can read Bloom’s own post for that). To unpack what this architectural choice tells us about where AI creativity tools are going, and why most of the ones competing right now are going to hit a ceiling that Akasha doesn’t have.

Speed Run Notes

• Nearly every AI game builder racing to market is betting on the same wrong horse: let the AI generate code. That’s where “gameslop” comes from: hallucinated functions, security holes, physics that violates its own rules.
• Bloom’s Akasha (I advise the team) is the cleanest no-code AI game builder shipped to date because it makes the opposite bet: CONFIG not CODE. You speak a game idea, the model writes a validated JSON configuration, and a production Unity engine assembles the game from a curated catalog of professional 3D models, effects, and behaviors. The AI never touches a line of runtime code.
• The principle behind it: treat AI as a brilliant, unreliable intern. Let it configure, not code. The surface area of what it can catastrophically break shrinks by roughly two orders of magnitude.
• CONFIG scales with every smarter model that ships. CODE plateaus, because the catastrophe-surface scales with it. That’s the ceiling Akasha doesn’t have.
• The blockchain layer is optional. You can play without a wallet; creators can opt in to ownable mods and royalties through Bloom. Optionality is the design, not a compromise.
• Before reading the rest, play the sample game. The whole thesis hinges on the output speaking for itself.

Why I’m the one writing this

I’m Yu-kai Chou, creator of the Octalysis Framework, the behavioral design system now applied to products and experiences reaching over a billion users. I’ve advised MrBeast, LEGO, Microsoft, Porsche, Coca-Cola, Tesla, and governments including Ukraine on how to build systems people actually want to use. My work on human motivation and long-horizon system design has been taught at Stanford, Wharton, and inside the teams that ship the products you use every day.

I’m also a formal advisor to Bloom. That matters for this post because I’ve seen the architectural trade-offs behind Akasha from the decision side of the table, not the press-release side. Which model versions were tested, which failures forced which constraints, why the team kept picking configuration over generation even when the code path looked faster in the short term.

The CONFIG-not-CODE framing you’ll read below isn’t Bloom marketing I’m repeating. It’s the same distinction I’ve been teaching for over a decade through Octalysis: why intrinsic system design (the architecture, the constraints, the feedback loops) always outlasts extrinsic quick fixes (raw generation, points slapped on top, gimmicks that feel clever for a week). Akasha is the cleanest expression of that principle I’ve seen shipped into a live AI product so far. That’s why I wanted to write this instead of retweeting a launch post.

What Akasha Actually Is (and Isn’t)

The architecture, compressed:

You speak an idea. The model interprets it into a validated JSON schema. A structured description of what should exist in the game. A production Unity game engine reads that schema and assembles the game from a catalog of professional 3D models, materials, effects, and sounds. Physics, animation, collision, lighting, scoring, win conditions: all handled by the engine, which has been running at 60 frames per second in commercial games for years. The AI never writes a line of code. It decides what goes where. The engine handles the rest.

Same description in, same game out. Every time. Deterministic.

Bloom’s cleanest line about the architecture is this: “If it hallucinates, you get a weird forest.” Not a security breach. Not broken game logic. A weird forest with real physics and real lighting, because the engine is tested and the engine is deterministic.

The games deploy to Pump.fun, Solana Mobile, Steam, Discord, Telegram. The token, the on-chain publishing, the streaming trailer run on Solana, because that’s where the distribution tooling is mature. But Bloom has been explicit that Akasha doesn’t need the chain. Pull the blockchain layer out, and you still have voice-to-playable-Unity-in-browser.

Hold onto that detachability. It matters more than it looks.

The Principle Underneath It

If I stopped here, you’d have a summary of a well-engineered product. That isn’t why I wanted to write this.

I wanted to write this because Bloom’s architectural bet is the same principle I’ve been hammering on for years in a completely different context. The highest-leverage move in any complex creative system is to separate creative intent from execution complexity. When you fuse them, you get a tool that looks powerful in a demo and collapses in real use. When you separate them (and you do it at the right line), you get a tool that ages with its users instead of aging against them.

Here are the five places the CONFIG-not-CODE thesis meets work I’ve been doing on human motivation and system design.

Creativity Without the Cognitive Tax

In the Octalysis Framework, Core Drive 3 (CD3): Empowerment of Creativity & Feedback is the Core Drive almost every platform claims to activate and almost none actually do.

CD3 fires when a person expresses creative intent, sees the result, and adjusts. Minecraft is CD3. LEGO is CD3. A piano is CD3. The pattern is always the same: the tool gives you expressive range without making you pay a cognitive tax for it.

Most “creative” AI tools miss this badly. They give you power and complexity. You want to vibe code a game, great. Now read the error log, debug the hallucinated script, fix the physics glitch, re-prompt, repeat. The creative impulse dies inside the dependency tree. Most of the refunds on AI-flagged Steam games are exactly this failure mode at scale: people wanted to create, and the tool made them debug instead.

Akasha’s move is the LEGO move. You don’t cast the plastic. You don’t design the studs. You snap pieces. The pieces are professionally engineered. The combinations are yours. Constraints enable the creativity instead of limiting it, because the constraint (you can only configure, not code) is exactly what makes the creative act usable by someone who isn’t a software engineer.

My own rule for CD3 design, from years of getting this wrong on client projects before I got it right: if a user has to earn the right to create before they can create, you haven’t built a creativity tool. You’ve built a certification system. Akasha removes the certification. My twins are eight. They both describe forests. They both get forests. Theirs have purple skies and too many foxes. That’s fine. That’s what CD3 is supposed to feel like.

Weird Forest, Not Security Breach: A Reframe of AI Safety

Go back and re-read that “weird forest” line. It’s doing more work than it looks like.

Every AI system has failure modes. The real question is which layer of the stack absorbs them. In code-generation platforms, an AI failure means the system is broken: injected vulnerabilities, hallucinated functions, crashes, physics that violate their own rules. The failure mode attacks the substrate. In CONFIG-not-CODE, an AI failure means the aesthetics are weird: a strangely placed tree, an odd scoring balance, a character in an unexpected spot. The failure mode attacks the surface.

Those two failure modes are not comparable. One requires a security team to triage. The other is a giggle and a re-roll.

This is the same design principle I’ve been arguing for a decade in what I call White Hat Gamification. White Hat motivators (Epic Meaning, Accomplishment, Creativity) feel good because they sit on top of a trustworthy substrate. The user feels free because the system beneath them will not betray them. Black Hat motivators (Scarcity, Unpredictability, Avoidance) can spike short-term behavior, but they eat the substrate to do it. The substrate is everything. If the base is fragile, nothing on top of it is safe to love.

Akasha’s base (the Unity engine, the asset catalog, the deterministic runtime) is the White Hat substrate for AI game creation. The AI is free to be playful on top of it because the base is not negotiable. A first-time creator can hand their voice to Akasha without worrying what they’ll break, in the same way a kid can hand their hands to LEGO without worrying about cutting themselves on an extruder. Contrast that with handing the keys to a code-generation AI tool on a bad day: you get bad assets and bad code, and you’re debugging both.

The quality floor is the feature. Most AI game builders are trying to raise the ceiling. Bloom raised the floor. The floor is where most of the real value in a creative tool lives.

The Integration Is the Contribution

Bloom’s post has a line I keep coming back to: “What I built is the specific pipeline that nobody else assembled.”

Every component Akasha uses existed before Akasha. Unity. Large language models. ElevenLabs for voice. Cloudflare for the asset delivery. Deepgram for transcription. Tripo, Meshy, Hunyuan for 3D generation. Pump.fun for deployment. The contribution was the assembly.

This is how almost all durable intellectual work actually happens, and almost nobody admits it.

When I published the Octalysis Framework in 2013, people occasionally asked which Core Drive I had “invented.” The honest answer is none of them. Every motivator in Octalysis was documented in psychology literature decades before I was born. Autonomy, mastery, scarcity, social proof, loss aversion: I’m standing on Self-Determination Theory, on Maslow, on Cialdini, on Kahneman. The contribution was the specific synthesis of eight motivators into an applied framework that a product designer could pick up on a Tuesday and use Wednesday morning. The contribution wasn’t the discovery of any piece. The contribution was the pipeline.

Same with Bloom. The voice-to-Unity pipeline is the thing that matters, not any single link in it. This is a pattern worth internalizing for your own work: in mature fields, the moat is never a single component. The moat is always the pipeline. If you’re an operator looking for where to put craftsman-level effort, the integration layer is almost always where undervalued work lives. Components get commoditized. Pipelines don’t.

CONFIG Scales With AI. CODE Plateaus With AI.

This is the point I find most compelling for anyone thinking about the durability of a technology bet.

When a better model ships next year, Akasha gets richer game designs on the same deterministic engine. The physics don’t change. The catalog doesn’t change. What changes is the AI’s ability to compose across that catalog. The engine runs a Claude-Sonnet composition today and a Claude-Opus composition next year, and the newer version is simply a better arrangement of trusted parts.

When a better model ships for a code-generation competitor, they get slightly better code on the same fragile substrate. Their AI writes cleaner scripts, but the runtime is still the AI’s half-hallucinated output. The structural issues don’t go away because the model is smarter. They’re smoothing a problem, not solving it.

This is the same reason Octalysis has held up reasonably well over 13 years. The framework maps to permanent human motivation, not to transient platform conventions. Facebook changed its feed algorithm. Octalysis didn’t rot. TikTok replaced Vine. Octalysis didn’t rot. Generative AI emerged. Octalysis didn’t rot; it applied. What the framework describes is the human, and the human is the slow-moving substrate underneath every fast-moving platform.

Evergreen systems separate the fast layer from the slow layer. Akasha’s engine is the slow layer. The AI is the fast layer. Put the intelligence where it can be upgraded. Put the quality guarantee where it can be trusted. Most product architectures fuse the two and then get crushed when one of the two moves. Bloom split them. That split is why CONFIG-not-CODE scales with AI instead of hitting a wall.

The Blockchain Layer Is Optional, and That’s a Feature

This is the subtlest point, and the one I want to leave you with.

Bloom chose Solana for distribution: token launches, on-chain publishing, Pump.fun streaming. Solana Mobile Seeker distribution is a real opportunity that gets under-credited in general tech commentary. The economics of chain-native distribution are better than most non-crypto operators realize.

But the thing that impressed me most, reading Bloom’s post as an advisor who has watched a lot of founder decks, was this framing: “If web3 limits where this goes, we’ll drop it.” That one sentence is an architectural maturity tell. A team that understands its own thesis can name which parts are load-bearing and which parts are replaceable. Akasha’s load-bearing parts are the voice-to-JSON pipeline, the deterministic engine, the asset catalog, and the protocol between the runtime and the browser page. Replaceable: the specific chain, the specific deployment target, the specific model vendor, the specific 3D generator.

Octalysis works the same way. The load-bearing claim is that human motivation decomposes into eight Core Drives. Replaceable: which app you apply it to, which CRO layer you pair it with, which specific game technique activates Core Drive 3 in this quarter’s product. I can strip out any of those top layers and the framework still does its core job.

A framework or a product that doesn’t have this hierarchy, that needs every piece of its original context present to work, is fragile. One that can shed layers and still do its core job is durable. That’s not a judgment call. It’s a structural property you can look for in anything you build or buy or invest in.

Beyond Games

Zoom out one more level.

AI is going to eat every creative tool category over the next five years. It won’t win by generating execution. It will win by configuring proven execution engines. The same architectural bet Bloom just placed on games is available for music, for video, for interactive narrative, for product design, and yes, for the behavior-change systems I spend most of my days helping clients build. The winners in each category will be the teams that understand this: the AI’s job is to describe what should exist, not to build it. The engine’s job is to guarantee the floor. The creator’s job is to have a vision worth configuring.

For those of us working in applied behavioral design, there’s a direct implication. If you’re building an Octalysis-driven product today, the question you should be asking is: where is my CONFIG layer, and where is my CODE layer? Which assumptions are the fast-moving AI-interpretable surface, and which are the slow-moving trusted base? If you can’t name the separation, you probably don’t have one, and your system will rot the minute the platform underneath it shifts.

This is also why I keep pushing against the vibe-coding framing even when I love the spirit. The spirit of vibe coding is “anyone should be able to create.” The implementation of vibe coding was “anyone should be able to generate code.” Those are not the same thing. One is a design philosophy. The other is a specific wrong path. Akasha is what the spirit looks like when you pick a different implementation.

What I Think Comes Next

Two predictions I’m willing to put on the record.

First, the next generation of AI creativity tools will look less like chatbots and more like instruments. You’ll speak or write an intent, and a tuned engine will play it into existence within a domain it has mastered. The engine will have opinions. It will refuse invalid configurations. That refusal is precisely what will make the output trustworthy at scale. The tools that are easiest to break are not the ones that will last.

Second, the teams that win the next five years of AI creativity will be the ones with the best catalogs, not the ones with the best models. Models are becoming commodities fast. A professionally curated catalog of thousands of production-grade assets is not. Whoever owns the substrate owns the category. If you’re thinking about where to invest (personally, strategically, or financially), invest in what the AI sits on top of, not just in the AI itself. The catalog is the moat. The model is a renter.

Bloom understood this early, and Akasha is the receipt.

If you want to check the thesis yourself, don’t take my word for any of it. Play the sample game. Judge the output. If you want in as an early creator or tester, sign up at Akasha.Bloomverse.io.

The machine that builds realities doesn’t need you to read about it. It needs you to speak into it and see what happens.

Related Reading

• AI and Gamification: How Octalysis Meets AI — the foundational post on why AI changes the economics of applied motivation design.
• How AI Is Already Transforming Games: 17 Examples Analyzed Through Octalysis — seventeen live AI-in-games deployments mapped onto the eight Core Drives.

WOULD YOU LIKE YU-KAI CHOU TO WORK WITH YOUR ORGANIZATION?