Si hoy trabajas con agentes de programación con IA, conoces la rutina: abres una sesión, la revisas, abres la siguiente y mantienes tú solo la visión de conjunto. El 28 de octubre de 2026, GitHub anunció para la aplicación GitHub Copilot una función que intenta quitarte ese trabajo de coordinación. Se llama Projects y ya está disponible en versión preliminar pública.
Qué son realmente los Copilot Projects
Un proyecto le da a Copilot un objetivo continuo en lugar de una sola tarea. Según el registro de cambios de GitHub, un proyecto reúne en un solo lugar el contexto, los agentes y los resultados de un trabajo. Describes el objetivo y añades contexto, como repositorios, bocetos de diseño o hilos de Slack. Copilot ejecuta entonces tantos agentes como necesite el trabajo y te devuelve resultados, por ejemplo pull requests, para que los revises. Un pull request es un conjunto de cambios de código propuestos que puedes revisar antes de integrarlos.
La diferencia con una sesión normal es el alcance. Una sesión se ocupa de una tarea, normalmente en un repositorio, el lugar donde vive el código de un proyecto. Un proyecto puede abarcar un repositorio, varios o ninguno. La documentación de GitHub da ejemplos como agrupar comentarios de clientes por temas sin tocar el código. Para una tarea concreta en un solo repositorio, GitHub sigue recomendando abrir la sesión directamente desde ese repositorio.
Cómo se configura un proyecto
Según la documentación, la configuración tiene cinco pasos. En la barra lateral, haz clic en el icono de suma junto a Projects para abrir la página New project. Si quieres, elige qué repositorios usará el proyecto, o sáltate este paso. En el cuadro de texto, describe cuatro cosas: el propósito, las primeras tareas, los resultados esperados y las restricciones, es decir, las reglas que Copilot debe seguir. Si lo necesitas, añade archivos o carpetas en la pestaña Library. Después envía el prompt y Copilot empieza a trabajar.
GitHub también aconseja dar a cada proyecto un único objetivo concreto, para que las tareas y los resultados relacionados queden juntos. Parece una cuestión de orden, pero importa: un objetivo vago da a los agentes un blanco vago, y las correcciones las pagas después.
Cómo seguir el trabajo de muchos agentes
Un proyecto tiene cuatro partes: las sesiones, que son las unidades de trabajo que inicia Copilot; los repositorios, opcionales; las automatizaciones; y una Library. La Library se divide en Agent, para el material que genera Copilot, y User, para el que añades tú. Así siempre sabes quién ha producido qué.
La pestaña Overview ordena todo el trabajo por estado en cuatro grupos. Needs input reúne decisiones, revisiones y solicitudes de permiso que esperan tu respuesta. Open muestra el trabajo con un pull request abierto, con el estado de la sesión y las líneas añadidas y eliminadas. Working enumera las sesiones en marcha y Done, el trabajo terminado. Si una sesión va en la dirección equivocada, la abres desde Overview, revisas la conversación, los cambios, el pull request y el plan, y usas Steer this session para darle nuevas indicaciones. También puedes enviar una tarea de seguimiento en el proyecto, o volver más tarde, añadir material nuevo y pedirle a Copilot que lo compare con lo que encontró antes.
Qué hacen las automatizaciones de proyecto
Las automatizaciones son tareas recurrentes dentro de un proyecto. En el cuadro de texto del proyecto describes la tarea y cuándo debe ejecutarse, y respondes a las preguntas que te haga Copilot. La pestaña Automations muestra después la programación y la próxima ejecución. Desde su menú de opciones puedes pausar una tarea hasta reanudarla, editar la programación o eliminarla. Si quieres cambiar lo que hace la tarea, basta con pedírselo a Copilot en la conversación del proyecto. El ejemplo de GitHub: crear un vídeo promocional cada vez que llega una nueva función.
Nuestra valoración: ¿quién revisa al final?
Los hechos son claros: GitHub lleva Copilot de ejecutar tareas sueltas a coordinar un objetivo. Lo más útil, a nuestro juicio, no es el número de agentes, sino el grupo Needs input y la separación entre Agent y User en la Library. Hacen visibles los puntos de control humanos. Ahí sigue estando el trabajo de verdad, porque un pull request creado por un agente es una propuesta, no una prueba de que el código hace lo que querías.
Primero, aislemos el cambio. Antes de dar un objetivo a varios agentes, escribe qué debe hacer el resultado final y cómo lo vas a comprobar. Nuestra conclusión: cuantos más agentes trabajen en paralelo, más se convierte tu revisión en el cuello de botella. Un primer prompt preciso y la costumbre de mirar primero Needs input valen más que cualquier agente adicional.
Lo que aún no está claro
Projects es una versión preliminar pública y, según la documentación de GitHub, la función puede cambiar. Ni el registro de cambios ni la documentación indican qué planes incluyen Projects, cuántos repositorios, sesiones o automatizaciones puede tener un proyecto ni cómo cuenta ese trabajo en el uso o la facturación. Si lo pruebas, empieza con un proyecto pequeño y de un solo objetivo, y observa cómo se comporta antes de ampliarlo.
