Dejar que el agente de Copilot escriba y suba código

A quién le sirve. Equipos y programadores con repositorios en GitHub que quieren asignar tareas pequeñas al agente de Copilot y revisar lo que devuelva.

Qué hicieron

Es un hilo de opiniones de la comunidad de GitHub sobre el agente de programación de Copilot, no un tutorial único. El autor original asignó incidencias al agente y lo vio trabajar. Un comentarista, BaljeetCyber, le dijo que subiera el código terminado al repositorio y luego que siguiera con toda la configuración sin volver a preguntar.

Cómo salió

El autor original vio que el agente entiende bien el contexto y el código, pero sus primeras propuestas eran flojas sin instrucciones y no podía leer adjuntos ni enlaces a propuestas de la organización. El comentarista cuenta que subió el trabajo a una rama, dejó main vacía y luego pasó horas revisando carpetas vacías.

Conviene saber

Configura las instrucciones de Copilot antes de la primera asignación y pega el contenido de los adjuntos directamente en la incidencia, porque el agente no pudo leer los archivos adjuntos.

Qué necesitas

• Una cuenta de GitHub con un plan de Copilot que incluya el agente de programación
• Un repositorio de prueba (la carpeta del código con su historial de cambios), mejor uno sin importancia
• Un archivo de instrucciones para Copilot con las normas del proyecto
• Incidencias bien escritas, con todo el texto dentro y sin depender de archivos adjuntos
• Alguien que revise las propuestas de cambio

Cómo hacerlo tú, paso a paso

1. Prueba primero en un repositorio sin importancia y protege la rama principal (la versión oficial del código) para que el agente no la toque.
2. Escribe las instrucciones de Copilot para el repositorio: estilo, estructura y cómo ejecutar las pruebas. Hazlo antes de asignar la primera tarea.
3. Escribe la incidencia con todo el contexto dentro. Pega el contenido de los adjuntos en el texto, porque el agente no pudo leerlos.
4. Asígnale la incidencia al agente de Copilot o pega el prompt de la ficha con el nombre de la rama.
5. Antes de que suba nada, pídele que te diga a qué rama va a subir y un resumen de los cambios.
6. Revisa la rama y la pull request (la propuesta de cambio). Comprueba que los archivos tienen contenido y que la rama principal sigue intacta.
7. Pide los cambios que falten con comentarios en la propia pull request.

En [propietario/repositorio], implementa [función o tarea]. Trabaja en una rama nueva llamada [nombre de la rama], no en main, y antes de subir nada enséñame la rama a la que vas a subir y un resumen de los cambios. Cuando yo lo apruebe, sube el trabajo y abre una pull request. Habrás terminado cuando me cuentes qué has subido y dónde.

Consejos

• No le des carta blanca con órdenes como «sigue sin preguntar». Un comentarista lo hizo y acabó revisando carpetas vacías durante horas.
• Sin instrucciones, las primeras propuestas suelen ser flojas. Dedica tiempo a las instrucciones antes que a corregir cada resultado.
• Empieza con tareas pequeñas y bien delimitadas.

Preguntas frecuentes

Fuentes

• orgs/community en GitHub ↗

En el directorio desde el 13 de octubre de 2026.