La actualización de junio de GitHub Copilot en Visual Studio se centra en tres áreas especialmente relevantes para equipos técnicos: más visibilidad sobre el consumo de Copilot, una validación de confianza para servidores MCP y la disponibilidad general de escenarios de modernización C++ relacionados con MSVC.
No es una actualización limitada al autocompletado. El mensaje de fondo es más amplio: Copilot dentro de Visual Studio avanza hacia un uso más gobernable, con señales de consumo más visibles, controles explícitos antes de ejecutar herramientas externas y primeros flujos más estructurados para modernizar proyectos C++.
GitHub resume los cambios en su changelog de GitHub Copilot in Visual Studio — June update. Como ocurre con este tipo de anuncios, conviene leerlo como una nota de producto y no como una especificación completa: la disponibilidad concreta puede depender del canal de Visual Studio, la versión instalada, la licencia de Copilot y la configuración del entorno.
Nota: el anuncio menciona Visual Studio y recomienda revisar el canal Insiders para las novedades más recientes. Antes de desplegar estas capacidades en un equipo amplio, es recomendable validar versión, canal, licencia y políticas internas.
De asistente individual a capacidad gestionada en el IDE
Durante las primeras fases de adopción de Copilot, muchas organizaciones lo evaluaban de forma bastante subjetiva: si el desarrollador percibía que escribía código más rápido, si aceptaba más sugerencias o si resolvía tareas rutinarias con menos fricción.
Esa percepción sigue siendo importante, pero no basta para una adopción seria en equipos grandes. Cuando Copilot forma parte del flujo diario de desarrollo, aparecen preguntas más operativas:
- ¿Cuánto se está usando realmente?
- ¿Qué ocurre cuando se alcanzan límites de consumo?
- ¿Qué herramientas externas puede invocar el asistente?
- ¿Qué nivel de confianza exige cada integración?
- ¿Cómo se aplica Copilot a bases de código complejas, como proyectos C++ antiguos?
La actualización de junio responde precisamente a parte de esas preguntas. Visual Studio no es solo otro cliente de Copilot: en muchas organizaciones es el entorno principal para soluciones .NET, C++, escritorio, gaming y aplicaciones empresariales. Por eso, las capacidades de uso, confianza y modernización tienen un impacto especial en este IDE.
Nueva ventana de uso de Copilot y alertas de consumo
Uno de los cambios principales es la ventana renovada de Copilot Usage. Según GitHub, esta vista refleja el modelo de facturación basado en uso de Copilot y se actualiza en tiempo real. También incorpora alertas proactivas para avisar cuando el usuario se acerca a su límite, cuando lo alcanza y cuando se activan consumos por encima del límite, si aplican al plan correspondiente.
El acceso indicado por GitHub es desde el menú del distintivo de Copilot:
Copilot badge menu > Copilot Usage
Además, el umbral de aviso puede ajustarse en la configuración para decidir con cuánta antelación se recibe la notificación.
La mejora es relevante porque acerca el consumo al lugar donde ocurre el trabajo: el IDE. En vez de depender solo de paneles administrativos o revisiones externas, el desarrollador puede tener una señal más directa de su propio uso.
Cómo interpretar las métricas de uso
La visibilidad de uso no debería confundirse con una métrica directa de productividad individual. Que una persona acepte muchas sugerencias no significa necesariamente que entregue mejor código; y que acepte pocas no implica que Copilot no le aporte valor.
En Visual Studio, muchos usos útiles de Copilot no se reducen a una línea aceptada en el editor. Un desarrollador puede utilizar Copilot Chat para:
- entender una parte de una solución grande;
- analizar un error de compilación;
- preparar una refactorización;
- generar un primer borrador de pruebas;
- explorar una API interna;
- revisar alternativas de implementación.
Por eso, las métricas de uso deben leerse como señales de adopción y consumo, no como indicadores aislados de rendimiento.
Advertencia: las métricas de Copilot no deberían utilizarse para evaluar individualmente a desarrolladores. Su valor principal está en detectar patrones agregados, necesidades de formación, fricciones de adopción y posibles problemas de configuración o licencia.
Una lectura sana combina datos cuantitativos con feedback cualitativo. Si un equipo usa poco Copilot, puede haber varias explicaciones: desconocimiento de Copilot Chat, restricciones de repositorio, falta de contexto útil, preferencia por otro editor o simplemente un tipo de trabajo donde Copilot aporta menos. La métrica por sí sola no explica la causa.
Validación de confianza para servidores MCP
La segunda novedad importante es la validación de confianza para servidores MCP.
MCP, o Model Context Protocol, permite conectar un cliente como Visual Studio con servidores que exponen herramientas externas. En la práctica, un servidor MCP puede ampliar lo que Copilot puede consultar o ejecutar: repositorios, documentación, sistemas de trabajo, herramientas internas o servicios auxiliares.
Esa capacidad tiene mucho valor, pero también introduce riesgo. Si un asistente puede utilizar herramientas externas, leer información o iniciar acciones, el IDE necesita un modelo explícito de confianza.
Según el changelog, Visual Studio compara al inicio la configuración y la huella de activos de un servidor MCP con una línea base de confianza. Si algo ha cambiado, muestra un diálogo para que el usuario revise y apruebe el cambio antes de que el servidor se ejecute.
GitHub indica que esta función está activada por defecto y que se puede encontrar en:
Tools > Options > GitHub > Copilot > Copilot Chat >
Show trust dialog before running tools from an updated MCP server
La idea es sencilla pero importante: un servidor MCP no debería ejecutarse sin que el usuario sea consciente de cambios relevantes en su configuración o en los activos asociados.
Qué debe evaluar un equipo antes de confiar en un servidor MCP
La confianza en MCP no debería tratarse como un simple botón de “permitir” o “denegar”. Para un equipo técnico, confiar en un servidor implica entender al menos cinco aspectos:
- Origen del servidor: si lo mantiene un equipo interno, un proveedor conocido o una comunidad externa.
- Capacidades expuestas: qué herramientas ofrece y qué puede hacer Copilot a través de ellas.
- Tipo de acceso: solo lectura, escritura, creación de recursos, ejecución de comandos u otras acciones.
- Datos accesibles: documentación interna, código fuente, tickets, secretos, información de clientes u otros datos sensibles.
- Trazabilidad y revisión: quién lo aprobó, con qué alcance y bajo qué condiciones.
No todos los servidores MCP tienen el mismo riesgo. Un servidor que solo consulta documentación técnica interna no tiene el mismo perfil que uno capaz de modificar work items, abrir pull requests o ejecutar operaciones sobre infraestructura.
Un patrón razonable para organizaciones es clasificar los servidores en niveles:
- Aprobados para uso general: revisados por plataforma o seguridad, con propietario claro.
- Permitidos para pruebas locales: útiles para experimentación, pero sin acceso a datos sensibles ni acciones destructivas.
- Bloqueados hasta revisión: servidores externos o con permisos amplios que requieren análisis previo.
La validación de confianza en Visual Studio ayuda en el flujo de uso, pero no sustituye una política interna. Si una organización permite MCP, debería definir qué servidores se pueden usar, con qué permisos y bajo qué criterios.
Inventario interno de servidores MCP permitidos
Una práctica sencilla es mantener un inventario interno de servidores MCP aprobados. El siguiente ejemplo no representa una configuración oficial de Visual Studio; es solo una forma de documentar decisiones de confianza dentro de un equipo de plataforma.
servers:
- name: "docs-internas"
owner: "platform-engineering"
purpose: "Consulta de documentación técnica interna"
access_level: "read-only"
data_classification:
- "internal"
- "technical-documentation"
approved_for:
- "Visual Studio"
- name: "design-system"
owner: "frontend-platform"
purpose: "Consulta de componentes y tokens del sistema de diseño"
access_level: "read-only"
data_classification:
- "internal"
- "design-assets"
approved_for:
- "Visual Studio"
- name: "work-item-helper"
owner: "developer-experience"
purpose: "Lectura y clasificación asistida de elementos de trabajo"
access_level: "read-write"
data_classification:
- "internal"
- "work-items"
approved_for:
- "Visual Studio"
El formato es secundario. Lo importante es que cada servidor tenga propietario, propósito, nivel de acceso y clasificación de datos. Así, cuando Visual Studio solicite confianza para un servidor MCP actualizado, el equipo tendrá una referencia clara para decidir.
Modernización C++ con MSVC: disponibilidad general de escenarios
La tercera novedad destacada es la disponibilidad general de los escenarios de actualización de MSVC para el agente de modernización de GitHub Copilot para C++.
Este matiz es importante. No significa que Copilot resuelva cualquier modernización de C++ de forma automática, ni que todos los escenarios posibles de C++ estén cubiertos. Lo que GitHub anuncia es que los escenarios de actualización de MSVC para el agente de modernización han salido de preview.
El changelog menciona dos formas de uso:
- Automated mode, para ejecutar actualizaciones de extremo a extremo.
- Guided mode, para revisar evaluación, plan y ejecución antes de cada paso.
También indica dos formas de invocarlo:
Right-click project in Solution Explorer > Modernize
o desde Copilot Chat:
@Modernize
Para equipos con bases de código C++ grandes, esto es relevante. C++ suele combinar toolchains, configuraciones de build, macros, plantillas, cabeceras, dependencias nativas y decisiones históricas acumuladas durante años. En ese contexto, una asistencia de modernización integrada en el IDE puede ser útil, siempre que se use con revisión técnica y validación de build.
Por qué C++ exige más cautela que otros lenguajes
C++ plantea retos distintos a lenguajes gestionados como C# o JavaScript. Una sugerencia aparentemente correcta puede tener implicaciones en:
- lifetime y ownership;
- compatibilidad con el estándar usado por el proyecto;
- ABI;
- rendimiento;
- alineamiento de memoria;
- comportamiento indefinido;
- configuración de compilador;
- dependencias del linker;
- compatibilidad con plataformas objetivo.
Por eso, Copilot puede ayudar a acelerar el análisis, proponer cambios o generar primeros borradores, pero no debe sustituir la revisión de un desarrollador con conocimiento del dominio.
En modernización C++, el valor no está solo en producir código nuevo. También está en ayudar a entender errores, identificar patrones antiguos, proponer pasos de migración y reducir el esfuerzo inicial de análisis.
Ejemplo ilustrativo de modernización C++
El siguiente ejemplo no describe una funcionalidad específica del agente de modernización anunciado por GitHub. Es simplemente un caso típico donde Copilot podría ayudar a razonar sobre una refactorización en C++.
Supongamos una función que devuelve un puntero creado dinámicamente:
#include <string>
#include <vector>
struct Customer {
int id;
std::string name;
};
Customer* findCustomerById(const std::vector<Customer>& customers, int id) {
for (const auto& customer : customers) {
if (customer.id == id) {
return new Customer(customer);
}
}
return nullptr;
}
El problema es que la función transfiere ownership al llamador de forma implícita. Quien use esta API debe recordar liberar memoria con delete, lo que aumenta el riesgo de fugas o errores de mantenimiento.
Una alternativa moderna, si el proyecto permite C++17, podría ser devolver std::optional<Customer>:
#include <optional>
#include <string>
#include <vector>
struct Customer {
int id;
std::string name;
};
std::optional<Customer> findCustomerById(const std::vector<Customer>& customers, int id) {
for (const auto& customer : customers) {
if (customer.id == id) {
return customer;
}
}
return std::nullopt;
}
La mejora no está solo en cambiar la sintaxis. La intención queda más clara: puede que no exista un resultado, y no hay ownership manual que gestionar.
Un prompt útil para Copilot no sería simplemente “refactoriza esta función”, sino algo más preciso:
Refactoriza esta función para evitar ownership manual.
Mantén compatibilidad con C++17.
No uses asignación dinámica explícita.
Representa claramente el caso en el que no se encuentra el cliente.
En C++, expresar restricciones concretas es especialmente importante. Ayuda a evitar sugerencias genéricas que compilan, pero no respetan las reglas del proyecto.
Sugerencias de próxima edición a mayor distancia
El changelog también menciona long-distance next edit suggestions, es decir, sugerencias de próxima edición que pueden anticipar cambios en zonas más alejadas del archivo o del contexto inmediato.
GitHub no detalla en el anuncio todos los criterios de funcionamiento, así que conviene no sobredimensionar esta capacidad. La lectura prudente es que Copilot sigue mejorando en escenarios donde una edición en un punto del código implica cambios relacionados en otros lugares.
Para equipos que trabajan con soluciones grandes, esta línea es interesante: muchas tareas no consisten en modificar una sola función, sino en propagar un cambio por varias capas, actualizar llamadas, ajustar pruebas o mantener consistencia entre archivos.
Aun así, la recomendación sigue siendo la misma: revisar cada sugerencia, ejecutar pruebas y validar que el cambio respeta la arquitectura del proyecto.
Recomendaciones para equipos técnicos
Para adoptar esta actualización de forma ordenada, conviene separar tres frentes: consumo, MCP y C++.
1. Usar la ventana de consumo como señal, no como ranking
La nueva ventana de uso puede ayudar a entender límites y consumo individual, pero no debería convertirse en una herramienta de presión. Es más útil para evitar sorpresas de facturación o bloqueo de uso que para medir rendimiento.
Buenas prácticas:
- explicar al equipo qué significan los límites;
- configurar umbrales de alerta razonables;
- revisar patrones agregados, no comportamientos individuales;
- combinar datos de uso con feedback real de los desarrolladores.
2. Definir una política mínima para MCP
Antes de que cada desarrollador conecte servidores MCP por su cuenta, conviene acordar reglas básicas.
Como mínimo:
- qué servidores están permitidos;
- quién los mantiene;
- qué datos pueden consultar;
- qué acciones pueden ejecutar;
- cuándo se requiere revisión de seguridad;
- qué hacer si Visual Studio muestra una alerta de confianza.
La validación integrada en el IDE es una ayuda, pero la política debe existir fuera del IDE.
3. Probar la modernización C++ en escenarios acotados
En vez de pedir a todo el equipo que use Copilot para “modernizar C++”, es mejor empezar con casos concretos:
- actualización de proyectos MSVC;
- explicación de errores de compilación;
- análisis de código heredado;
- generación inicial de pruebas;
- refactorizaciones pequeñas y revisables;
- eliminación de patrones de ownership manual cuando sea seguro.
Cada piloto debería evaluarse por calidad de resultados, reducción de tiempo y defectos evitados, no solo por volumen de uso.
4. Mantener revisión humana obligatoria
Copilot puede acelerar tareas, pero no elimina la responsabilidad técnica. En C++, especialmente, cualquier cambio generado o sugerido debe pasar por:
- revisión de código;
- compilación limpia;
- pruebas automatizadas;
- análisis de rendimiento si aplica;
- validación en las plataformas objetivo.
La modernización asistida por IA debe integrarse en el ciclo de ingeniería existente, no saltárselo.
Implicaciones para arquitectura y plataforma
La actualización refuerza una tendencia clara: Copilot se está convirtiendo en una capacidad de plataforma, no solo en una extensión de productividad individual.
Esto tiene varias implicaciones:
- Los equipos de plataforma deben participar en la definición de servidores MCP permitidos.
- Seguridad debe revisar qué herramientas externas puede usar el asistente.
- Los responsables técnicos deben decidir qué métricas son útiles y cuáles pueden generar incentivos incorrectos.
- Los equipos C++ deben tratar la modernización asistida como un proceso guiado y verificable.
- Los administradores deben validar licencias, límites y canales antes de desplegar cambios ampliamente.
El mayor riesgo no es usar Copilot, sino usarlo sin modelo operativo. A medida que el asistente gana capacidad para interactuar con herramientas, el gobierno se vuelve tan importante como la experiencia de usuario.
Conclusión
La actualización de junio de GitHub Copilot en Visual Studio es relevante porque apunta a una etapa más madura del asistente dentro del IDE.
La nueva ventana de uso mejora la visibilidad del consumo. La validación de confianza para servidores MCP introduce un control necesario antes de permitir herramientas externas. Y la disponibilidad general de escenarios de modernización C++ con MSVC abre una vía interesante para equipos que mantienen proyectos nativos complejos.
La adopción recomendable no es activar todo sin más, sino integrar estas capacidades con criterio: medir uso sin convertirlo en vigilancia, aprobar servidores MCP con una política clara y probar la modernización C++ en escenarios concretos y revisables.
Copilot puede aportar mucho valor en Visual Studio, pero su impacto sostenido dependerá de cómo se gobierne dentro del flujo real de ingeniería.