Copilot Auto: cómo evaluar coste y calidad en tu equipo

El 14 de septiembre de 2026, GitHub anunció tres preferencias para Copilot Auto: efficiency, balance e intelligence. Orientan la selección hacia coste, equilibrio o calidad, respectivamente. El despliegue abarca VS Code, Copilot CLI y la aplicación de Copilot; la facturación sigue dependiendo del modelo elegido.

Para un equipo de ingeniería, la pregunta útil es qué trabajo conviene asignar a cada preferencia y con qué evidencia aprobar el resultado. Un cambio de configuración puede ser rápido; descubrir que el ahorro aparente se perdió en revisiones, correcciones o incidentes tarda bastante más. Por eso conviene diseñar el experimento antes de extender una preferencia a todo el equipo.

La documentación de Auto explica que el enrutamiento considera complejidad y disponibilidad, dentro de los modelos permitidos por el plan y las políticas. Elegir intelligence no fija necesariamente un modelo grande para todas las peticiones. Esta distinción impide interpretar el nombre del nivel como una especificación técnica reproducible por sí sola.

Nuestra recomendación es mantener tres decisiones explícitas: qué capacidad solicitar, qué herramientas puede ejecutar el agente y quién acepta el cambio. Una tarea barata de generar puede tener consecuencias caras: alterar una regla de autorización es un ejemplo. El responsable del repositorio debería conservar el control sobre acceso a secretos, publicación y cambios de datos, independientemente del nivel elegido.

Selecciona tareas pequeñas, medianas y difíciles del propio repositorio. Incluye una corrección localizada con prueba existente, una integración que atraviese varios módulos y una investigación de un fallo poco evidente. Prepara contexto, criterios de aceptación y una versión base común. No conviene comparar una petición detallada con otra ambigua y atribuir toda la diferencia al enrutamiento.

Cuando compares preferencias, utiliza ramas o entornos independientes para evitar que una solución previa revele la respuesta al siguiente intento. Alterna el orden de ejecución y conserva los intentos fallidos. Una muestra en la que solo sobreviven los mejores resultados puede producir una conclusión atractiva y completamente inútil para planificar capacidad. Anota también qué dependencias externas o permisos impidieron terminar.

Prepara también una respuesta de referencia para cada tarea: comportamiento esperado, evidencia mínima y condiciones que obligan a rechazar el cambio. Oculta al revisor la preferencia utilizada hasta que haya evaluado la entrega, cuando sea viable. Esto ayuda a reducir el sesgo de aceptar una solución solo porque proviene del nivel que el equipo considera más capaz. No hace falta un laboratorio grande; sí hace falta acordar las reglas antes de ver los resultados.

Establece un límite de tiempo o intentos y registra las tareas que lo superan. Excluir silenciosamente los fallos mejora cualquier promedio de forma artificial. Si una muestra es pequeña o las diferencias son inestables, documenta la incertidumbre y amplía la prueba antes de cambiar la política de todo el equipo.

Define la unidad de comparación como una tarea aceptada con evidencia, y registra cinco criterios para cada intento. Mantén los datos suficientemente simples para que otro revisor pueda reconstruir la decisión. Si el equipo termina necesitando una herramienta nueva y compleja para entender el piloto, probablemente está midiendo demasiadas cosas a la vez.

Imagina un caso hipotético: una pantalla duplica un movimiento de inventario cuando el usuario reintenta una solicitud. La tarea podría parecer un ajuste de botón, pero también puede involucrar idempotencia en el servidor. Antes de evaluar modelos, exige reproducir el fallo, identificar dónde se crea el duplicado y demostrar que la solución resiste dos solicitudes equivalentes.

Si un intento deshabilita el botón y otro protege la operación completa, no son resultados equivalentes aunque ambos dejen verde una prueba superficial. La evaluación debe detectar esa diferencia antes de sumar costes. También conviene revisar si el agente modificó módulos ajenos o introdujo dependencias innecesarias. El piloto sirve para observar cómo se resuelve trabajo real, no para premiar la primera respuesta convincente.

Otra actualización oficial, del 11 de septiembre, incorpora métricas de actividad de la ventana dedicada VS Code Agents. GitHub aclara que ese alcance es distinto del modo agente del editor. Es una fuente útil para entender uso, pero no demuestra por sí sola que los cambios entregados sean correctos o que el equipo haya reducido su ciclo de entrega.

Relaciona la actividad agregada con resultados de tareas y revisiones, sin convertir conteos de mensajes en una clasificación de personas. Un equipo puede enviar menos mensajes porque preparó mejor el contexto; otro puede enviar más porque está resolviendo un problema nuevo. Publica qué incluye cada indicador, qué queda fuera y dónde hay datos ausentes para evitar comparaciones engañosas entre equipos.

Al terminar, adopta una preferencia por clase de tarea solo si la evidencia justifica el cambio. Conserva revisión reforzada para operaciones sensibles y una ruta de escalamiento cuando el intento no progresa. Documenta las excepciones: una investigación arquitectónica puede requerir un tratamiento distinto de una edición mecánica aunque ambas ocurran en el mismo repositorio.

Repite una muestra cuando cambien el catálogo disponible, las políticas del equipo o la naturaleza del trabajo. Conserva el contexto de la medición anterior para saber qué comparación sigue siendo válida. La conclusión responsable no es que un nivel gane siempre: es que tu equipo puede explicar qué acepta, cuánto esfuerzo completo requiere y qué señales obligan a revisar esa decisión.