Construyendo un RTS con 5-10 Sesiones Paralelas de Claude
Construí un juego RTS completo en Godot usando un flujo de trabajo experimental: múltiples sesiones de IA trabajando de forma autónoma en tareas separadas, con testing y merge automáticos. Así es como funciona y qué aprendí.
Quería construir un juego de estrategia en tiempo real. No un prototipo—un juego completo con multijugador, oponentes IA y un ciclo económico completo. El tipo de proyecto que normalmente lleva meses a un equipo.
Lo que hizo esto diferente no fue el juego en sí. Fue cómo lo construí: ejecutando 5-10 sesiones paralelas de Claude, cada una trabajando de forma autónoma en tareas independientes, con testing automático y merge de PRs.
El Problema del Desarrollo Secuencial con IA
El flujo de trabajo estándar con IA es conversacional. Explicas una tarea, la IA escribe código, lo revisas, iteras y pasas a lo siguiente. Funciona, pero es lento. Siempre estás esperando—o a la IA o a ti mismo.
Quería algo más rápido. Si las tareas son independientes, ¿por qué no ejecutarlas en paralelo?
La solución obvia son los git worktrees. Crear múltiples directorios de trabajo compartiendo el mismo .git/. Pero los worktrees causan conflictos cuando múltiples sesiones intentan trabajar simultáneamente—bloqueos de índice, actualizaciones de refs pisándose entre sí. Necesitaba aislamiento total.
El Sistema Basado en Clones
La solución fue simple: dar a cada sesión paralela su propio clon completo de git.
Un directorio .rts-clones/ contiene copias de trabajo independientes. Cada clon tiene su propio .git/, su propia rama de feature, su propia sesión de Claude. Un archivo marcador rastrea qué issue tiene vinculado.
Construí 15 comandos slash personalizados para orquestar el flujo de trabajo:
/sync- Pull de últimos cambios, mostrar issues abiertos y estado de PRs/clone nombre-issue --auto- Crear un clon aislado y empezar a trabajar autónomamente/plan- Investigar el issue y publicar notas de implementación antes de programar/test- Ejecutar la suite de tests/finish- Si los tests pasan, crear PR y hacer merge
El comando clave es /clone con sus flags de automatización. Cuatro modos:
| Modo | Flag | Qué Pasa |
|---|---|---|
| Wait | ninguno | Interactivo, guío cada paso |
| Auto | --auto | Trabajo autónomo, observo el progreso |
| Full-Auto | --full-auto | Disparar y olvidar, auto-merge si pasan tests |
| Quiet | --quiet | Ejecución en segundo plano, revisar logs después |
Una Sesión Típica
/sync # Ver qué hay abierto
/clone 51-extract-attack-range --auto # Terminal 1
/clone 53-refactor-building-types --full-auto # Terminal 2
/clone 54-movement-constants --quiet # Terminal 3Cada clon automáticamente:
- Crea una rama de feature vinculada al issue
- Ejecuta
/planpara investigar el enfoque - Implementa la solución
- Ejecuta tests
- Crea un PR
- Si es full-auto y pasan los tests: hace merge automáticamente
Puedo observar la sesión --auto, revisar --quiet después, y confiar en que --full-auto se maneje solo.
El Pipeline de /audit
El flujo de trabajo más potente es la revisión sistemática de código. El comando /audit hace un barrido en tres fases:
- Revisar:
/audit scripts/core/- Analizar código, documentar hallazgos - Ejecutar:
/audit --execute- Convertir hallazgos en issues de GitHub con etiquetas - Correr:
/audit --run- Lanzar 3-5 clones paralelos en los issues seleccionados
Una auditoría reciente identificó 12 problemas de calidad de código. Los 12 se convirtieron en issues de GitHub, los 12 se convirtieron en clones paralelos, los 12 se mergearon exitosamente. Una capa de compatibilidad de 82 líneas fue eliminada. Se añadió object pooling al minimapa. El código mejoró sistemáticamente mientras yo trabajaba en otras cosas.
Medidas de Seguridad
Las sesiones de IA paralelas y autónomas suenan peligrosas. Algunas cosas las mantienen seguras:
Hooks de pre-commit validan el formato de conventional commits y escanean en busca de secretos. Ninguna API key o contraseña se commitea.
Linting de GDScript se ejecuta en cada edición de archivo. Los números mágicos y código de debug se marcan.
Modelo de permisos lista los comandos permitidos. git push --force está explícitamente denegado. El directorio addons/ (código de terceros) está protegido.
Auto-merge condicional solo ocurre si los tests pasan. Un test fallido significa que el PR queda para mi revisión.
La suite de tests tiene más de 8.000 líneas en 30 archivos. Es la base que hace posible el trabajo autónomo.
Lo Que Se Construyó
El juego en sí es un RTS completo inspirado en Age of Mythology:
- 5 tipos de unidades con un triángulo de combate piedra-papel-tijeras
- 6 tipos de edificios para construcción de base
- 4 recursos con recolección y economía
- Oponente IA con fases económicas y militares
- Multijugador LAN determinístico con sincronización lockstep
Más de 13.000 líneas de código, 76 clases, 12 comandos serializables, 12 estados de unidad. Todo construido en Godot 4.6 con GDScript.
Lo Que Aprendí
El aislamiento supera a la coordinación. Los git worktrees comparten demasiado estado. Clones completos significan que las sesiones nunca entran en conflicto. El espacio en disco vale la pena.
Los tests permiten la autonomía. Sin una suite de tests sólida, no podría confiar en sesiones autónomas. Los tests son el contrato que permite a la IA trabajar independientemente.
El paso de /plan importa. Saltar directamente al código produce peores resultados. Hacer que Claude investigue primero—encontrar patrones relacionados, identificar archivos a modificar, sugerir enfoques—lleva a implementaciones más limpias.
Lo sistemático supera a lo reactivo. El pipeline de /audit encuentra problemas que no notaría manualmente. Ejecutarlo regularmente evita que la deuda técnica se acumule.
El trabajo paralelo cambia el cuello de botella. El factor limitante dejó de ser “qué tan rápido se puede escribir código” y se convirtió en “qué tan bien puedo definir tareas independientes.” La descomposición de tareas se convirtió en la habilidad que importaba.
¿Lo Usaría de Nuevo?
Ya lo estoy haciendo. El flujo de trabajo no es específico de juegos RTS ni siquiera del desarrollo de videojuegos. Cualquier proyecto con buena cobertura de tests y tareas bien definidas puede beneficiarse de sesiones paralelas autónomas.
El juego era el objetivo. El flujo de trabajo fue el descubrimiento.