Entwickler nutzt Claude Code-Agenten, um 635 Probleme in 42 Brettspielen in einer einzigen Sitzung zu lösen.

Ein Solo-Entwickler, der eine kostenlose Multiplayer-Brettspielplattform aufbaut, nutzte Claude Code Agents, um systematisch Hunderte von UI/UX-Problemen über 42 verschiedene Spiele hinweg in einer einzigen Entwicklungssitzung zu lösen.

Das Setup

Der Entwickler pflegte etwa 800 Probleme in einem lokalen SQLite-basierten Tracker, der sowohl Backend-Rust-Fehler (wie Feldnamen-Unterschiede zwischen Rust und TypeScript) als auch Frontend-Verfeinerungsaufgaben abdeckte. Beispiele waren "Backgammon braucht Drag-and-Drop", "Hearts braucht Karten-Dimmung für ungültige Züge", "Shogi braucht Handicap-Unterstützung" und "Skat braucht Ramsch-Modus".

Konfigurationsdateien umfassten:

• CLAUDE.md mit Architekturregeln
• .claude/rules/-Dateien, die Actor-Model-, Game-Engine-Muster und E2E-Testkonventionen abdecken

Diese Regeln wurden jedes Mal automatisch geladen, wenn Claude mit der Arbeit begann.

Der Workflow

Der Entwickler führte vier Agents gleichzeitig aus, die jeweils ein einzelnes Problem aus einem anderen Spiel bearbeiteten, um Dateikonflikte zu verhindern. Beispielhafte Agentenzuweisungen:

• Agent 1: Backgammon-Drag-and-Drop beheben (#407)
• Agent 2: Belote-Coinche-Bidding-UI beheben (#417)
• Agent 3: Briscola-Feld-Unterschiede beheben (#454-457)
• Agent 4: Schach-geschlagene-Figuren-Anzeige beheben (#494)

Jeder Agent las relevante Dateien, implementierte die Lösung, führte svelte-check aus, markierte das Problem als gelöst und committete. Während diese vier im Hintergrund liefen, überprüfte der Entwickler abgeschlossene Lösungen, behegte eventuelle Build-Fehler und startete dann den nächsten Batch.

Was gut funktionierte

• Der Ansatz "Ein Agent pro Problem, niemals bündeln" erwies sich als effektiver, als einem Agenten mehrere Probleme zu geben
• Strikte Regeln in CLAUDE.md (keine any-Typen, data-ui-Attribute verwenden, Backend als Quelle der Wahrheit für Feldnamen) sorgten für konsistenten Code
• Claude verstand sowohl Rust-Game-Engine-Code als auch SvelteKit-Canvas-Rendering gleichermaßen gut
• Agents konnten eine Rust-Funktion build_state_message() lesen und entsprechende TypeScript-Handler beheben
• Die Implementierung von Soundeffekten war erfolgreich – Claude synthetisierte Web Audio API-Sounds (Holzklopfen für Go, Kartenklappen für Hearts, Würfelrollen für Backgammon) ohne Audiodateien

Was schiefging

• Wenn Agents neue GameRule-Enum-Varianten in Rust hinzufügten, vergaßen sie, den erschöpfenden Match in judge.rs zu aktualisieren
• Gelegentliche Merge-Konflikte, wenn zwei Agents dieselbe game.svelte.ts-Store-Datei änderten
• Einige Agents überentwickelten Lösungen – fügten 200 Zeilen hinzu, wo 20 ausgereicht hätten
• Train Dominoes-Tests brachen dreimal, weil ein Agent round_scores von Vec<u32> zu Vec<Vec<u32>> änderte, ohne alle Test-Assertions zu aktualisieren

Die Ergebnisse

• 325 Commits in einer Sitzung
• 635 Probleme gelöst (alle kritischen und hohen Prioritäten aus ~800 insgesamt bereinigt)
• 42 verschiedene Spiele bearbeitet
• Build durchgehend bei 0 Fehlern gehalten (Rust + Frontend)
• Jedes Spiel erhielt: Soundeffekte, Brett-Themen, Zugverlauf, Ergebnisbildschirme, Drag-and-Drop wo anwendbar

Gelernte Lektionen

• Hätte cargo test nach jedem Batch ausführen sollen, nicht nur cargo check – einige zur Kompilierzeit korrekte Änderungen brachen Laufzeitverhalten
• Hätte zuerst gemeinsame Komponenten für Spiele mit ähnlichen Mustern erstellen sollen (Stichkartenspiele, 4-Spieler-NESW-Layouts), anstatt dass jeder Agent das Rad neu erfindet