GitHub Copilot: autocompletado, chat y el agente de la nube
GitHub Copilot sugiere código, ofrece chat y un agente en la nube que abre pull requests. Qué incluye cada plan, sus límites y cómo revisar lo que entrega.
¿Qué hace el agente de la nube?
Según la documentación oficial, el agente investiga el repositorio, planea cambios e implementa en segundo plano. Edita archivos y corre pruebas y linters en un entorno de desarrollo efímero en la nube, no en tu IDE local. También se encarga de crear la rama, escribir el mensaje de commit y subir los cambios.
Puedes iniciarlo desde el panel de agentes, desde una conversación de chat o desde un issue o pull request en GitHub.com. La documentación también lista GitHub Mobile, varios IDEs, la CLI de GitHub, la API REST y integraciones con herramientas como Jira, Slack, Microsoft Teams y Linear. Puede abrir el PR desde el inicio, o después de que revises los cambios y pidas ajustes.
Es el mismo patrón de otros agentes en segundo plano, y existen alternativas como Claude Code: un agente de programación que trabaja en tu repo, Cursor: el editor con IA y su modo agente y Codex: el agente de programación de OpenAI.
¿Por qué le importa a un diseñador?
Porque permite delegar una tarea pequeña y bien definida sin abrir el editor. Por ejemplo, cambiar el texto de un estado vacío o ajustar un componente según una nota. Lo que vuelve el trabajo revisable es el pull request: ahí puedes comparar el resultado contra el diseño, pedir cambios en comentarios y aprobar solo cuando esté bien. Si no conoces ese flujo, empieza por ramas y pull requests.
La documentación oficial es explícita en un punto que conviene recordar: los registros de sesión muestran el trabajo y las herramientas usadas, pero no reemplazan tu revisión y tus pruebas. Un PR sin revisar es un riesgo, no un entregable.
¿Qué planes incluyen qué?
Según la página de planes de GitHub consultada el 20 de octubre de 2026:
| Plan | Mensual (USD) | Agente de la nube | Créditos de IA |
|---|---|---|---|
| Free | 0 | No incluido | Límite de 2000 completados y 50 solicitudes de chat |
| Pro | 10 | Incluido | 10 base más 5 flexibles (15 en total) |
| Pro+ | 39 | Incluido | 39 base más 31 flexibles (70 en total) |
| Max | 100 | Incluido | 100 base más 100 flexibles (200 en total) |
| Business y Enterprise | No mostrado | No indicado en la tabla | Los administradores fijan límites de uso |
Un crédito de IA equivale a 0,01 dólares. Según la misma página, los completados de código y las sugerencias de siguiente edición no consumen créditos. Para Business y Enterprise la página no muestra precios y remite a contacto con ventas; consulta con tu administrador si el agente está habilitado. Delegar tareas a agentes de terceros aparece como vista previa, no incluida en Pro e incluida en Pro+ y Max. Los precios y las condiciones cambian, así que revisa la página antes de decidir.
¿Cuáles son sus límites?
- Un repositorio por tarea. Solo hace cambios en el repositorio indicado al iniciar la tarea.
- Una rama a la vez y un PR por tarea.
- 59 minutos como máximo por sesión, que no se pueden extender ni evitar. En el archivo
copilot-setup-steps.ymlpuedes fijar un tiempo menor contimeout-minutes, con máximo 59. - Solo GitHub. El repositorio debe estar alojado en GitHub.
- Permisos. Los dueños y administradores del repositorio pueden desactivar el agente. Si un conjunto de reglas (ruleset) bloquea su acceso, un administrador puede agregar a Copilot como actor con excepción.
- Errores posibles. La documentación advierte que el código puede ser incorrecto o subóptimo, incluso con vulnerabilidades de seguridad, así que hay que revisarlo y probarlo antes de producción.
¿Cómo se revisa lo que entrega?
- Lee el PR completo, no solo el resumen. Abre la vista previa y compárala con el diseño.
- Pide cambios en un comentario mencionando
@copiloten el PR, o sube tus propios commits a la rama. - Aprueba la ejecución de los workflows. Por defecto, los workflows de GitHub Actions no se ejecutan solos cuando Copilot sube cambios a un PR: alguien debe pulsar “Approve and run workflows”. Revisa antes los cambios, sobre todo si tocan
.github/workflows/. - Deja instrucciones en el repositorio. Un archivo
.github/copilot-instructions.mdguarda convenciones del proyecto, y el agente puede usarlo para trabajar con más contexto.
Más criterios en revisar PRs de agentes.
¿Cuándo NO conviene?
- Cuando la tarea es ambigua. Un agente de fondo con una instrucción vaga produce un PR difícil de revisar.
- Cuando el proyecto no vive en GitHub.
- Cuando la tarea necesita coordinar varios repositorios a la vez.
- Cuando no vas a revisar el PR con calma. Delegar sin revisar traslada el riesgo a producción.
Ejemplo
Ejemplo ilustrativo: un diseñador necesita que el estado vacío de la lista de proyectos use el componente EmptyState y el texto que aprobó. Abre un issue con el texto exacto, el enlace al componente y la captura del diseño, y asigna el agente de Copilot. El agente abre un PR en una rama. El diseñador lo revisa, compara la captura con el resultado, pide un cambio en el espaciado mencionando @copilot en un comentario y aprueba cuando coincide.
Lo que queda para ti: la comparación con el diseño y la decisión de aprobar, que ningún agente puede tomar por ti.
Errores comunes
- Asignar tareas vagas como “mejora la pantalla” sin criterio de aceptación.
- Aprobar el PR porque los tests pasaron, sin mirar la pantalla.
- Asumir que el agente conoce tu sistema de diseño sin documentarlo en el repositorio.
- Olvidar aprobar la ejecución de los workflows y creer que las pruebas pasaron cuando no corrieron.
- No revisar la configuración del repositorio, que puede bloquear o limitar el agente.
- Olvidar que el plan y las políticas de la organización determinan si el agente está disponible.