Menú de navegaciónMenú
Categorías
Logo campusMVP.es

La mejor forma de Aprender Programación online y en español www.campusmvp.es

Cómo comparar modelos de IA en VSCode (y otras novedades de la 1.143)

VS Code 1.143 trae muchas cosas importantes para escritura de código con IA: hace del arnés de Copilot la opción por defecto en VSCode, trae herramientas para comparar modelos, recuperar el disco que se comen los worktrees de los agentes y algunas cosas más. Te contamos qué hace cada novedad, cómo activarla y cuáles tienen requisitos que conviene conocer antes de probarlas.

Imagen ornamental

Acaba de salir la versión 1.143 de Visual Studio Code y trae muchas novedades importantes para programación con IA, que es donde están poniendo el foco desde hace mucho tiempo.

A partir de esta versión, cuando creas una nueva sesión de programación con IA, el arnés que ejecuta a los agentes pasa a ser el llamado "Copilot harness" . Esto significa que puedes dejar sesiones trabajando en segundo plano, abrirlas desde el editor o desde la ventana de Agents, y volver a ellas con agilidad incluso desde otros entorns, sin tener que esperar una eternidad.

Además llegan cosas que te afectarán en el día a día: comparar el resultado de varios modelos con el mismo prompt, liberar worktrees abandonados y poder usar modelos locales mejor. Algunas funciones siguen marcadas como experimentales o en preview, así que conviene saber qué se puede activar y cómo.

Repasamos lo importante, con los ajustes que necesitas para probarlo.

¿Qué es el Copilot harness?

El Copilot harness es la capa del producto que se encarga de dirigir al agente cuando trabaja. Gestiona las herramientas, el contexto y todo el "loop" de trabajo. Está construido sobre Copilot SDK, una base común para que el comportamiento y las mejoras sean los mismos (o muy similares) en todos los productos de Copilot (Github Copilot CLI, Github Copilot App, etc).

Cuando abres una sesión nueva, el selector de arnés muestra Copilot como la opción predeterminada:

Selector de arnés con Copilot seleccionado y su descripción

Las sesiones de este arnés se ejecutan a través del Agent Host. Eso te permite mantenerlas en segundo plano y acceder a ellas tanto desde la ventana del editor como desde la de Agentes.

Como ves, existen además varios arneses que puedes elegir, como los de Claude Code o el de Codex de OpenAI.

El arnés local es el tradicional de Copilot, y se diferencia del nuevo en que la sesión está enlazada a la ventana del editor, por lo que si cierras esa ventana, el trabajo en curso del agente se detiene. Sin embargo, en el arnés de Copilot las sesiones funcionan de forma independiente a la ventana del editor y pueden continuar en segundo plano después de que la cierres (siempre que el Agent Host permanezca en ejecución). No solo eso, sino que puedes continuar cualquier sesión en marcha desde las demás interfaces compatibles de Copilot (por ejemplo, puedes empezarla en VSCode y continuar (o ver su ejecución) en la app de escritorio o en la de línea de comandos).

Si te interesa entender cómo se reparten el trabajo, la documentación oficial explica cómo trabajar con el Copilot harness.

El equipo de VS Code también ha trabajado en la latencia, o sea, en la velocidad de respuesta. Por ejemplo, han reducido las esperas largas que había antes de la primera respuesta del chat, y las que venían de servidores MCP que no terminaban de cargar sus herramientas.

Abrir chats muy largos ya no congela la ventana

Si trabajas con sesiones muy largas (una mala idea en cualquier caso), esta mejora seguro que la agradeces.

Antes, abrir un chat grande el Agent Host podía llegar a bloquear la ventana hasta 30 segundos en casos muy extremos. Ahora el historial se va restaurando en trozos pequeños a medida que se necesitan.

Gracias a ello la cosa ha mejorado enormemente. Los siguientes son los tiempos medios que indica el equipo de Copilot para chats reales en macOS, con la diferencia entre la versión anterior y la nueva:

Escenario Chat Tiempo de apertura (1.142 → 1.143) Ventana sin responder (1.142 → 1.143)
Apertura en frío A (~1.150 peticiones, ~530 MB) 35,6 s → 9,0 s 28,3 s → 0,6 s
Apertura en frío B (~1.450 peticiones, ~200 MB) 20,3 s → 3,0 s 20,3 s → 0,4 s
Reapertura A 26,7 s → 0,6 s 26,8 s → 0,3 s
Recarga de ventana A 26,7 s → 2,9 s 25,3 s → 0,9 s

Es una mejora espectacular.

¿Cómo comparar varios modelos y arneses con el mismo prompt en VS Code?

Con Compare Models (que está en preview) puedes conseguir que la misma tarea la hagan varios modelos en paralelo y luego comparar automáticamente qué ha hecho cada uno. Así dejas de elegir el modelo por simple intuición y tienes datos reales con los que decidirte.

Ojo, esto solo funciona desde la ventana de Agents y, para que funcione, hay que activar el ajuste sessions.chat.compareAgents.enabled desde esa ventana (no desde los ajustes generales de VSCode).

El flujo es sencillo y comienza comienza por lo obvio: elegir los modelos. En el selector de modelo pulsas el iconito con forma de copa de fútbol (arriba a la derecha) y marcas dos o más:

Selector con varios modelos seleccionados

Es muy interesante fijarse también en que, con los iconos de la parte superior izquierda, puedes elegir modelos de distintos arneses (Copilot, Claude o Codex), y también elegir distintos niveles de razonamiento, lo cual te da una comparativa mucho más interesante, porque todo eso influye.

Yo, en ese caso, variaría solo el arnés y eligiría el mismo modelo en todos ellos, porque si cambias varios parámetros es muy difícil saber cuál ha influido más.

En el siguiente paso puedes elegir un modelo concreto para que sea el juez y decida cuál es el modelo ganador de los que has seleccionado, y opcionalmente otro para sintetizar los resultados:

Selección del modelo que juzga a los otros

Una vez que lanzas la petición, los modelos elegidos trabajan en paralelo y puedes verlos en pantalla dividida para examinar exactamente qué están haciendo (la captura siguiente no es mía, sino del equipo de VS Code: no tengo ninguna que pueda enseñar):

Cuatro intentos ejecutándose en una cuadrícula

El modelo "juez" analiza lo que hacen y muestra también tiempo y tókenes consumidos, y te da una la justificación, la evidencia de validación y enlaces a cada intento. Si quieres, pulsas Synthesize para trabajar sobre el resultado recomendado pero aportando ideas de los demás (la síntesis solo empieza cuando tú lo pides expresamente):

Resultados con el intento recomendado, el scorecard y la acción Synthesize

Puedes ver el proceso completo en este vídeo corto.

Mi opinión: esto puede ser muy útil para tareas donde el resultado sea claramente verificable (una refactorización, un bug con tests...). Para tareas con resultados más abiertos o interpretables, el juez al final no deja de ser otro modelo opinando, así que en ese caso yo me lo tomaría como una pista y no como veredicto infalible Y ¡ojito!, 3 o 4 modelos son el triple o el cuádruple (o más) de consumo de tókenes, así que no conviene abusar.

Y hablando de sesiones en paralelo, ¿dónde crees que se guarda el trabajo de cada una?

¿Cómo liberar el espacio que ocupan los worktrees de las sesiones del agente?

Cada sesión de agente trabaja generalmente en un worktree de Git, que es una copia de trabajo independiente del mismo repositorio. Así, varios agentes pueden tocar funcionalidades distintas sin pisarse.

El problema es que los worktrees inactivos se acumulan y, con proyectos grandes (por ejemplo con su node_modules, builds y demás), se comen tu espacio en disco sin que te des cuenta (y con la función de comparar modelos que acabamos de ver... pues multiplica y verás).

La solución es sencilla y, para mí, de las cosas del día a día más prácticas de esta versión. Si ejecutas Chat: Open Worktree Cleanup desde la paleta de comandos podrás ver:

  • Ver cuánto espacio ocupan los worktrees de sesiones inactivas.
  • Filtrar las sesiones por el tiempo que llevan inactivas.
  • Revisar el tamaño de cada worktree y marcar los que sobran.
  • Configurar la limpieza automática de sesiones con pull requests ya fusionados.

Editor de limpieza de worktrees con la configuración y las sesiones inactivas

OJO: tienes que activarlo antes en la ventana de Agents buscando el ajuste chat.agentSessions.sessionStorageCleanupSuggestion.enabled

Al limpiarlas, las sesiones seleccionadas pasan a "hechas" y se borran sus worktrees. No pierdes la sesión del agente: puedes restaurarla más tarde y se recrea el worktree. Las sesiones activas, las que están aún en ejecución, esperando tu respuesta o ancladas (pinned) están protegidas.

Con el ajuste activado, la ventana de Agents también te avisa cuando los worktrees inactivos se acumulan u ocupan lo bastante como para que merezca la pena limpiar:

Aviso en la ventana de Agents sugiriendo limpiar worktrees

Nada que no pudieras hacer antes a mano, pero muchísimo más cómodo y proactivo.

¿Se puede ejecutar un modelo de Copilot en local con VS Code?

Sí, en modo experimental, y con requisitos de hardware importantes. Ahora puedes descargar MAI Code 1.1 Flash desde la pestaña "On This Device" del selector de modelos y usarlo en sesiones del arnés de Copilot procesándolo directamente en tu equipo. VS Code descarga y gestiona el modelo por ti.

Esas respuestas locales se etiquetan como "On-device" y no consumen créditos de IA.

Si activas la opción Use in Auto en la página de detalles del modelo, se le enviarán peticiones que el modo automático crea que son apropiadas para el modelo local, pero recurrirá a la nube si cree que es mejor.

Para probarlo necesitas:

  1. Instalar una build de llama.cpp compatible con tu hardware.
  2. Apuntar chat.copilot.localModel.llamaServerPath a su ejecutable llama-server.
  3. Activar chat.copilot.localModel.enabled.

Y aquí viene la letra pequeña que estabas esperando: para usar este modelo te hace falta una GPU NVIDIA con 96 GB o más de memoria. Vamos, que muy pocos lo tienen a su alcance. Microsoft lo plantea para portátiles como el Surface Laptop Ultra (NVIDIA RTX Spark, hasta 128 GB de memoria unificada). Con un equipo normal no lo vas a poder usar, así que de momento es más una cosa aspiracional que una opción viable para la mayoría. Quizá en un par de años la cosa cambie mucho, pero está bien que de momento se vaya planteando la opción.

Y no, en mi experiencia y por mucho que nos lo quieran "vender", los modelos pequeños que te funcionan en una tarjeta RTX convencional para juegos con 8, 12 o 16GB de RAM no están ni de lejos a la altura de las otras opciones comerciales, ni en capacidades, ni en resultados, ni en velocidad de respuesta. Y comprarte 4 Mac mini M4 para ejecutar modelos en paralelo está muy bien como frikismo pero económicamente no tiene sentido para un desarrollador individual o para una pequeña empresa.

Más detalles en la documentación de modelos on-device.

José M. Alarcón Aguín Fundador de campusMVP.es, es ingeniero industrial y especialista en consultoría de empresa. Ha escrito diversos libros, habiendo publicado hasta la fecha cientos de artículos sobre informática e ingeniería en publicaciones especializadas. Microsoft lo ha reconocido como MVP (Most Valuable Professional) en desarrollo web desde el año 2004 hasta la actualidad. Puedes seguirlo en LinkedIn. Ver todos los posts de José M. Alarcón Aguín
Archivado en: Inteligencia Artificial

Boletín campusMVP.es

Solo cosas útiles. Una vez al mes.

🚀 Únete a miles de desarrolladores

DATE DE ALTA

x No me interesa | x Ya soy suscriptor

La mejor formación online para desarrolladores como tú

Agregar comentario

Los datos anteriores se utilizarán exclusivamente para permitirte hacer el comentario y, si lo seleccionas, notificarte de nuevos comentarios en este artículo, pero no se procesarán ni se utilizarán para ningún otro propósito. Lee nuestra política de privacidad.