Cuando delegas tareas de código a un agente de IA, el flujo de trabajo cambia: ya no escribes líneas, sino que revisas, apruebas y coordinas. Aquí verás cómo gestionar un pull request creado por GitHub Copilot, qué validar antes de aprobarlo y por qué necesitas a otra persona para cerrarlo.

¿Qué pasa cuando Copilot termina un pull request?

La notificación llega directo al teléfono. No tienes que estar revisando el portal cada cinco minutos para saber si el agente terminó. En cuanto Copilot finaliza el trabajo del issue, te avisa y tú decides cuándo entrar a revisar.

Al abrir el pull request en estado draft, lo primero es ir a la pestaña de archivos cambiados. Ahí Copilot deja todo lo que tocó:

• Referencias agregadas dentro del proyecto SLN.
• Un proyecto nuevo de C Sharp llamado API test.
• Los archivos de unit tests solicitados en el issue.
• Un readme con la documentación de los cambios.

Ese readme es un detalle interesante. Copilot lo genera cuando el issue lo pide o cuando interpreta que el contexto lo necesita, lo que te ahorra escribir documentación a mano.

¿Qué debo revisar en un pull request creado por Copilot? Verifica los archivos modificados, lee la documentación generada, confirma que los unit tests pasaron y revisa la conversación del pull request donde Copilot deja evidencia de las pruebas ejecutadas.

¿Por qué no puedes aprobar tu propio pull request de Copilot?

Aquí viene el detalle que bloquea a muchos. Copilot ejecuta los cambios a tu nombre, así que aunque tú no escribiste el código, GitHub te considera el autor. Y nadie puede aprobar su propio código.

En la sección de reviewers y assignees notarás que apareces en ambos lados. Eso no funciona. La regla es simple: el autor no puede ser también el revisor que aprueba.

La solución es agregar a un tercer usuario como reviewer. En este caso, Marce entra al flujo. Tú dejas tu review changes con un looks good to me y haces submit review, pero el merge sigue bloqueado hasta que alguien externo apruebe.

¿Quién aprueba un pull request hecho por Copilot a mi nombre? Otra persona del equipo con permisos de reviewer. Tú no puedes generar y aprobar al mismo tiempo, así que asignas a un compañero para que valide y apruebe los cambios.

¿Cómo se cierra el merge después de la aprobación?

Una vez que Marce aprueba en cuatro minutos, el botón de merge pull request se desbloquea. El proceso final es directo:

1. Hacer clic en merge pull request.
2. Escribir un mensaje de confirmación del merge.
3. Confirmar la fusión.
4. Borrar la rama de trabajo.

Y listo. El pull request queda fusionado y cerrado sin que tú hayas escrito una sola línea de código. La inversión real fueron unos 30 o 40 minutos de espera mientras Copilot trabajaba en segundo plano.

¿Cómo cambia tu rol cuando Copilot escribe el código?

Tu trabajo deja de ser teclear y pasa a ser coordinar. Defines el issue, esperas la notificación, validas el pull request, asignas un reviewer externo y autorizas el merge. Es un flujo más cercano al de un tech lead que al de un desarrollador individual.

Esto también te obliga a diseñar tu equipo pensando en revisores disponibles. Si trabajas solo o con una sola persona, vas a depender de ella para cerrar cualquier pull request que Copilot genere a tu nombre. Sin un segundo par de ojos, el flujo se detiene.

¿Ya probaste delegar un issue completo a Copilot? Cuéntame en los comentarios cómo organizaste a tus reviewers para no quedarte bloqueado.