Warum die verrücktesten Projekte manchmal die besten Ideen liefern

Manchmal kommt man nur durch absolute Hirngespinste auf die wirklich guten Ideen.

Stell dir folgendes vor: Du bist Entwickler, gerade mit einem Stellenabbau crash gelandet. Wochen vergehen mit Bewerbungen, die ins Leere laufen. Du suchst Schuldige, bist frustriert – und merkst irgendwann: So kommt nichts voran. Der einzige Ausweg? Selbst etwas bauen. Etwas Großes. Etwas, das dich zwingt, neue Tools zu lernen.

Genau das ist mir passiert. Herausgekommen ist ein MMO, in dem jeder NPC von einem LLM gesteuert wird – und zwar exakt wie ein menschlicher Spieler. Der Name? SAO: Slop Art Online. (Ja, eine Anspielung. Nein, ich entschuldige mich nicht.)

Die Tech-Stack-Entscheidung

Als ich das Projekt startete, habe ich mir做了一个 „nicht ganz optimale" Werkzeugauswahl: Rust, Bevy und SpacetimeDB. Unglaubliche Tools, keine Frage. Aber gerade für Spieleprogrammierung? Eher nichts für Anfänger. Das war aber gewollt. Ich wollte Reibung. Ich wollte verstehen, was da unten im Inneren passiert.

Das Kernkonzept war simpel, aber ehrgeizig: NPCs und Spieler sollten auf Architekturebene identisch sein. Der einzige Unterschied? NPCs treffen Entscheidungen durch Large Language Models statt durch menschliche Gehirne. Händler, Wachen, Monster – alle werden von denselben Systemen gesteuert, alle „erleben" die Spielwelt durch KI.

Mein erster Ansatz war naiv, aber funktionierte: Zustandsmomentaufnahme, verfügbare Aktionen dazu, zum LLM schicken, Antwort abwarten. Hat funktioniert. Bis es das nicht mehr tat.

Das Echtzeit-Problem

Das Problem an MMOs: Die Welt wartet nicht. Kampf läuft in Echtzeit ab. Spieler erwarten sofortige Reaktionen – nicht nach einem mehrsekündigen LLM-Call. Egal wie sehr ich Inference optimiert habe, diese Latenz blieb.

Fine-Tuning eines kleineren Modells auf Gameplay-Daten? Zu teuer, zu starr. Die Spielmechanik war noch nicht mal fertig – ein Modell auf sich bewegende Ziele zu trainieren, fühlte sich rückwärts an.

Dann kam der Durchbruch: Eine Hybrid-Architektur.

Statt LLMs komplett für Entscheidungen zu nutzen, habe ich Behavior Trees als Basis implementiert. Jeder NPC-Typ bekommt einen Standardbaum basierend auf seiner Rolle. Das LLM wird zum „Regenerator", der diese Bäume basierend auf dem aktuellen „Erleben" des NPC aktualisiert. Deterministische, sofortige Ausführung trifft auf situationsbezogene Anpassungsfähigkeit.

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

Das Magische daran: SpacetimeDBs Push-basierte Architektur. Der LLM-Bridge erhält immer frischen, kontextualisierten Spielzustand. Keine flache Werkzeugliste. Kein statisches Prompt. Eine lebendige Momentaufnahme der Welt, wie sie gerade existiert – mit Aktionen, die semantisch mit der aktuellen Situation verknüpft sind.

Die Frage, die alles veränderte

An dieser architektonischen Kreuzung tauchte ein seltsamer Gedanke auf:

Warum ist nicht jedes KI-Protokoll so aufgebaut?

Warum präsentieren wir LLMs flache Werkzeuglisten? Warum nutzen wir Interfaces, die für menschliche Augen gemacht wurden? Was wäre, wenn wir Systeme speziell für KI-Agenten designen würden – Maschinen, die Push-basierten Zustand brauchen, kontextualisierte Aktionen und strukturierte Entscheidungsrahmen?

Das Behavior-Tree-Muster ist nicht nur für Spiele geeignet. Es ist ein bewährtes Modell für KI-Entscheidungsfindung. Das Konzept, relevanter Zustand zu pushen, statt Agenten pollen zu lassen? Das ist keine inkrementelle Verbesserung – das ist ein Paradigmenwechsel.

Was Agent-First Design wirklich bedeutet

Hier wird es spannend für alle, die mit KI entwickeln. Wir befinden uns noch in der Ära, in der wir menschliche Interfaces für Maschinen anpassen. Aber was, wenn wir das umdrehen?

Ein Agent-First-Protokoll könnte so aussehen:

• Push-basierter Zustand: Systeme pushen relevanten Kontext zu Agenten, nicht umgekehrt
• Kontextualisierte Aktionen: Werkzeuge, die ihre aktuelle Relevanz basierend auf dem Zustand verstehen
• Strukturierte Entscheidungsräume: Klare Hierarchien für Entscheidungen, statt unbegrenzter Auswahl
• Integrierte Validierung: Reducer, die Zustandskonsistenz vor und nach Aktionen sicherstellen

Denk mal dran, wie viel Entwicklungszeit aktuell in Prompt Engineering fließt, nur damit Modelle verstehen, welche Aktionen möglich sind und wann. Jetzt stell dir ein Protokoll vor, wo dieser Kontext inhärent ist – immer frisch, immer relevant.

Die unerwartete Erkenntnis

Was mir „Vibe Coding" beigebracht hat: Die wertvollsten Einsichten kommen oft durch ambitionierte Projekte mit neuen Tools. Ich wollte ein Spiel mit KI-NPCs bauen. Am Ende habe ich fundamentale Annahmen darüber in Frage gestellt, wie KI-Agenten mit Systemen interagieren sollten.

Das Protokoll, das ich gerade skizziere, ist nicht nur Theorie. Es ist aus echten Constraints geboren, aus echten architektonischen Entscheidungen und echten Lektionen davon, LLMs in Bereiche zu drücken, für die sie nicht gedacht waren.

Wenn du gerade irgendwas mit Vibe Coding baust – ob Spiel, App oder wildes Experiment – achte auf die Momente, in denen du denkst: „Das sollte doch nicht so funktionieren." Diese Reibungspunkte enthüllen oft mehr über die Zukunft von KI als jeder Roadmap.

Das Beste daran? Diese Erkenntnisse hätte ich nie gefunden, wenn ich auf Nummer sicher gegangen wäre. Manchmal muss man Slop Art Online bauen, um rauszufinden, was als nächstes kommt.

Was ist deine Vibe-Coding-Geschichte? Die albernsten Projekte führen oft zu den interessantesten Durchbrüchen. Schreib in die Kommentare – ich bin echt neugierig, welche unerwarteten Wege andere eingeschlagen haben.