Van ontslag naar MMO: hoe mijn stomste project mijn kijk op AI veranderde

Soms kom je de beste ideeën tegen op de meest onverwachte momenten.

Stel je voor: je bent developer, je komt net te weten dat je ontslagen bent, en je verdrinkt in een zee van sollicitaties. Je zoekt schuld bij iedereen behalve jezelf. Best somber, eerlijk gesagt.

Totdat er ergens een knop omgaat. Je stopt met klagen. Je begint te bouwen. Iets ambitieus. Iets dat je dwingt om nieuwe tools onder de knie te krijgen.

Zo ging het bij mij. En wat ik bouwde? Een MMO waar elke NPC wordt aangestuurd door een LLM, exact hetzelfde behandeld als echte spelers. De naam? SAO: Slop Art Online. (Ja, een referentie. Nee, ik ga me niet verontschuldigen.)

Mijn tech-stack keuze: leerzaam pijnlijk

Bij dit project koos ik voor wat je mild gekscheppend "niet-ideaal voor beginners" zou kunnen noemen: Rust, Bevy en SpacetimeDB. Geweldige tools, absolutely. Maar beginner-vriendelijk? Nope.

Dat was echter de bedoeling. Ik wilde wrijving. Ik wilde mezelf dwingen om te begrijpen wat er daadwerkelijk gebeurt onder de motorkap.

Het basisconcept was simpel maar ambitieus: NPCs en spelers zouden architectuurlijk identiek zijn. Het enige verschil? NPCs halen hun beslissingen van large language models in plaats van menselijke hersenen. Handelaren, gardisten, politici, monsters—allemaal geregeerd door dezelfde systemen, allemaal die "game wereld" ervarend via AI.

Mijn eerste aanpak was simpel maar werkend: neem een snapshot van de observable wereld, stop het samen met beschikbare acties, stuur het naar een LLM, en wacht op antwoord. Het werkte. Tot het niet meer werkte.

Het real-time probleem

MMOs hebben een vervelende eigenschap: ze wachten niet. Combat gebeurt real-time. Spelers verwachten dat NPCs instant reageren, niet na een multi-second LLM call. Hoeveel ik inference ook optimaliseerde, die latency bleef er gewoon zitten.

Ik overwoog om een kleiner model te fine-tunen op gameplay data, maar dat voelde duur en star. De game mechanics waren nog niet eens af. Trainen op bewegende doelen leek me achterwaarts werken.

Toen kwam het inzicht: een hybride architectuur.

In plaats van alleen te vertrouwen op LLMs voor beslissingen, implementeerde ik behavior trees als fundering. Elk NPC-type krijgt een default tree gebaseerd op zijn rol. De LLM wordt een "regenerator" die deze trees bijwerkt op basis van wat de NPC "ervaart". Deterministische, instant executie ontmoet situationele aanpasbaarheid.

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

De magie ontstond door SpacetimeDB's push-based architectuur. De LLM bridge ontvangt altijd verse, gecontextualiseerde game state. Geen platte lijst van tools. Geen statische prompt. Een levende projectie van de wereld zoals die nu bestaat, met acties semantisch verbonden aan de huidige situatie.

De vraag die alles veranderde

Staand op dit architecturale kruispunt, duikte een vreemde gedachte op:

Waarom is niet elk AI protocol zo ontworpen?

Waarom stellen we platte tool lijsten beschikbaar aan LLMs? Waarom gebruiken we interfaces ontworpen voor menselijke ogen? Wat zou er gebeuren als we systemen specifiek voor AI agents bouwden—machines die push-based state nodig hebben, gecontextualiseerde acties, en gestructureerde besluitvormingskaders?

Het behavior tree patroon is niet alleen voor games. Het is een bewezen model voor AI besluitvorming. Het concept van relevante state pushen in plaats van agents te laten pollen voor informatie? Dat is geen incrementele verbetering—dat is een paradigmaverschuiving.

Wat Agent-First Design eigenlijk betekent

Dit is waar het interessant wordt voor iedereen die met AI bouwt. We zitten nog steeds in het tijdperk van het aanpassen van menselijke interfaces voor machines. Maar wat als we dat omdraaiden?

Een agent-first protocol ziet er misschien zo uit:

• Push-based state: Systemen pushen relevante context naar agents, niet andersom
• Gecontextualiseerde acties: Tools die hun huidige relevantie begrijpen gebaseerd op state
• Gestructureerde beslissingsruimtes: Duidelijke hiërarchieën voor beslissingen, niet ongelimiteerde keuze
• Ingebouwde validatie: Reducers die state consistentie verzekeren voor en na acties

Denk aan hoeveel van huidige AI development bestaat uit prompt engineering alleen maar om modellen te laten begrijpen welke acties mogelijk zijn en wanneer. Stel je nu een protocol voor waarbij die context inherent is, altijd vers, altijd relevant.

De onverwachte les

Dit is wat vibe coding me leerde: soms komen de meest waardevolle inzichten van het bouwen van iets ambitieus met nieuwe tools. Ik wilde een game maken met AI NPCs. Ik eindigde met het bevragen van fundamentele aannames over hoe AI agents met systemen zouden moeten interageren.

Het protocol dat ik nu uitwerk is niet alleen theoretisch. Het is geboren uit echte constraints, echte architecturale beslissingen, en echte lessen geleerd van het pushen van LLMs naar domeinen waar ze niet voor bedoeld waren.

Als je momenteel aan het vibe coden bent—of het nu een game is, een app, of een wild experiment—let op de momenten waarop je denkt "dit zou niet zo moeten werken." Die wrijvingspunten onthullen vaak meer over de toekomst van AI dan welke roadmap dan ook.

Het mooiste? Deze inzichten had ik nooit gevonden door veilig te spelen. Soms moet je Slop Art Online bouwen om te ontdekken wat daarna komt.

Heb jij een vibe coding verhaal? De meest stomme projecten leiden vaak tot de interessantste doorbraken. Deel je ervaringen in de comments—ik ben oprecht benieuwd naar welke onverwachte paden anderen bewandeld hebben.