Dos modelos llegan a Copilot, pero su disponibilidad no responde a la pregunta esencial: ¿cuál ayuda realmente a su equipo a entregar un cambio correcto? Así puede preparar una comparación reproducible sobre sus propias tareas, sin fabricar un benchmark.
Lo que cambian los anuncios y lo que no demuestran
Dos fechas, un acceso que comprobar
GitHub anunció Gemini 3.8 Flash en Copilot el 3 de septiembre de 2026, y después la disponibilidad general de GPT-6 Astra el 4 de septiembre de 2026. En ambos casos, GitHub describe un despliegue gradual, planes elegibles y ajustes de administración propios del servicio. Son hechos anunciados, consultados el 9 de septiembre de 2026; no permiten afirmar que un modelo ya esté activado para cada cuenta.
| Modelo | Anuncio de GitHub | Acceso en su entorno |
|---|---|---|
| Gemini 3.8 Flash | 3 de septiembre de 2026 | No verificado |
| GPT-6 Astra | 4 de septiembre de 2026 | No verificado |
Por tanto, la primera acción es sencilla: anotar el plan, las políticas aplicables, el cliente utilizado y el modelo realmente seleccionable. Un registro fechado evita confundir un anuncio, una activación administrativa y una experiencia de desarrollo observable.
La disponibilidad no es una victoria en el benchmark
GitHub presenta sus propias evaluaciones en estos anuncios. Informan sobre cómo el editor posiciona el servicio; no sustituyen una comparación independiente en un repositorio, unas reglas de revisión y una cadena de integración continua determinados. El análisis de Partitech es, por tanto, el siguiente: la elección debe recaer en un cambio aceptado por el equipo, no en la fluidez de una conversación o una demostración aislada.
Construir un conjunto de tareas que se parezca al trabajo real
Cambios cortos con criterios de aceptación
Prepare tareas lo bastante pequeñas para revisarlas, pero lo bastante realistas para mostrar las limitaciones del proyecto. Por ejemplo: corregir una validación PHP que acepta un valor no válido; añadir un campo documentado a una respuesta de API sin romper los clientes existentes; reparar una prueba JavaScript que se ha vuelto inestable. Estos ejemplos son ficticios: describen un protocolo, no un resultado observado.
Cada tarea debe partir de un commit conocido, aportar el contexto estrictamente necesario, designar las pruebas dirigidas y definir el resultado esperado. «La prueba pasa», «no se modifica ningún archivo fuera del perímetro» y «la respuesta sigue siendo compatible» son criterios verificables. Una solicitud imprecisa, como «mejorar este módulo», no produce una unidad de comparación utilizable.
Hacer comparables las condiciones
Fije el commit, las dependencias, los permisos de las herramientas, el contexto transmitido y el presupuesto de generación. Separe las tareas ya conocidas de las que se reservarán para la evaluación, para que el equipo no adapte involuntariamente el protocolo a una respuesta anterior. Prevea varias pasadas cuando sea pertinente, sin convertir esa intención en un resultado antes de haber ejecutado realmente las pruebas.
Medir el resultado aceptado, no solo la respuesta producida
Una cuadrícula vacía es más honesta que una tabla llena de cifras decorativas. Registra lo que se ha constatado después de la ejecución, con las convenciones elegidas por el equipo.
| Tarea | Pruebas dirigidas | Defectos de revisión | Revisiones | Tiempo humano | Coste observado | Resultado |
|---|---|---|---|---|---|---|
| Por completar | No medido | No medido | No medido | No medido | No medido | No medido |
El coste por cambio validado puede seguirse así: (generación + revisión + repeticiones) / cambios aceptados. Hay que fijar lo que abarcan «revisión» y «repeticiones»: tiempo de ingeniería, ejecuciones facturadas, espera de CI o solo tiempo activo. Si no se acepta ningún cambio, el coste unitario sigue sin poder calcularse: conserve por separado los gastos y los fracasos. La fórmula ayuda a comparar pruebas documentadas; no predice ningún rendimiento.
Interpretar las diferencias sin sacar conclusiones excesivas
Clasifique los fallos antes de atribuirlos: error funcional, regresión, modificación fuera del perímetro, contexto incompleto o herramientas no disponibles. Una salida rechazada porque no se ejecutó una prueba no tiene el mismo significado que una corrección que incumple una regla de negocio. Si se publican pruebas, indique el tamaño del conjunto, las exclusiones y los límites de representatividad.
La decisión puede ser entonces condicional. Conserve un modelo para una familia de tareas si los cambios se aceptan regularmente y la revisión sigue siendo sostenible. Pruebe más si los resultados dependen mucho del contexto o varían de una prueba a otra. Limite su uso a un perímetro preciso si las repeticiones o las modificaciones fuera de tema se vuelven demasiado frecuentes. Esta matriz es una recomendación editorial, no una clasificación de GPT-6 Astra o Gemini 3.8 Flash.
Pasar de la prueba al seguimiento de versiones
Conserve los identificadores de versión, los prompts, las salidas, los comandos de prueba y los arbitrajes de revisión, excluyendo secretos y datos de clientes. Repita un subconjunto representativo después de una evolución sustancial del servicio, un modelo, sus dependencias o sus políticas. Este registro hace que una decisión pueda revisarse en vez de convertirla en una preferencia duradera.
El protocolo no responderá a todas las preguntas: por sí solo no mide la calidad arquitectónica a largo plazo ni el valor de negocio de una evolución. Sin embargo, permite decidir qué autorizar, qué observar y qué suspender basándose en pruebas locales. Para situar esta disciplina en el contexto más amplio de los agentes, consulte también nuestro análisis de los agentes cibernéticos críticos.
Elegir un modelo en Copilot equivale así a comprar una prueba local, no una promesa general. Verifique el acceso, fije las condiciones, mida los cambios aceptados y conserve los elementos que permitan volver a tomar la decisión.