Bericht über die Entwicklung eines Webspiels, das täglich automatisch anhand von Nutzerfeedback weiterentwickelt und deployed wird

Ich habe versucht, ein Webspiel mit dem Konzept zu entwickeln, dass gesammelte Feedback-Punkte der Nutzer am nächsten Tag ausgerollt werden.
Es ist ein Projekt, das ich erstellt habe, um mich mit AI-Tools vertraut zu machen; das GitHub-Repository ist ebenfalls öffentlich, also schaut es euch gern an.
game: https://spiralwave.frogred8.dev
github: https://github.com/frogred8/SpiralWave

• Projektüberblick und Planung
  • Motivation und Ziel: Ein Vibe-Coding-Experiment mit fortgeschrittenen AI-Tools (z. B. Gemini) und der Versuch, ein Webspiel mit Technologien zu entwickeln, die ich bisher noch nicht eingesetzt hatte.
  • Entwicklungsrichtung: Festgelegt wurde ein Mini-Webspiel zur Ressourcensammlung mit Zeitlimit, in dem Nutzermeinungen täglich automatisch berücksichtigt werden.
• Erstellung des ersten Prototyps
  • Kernkonzept: Ein Spiel zum Sammeln von Ressourcen und zum Aufbau eines Skill-Trees ohne Wettbewerb oder Verlustmechaniken.
  • Einsatz von AI: Eine Papierskizze wurde in einen Prompt umgewandelt, um in 30 Minuten die grundlegende Spielstruktur auf Basis von TypeScript, Vite und Phaser umzusetzen.
• Grenzen bei der Umsetzung komplexer Logik und direkte Lösung per Hand
  • Entwicklung des Skill-Trees: Die grundlegende Logik für vorausgesetzte Skills wurde mit AI umgesetzt, aber die komplexe Logik, bei der beim Abwählen eines mittleren Knotens untergeordnete Knoten kaskadierend zurückgesetzt werden, konnte AI nicht lösen, sodass ich sie selbst implementiert habe.
  • Verzicht auf Testcode: Wegen häufiger Designänderungen und der hohen Entwicklungsgeschwindigkeit wurde bewusst ohne Testcode gearbeitet.
• Großes Refactoring und die Eigenheiten von AI-Debugging
  • Trennung der UI: Weil eine einzelne Datei zu groß geworden war, wurde der UI-Code ausgelagert; die Einheitlichkeit und strukturelle Zufriedenheit blieben aber gering. Dabei zeigte sich, dass es bei größeren Aufgaben sinnvoll ist, Prompts nachzuschärfen und die Arbeit dann neu ausführen zu lassen.
  • Bug in der Ausführungsreihenfolge: Bei einem nach dem Refactoring aufgetretenen Runtime-Fehler (vertauschte Reihenfolge von Statusaktualisierung und UI-Anzeige) produzierte AI nur übermäßig viel Guard-Code. Letztlich hat der menschliche Entwickler den Ablauf selbst nachvollzogen und das Problem durch die direkte Änderung von zwei Codezeilen einfach gelöst.
  • Es fühlte sich seltsam an, weil die Fehler von AI vergleichsweise menschlich wirkten.
• Automatische Git-Commits und Anwendung von Leitlinien
  • Aufbau eines Prompt-Guides: Um die Mühe wiederholter Anweisungen zu reduzieren, wurde eine Richtliniendatei (GEMINI.md) eingeführt, die Tech-Stack und Funktionsweise zusammenfasst.
  • Automatisierter Workflow: Nach Abschluss der Codearbeit wurde eine Einstellung vorgenommen, die automatisch Commit-Messages mit Laufzeit des Agenten, Anweisungs-Prompt und Arbeitszusammenfassung erzeugt, um den Aufwand für einfache Reviews zu reduzieren.
• Entwurf und Optimierung der Architektur für automatische Updates
  • Umstellung der Deployment-Methode: Das zunächst geplante automatische Echtzeit-Deployment im 2-Stunden-Takt wurde wegen einer hohen Rate an Runtime-Bugs (ca. 25 %) und unzureichender Build-Stabilität aufgegeben; stattdessen fiel die Entscheidung auf die separate tägliche Erstellung und Auslieferung eines Test-Builds.
  • Cron-Workflow: Mit node:cron wurde ein automatisierter Prozess in monolithischer Struktur aufgebaut, der von „Feedback sammeln → bereinigen → Code generieren → Build und Release erstellen → deployen“ reicht.
  • Aktualisierung der Release Notes: Eine Serverlisten-Datei wurde zwischen Docker-Instanzen über ein gemeinsames Volume geteilt, zusätzlich wurde ein Cache mit 5 Minuten Ablaufzeit zur Lastkontrolle eingesetzt. Nutzeranfragen in mehreren Sprachen werden zuerst ins Englische bereinigt und anschließend erneut übersetzt, damit sie in den Release Notes angezeigt werden können.
• Funktionen, die während der Entwicklung ausgeschlossen wurden
  • Like-Funktion für Empfehlungen im Leaderboard (fehlende Identifikatoren und Kosten für API-Aufrufe).
  • Ausgereiftes Tool zur Verwaltung von Skill-Daten (Grenzen der Vorstellungskraft und direkte Bearbeitung von JSON ist effizienter).
  • Verteilte Docker-Umgebung pro Service (für minimale Betriebs- und Verwaltungs­komplexität in einem Image zusammengeführt).
  • E-Mail-Benachrichtigung bei Übernahme von Nutzerfeedback (Zweifel an der Sinnhaftigkeit des Sammelns von E-Mails ohne Registrierung und Risiko von Missbrauch).
  • Zusätzliche Seitenwerbung (ermüdender Plattform-Freigabeprozess und geringe Wirkung im Verhältnis zu niedrigen Vergütungssätzen).
• Rückblick auf AI-basierte Entwicklung
  • Trade-off zwischen Produktivität und Tests: Die Umsetzungsgeschwindigkeit in der Entwicklung stieg zwar um etwa das Zehnfache, zugleich nahmen aber Zeitaufwand und Ermüdung für die Verifikation (QA) proportional zu.
  • Merkmale der Codequalität: Die Qualität auf Funktionsebene ist hoch, aber die Lesbarkeit leidet, wodurch der Gesamtfluss schwer zu erfassen ist. Außerdem zeigte sich eine Tendenz, selbst in Situationen, in denen lokales Hardcoding vorteilhaft wäre, unnötig aufgeblähte Generalisierungsmuster einzuführen.

[recast7838]

Interessant.