En esta nueva entrega de nuestra serie “Hablemos de”, analizamos el paso de GitHub Copilot desde un sistema de sugerencias en el editor hacia un ecosistema agéntico que acompaña al desarrollador desde la planificación en terminal hasta la validación colaborativa en GitHub. Más que escribir código más rápido, la clave está en dominar un nuevo flujo de trabajo donde intención, contexto y ejecución se articulan de forma continua. En este artículo abordaremos las prácticas que permiten sacar el máximo partido a esa evolución.
El Dilema del Desarrollador Moderno: Fricción Cognitiva y Fatiga de Contexto
Como ingenieros senior, sabemos que el cuello de botella en el desarrollo no suele ser la velocidad de escritura, sino la fricción cognitiva. Perdemos horas valiosas en la «burocracia del código»: configurar entornos, depurar fallos de CI que no se replican localmente o navegar por una documentación fragmentada. Esta fatiga de contexto nos aleja de lo que realmente importa: la arquitectura y la resolución de problemas complejos.
A menudo, GitHub Copilot se percibe erróneamente como un simple autocompletador para el IDE. Sin embargo, para el desarrollador que busca la máxima productividad, Copilot ha evolucionado hacia un ecosistema de agentes interconectados que residen donde ocurre la acción: la terminal y el editor. Dominar este flujo no es solo una cuestión de «tipear menos», sino de adoptar un nuevo paradigma de ejecución programable.
Primero la Intención, luego el Código: El poder de /plan en la CLI
El desarrollo tradicional suele empezar con un scaffolding manual prematuro. El enfoque de «Intención Primero» utiliza la GitHub Copilot CLI para validar la arquitectura antes de escribir la primera línea de código, reduciendo drásticamente la «deuda técnica por omisión».
Mediante github-copilot-cli, el comando /plan (o el atajo Shift + Tab) nos permite entrar en un modo interactivo de resolución de problemas. En lugar de generar archivos al azar, el agente explora el espacio del problema, sugiere un stack tecnológico y esboza la lógica necesaria. Esta fase de planificación es crítica: permite al ingeniero actuar como un arquitecto que aprueba o ajusta el diseño antes de que el agente ejecute cualquier comando de creación.
Como bien señala la experiencia en flujos de trabajo de alto rendimiento:
«Copilot CLI es más útil cuando lo tratas como una herramienta de impulso, no como un reemplazo del juicio.» — Ari LiVigni.
La Regla de Oro: CLI para el Impulso, IDE para la Precisión
Para masterizar el ecosistema, debemos adoptar el modelo mental de «Un flujo, tres momentos». No todos los entornos son iguales, y forzar una tarea en el lugar equivocado genera ineficiencias.
- Terminal (CLI): Es el entorno de baja ceremonia y alto impulso. Ideal para probar ideas rápidas con /plan, generar un /diff inmediato o realizar cambios mecánicos y repetitivos en todo el repositorio (como refactorizaciones de nombres de variables).
- IDE: Es el espacio de la precisión técnica. Aquí es donde refinamos la lógica de negocio, gestionamos casos de borde (edge cases) y tomamos decisiones de diseño críticas que definen la mantenibilidad a largo plazo.
- GitHub: Es el destino de la colaboración duradera. Al usar comandos como /delegate, transformamos la intención local en un Pull Request formal, donde la IA ayuda en la revisión y las pruebas de CI validan el trabajo de forma asíncrona.
El Arte de las Instrucciones: Optimizando copilot-instructions.md
Para que un agente sea efectivo, necesita contexto. El archivo copilot-instructions.md a nivel de repositorio es nuestra herramienta para inyectar estándares de codificación y reglas de negocio. Sin embargo, existe un límite técnico crítico: el umbral de los 9,000 tokens.
Cuando las instrucciones exceden este límite, el modelo sufre de saturación del contexto, lo que provoca respuestas lentas, pérdida de instrucciones iniciales o bucles donde la IA repite tareas innecesariamente. Para evitar esto, aplicamos ingeniería de prompts a nivel de sistema:
- Modularización mediante Enlaces: En lugar de un archivo masivo, dividimos las reglas por dominios (ej. standards/typescript.md) y las referenciamos mediante enlaces de Markdown. Esto permite que Copilot cargue contextualmente solo lo que necesita («lazy-loading» de contexto).
- Diferenciación de Archivos: Es vital distinguir entre copilot-instructions.md (reglas globales para todo el repositorio) y AGENT.md (instrucciones específicas para el comportamiento y la lógica interna de un agente especializado).
- Auto-optimización: Podemos delegar al propio Copilot la limpieza de su contexto con un prompt como: «Optimiza este archivo para el uso de tokens, eliminando redundancias pero manteniendo los ejemplos de arquitectura esenciales».
Agentes, Skills y el estándar llms.txt
El ecosistema de GitHub Copilot ya no se limita a sugerencias dentro del editor: hoy permite extender sus capacidades mediante agentes personalizados, skills y mecanismos de integración que enriquecen el flujo de trabajo de desarrollo. La clave no está en construir todo desde cero, sino en componer capacidades especializadas allí donde aportan más valor. GitHub soporta este modelo a través de custom agents, agent skills y agentes conectados al stack técnico, tanto en CLI como en IDEs y, en determinados escenarios, también en GitHub.com.
Dentro de este enfoque, destacan tres piezas especialmente relevantes. La primera son los hooks y automatizaciones del ecosistema, que permiten estandarizar acciones repetitivas y reforzar la disciplina operativa del equipo. La segunda son los agentes de partners o integraciones externas, con los que Copilot puede actuar como punto de acceso a herramientas de infraestructura, observabilidad o plataformas de desarrollo. La tercera es el estándar llms.txt, pensado para que los modelos descubran de forma estructurada los recursos, agentes y capacidades disponibles en un repositorio o entorno, facilitando su consumo por sistemas compatibles.
La conclusión práctica es clara: GitHub Copilot empieza a comportarse menos como un asistente aislado y más como una plataforma extensible de ejecución asistida, donde el valor surge de combinar contexto, especialización y reutilización operativa.
Subagentes y Agent Squads: Orquestación Multiagente en GitHub Copilot
A medida que GitHub Copilot evoluciona desde asistente contextual hacia sistema de ejecución agéntica, aparece una capacidad especialmente valiosa para equipos de alto rendimiento: la posibilidad de descomponer el trabajo entre agentes especializados en lugar de concentrarlo todo en un único hilo monolítico.
En la GitHub Copilot CLI, este patrón ya existe de forma explícita. GitHub permite definir custom agents que se ejecutan como subagents, separados del agente principal y con su propia ventana de contexto. Esto permite delegar investigación, revisión o tareas especializadas sin contaminar el hilo principal, manteniendo la conversación de alto nivel limpia y enfocada. En términos de ingeniería, esto reduce ruido, mejora la precisión y crea una base operativa mucho más cercana a un modelo de agent squad que a un simple chat lineal.
En los IDEs, especialmente en VS Code, la evolución va incluso más lejos. GitHub Copilot en modo agente permite trabajar con custom agents, subagents y handoffs, es decir, transiciones guiadas entre agentes especializados. Esto habilita flujos como: un agente de planificación analiza el problema, otro agente de implementación ejecuta el cambio, y un tercero revisa calidad o seguridad antes de devolver el resultado al desarrollador. VS Code documenta además la ejecución de subagentes aislados y la posibilidad de correr varios en paralelo, acercando el entorno a una verdadera lógica de orquestación multiagente.
Ahora bien, no todas las superficies ofrecen exactamente la misma semántica. GitHub.com, a través del Copilot coding agent, sí soporta agentes personalizados y skills, pero algunas capacidades propias de IDEs, como handoffs, todavía no se trasladan de forma nativa al agente cloud de GitHub. Por eso, la estrategia más madura no consiste en asumir un único modelo universal, sino en diseñar una cadena de orquestación por entorno: el IDE para coordinación interactiva y precisión local; la CLI para delegación especializada y ejecución terminal; y GitHub para colaboración duradera, revisión y apertura de Pull Requests.
La pieza que termina de consolidar este enfoque son las Agent Skills. GitHub las define como carpetas con instrucciones, scripts y recursos que Copilot puede cargar cuando son relevantes, y especifica que funcionan en Copilot coding agent, Copilot CLI y agent mode en VS Code Insiders. Esto permite construir un catálogo reutilizable de capacidades para tareas recurrentes —por ejemplo, auditoría de seguridad, generación de documentación o validación arquitectónica— y activarlas solo cuando aportan valor. Desde la perspectiva de productividad, esto convierte a Copilot en una plataforma composable, no en un asistente estático.
En la práctica, un equipo puede estructurar un agent squad con una lógica como esta: Plan Agent → Explore Subagent → Implementation Agent → Review/Security Agent → Coding Agent para PR. De hecho, GitHub ya ha introducido un Explore subagent integrado para investigación paralelizada del código, memoria compartida entre CLI, coding agent y code review, y handoff entre coding agent y CLI para continuar una sesión localmente o devolverla a la nube. Todo ello apunta a una dirección clara: Copilot ya no es solo un generador de sugerencias, sino una base operativa para sistemas multiagente supervisados dentro del ciclo de ingeniería.
Iteración en el Punto de Falla: La Verdad de command
Uno de los errores más comunes es intentar que la IA solucione un error basándose solo en nuestra descripción. En la terminal, la clave es el uso del prefijo !.
Al ejecutar un comando como !npm test dentro de la sesión de Copilot, permitimos que el agente observe la salida real del sistema (Ground Truth). Esto es fundamental para evitar alucinaciones: el agente no está «adivinando» qué falló; está leyendo el stack trace exacto y el código de salida. A partir de ahí, el flujo explain para entender y suggest para aplicar la corrección se vuelve exponencialmente más preciso.
Precisión y Seguridad: Programación en Pareja, no Reemplazo
La IA en GitHub Copilot es un socio, no un piloto automático. La seguridad y la precisión dependen de un ciclo de retroalimentación activo:
- Validación de Salida: Todo código generado debe pasar por análisis estático y pruebas unitarias. La transparencia del agente (mostrar qué está haciendo) facilita esta revisión.
- Entrenamiento del Modelo: Al aceptar, modificar o rechazar sugerencias, estamos «entrenando» el contexto del agente sobre nuestro estilo personal y las convenciones del proyecto.
- Contexto Estructurado: Proporcionar firmas de funciones claras y comentarios detallados en el código actúa como un «ancla» que guía a la IA hacia soluciones más seguras y alineadas con la arquitectura deseada.
El Futuro de la Ejecución Programable
Estamos transitando de la «IA como texto» (simples diálogos) a la IA como ejecución. El flujo de trabajo completo, desde la intención en la terminal hasta la revisión en GitHub, es el activo más valioso de un equipo moderno.
Es crucial entender el rol del Copilot SDK: mientras que la CLI y el IDE ofrecen una experiencia integrada con toda la «memoria» y contexto de GitHub, el SDK nos permite construir estas capacidades agénticas dentro de nuestras propias aplicaciones. Sin embargo, el SDK funciona como un motor de ejecución pura, careciendo del conocimiento profundo de repositorio que ofrece el ecosistema estándar.
Al recuperar el tiempo invertido en tareas mecánicas gracias a estos agentes, la responsabilidad del ingeniero se desplaza hacia un nivel superior.
«Si la IA ahora puede planificar y ejecutar por nosotros, ¿en qué decisiones arquitectónicas críticas vas a invertir el tiempo que acabas de recuperar?»
En Raona ayudamos a las organizaciones a transformar la productividad de sus equipos de desarrollo mediante la adopción estratégica de IA, automatización y nuevos modelos de colaboración entre personas y agentes. Si tu objetivo es llevar GitHub Copilot más allá del autocompletado y convertirlo en una capacidad real dentro de tu ciclo de ingeniería, podemos acompañarte.
