GPT-6 Astra para delegar tareas largas en GitHub CopilotGPT-6 Astra para delegar tareas largas en GitHub Copilot

Delegar sin convertir la tarea en una caja negra

Hay cambios que no se resuelven bien con una sugerencia aislada en el editor. Añadir una funcionalidad en Laravel, ajustar migraciones, cubrir casos con tests y revisar el arranque de servicios en Compose exige recorrer varios archivos y validar decisiones intermedias. Para ese tipo de trabajo, lo relevante de GPT-6 Astra en GitHub Copilot no es el nombre del modelo, sino poder elegirlo al lanzar una tarea del agente en la nube. (github.blog)

GitHub publicó la disponibilidad general de GPT-6 Astra el 4 de septiembre de 2026. El modelo figura como disponible de forma general en la documentación de modelos compatibles de Copilot, aunque la aparición en cada cuenta puede depender del despliegue y de las políticas de la organización. No conviene asumir que todos los miembros de un equipo lo verán sin revisar antes la configuración de Copilot. (github.blog)

El agente en la nube trabaja en un entorno efímero basado en GitHub Actions. Puede examinar el repositorio, preparar un plan, modificar una rama y ejecutar pruebas o linters que estén disponibles en el proyecto. Eso no elimina la revisión del cambio, pero sí permite sacar del trabajo manual las tareas de preparación y comprobación más repetitivas. (docs.github.com)

Elegir el modelo cuando importa el recorrido

La selección de modelo no está disponible en cualquier sitio de Copilot. GitHub la documenta al asignar un issue a Copilot en GitHub.com, al mencionar a @copilot en un comentario de una pull request y al iniciar una tarea desde las superficies compatibles del agente, como la pestaña de agentes o el panel de agentes. Si no hay selector, Copilot utiliza Auto. (docs.github.com)

Mi criterio sería sencillo: elegir GPT-6 Astra cuando la petición tiene un objetivo delimitado, pero implica investigar el repositorio, tocar varias piezas y comprobar que no se ha roto el flujo existente. Para renombrar una variable, corregir una condición trivial o pedir una explicación, abrir una sesión autónoma es normalmente más trabajo que hacerlo directamente. Delegar bien empieza por no delegar tareas demasiado pequeñas.

El selector tampoco sustituye un encargo claro. Antes de seleccionar el modelo, hay que describir qué comportamiento se espera, qué rutas o servicios están afectados y cómo se puede validar el resultado. Si el repositorio contiene instrucciones propias, el agente puede usarlas como contexto para entender cómo construir, probar y revisar el proyecto. (docs.github.com)

Un encargo útil para una aplicación Laravel

En Laravel, una tarea razonable para el agente podría ser implementar una parte incremental de una funcionalidad, añadir pruebas de integración y comprobar que el cambio sigue funcionando dentro del entorno de desarrollo con Compose. El encargo debe indicar límites concretos: por ejemplo, no alterar contratos públicos, no introducir paquetes nuevos sin justificación y no tocar variables secretas ni ficheros de producción. También debe incluir el comando de pruebas que el repositorio considera válido.

Un comentario o descripción de issue puede plantearse así:

@copilot Implementa el filtro por estado en el listado de pedidos.
 
Revisa los patrones existentes en rutas, controladores y tests Feature.
Añade o actualiza las pruebas necesarias y ejecuta:
 
php artisan test --testsuite=Feature --stop-on-failure
 
No cambies la autenticación, no añadas dependencias y explica en la PR
qué archivos has modificado y qué casos has validado.

El comando php artisan test es el ejecutor de pruebas documentado por Laravel, y admite opciones que se pasan a Pest o PHPUnit, como --testsuite y --stop-on-failure. Dar ese punto de salida evita que el agente invente una definición de terminado basada solo en que el código compila. Aun así, que una batería de tests pase no demuestra por sí sola que la regla de negocio sea correcta. (laravel.com)

Compose también necesita condiciones verificables

En infraestructura Compose, pedir “arregla el arranque” deja demasiado espacio para interpretar. Es mejor expresar el síntoma, identificar el servicio dependiente y exigir una comprobación reproducible. Docker Compose permite declarar dependencias mediante depends_on y esperar una comprobación de salud usando la condición service_healthy. (docs.docker.com)

Este es un fragmento válido que sirve como base para pedir al agente que revise el orden de inicio. No es una receta universal para Laravel, pero sí deja claro qué relación entre servicios debe preservar o validar:

services:
  app:
    build: .
    depends_on:
      db:
        condition: service_healthy
 
  db:
    image: postgres:18
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: app
      POSTGRES_PASSWORD: change-me
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 10s
      timeout: 10s
      retries: 5
      start_period: 30s

En un repositorio real no pondría una contraseña en claro como solución final, aunque el ejemplo la use para mostrar la estructura. El encargo debería pedir que se respeten los mecanismos de secretos y las variables ya existentes en el proyecto. También pediría que no se cambien imágenes, versiones o puertos si no forman parte del problema descrito.

Ajustar el nivel de razonamiento

Al seleccionar modelos compatibles, Copilot puede mostrar un segundo selector para el nivel de razonamiento. GitHub explica que ese ajuste controla el tiempo y esfuerzo que el modelo dedica a razonar antes de responder; los niveles más altos pueden ayudar con tareas complejas, pero pueden tardar más y consumir más créditos de IA. (docs.github.com)

No usaría el nivel alto como valor por defecto para todo. Tiene sentido reservarlo para refactors con efectos cruzados, errores difíciles de reproducir o cambios que requieran seguir una cadena larga entre aplicación, pruebas e infraestructura. Para una tarea rutinaria y bien acotada, un nivel normal y unas instrucciones mejores suelen ser una combinación más sensata.

La documentación también recomienda el contexto y el razonamiento normales como opción predeterminada, elevándolos solo cuando la complejidad lo justifique. Es una regla práctica útil porque obliga a pensar en el coste de la sesión antes de convertir cada issue en una investigación extensa. El modelo no sabe qué nivel de detalle compensa para tu proyecto si no se lo impones mediante alcance y criterios de aceptación. (docs.github.com)

La letra pequeña que evita sorpresas

GPT-6 Astra no convierte Copilot en responsable del cambio. El agente puede hacer modificaciones y abrir o preparar una pull request, pero el equipo sigue teniendo que revisar el diff, entender las decisiones y comprobar los riesgos de seguridad, regresión y mantenimiento. GitHub también advierte que el código generado debe revisarse y validarse cuidadosamente antes de llevarlo a producción. (docs.github.com)

El agente trabaja sobre el repositorio desde el que se inicia la tarea. No puede modificar varios repositorios en una misma ejecución, y por defecto su contexto también queda limitado a ese repositorio. Si una aplicación Laravel depende de un paquete privado, un repositorio de infraestructura separado o documentación interna, hay que planificar explícitamente cómo proporcionar ese contexto. (docs.github.com)

También hay límites de acceso y de administración. El agente en la nube está disponible en planes de pago, pero en Copilot Business y Enterprise puede requerir que un administrador active las políticas correspondientes, y los propietarios del repositorio pueden deshabilitarlo. Que el modelo aparezca en una captura o en una nota de lanzamiento no garantiza que esté permitido en tu organización. (github.blog)

Por último, hay coste operativo. Las sesiones del agente consumen minutos de GitHub Actions y créditos de IA, según el modelo y los tokens procesados. Antes de asignarle tareas largas, conviene comprobar que el pipeline de pruebas es fiable, que el entorno se puede levantar sin intervención manual y que el resultado tendrá una revisión humana con contexto. (docs.github.com)

Una definición de terminado que se pueda revisar

Para aprovechar este tipo de modelo, yo empezaría con issues pequeños pero completos. Un buen primer caso es uno que tenga comportamiento observable, tests existentes cerca del cambio y una pull request que pueda revisarse sin necesitar conocimiento tácito de media empresa. Si el agente necesita cinco preguntas para empezar, el problema suele estar en el issue, no en el modelo.

También separaría implementación y decisión de arquitectura. El agente puede investigar alternativas y proponer un plan antes de escribir código, pero las decisiones que cambian límites entre servicios, contratos o datos merecen una aprobación explícita. GitHub permite precisamente usar el agente para investigar, planificar e iterar antes de crear una pull request. (docs.github.com)

GPT-6 Astra encaja cuando el objetivo es entregar una primera versión revisable de un cambio con recorrido, no cuando se busca automatizar el criterio técnico. En Laravel y Compose eso significa pedir implementación, pruebas y validación con límites claros, y tratar la pull request resultante como trabajo de un colaborador que todavía necesita revisión. Esa es la parte que hace útil al agente sin delegarle una confianza que no se ha ganado.

Fuente: GitHub Changelog sobre GPT-6 Astra Documentación oficial: Changing the AI model for GitHub Copilot cloud agent