Now Reading: GitHub Copilot: Reparte juego con subagentes
-
01
GitHub Copilot: Reparte juego con subagentes
GitHub Copilot está dejando de ser “ese asistente que completa código” para convertirse en un motor de orquestación. Lo que antes era un chat contextual ahora es un entorno capaz de coordinar roles especializados, tomar decisiones, distribuir trabajo y garantizar una ejecución coherente en tu workspace.
Cuando entiendes esto, empiezas a ver el verdadero giro: Copilot no escribe código; dirige cómo se escribe.
Para explicarlo de forma digerible, voy a utilizar un ejemplo que mezcla técnica seria con un contexto amable: construir un pequeño juego retro 2D usando un agente principal y un escuadrón de subagentes.
Pero ojo: aunque usemos un juego como hilo conductor, la arquitectura es idéntica a la que usarás en automatización real, extensiones AL, pipelines internos o herramientas basadas en MCP.
Vamos al lío.
Un agente principal con mirada larga, no con prisas cortas
El agente principal —llamémosle RetroGameDesigner— se define en un .agent.md dentro de .github/agents/.
Ese archivo es su ADN: qué sabe hacer, en qué lenguaje trabaja, qué herramientas puede utilizar, qué modelo ejecuta, qué límites tiene y cómo debe comportarse.
Su trabajo no es “hacer cosas”: es coordinar.
Tú le lanzas:
“Quiero un shooter espacial retro, estilo 8-bit, con niveles cortos.”
Y su responsabilidad es:
- Interpretar la intención real del prompt.
- Establecer el lenguaje objetivo y la arquitectura base (C#, JS, lo que marque tu proyecto).
- Decidir qué partes deben resolver subagentes especializados.
- Mantener la coherencia entre todos los outputs.
- Revisar, ensamblar y preparar la siguiente fase.
Es decir: es un director técnico digital.
Subagentes: especialistas sin síndrome del “yo me lo guiso, yo me lo como”
Aquí está el corazón del patrón multi-agente:
cada subagente solo ve lo que necesita, solo hace lo que tiene asignado, solo opera dentro de su contexto.
Ejemplo de reparto:
GameLoop Agent
Especializado en mecánicas, físicas 2D, entidades básicas y el bucle principal del juego.
No opina del diseño de niveles. No toca refactors. No genera tests.
LevelDesigner
Su mundo es la geometría, la progresión y la configuración de niveles.
Nunca implementa lógica de gameplay.
Refactorer
Su trabajo es limpiar, reorganizar, aplicar patrones y unificar estilo.
Nada de inventarse nuevas entidades.
Tester
Genera tests automatizados para validar reglas y colisiones.
No refactoriza ni implementa.
Este reparto es lo que hace que el conjunto sea robusto.
No hay solapamientos, no hay ruido, no hay improvisación.
El pegamento: runSubagent, la instrucción que permite repartir juego de verdad
El agente principal funciona como un orquestador. Cuando necesita ejecución especializada, activa un subagente mediante por ejemplo:
**Delegate Research**: Use `#runSubagent` to invoke the **al-planning-subagent** for comprehensive context gathering.
Esa instrucción define:
- Qué agente se invoca.
- Qué contexto exacto recibe.
- Qué archivos debe abrir o ignorar.
- Qué formato debe devolver.
- Qué límites tiene en esa operación.
De repente, tu workspace se convierte en un sistema coordinado.
Copilot deja de reaccionar a instrucciones sueltas y pasa a ejecutar procesos.
Ejemplos reales:
- “Genera la física 2D del jugador y enemigos, sin tocar niveles.”
- “Construye tres niveles con dificultad creciente.”
- “Refactoriza todo el directorio
/src/sin alterar comportamiento.” - “Crea un set de tests para colisiones y reglas de daño.”
Tú defines etapas.
Copilot reparte juego.
Cómo se construye un agente en serio (VS Code + .agent.md)
El .agent.md permite un control quirúrgico:
Campos clave del frontmatter
description: qué hace el agente.tools: qué puede utilizar (search, edit, runInTerminal, MCP…).model: qué LLM ejecuta (Opus para decisiones, Sonnet para ejecución).target:vscodeo GitHub.handoffs: transiciones guiadas entre agentes.
Instrucciones internas
Aquí defines:
- Su voz.
- Sus límites.
- Su flujo de trabajo.
- Sus reglas mínimas.
- La forma exacta en que debe delegar a subagentes.
Cuando está bien definido, el agente ya no improvisa: opera como un componente más del sistema.
La capa seria: la arquitectura conductor–subagentes en el mundo real
Este ejemplo de juegos retro se parece mucho a cómo funciona una orquestación profesional.
De hecho, refleja exactamente los principios de la arquitectura conductor–subagentes explicada en tu documento técnico de referencia :
- El conductor piensa, planifica, decide, delega y valida.
- Los subagentes ejecutan tareas acotadas con mínimo privilegio.
- El workspace actúa como memoria viva del proceso.
- Tú mantienes control humano, revisas etapas y tomas decisiones finales.
Cambia “juego retro” por:
- Implementar autenticación OAuth.
- Crear un módulo AL en Business Central.
- Automatizar análisis de código.
- Construir pipelines inteligentes.
- Generar documentación técnica continua.
- Integrar MCP para exponer datos internos a Copilot.
La arquitectura es la misma.
Esto no va de juegos:
va de entender cómo va a funcionar el desarrollo en 2025 y más allá.
Un flujo real de trabajo en VS Code
- El usuario formula el objetivo.
- El conductor genera un plan con fases.
- Cada fase involucra uno o varios subagentes.
- Se ensamblan resultados en el workspace.
- El conductor pide revisión o itera.
- El usuario revisa, confirma o redirige.
- Se produce un entregable estable, revisado y modular.
Este patrón es escalable, auditable y mucho más fiable que pedirle a un único agente que haga todo en una sola generación.
Buenas prácticas para que tus agentes funcionen como un equipo profesional
- Minimiza herramientas por subagente.
Cuantas menos capacidades tenga, menos se desvía. - No mezcles roles.
Un subagente implementador nunca debe revisar. - Define outputs estructurados.
Nada de respuestas abiertas. - Usa modelos potentes solo para decisiones.
No quemes un Opus en una tarea repetitiva. - Crea contratos explícitos.
“Tú haces esto. Tú solo ves esto. Tú devuelves esto.” - Revisión humana obligatoria.
El sistema es bueno. Tú sigues siendo la autoridad.
Copilot no es un generador, es un director
Cuando entiendes cómo funciona esta arquitectura, te das cuenta de que el poder real no está en el autocompletado, sino en la orquestación.
Copilot no viene a sustituirte.
Viene a multiplicar tu capacidad con un equipo completo de subagentes que puedes diseñar, ajustar y evolucionar.
Y cuando controlas eso, literalmente repartes juego.
Cuando tengas tu primer equipo de subagentes funcionando, quiero verlo.
Promete.
Siguientes Pasos
Próximamente compartiré por mi canal de YouTube como implementar y estad atentos al blog para una version más técnica de este contenido introductorio.
Recordad esto porque ayuda mucho
Suscríbete al canal (anima y da ese empujón a todo esto).
Pulsa «like» si te ha gustado.
Si no quieres perderte nada, ya sabes, pulsa la campana.
En los comentarios déjame cualquier idea, duda, corrección o aportación. Todo será bien bienvenido.
Nota:
ES-El contenido de este artículo ha sido generado en parte con la ayuda de IA para revisión, orden o resumen.
El contenido, las ideas ,comentarios ,opiniones son totalmente humanas. Los posts pueden basarse o surge la idea de escribirse de otro contenido se referenciará ya sea oficial o de terceros.
Por supuesto ambas humana e IA pueden contener errores.
Te animo a que en los comentarios lo indiques, para más información accede a la página sobre responsabilidad AI del blog TechSphereDynamics.
EN-The content of this article has been generated in part with the help of IA for review order or summary.
The content, ideas, comments, opinions are entirely human. The posts can be based or arises the idea of writing another content will be referenced either official or third party.
Of course both human and IA can contain errors.
I encourage you to indicate in the comments, for more information go to the page on responsibility AI of the blog TechSphereDynamics.
Original Post https://techspheredynamics.com/2025/12/05/github-copilot-reparte-juego-con-subagentes/
