GitHub Copilot se ha ganado un lugar en el corazón de muchos desarrolladores, y con razón. A menudo se le describe como un ‘programador par’ de IA, un miembro más del equipo que puede encargarse de tareas de programación. Con funcionalidades como ‘coding agent’, puedes asignarle incidencias a Copilot y este trabajará diligentemente en segundo plano para crear una propuesta de solución, ¡y todo sin pedir ni una taza de café!
La configuración inicial de Copilot coding agent se asemeja bastante a la incorporación de un nuevo desarrollador: proporcionar buena documentación y simplificar el proceso de configuración. Pero, al ser una IA, Copilot tiene algunas características que lo hacen único como miembro del equipo (aparte de no necesitar cafeína).
En este artículo, exploraremos cómo lograr que Copilot se integre a tu equipo. Analizaremos el flujo de trabajo de Copilot coding agent y las estrategias clave para garantizar que Copilot tenga los recursos necesarios para generar el mejor *pull request* posible.
Flujos de trabajo “Agentic” en GitHub Copilot: Coding Agent vs. Agent Mode
GitHub Copilot ofrece dos capacidades clave de tipo ‘agentic’: *coding agent* y *agent mode*. Piensa en *coding agent* como una herramienta autónoma: le asignas un problema a Copilot, este pone en marcha un contenedor de Actions, itera en segundo plano y te devuelve un *pull request* (PR). *Agent mode*, por otro lado, es como tener un compañero interactivo en el editor o en github.com que ejecuta tareas más pequeñas y de varios pasos contigo en tiempo real. Es el mismo cerebro, pero con un modelo de interacción diferente: uno es asíncrono y orientado a *pull requests*, mientras que el otro es conversacional e inmediato.
El Flujo Interno de Copilot Coding Agent: De la Incidencia al Pull Request Listo para Revisar
Cuando le asignas una incidencia a Copilot, este sigue un patrón establecido:
- Crea una rama para el código que va a generar.
- Crea un *pull request* para hacer seguimiento de su trabajo y comunicarse con el equipo.
- Crea un entorno aislado para su trabajo (ejecutándose dentro de GitHub Actions).
- Lee la incidencia o *prompt* para entender la tarea solicitada.
- Explora el proyecto para determinar el mejor enfoque para abordar el problema.
- Trabaja iterativamente hacia una solución.
- Finaliza su trabajo, actualiza el *pull request* y notifica al equipo que el *pull request* está listo para ser revisado.
Comprender este flujo te permite configurar Copilot para el éxito.
Los dos primeros pasos (crear el *pull request* y la rama) son autónomos y no requieren ninguna acción adicional por nuestra parte para ayudar a Copilot.
Así que, pasemos directamente al tercer paso: el entorno. Aquí es donde podemos configurar todo lo que Copilot pueda necesitar en el entorno donde escribirá el código y ejecutará las tareas mientras genera el *pull request*.
Configura el Entorno de Copilot con GitHub Actions
Siguiendo con la analogía de la incorporación de un nuevo desarrollador, pensemos en el entorno en el que GitHub Copilot (o cualquier desarrollador) realiza su trabajo. Antes de poder ser productivo, necesitas tener instalados servicios, bibliotecas y *frameworks* específicos.
Con Copilot ocurre exactamente lo mismo. Para que Copilot pueda añadir una nueva funcionalidad y ejecutar las pruebas necesarias para garantizar que todo funciona, necesita acceso a todas las herramientas que utiliza el resto de tu equipo. Esto lo haremos con un archivo de *workflow* personalizado.
Coding agent utiliza un contenedor que se ejecuta dentro de GitHub Actions. Si aún no estás familiarizado con Actions, es nuestra plataforma de automatización y se configura mediante archivos YAML, que describen las tareas necesarias que deben completarse.
Actions se utiliza a menudo para CI/CD, es decir, para tareas como pruebas, despliegue, etc. En este caso, Actions aloja el contenedor que coding agent utilizará para su trabajo. ¡Y podemos aprovechar la capacidad de programar tareas en YAML para asegurarnos de que dicho contenedor esté configurado correctamente!
💡 Consejo Pro: Es muy probable que ya tengas un *workflow* para crear un entorno, que podrías utilizar para el desarrollo (por ejemplo, el que se utiliza al ejecutar varias pruebas o scripts de validación). ¡Puedes reutilizar esos *workflows* para el entorno de Copilot coding agent!
Ejemplo de archivo de *workflow* de configuración de Copilot
Para ello, crea un nuevo archivo de *workflow* ubicado en `.github/workflows/copilot-setup-steps.yml` con un trabajo titulado `copilot-setup-steps`. Dentro del trabajo, enumera todos los pasos para instalar los requisitos necesarios para el entorno. Digamos, por ejemplo, que estamos construyendo una aplicación en Python que utiliza SQLite. Podríamos tener un archivo de *workflow* como el siguiente, que se ejecutará para configurar el entorno para Copilot:
name: "Copilot Setup Steps"
# Automatically run the setup steps when they are changed
# Allows for streamlined validation,
# and allow manual testing through the repository's "Actions" tab
on:
workflow_dispatch:
push:
paths:
- .github/workflows/copilot-setup-steps.yml
pull_request:
paths:
- .github/workflows/copilot-setup-steps.yml
jobs:
# The job MUST be called `copilot-setup-steps`
# otherwise it will not be picked up by Copilot.
copilot-setup-steps:
runs-on: ubuntu-latest
# Permissions set just for the setup steps
# Copilot has permissions to its branch
permissions:
# To allow us to clone the repo for setup
contents: read
# The setup steps - install Python and our dependencies
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Set up Python
uses: actions/setup-python@v4
with:
python-version: "3.13"
cache: "pip"
- name: Install Python dependencies
run: pip install -r requirements.txt
- name: Install SQLite
run: sudo apt update && sudo apt install sqlite3
Cada vez que se asigne una incidencia a Copilot, este ejecutará este *workflow* para configurar su entorno y tener todo lo que necesita.
💡 Consejo Pro: Si sabes que algo debe hacerse de una manera particular, ¡díselo a Copilot! En nuestro ejemplo anterior, Copilot podría instalar los servicios necesarios por sí solo. Sin embargo, hacerlo podría llevar a versiones inesperadas u otros errores. Como siempre me gusta bromear, no seas pasivo-agresivo con Copilot. 😀
Prepara a Copilot Para el Éxito con Incidencias y *Prompts* Bien Redactados
Hablando de no ser pasivo-agresivo, ahora es el momento perfecto para centrarnos en el siguiente paso que sigue Copilot: leer la incidencia. Este será el punto de partida de Copilot para crear el *pull request* que revisarás más adelante. Recuerda que cuanto más claramente se defina la incidencia, mejor será la calidad del *pull request*.
El mejor enfoque es pensar en cómo te gustaría ver la primera incidencia que te asignan en un nuevo proyecto. Lo más probable es que agradecerías lo siguiente:
- Una declaración del problema o *user story* claramente definida.
- Si es un error, el mensaje de error completo, el *stack trace* o la salida, y los pasos para reproducir el problema.
- Cualquier historial relevante o enfoques que se hayan probado anteriormente.
- Sugerencias sobre cómo abordar el problema.
Lo mismo ocurre con Copilot. Digamos que necesitas migrar un conjunto de pruebas de unittest a pytest. Claro, Copilot probablemente podría encontrar el mejor enfoque por sí solo, pero dedicar un par de minutos a redactar una buena incidencia contribuye en gran medida a garantizar que el PR de Copilot sea aceptado e incorporado a tu base de código.
Aquí tienes un ejemplo de una buena incidencia (¡tanto para los desarrolladores como para Copilot!):
Título: Migrar pruebas del servidor de unittest a pytest
Cuerpo:
Buscamos migrar de unittest a pytest para aprovechar algunas características específicas de pytest.
Requisitos:
- Se creará una nueva carpeta llamada `migrated_tests` con las nuevas pruebas de pytest.
- Todas las pruebas unitarias existentes se reescriben utilizando el estilo pytest en la carpeta `migrated_tests`, manteniendo exactamente la misma funcionalidad y cobertura de código.
- Se actualiza la documentación, destacando la migración y los pasos necesarios para ejecutar las nuevas pruebas.
- Todas las nuevas pruebas pasan.
Recursos existentes:
- Todas las pruebas existentes se encuentran en `server/tests`
- Hay un script en `scripts/run-server-tests.sh` que se utiliza para ejecutar pruebas y generar informes de cobertura de código
Enfoque recomendado:
- Explorar las pruebas existentes para determinar su funcionalidad
- Leer los informes de cobertura para determinar la cobertura de código existente
- Recrear las pruebas una por una, probando a lo largo del camino, para garantizar la compatibilidad
- Ejecutar todas las pruebas al final para garantizar que todo pasa
- Generar un informe de cobertura de código para demostrar que se ha mantenido la cobertura de código
- Generar documentación de la migración y cómo ejecutar las nuevas pruebas
Haz que Tu Repositorio Sea Acogedor (Para Desarrolladores e IA)
Sigamos con la analogía de incorporar a un desarrollador a un nuevo equipo y proyecto, algo que he hecho varias veces a lo largo de mi carrera.
Cuando me incorporo a un lugar nuevo, configuro mi portátil e intento superar mis nervios del primer día, porque sé que hay mucho trabajo por hacer. Dejando a un lado una conversación sobre mi ansiedad, exploremos todo lo que necesito hacer para ser productivo.
Primero, necesito averiguar dónde y cómo se debe crear mi código. ¿Cuál es la estructura del proyecto? ¿Cuáles son las reglas y directrices que deben seguirse? ¿Estamos usando tabulaciones o espacios? (La respuesta correcta, por supuesto, es espacios).
¡GitHub Copilot necesita saber estas mismas cosas! Afortunadamente, las mejores prácticas estándar en torno a la documentación y la estructura del proyecto ayudarán a Copilot de la misma manera que ayudan a los desarrolladores.
💡 Consejo Pro: Comprender cómo Copilot aborda los problemas puede ayudarte a mejorar cómo lo usas. Aquí te mostramos cómo hacerlo: En el PR que Copilot creó, verás un botón de “View session” que te muestra todo lo que Copilot hizo (o está haciendo si la sesión está actualmente activa). Esta es una excelente manera de validar el trabajo de Copilot y ver cómo aborda las tareas. Luego, puedes usar esta información para refinar aún más tu enfoque para asignar tareas y configurar el entorno de Copilot.
Optimiza la Estructura del Proyecto y la Documentación Para que Copilot Encuentre la Información Correcta Rápidamente
Digamos que asignamos una incidencia a Copilot y le pedimos que añada funcionalidad de búsqueda a una aplicación. Cuando Copilot asume una incidencia, lo primero que hace es explorar la base de código. Buscará archivos README y, a diferencia de este desarrollador, realmente lee la documentación para aprender sobre el proyecto antes de escribir código. Realizará búsquedas en la base de código de cualquier cosa relacionada con la interacción con la base de datos y leerá los archivos que descubra. Entonces se pondrá a trabajar.
Este es el mismo enfoque que probablemente adoptarías como desarrollador si te asignaran la tarea. Así que, garantizar que la estructura del proyecto tenga los recursos y las entidades para que sea lo más acogedor posible para los nuevos desarrolladores prepara a todos (incluidos tus compañeros de equipo de IA) para el éxito.
Esto incluye tener un README robusto y actualizado para el proyecto y los servicios, comentarios en el código para describir qué y cómo se realizan las operaciones, y buenas prácticas seguidas en la denominación de clases, funciones y variables. Además, tener una estructura de proyecto lógica que siga las mejores prácticas aceptadas en los nombres de las carpetas y las agrupaciones de entidades proporcionará un entorno más predecible para Copilot (y el resto de tu equipo).
Documenta el Conocimiento Institucional con Instrucciones Personalizadas de Copilot
Una de las mejores maneras de proporcionar orientación a Copilot es mediante el uso de instrucciones personalizadas. Las instrucciones personalizadas son justo lo que su nombre indica: un conjunto de instrucciones específicamente para Copilot. Pueden ser sobre las diversas reglas y directrices que tienes en torno al formato del código, o el conocimiento institucional que todos los desarrolladores “conocen inherentemente”, pero que no está escrito en ninguna parte.
Copilot coding agent admite dos tipos de archivos de instrucciones: `copilot-instructions.md`, que son para todo el repositorio y se aplican a todas las solicitudes, y `.instructions.md`, que pueden dirigirse a tipos de archivos específicos.
Archivos de instrucciones a nivel de repositorio
Los archivos de instrucciones a nivel de repositorio, almacenados en `.github/copilot-instructions.md` en la base de código, albergan notas que generalmente son relevantes para todas las solicitudes realizadas a Copilot. Algunas piezas clave de información para incluir serían:
- Una visión general de lo que estás construyendo y cómo lo estás construyendo
- Cualquier *user story* general
- *Frameworks* y bibliotecas en uso
- La estructura del proyecto, destacando los archivos y carpetas clave
- Directrices y reglas de codificación globales
En el ejemplo siguiente, observa cómo hemos comenzado con una rápida visión general de la aplicación, el flujo esperado para el usuario, los *frameworks* y las reglas, y los recursos disponibles.
# Classic arcade
This project hosts a classic arcade, themed after the 1980s 8-bit games.
## Standard player flow
1. Player opens app and sees list of games.
2. Player selects game to play.
3. Player sees a splash screen with the message "Insert quarter".
4. Player presses space to start game and plays game
6. After game ends, the "Game over" message is displayed.
7. The player score is checked against high scores. If the score is in top 10, user is prompted for their initials (3 initials).
8. High scores are displayed, and an option to return to the main menu to start over again.
## Frameworks
- Python `arcade` library is used for the arcade itself
- SQLite is used to store all scores
## Coding guidelines
- All games must inherit from `BaseGame`
- Python code should follow PEP8 practices, including docstrings and type hints
## Project structure
- `data`: Stores data abstraction layer and SQLite database
- `games`: Stores collection of games and `BaseGame`
- `app`: Stores core app components including menuing system
Todo lo documentado en el documento de instrucciones de Copilot anterior podría ser descubierto por Copilot a medida que realiza su investigación. Pero enumerar tus requisitos y recursos ayuda a garantizar que tenga la información correcta, especialmente porque es probable que haya código que se desvíe de las mejores prácticas aceptadas de tu organización.
Nota: El código de este autor siempre es perfecto, así que eso no es aplicable a mí, por supuesto. 😉
Archivos de instrucciones dirigidos
Obviamente, el código que reside en una prueba unitaria es muy diferente del código en una capa de abstracción de datos, que es muy diferente de … Si bien tener instrucciones para todo el repositorio es poderoso, normalmente también tenemos reglas en torno a tipos de archivos específicos. Copilot coding agent admite esto mediante el uso de archivos `.instructions.md`, que residen en la base de código en la carpeta `.github/instructions/` (o subcarpetas dentro de ella).
Estos archivos de instrucciones dirigidos pueden contener una sección `applyTo`, que te permite establecer un patrón glob para identificar los archivos a los que se deben aplicar las reglas. Siguiendo con el escenario anterior (construir una máquina arcade clásica), podríamos tener todos los juegos en una carpeta de juegos como archivos de Python. El patrón que usaríamos sería `**/games/*.py`. Dentro de esa sección, puedes añadir instrucciones específicas para estos archivos, como qué clase base heredar y cualquier requisito de prueba. Un ejemplo de `.github/instructions/game.instructions.py` podría ser el siguiente:
---
applyTo: **/games/*.py
---
## Resources and requirements
- All games inherit from `BaseGame`
- Unit tests are required for all games, focused on core functionality
- When adding a new game to the arcade ensure sample high scores are added to the database
## Arcade framework notes
- `rectangle` is always abbreviated as `rect` in the framework
- The `BaseGame` class contains numerous abstractions to streamline game creation
Observa cómo estamos enumerando los requisitos y los recursos. También añadimos una nota sobre que rectángulo se abrevia como rect, que está ahí para ayudar a Copilot con los errores comunes que podría cometer.
💡 Consejo Pro: Los archivos de instrucciones son una excelente manera de guiar a Copilot en la dirección correcta cuando ves que comete ciertos tipos de errores.
Una Reflexión Final Sobre los Archivos de Instrucciones
Invertir tiempo en crear un conjunto robusto de archivos de instrucciones ayudará a Copilot cuando lo uses en el IDE y cuando asignes tareas a Copilot coding agent. De hecho, es muy probable que ya estés familiarizado con los conceptos de esta sección si tienes experiencia con Copilot. Debido a que estos se convierten en artefactos en el proyecto, seguirán dando frutos tanto en productividad como en calidad de las sugerencias.
Extiende Copilot con MCP para Darle Más Contexto y Herramientas
Todos los desarrolladores necesitan una mano amiga en algún momento. Podría ser recuperar una discusión específica de tu repositorio de GitHub para obtener más información sobre la historia de una función, o buscar la sintaxis para implementar un algoritmo o bloque de código en particular.
Los agentes de IA pueden realizar estas tareas utilizando MCP, o Model Context Protocol. MCP es un estándar abierto de Anthopic diseñado para ayudar a la IA a conectarse a servicios y herramientas clave. Esto ayuda a los agentes de IA a ejecutar tareas en tu nombre, pero también te permite dar al modelo más contexto conectándolo a más fuentes de datos e información (¡como GitHub!).
Esta es la razón por la que esto importa: ¡GitHub Copilot puede usar servidores MCP! De forma predeterminada, hay dos servidores MCP disponibles cuando usas su agente de codificación: GitHub y Playwright. El primero permite a Copilot interactuar con tu repositorio, buscando incidencias y otra información, mientras que el segundo permite a Copilot generar pruebas de Playwright para pruebas de extremo a extremo o de aceptación.
Ejemplo: Servidor Azure MCP para la generación de Bicep
Tomemos Azure Bicep como ejemplo, que es un lenguaje específico del dominio (DSL) para definir recursos de Azure. Para hacer su mejor trabajo con un DSL, como Azure Bicep, Copilot se beneficia de una mano amiga virtual para generar el código. Afortunadamente, hay un servidor Azure MCP disponible que Copilot puede usar para obtener un poco de apoyo.
Si tu equipo ya está usando servidores MCP para el proyecto en VS Code, Copilot puede usar el archivo `.vscode/mcp.json` existente en tu proyecto para identificar los servidores MCP. De lo contrario, puedes configurar los servidores MCP específicamente para Copilot coding agent en la pestaña Configuración de tu proyecto, en Copilot y luego en Coding agent, donde tendrás un cuadro de texto para pegar el JSON.
Siguiendo con nuestro ejemplo de querer apoyar mejor la creación de Bicep, el JSON siguiente habilita el servidor Azure MCP mientras especifica que solo queremos el soporte del esquema Bicep.
{
"mcpServers": {
"AzureBicep": {
"type": "local",
"command": "npx",
"args": [
"-y",
"@azure/mcp@latest",
"server",
"start",
"--namespace",
"bicepschema",
"--read-only"
]
}
}
}
Gestiona el Acceso a Internet y los Riesgos de Exfiltración de Datos con el Cortafuegos de Copilot
Es posible que hayas notado que la opción `type` en el ejemplo de MCP anterior está establecida en `local`. Esto significa que se accederá al servidor dentro del contenedor sin que Copilot necesite contactar con un servicio externo. Pero esto también implica la posibilidad de un servidor remoto, lo que plantea la pregunta: ¿Se le permite a Copilot acceder a Internet? Y si es así, ¿cómo podemos controlarlo?
Copilot coding agent tiene un cortafuegos predeterminado, que limita eficazmente el acceso de Copilot a los servicios principales, como los servicios de alojamiento de paquetes como npm y pip. Esto te ayuda a gestionar los riesgos de exfiltración de datos. Por ejemplo, si de alguna manera se dan instrucciones maliciosas a GitHub Copilot, podría conducir a que el código u otra información confidencial se filtre a ubicaciones remotas.
Si estás añadiendo un servidor MCP remoto, o necesitas permitir que Copilot acceda a recursos de Internet, tendrás que actualizar el cortafuegos, lo que puedes hacer actualizando la lista de permitidos. Esto está disponible en la configuración de tu repositorio, dentro de Copilot, luego Coding agent (convenientemente, ¡esa es la misma pantalla que para configurar tus servidores MCP!).
¡Bienvenido al Equipo, Copilot!
Al igual que cualquier buen compañero de equipo, ¡GitHub Copilot coding agent prospera cuando está preparado para el éxito! Al invertir un poco de tiempo por adelantado para configurar su entorno, crear incidencias claras, optimizar tu proyecto y aprovechar las instrucciones personalizadas y los servidores MCP, empoderarás a Copilot para que ofrezca su mejor trabajo.
Con estos consejos en tu arsenal, estarás bien encaminado para obtener *pull requests* de mayor calidad de Copilot coding agent, y una experiencia de desarrollo más productiva.
¿Listo para ver la magia suceder? ¡Obtén más información sobre GitHub Copilot!
Referencia: GitHub
Leave a Comment