Visual Studio conecta modelos con facilidad. La fiabilidad de los agentes aún necesita pruebas
Visual Studio 18.10 Insiders puede conectar modelos locales y alojados al modo Agent, pero una prueba práctica muestra que la disponibilidad del endpoint no implica un trabajo de programación fiable.
Microsoft ha incorporado Bring Your Own Model (BYOM) a la nueva experiencia Agent de Visual Studio 18.10 Insiders. Los desarrolladores pueden conectar Microsoft Foundry, OpenAI, Anthropic u Ollama y después seleccionar el modelo añadido en el selector de modelos de Visual Studio. Eso facilita la configuración del proveedor. No demuestra que todos los modelos seleccionables puedan inspeccionar un repositorio, llamar a herramientas, editar archivos y recuperarse de fallos de forma fiable.
BYOM es una capa de conexión, no un certificado de compatibilidad. La fiabilidad depende de la compilación exacta de Visual Studio, el endpoint, la revisión del modelo, las capacidades de las herramientas, el tipo de proyecto y el conjunto de tareas. Una conexión correcta dice muy poco sobre cómo se comportará esa combinación completa durante un trabajo real con agentes.
La cautela no es hipotética. En una prueba práctica independiente, un modelo local Qwen3:4b conectado mediante Ollama respondió a una pregunta básica sobre el proyecto, pero no consiguió terminar una pequeña tarea de programación después de 25 minutos. Claude Sonnet 4.6 completó la misma edición y compilación en segundos. Una sola prueba no puede clasificar ninguna de las dos familias de modelos; sí muestra por qué una conexión correcta y un agente de programación fiable son resultados diferentes.
Qué conecta realmente Visual Studio BYOM
El anuncio de BYOM de Microsoft del 24 de agosto sitúa la versión preliminar en Visual Studio 18.10 Insiders y en el nuevo Agent (Preview), que utiliza un arnés impulsado por el SDK de GitHub Copilot. Está habilitado de forma predeterminada en las ediciones preliminares Community, Professional y Enterprise. El selector de modelos puede añadir proveedores de Microsoft Foundry, OpenAI, Anthropic y Ollama, y el flujo funciona tanto si el desarrollador ha iniciado sesión en GitHub como si no.
“Bring your own model” no significa importar un archivo de pesos del modelo a Visual Studio. El IDE conecta su arnés de agente a un proveedor o endpoint. Un modelo local puede participar cuando un software como Ollama lo sirve a través de un endpoint compatible, mientras que un proveedor alojado normalmente requiere sus propias credenciales.
La versión preliminar actual también sustituye la experiencia BYOM anterior de los antiguos modos Ask y Agent. Microsoft dice que los modelos añadidos previamente deben añadirse de nuevo. La guía antigua de selección de modelos de Visual Studio 17.14 (en inglés), actualizada por última vez en 2025, describe una lista de proveedores y unos límites de Business y Enterprise diferentes. No debe tratarse como la fuente de referencia para la versión preliminar 18.10.
| Superficie preliminar | Lo que respaldan las fuentes actuales | Lo que aún necesita verificación |
|---|---|---|
| Versión de Visual Studio | 18.10 Insiders con el nuevo Agent (Preview) | Número de compilación exacto y si una actualización cambió el comportamiento del proveedor |
| Proveedores | Microsoft Foundry, OpenAI, Anthropic y Ollama | Modelos y capacidades disponibles que expone cada endpoint |
| Capacidad del agente | Los modelos pueden aparecer en el selector de modelos de Agent | Uso de herramientas, gestión del contexto, ediciones, pruebas y recuperación en las tareas del equipo |
| Compatibilidad | Visual Studio muestra cierta información sobre la capacidad del modelo | Microsoft no certifica explícitamente todas las combinaciones de modelo y proveedor |
| Control empresarial | BYOM está presente en las versiones preliminares Professional y Enterprise | La política de desactivación y la gestión centralizada de modelos están previstas, no disponibles actualmente |
También hay una discrepancia en la documentación activa. El anuncio dice que se admiten URL personalizadas para OpenAI y Ollama. Las notas de versión de Insiders de Visual Studio, actualizadas el 25 de agosto, dicen que el soporte de endpoints personalizados para esos proveedores aún está por llegar. Las mismas notas registran que los modelos de Ollama añadidos en Insiders 1 tuvieron que añadirse de nuevo en Insiders 2 después de cambios en el backend.
Ese conflicto es un riesgo de la versión preliminar, no un detalle que deba suavizarse. Registre la compilación exacta y pruebe la ruta del endpoint en lugar de prometer a un equipo que “18.10 admite URL personalizadas” en abstracto.
Una prueba local frente a alojada expuso el límite real
La prueba práctica de Visual Studio Magazine utilizó una aplicación Blazor estándar de .NET 10. Visual Studio encontró siete modelos en un servidor local de Ollama y marcó las diferencias de capacidad en el selector. El probador eligió Qwen3:4b porque Visual Studio lo identificó como compatible con herramientas.
El modelo local identificó en términos generales el proyecto, aunque describió incorrectamente partes de su estructura. En una segunda tarea —añadir un botón de reinicio al contador de ejemplo— leyó el archivo objetivo y empezó a utilizar las herramientas de Agent, pero se confundió con las instrucciones, el contenido de los archivos y los resultados de las herramientas. El probador detuvo la ejecución después de unos 25 minutos sin que la edición se hubiera completado.
Después, Claude Sonnet 4.6 completó el mismo cambio, compiló el proyecto correctamente y consumió 0,9 créditos de Copilot, según el informe. La comparación fue entre una revisión de modelo, un proyecto pequeño, una tarea, una máquina local y una ejecución alojada. No controló el hardware, la construcción del contexto, los ajustes de inferencia ni la variación entre ejecuciones repetidas. Por tanto, solo respalda una conclusión limitada: el endpoint local funcionó, mientras que esa configuración del modelo no logró completar esa tarea del agente.
Esta es precisamente la brecha que un equipo necesita medir. El trabajo de un agente no es un chat ordinario. El modelo debe interpretar los esquemas de las herramientas, mantener separado el objetivo del usuario de las salidas de archivos y herramientas, elegir la siguiente acción, detectar errores y detenerse con un resultado verificable. Un modelo que resume código con precisión puede fallar cuando el arnés añade varias rondas de estado y comentarios de las herramientas.
El mismo principio se aplica al dimensionamiento del hardware. Un modelo local que cabe en la memoria todavía puede ser demasiado lento o poco fiable para el flujo de trabajo previsto; el análisis del despliegue local de Qwen explica por qué hay que medir conjuntamente los pesos, el contexto, el estado de ejecución y la aceptación de la tarea.
El selector de modelos expone una elección, no una capacidad equivalente
El resultado práctico concreta la distinción: Visual Studio pudo descubrir el modelo local y exponer las herramientas de Agent, pero esa configuración no terminó la pequeña edición después de unos 25 minutos. La compatibilidad del endpoint era real; la fiabilidad del agente no se deducía de ella.
Una tarea no puede clasificar los modelos locales y alojados, y el informe no controló el hardware, la construcción del contexto, los ajustes de inferencia ni la variación entre ejecuciones repetidas. Sí muestra por qué un selector de modelos es el comienzo de una evaluación, no una prueba de que todos los modelos incluidos puedan utilizar las mismas herramientas con la misma fiabilidad.
La gobernanza de la versión preliminar sigue incompleta
Microsoft presenta BYOM en parte como una forma de utilizar modelos aprobados y endpoints privados. Eso puede mejorar el control, pero la versión preliminar actual no demuestra automáticamente adónde viaja cada byte. Los equipos deben verificar los registros del proveedor, la autenticación del endpoint, la indexación del repositorio, la telemetría, el almacenamiento de secretos y cualquier servicio que permanezca fuera de la ruta del modelo elegido.
Microsoft dice que está prevista para la versión de disponibilidad general 18.10 una política ADMX que desactive BYOM para los usuarios de Professional y Enterprise. La configuración centralizada de modelos, los controles granulares del contexto y las herramientas, una detección de compatibilidad más inteligente y una integración más profunda con Foundry también son trabajos futuros. Hasta que esos controles se publiquen y se verifiquen, aparecer en una SKU Enterprise no debe confundirse con una gobernanza centralizada.
La falta de controles administrativos importa porque la elección del proveedor solo es duradera mientras sigan disponibles el endpoint, el modelo y la política seleccionados. El análisis de la retirada de modelos de Copilot (en español) muestra lo rápido que puede cambiar ese catálogo bajo un nombre de producto estable.
La elección es la función; la fiabilidad es la decisión de despliegue
Visual Studio BYOM reduce la fricción de poner un despliegue local u otro proveedor detrás de la misma interfaz de Agent. Eso es valioso para experimentar, controlar costes, especializarse y elegir límites de datos. También traslada más responsabilidad por la validación del modelo y del endpoint al desarrollador o a la organización.
La próxima evidencia que hay que observar no es el número de modelos que aparecen en el selector. Es si Microsoft cierra la brecha documental sobre endpoints personalizados, publica los controles administrativos prometidos y mejora la detección de capacidades, y si las pruebas repetidas y específicas de cada compilación muestran que un modelo elegido puede terminar el trabajo real del equipo sin una recuperación insegura o costosa.