De bedste idéer kommer fra de mest vanvittige projekter

Nogle gange starter de mest værdifulde erkendelser et helt tilfældigt sted.

Forestil dig dette: Du er udvikler, og pludselig står du med fyresedlen i hånden. Ugerne går med ansøgninger, der aldrig bliver læst. Du brokker dig over markedet, over LinkedIn, over alt og alle. Ingen kan lide den følelse.

Men så sker der noget. Du stopper med at klage og begynder at bygge. Ikke noget sikkert. Noget ambitiøst. Noget der tvinger dig til at lære ting, du aldrig har rørt før.

Sådan startede mit projekt. Jeg byggede et MMO, hvor hver eneste NPC bliver styret af en LLM og behandlet præcis som en rigtig spiller. Navnet? SAO: Slop Art Online. (Ja, det er en reference. Nej, jeg undskylder mig ikke.)

Valget af værktøjer

Da jeg gik i gang, valgte jeg nogle teknologier, de fleste nok ville kalde "suboptimale": Rust, Bevy og SpacetimeDB. Fantastiske værktøjer, ingen tvivl om det. Men de er ikke ligefrem begyndervenlige til spiludvikling.

Det var med vilje. Jeg ville have friktion. Jeg ville forstå, hvad der faktisk skete under overfladen.

Kernen i projektet var enkel: NPCs og spillere skulle være fuldstændig ens på arkitekturniveau. Den eneste forskel? NPCs får deres beslutninger fra store sprogmodeller i stedet for menneskehjerner. Handlende, vagter, monstre—alle styret af de samme systemer.

Min første tilgang var naiv, men den virkede: tag et øjebliksbillede af verdenen, send det til en LLM sammen med tilgængelige handlinger, og vent på svar. Det fungerede. Indtil det ikke gjorde.

Problemet med realtid

Her kommer den kedelige sandhed om MMORPG'er: De venter ikke på dig. Kamp foregår i realtid. Spillere forventer, at NPCs reagerer øjeblikkeligt—ikke efter et par sekunders ventetid på en LLM-svartid. Uanset hvor meget du optimerer inference, forsvinder den latency aldrig helt.

Jeg overvejede at fine-tune en mindre model på gameplay-data. Men det føltes dyrt og stift. Spilmekanikkerne var slet ikke fastlagt endnu—at træne på et moving target gav ingen mening.

Vendepunktet

Og så kom gennembruddet: en hybrid arkitektur.

I stedet for udelukkende at stole på LLMs beslutninger implementerede jeg behavior trees som fundament. Hver NPC-type får et standard-træ baseret på sin rolle. LLM'en bliver en "regenerator", der opdaterer disse træer baseret på, hvad NPC'en "oplever."

Det deterministiske og øjeblikkelige møder den situationsbestemte tilpasningsevne.

[SpacetimeDB State] → [Behavior Tree Dispatch] → [Action Execution]
                          ↑
                          | (sjældne beslutninger)
                    [LLM Bridge]

Magien opstod på grund af SpacetimeDB's push-baserede arkitektur. LLM-broen modtager altid frisk, kontekstualiseret spiltilstand. Ikke en flad liste af tools. Ikke en statisk prompt. En levende projicering af verdenen, som den eksisterer lige nu, med handlinger der er semantisk forbundet til den aktuelle situation.

Spørgsmålet der ændrede alt

Midt i denne arkitektoniske afvejning dukkede et mærkeligt spørgsmål op:

Hvorfor er ikke alle AI-protokoller bygget sådan?

Hvorfor eksponerer vi flade tool-lister til LLMs? Hvorfor bruger vi grænseflader designet til menneskeøjne? Hvad hvis vi designede systemer specifikt til AI-agenter—maskiner der har brug for push-baseret tilstand, kontekstualiserede handlinger og strukturerede beslutningsrammer?

Behavior tree-mønsteret er ikke kun til spil. Det er en dokumenteret model for AI-beslutningstagning. Konceptet om at skubbe relevant tilstand i stedet for at lade agenter pollе efter information? Det er ikke en forbedring—det er et paradigmeskift.

Hvad agent-first design egentlig betyder

Her bliver det interessant for alle, der bygger med AI. Vi befinder os stadig i en æra, hvor vi tilpasser menneskegrænseflader til maskiner. Men hvad hvis vi vendte det om?

En agent-first protokol kunne se således ud:

• Push-baseret tilstand: Systemer skubber relevant kontekst til agenter, ikke omvendt
• Kontekstualiserede handlinger: Værktøjer der forstår deres aktuelle relevans baseret på tilstand
• Strukturerede beslutningsrum: Klare hierarkier for beslutninger, ikke ubegrænset valg
• Indbygget validering: Reducers der sikrer tilstandskonsistens før og efter handlinger

Tænk over, hvor meget af nuværende AI-udvikling der går til prompt engineering bare for at få modeller til at forstå, hvilke handlinger der er mulige og hvornår. Forestil dig en protokol, hvor den kontekst er iboende, altid frisk, altid relevant.

Den uventede læring

Her er, hvad "vibe coding" lærte mig: nogle gange kommer de mest værdifulde indsigter fra at bygge noget ambitiøst med nye værktøjer. Jeg satte mig for at lave et spil med AI-NPCs. Jeg endte med at stille fundamentale spørgsmål ved, hvordan AI-agenter burde interagere med systemer.

Protokollen jeg skitserer er ikke kun teoretisk. Den er født af virkelige begrænsninger, virkelige arkitektoniske beslutninger og virkelige lessons learned fra at presse LLMs ind i domæner, de ikke var designet til.

Hvis du vibe coder noget lige nu—hvad enten det er et spil, en app eller et skørt eksperiment—så vær opmærksom på de øjeblikke, hvor du tænker "dette burde ikke virke sådan." De friktionspunkter afslører ofte mere om fremtiden for AI end nogen roadmap nogensinde kunne.

Det bedste ved det hele? Jeg ville aldrig have fundet de indsigter ved at spille safe. Nogle gange skal man bygge Slop Art Online for at opdage, hvad der kommer næste gang.

Har du en vibe coding-historie? Nogle gange fører de mest tåbelige projekter til de mest interessante gennembrud. Del dine oplevelser i kommentarerne—jeg er ærligt nysgerrig efter at høre, hvilke uventede veje andre har taget.