Le développeur utilise des agents de code Claude pour résoudre 635 problèmes sur 42 jeux de société en une seule session.

Un développeur solo construisant une plateforme gratuite de jeux de société multijoueurs a utilisé des agents Claude Code pour résoudre systématiquement des centaines de problèmes d'interface utilisateur et d'expérience utilisateur sur 42 jeux différents en une seule session de développement.

La Configuration

Le développeur maintenait environ 800 problèmes dans un suivi local basé sur SQLite, couvrant à la fois des bogues backend en Rust (comme des incohérences de noms de champs entre Rust et TypeScript) et des tâches de finition frontend. Les exemples incluaient "Le Backgammon a besoin du glisser-déposer", "Le Cœur a besoin d'un assombrissement des cartes pour les coups invalides", "Le Shogi a besoin du support des handicaps" et "Le Skat a besoin du mode Ramsch".

Les fichiers de configuration incluaient :

• CLAUDE.md avec les règles d'architecture
• Les fichiers .claude/rules/ couvrant le modèle d'acteur, les motifs du moteur de jeu et les conventions de tests de bout en bout

Ces règles se chargeaient automatiquement chaque fois que Claude commençait à travailler.

Le Flux de Travail

Le développeur a exécuté quatre agents simultanément, chacun traitant un seul problème provenant d'un jeu différent pour éviter les conflits de fichiers. Exemples d'assignations d'agents :

• Agent 1 : Corriger le glisser-déposer du backgammon (#407)
• Agent 2 : Corriger l'interface d'enchères coinche de la belote (#417)
• Agent 3 : Corriger les incohérences de champs de la briscola (#454-457)
• Agent 4 : Corriger l'affichage des pièces capturées aux échecs (#494)

Chaque agent lisait les fichiers pertinents, implémentait la correction, exécutait svelte-check, marquait le problème comme résolu et effectuait un commit. Pendant que ces quatre agents fonctionnaient en arrière-plan, le développeur examinait les corrections terminées, résolvait les éventuelles erreurs de compilation, puis lançait le lot suivant.

Ce Qui a Bien Fonctionné

• L'approche "Un agent par problème, jamais par lots" s'est avérée plus efficace que de donner plusieurs problèmes à un seul agent
• Des règles strictes dans CLAUDE.md (pas de types any, utiliser les attributs data-ui, le backend comme source de vérité pour les noms de champs) assuraient un code cohérent
• Claude comprenait aussi bien le code du moteur de jeu en Rust que le rendu Canvas en SvelteKit
• Les agents pouvaient lire une fonction Rust build_state_message() et corriger les gestionnaires TypeScript correspondants
• L'implémentation des effets sonores a été un succès — Claude a synthétisé des sons avec l'API Web Audio (des tapotements de bois pour le Go, des claquements de cartes pour le Cœur, des bruits de dés pour le Backgammon) sans aucun fichier audio

Ce Qui a Mal Tourné

• Lorsque les agents ajoutaient de nouvelles variantes d'énumération GameRule en Rust, ils oubliaient de mettre à jour la correspondance exhaustive dans judge.rs
• Des conflits de fusion occasionnels lorsque deux agents modifiaient le même fichier de stockage game.svelte.ts
• Certains agents sur-ingénierisaient les solutions — ajoutant 200 lignes là où 20 auraient suffi
• Les tests du Domino Train ont échoué trois fois parce qu'un agent a changé round_scores de Vec<u32> à Vec<Vec<u32>> sans mettre à jour toutes les assertions de test

Les Résultats

• 325 commits en une session
• 635 problèmes résolus (tous les critiques et haute priorité effacés sur environ 800 au total)
• 42 jeux différents touchés
• La compilation maintenue à 0 erreur tout au long (Rust + frontend)
• Chaque jeu a reçu : des effets sonores, des thèmes de plateau, un historique des coups, des écrans de résultat, du glisser-déposer le cas échéant

Leçons Apprises

• Il aurait fallu exécuter cargo test après chaque lot, pas seulement cargo check — certains changements corrects à la compilation ont cassé le comportement à l'exécution
• Il aurait fallu créer d'abord des composants partagés pour les jeux avec des motifs similaires (jeux de cartes à plis, dispositions 4 joueurs NESO) au lieu de laisser chaque agent réinventer la roue