English

Asigna tu backlog a Copilot, no a ti mismo

Tu backlog tiene cuarenta issues y tú tienes tiempo para dos. La mayoría de los otros treinta y ocho no son difíciles: solo son tediosos: subir la cobertura de pruebas en un módulo que nadie quiere tocar, arreglar un bug menor reportado, hacer un refactor mecánico. El coding agent de GitHub Copilot está hecho justo para esa brecha: le asignas un issue igual que se lo asignarías a un compañero de equipo, y trabaja la tarea en segundo plano mientras tú haces algo más interesante.

El problema: el trabajo síncrono no escala

Cada issue de un backlog compite por el mismo recurso — tu atención, una tarea a la vez. Incluso un arreglo genuinamente simple tiene un costo fijo: cambiar de contexto, leer el issue, abrir el repo, hacer el cambio, abrir un PR, esperar la revisión. Cuando hay más tareas pequeñas que atención para gastar en ellas, la mayoría simplemente se queda ahí. El coding agent de Copilot elimina el cuello de botella de "tu atención" para el subconjunto de issues que están lo bastante bien acotados como para que un agente los ejecute.

La solución: asigna el issue a Copilot

Abre un issue de GitHub, haz clic en asignar y elige a Copilot igual que elegirías a una persona. A partir de ahí, el trabajo sucede de forma asíncrona: Copilot empieza a trabajar la tarea en segundo plano y, cuando termina, abre un pull request para que lo revises. Puedes asignar más de un issue a la vez — los trabaja de forma independiente, en paralelo, en lugar de uno a la vez.

Qué pasa realmente después de asignarlo

Copilot no desaparece para reaparecer con un PR terminado — el proceso es visible en todo momento:

1. Aparece un pull request en borrador casi de inmediato, antes de que el trabajo esté terminado. No es un marcador de posición — es donde Copilot publica su plan.
2. El cuerpo del PR se actualiza en vivo con una lista de verificación en curso: Copilot expone su plan para abordar el issue y luego marca cada paso a medida que lo completa, para que puedas seguir el progreso sin molestar a nadie.
3. Una vista de sesión muestra las llamadas a herramientas reales del agente — leer package.json para entender el proyecto, correr la suite de pruebas, correr el linter y, en algunas configuraciones, traer contexto adicional a través de un servidor MCP (por ejemplo, un doc interno vinculado). Es el mismo tipo de transparencia que querrías de un colaborador humano narrando su trabajo en la descripción de un PR.

Dispararlo desde tu editor

No tienes que pasar por la interfaz de issues de GitHub. Desde VS Code, resalta el código relevante y pídele a Copilot Chat que abra un pull request para el cambio — Copilot te devuelve un enlace al PR resultante, sin que salgas del editor. Este es el camino más rápido cuando ya estás mirando el código y sabes exactamente qué hay que cambiar, en comparación con crear un issue primero.

Iterar sobre el resultado

Trata el PR en borrador como lo harías con uno de un colaborador humano: deja comentarios de revisión. Copilot toma los comentarios dejados en su propio PR y sigue iterando — no necesitas reasignar el issue ni empezar una nueva sesión, solo comenta donde querrías cambios y deja que responda.

Dónde vale la pena

El mejor encaje es el backlog para el que nadie tiene tiempo: deuda técnica aburrida, subir la cobertura de pruebas en un proyecto que ha sido descuidado, arreglos de bugs pequeños y bien definidos, refactors mecánicos. Es un encaje más débil para trabajo ambiguo y con mucho criterio — issues donde la mitad del esfuerzo es decidir qué construir, no solo construirlo. Reserva el coding agent para tareas que podrías describir sin ambigüedad en un par de frases; ahorra tu propio tiempo para las que no puedes.

Errores a evitar

• No asignes issues vagos. El agente trabaja a partir de la descripción del issue — un issue mal especificado produce un PR mal especificado. Escribe el issue como si estuvieras informando a un nuevo colaborador.
• Igual revisa el PR. El plan en vivo y la lista de verificación facilitan seguir el hilo, pero eso no sustituye leer el diff antes de mergear — trata el PR de Copilot con el mismo escrutinio que darías al de cualquier colaborador.
• Verifica la disponibilidad actual de plan/tier antes de depender de ello. El acceso al coding agent ha estado ligado a niveles de suscripción específicos de Copilot, y los detalles de disponibilidad cambian a medida que GitHub extiende la función — confirma qué incluye tu plan actualmente en lugar de asumirlo.

Conclusión

Asignarle un issue a Copilot no es "dejar que la IA escriba mi código" en el sentido vago — es un flujo de trabajo específico y observable: asignar, ver aparecer un PR en borrador con un plan en vivo, revisar el diff y comentar si necesita ajustes. Úsalo para despejar el backlog que nunca llegarías a hacer por tu cuenta, y gasta tu propia atención en los issues que realmente la necesitan.

Recursos

• GitHub Docs — About Copilot coding agent