Un agente termina una función en la app de GitHub Copilot, pero antes de publicar quieres revisar el diff, tocar dos líneas y ejecutar el proyecto en tu máquina. Hasta ahora, muchos creadores resolvían esto abriendo otra ventana y reconstruyendo la conversación a mano. GitHub explica que una sesión de la app puede abrirse directamente en VS Code con el contexto, los cambios y el worktree asociados. El valor no es “seguir chateando” por sí solo: es poder inspeccionar lo que hizo el agente sin perder la historia de la decisión.

GitHub publicó el tutorial oficial el 19 de octubre de 2026. A continuación va un flujo de revisión para una app pequeña. Es una guía basada en la documentación oficial y un protocolo que puedes repetir; no afirmamos haber probado el traspaso en una cuenta propia.

Antes de empezar

Necesitas la app GitHub Copilot instalada e iniciada, VS Code conectado a la misma cuenta de GitHub, una sesión con cambios y permiso para trabajar y hacer push al repositorio. Comprueba esto antes de crear una tarea nueva: si la cuenta o los permisos no coinciden, el traspaso no te servirá para cerrar el pull request.

De la sesión al editor, sin reconstruir contexto

Abre la sesión en la app y revisa qué pidió el usuario, cuál era el plan del agente y qué archivos cambió. En la propia sesión selecciona Open in VS Code; si aparecen varias instalaciones del editor, elige la que usarás para probar. Según GitHub, VS Code abre el proyecto en el mismo worktree de esa sesión y muestra la conversación existente en la barra lateral de Copilot. Deberías ver juntas tres cosas: el historial de la tarea, el diff y el árbol de trabajo aislado.

Si cualquiera de esas piezas falta, detente y comprueba que abriste la sesión correcta. No copies cambios a otro checkout hasta entender qué rama y qué pull request están vinculados. Esa verificación evita el error frecuente de editar una copia local diferente y pensar que se actualizó la propuesta del agente.

Revisión útil para un vibecoder

En Source Control, lee los archivos modificados línea por línea. Pregunta: ¿el cambio resuelve el problema original?, ¿respeta las convenciones del repo?, ¿maneja estados vacíos y de error?, ¿incluye pruebas para el comportamiento cambiado?, ¿modificó archivos que no debía? La conversación preservada sirve para preguntar por una decisión concreta, no para sustituir la lectura del código. Puedes pegar este prompt en la misma sesión:

Explícame por qué modificaste esta función en vez de crear un helper.
Señala una ruta de error que tu cambio podría afectar.
No edites todavía: primero cita archivo y línea, y dime qué prueba lo detectaría.

El prompt es una sugerencia de revisión, no una instrucción oficial de GitHub. Si la respuesta no señala evidencia, inspecciona tú el código. Después realiza la corrección manual pequeña que necesitabas; el tutorial oficial indica que editas el worktree de la sesión, así que no tienes que copiar archivos entre carpetas.

Prueba local y cierre

Ejecuta los comandos que usa ese repositorio. En un proyecto JavaScript podrían ser npm test, npm run lint y npm run dev, pero no los ejecutes a ciegas si el proyecto usa otro gestor o carece de esos scripts. Para un cambio visual, comprueba escritorio y móvil, además de carga, vacío y error. Para una API, verifica al menos una entrada válida y una inválida. Guarda el comando y el resultado en el pull request: “funciona” no es evidencia suficiente.

Si el agente debe corregir algo repetitivo, pídeselo en la misma sesión con un alcance estrecho. Si el ajuste es de una línea, edítalo tú. Cuando termine, vuelve a mirar el diff completo y luego haz commit y push conforme al flujo del repositorio. GitHub indica que, al conservar el worktree y la rama vinculados, el push actualiza el pull request que ya sigue ese trabajo. Confirma el resultado en GitHub; no des por terminada la tarea solo porque la app diga que acabó.

Cuándo vale la pena

Este traspaso es especialmente útil si delegas la parte mecánica a un agente y necesitas control fino para revisar seguridad, diseño o comportamiento antes de enviar el cambio. Si la tarea es pequeña y ya estás en VS Code, abrir otra app quizá añada pasos. La decisión práctica es comparar la fricción de tu flujo real: tiempo hasta un diff revisable, pruebas pasadas y claridad del contexto. GitHub documenta la continuidad de la sesión; no promete que el código generado sea correcto.

Fuente: Kayla Cinnamon, GitHub Blog, 19 de octubre de 2026. La lista de comprobación y los prompts de revisión son propuestas de SoyJB.