From Slop Art Online to Protocol Design: The Unexpected Path of Vibe Coding

• Introduction about unexpected discoveries
• The personal journey
• The technical problem
• The breakthrough insight
• The protocol design
• Takeaways

Sometimes the best ideas come from the most ridiculous projects.

Let me paint you a picture: you're a developer who just got hit with the layoff hammer. You're stuck in job application purgatory, blaming everything and everyone, and frankly, being miserable. Then one day, something clicks. You decide to stop complaining and actually build something—something ambitious, something that pushes you to learn new tools.

That's exactly what happened to me. And what I built was an MMO where every NPC is controlled by an LLM, treated exactly like a player. The name? SAO: Slop Art Online. (Yes, it's a reference. No, I'm not apologizing.)

The Tech Stack Dilemma

When I started this project, I made what some might call "non-optimal" choices: Rust, Bevy, and SpacetimeDB. These are incredible tools, don't get me wrong. But they're not exactly beginner-friendly for game development. That was intentional, though. I wanted friction. I wanted to force myself to understand what was actually happening under the hood.

The core concept was simple yet ambitious: NPCs and players would be indistinguishable at the architectural level. The only difference? NPCs get their decisions from large language models instead of human brains. Merchants, guards, politicians, monsters—all governed by the same systems, all "experiencing" the game world through AI.

My initial approach was naive but functional: take a snapshot of the observable world, package it with available actions, send it to an LLM, and wait for a response. It worked. Until it didn't.

The Real-Time Problem

Here's the thing about MMOs: they don't wait. Combat happens in real-time. Players expect NPCs to react instantly, not after a multi-second LLM call. No matter how much I optimized inference, that latency would never disappear.

I considered fine-tuning a smaller model on gameplay data, but that felt expensive and rigid. The game mechanics weren't even finalized yet—training a model on moving targets seemed backwards.

Then came the breakthrough: a hybrid architecture.

Instead of relying solely on LLMs for decisions, I implemented behavior trees as the foundation. Every NPC type gets a default tree based on its role. The LLM becomes a "regenerator" that updates these trees based on what the NPC "experiences." Deterministic, instant execution meets situational adaptability.

[SpacetimeDB State] → [Behavior Tree Dispatch] → [Action Execution]
                          ↑
                          | (rare decisions)
                    [LLM Bridge]

The magic happened because of SpacetimeDB's push-based architecture. The LLM bridge always receives a fresh, contextualized game state. Not a flat list of tools. Not a static prompt. A living projection of the world as it exists right now, with actions semantically connected to the current situation.

The Question That Changed Everything

Standing at this architectural crossroads, a strange thought emerged:

Why isn't every AI protocol like this?

Why do we expose flat tool lists to LLMs? Why are we using interfaces designed for human eyes? What would happen if we designed systems specifically for AI agents—machines that need push-based state, contextualized actions, and structured decision frameworks?

The behavior tree pattern isn't just for games. It's a proven model for AI decision-making. The concept of pushing relevant state instead of letting agents poll for information? That's not incremental improvement—that's a paradigm shift.

What Agent-First Design Actually Means

This is where things get interesting for anyone building with AI. We're still in the era of adapting human interfaces for machines. But what if we flipped that?

An agent-first protocol might look like:

• Push-based state: Systems push relevant context to agents, not the other way around
• Contextualized actions: Tools that understand their current relevance based on state
• Structured decision spaces: Clear hierarchies for decisions, not unlimited choice
• Built-in validation: Reducers that ensure state consistency before and after actions

Think about how much of current AI development involves prompt engineering just to make models understand what actions are possible and when. Now imagine a protocol where that context is inherent, always fresh, always relevant.

The Unexpected Takeaway

Here's what vibe coding taught me: sometimes the most valuable insights come from building something ambitious with new tools. I set out to make a game with AI NPCs. I ended up questioning fundamental assumptions about how AI agents should interact with systems.

The protocol I'm sketching out isn't just theoretical. It's born from real constraints, real architectural decisions, and real lessons learned from pushing LLMs into domains they weren't designed for.

If you're vibe coding something right now—whether it's a game, an app, or a wild experiment—pay attention to the moments where you think "this shouldn't work like this." Those friction points often reveal more about the future of AI than any roadmap ever could.

The best part? I never would have found these insights by playing it safe. Sometimes you need to build Slop Art Online to discover what comes next.

What's your vibe coding story? Sometimes the silliest projects lead to the most interesting breakthroughs. Drop your experiences in the comments—I'm genuinely curious what unexpected paths others have taken.