Developer Tools | The .NET Blog

VS Code 1.119: OpenTelemetry para sesiones de agentes, integración del navegador y seguridad

Emiliano Montesdeoca — Fri, 15 May 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

VS Code 1.119 salió el 6 de mayo de 2026 (con un parche de seguridad 1.119.1 poco después). La versión se centra en la observabilidad de los agentes, la interacción con el navegador y la reducción de interrupciones.

Trazado OpenTelemetry para sesiones de agentes

Esta es la característica destacada para cualquiera que ejecute agentes en producción o depure flujos de trabajo agénticos. Actívala con dos configuraciones:

"github.copilot.chat.otel.enabled": true,
"github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318"

Las trazas siguen las convenciones semánticas de GenAI. Cada solicitud de agente produce un span raíz invoke_agent con spans hijo anidados: chat, execute_tool y execute_hook. El uso de tokens se reporta por solicitud — incluyendo recuentos de lectura y creación de caché.

Funciona con el agente local, el agente de fondo de Copilot CLI y el agente de Claude. Cualquier backend compatible con OTLP acepta las trazas — el Aspire Dashboard standalone funciona bien para el desarrollo local.

Los agentes ahora pueden acceder a las pestañas del navegador

Los agentes pueden solicitar acceso a las pestañas de tu navegador integrado — pero no es automático. Debes compartir explícitamente una pestaña mediante el selector de contexto, arrastrar y soltar, o contexto sugerido. Hay un botón de compartición en el navegador para revocar el acceso. Cuando un agente intenta abrir una nueva pestaña en el mismo dominio que una pestaña abierta (no compartida), VS Code te pide que reutilices la pestaña existente.

Uso optimizado de tokens

Un modelo ligero experimental ahora gestiona las listas de tareas de los agentes, manteniendo ese trabajo administrativo fuera del modelo principal más caro. Reduce el consumo de tokens para tareas que no necesitan capacidad de razonamiento completa.

Confianza y seguridad

Menos interrupciones: VS Code 1.119 reduce las solicitudes de acceso a la red y escrituras en carpetas temporales por parte de los agentes. El parche 1.119.1 aborda problemas de seguridad específicos — vale la pena actualizar si aún no lo has hecho.

Cambio rápido a vista previa de Markdown

Pequeño pero útil: ahora puedes cambiar rápidamente el editor actual a la vista previa de Markdown sin navegar.

VS Code Agents (vista previa Insiders)

La interfaz de sesión de agentes rediseñada — nuevo selector de repositorios (local/repos/remoto), mejoras de subsesiones, pulido web y móvil, animaciones de progreso — está disponible en Insiders en insiders.vscode.dev/agents.

Registro de cambios completo: code.visualstudio.com/updates/v1_119.

Azure Data Studio se retira: mueve tu flujo de Azure SQL a VS Code

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Azure Data Studio se retiró el 6 de febrero de 2025, con soporte hasta el 28 de febrero de 2026 — el reemplazo recomendado es VS Code con la extensión MSSQL.

Qué instalar

Tres cosas para empezar:

Extensión MSSQL — busca “SQL Server (mssql)” en el Marketplace de VS Code
Extensión SQL Database Projects — esquema como código, validación de compilación, publicación guiada
.NET 8 SDK — requerido por el sistema de compilación; el SDK faltante es el problema más común al primer uso

Migrar tus conexiones y configuraciones de ADS

La extensión MSSQL incluye el ADS Migration Toolkit, que gestiona la migración única en un flujo guiado: conexiones guardadas, grupos de conexiones, configuraciones y atajos de teclado se importan automáticamente.

Recuperar el músculo del F5

Los usuarios de ADS dependen de F5 para ejecutar consultas. Instala la extensión MSSQL Database Management Keymap para recuperar los atajos de teclado al estilo ADS, incluido F5.

SQL Database Projects: esquema como código

Clic derecho en un proyecto → Publicar → configurar destino → revisar el script T-SQL generado → desplegar. La vista previa del script antes del despliegue es la característica clave de seguridad. Las plantillas de elementos generan esqueletos para tablas, procedimientos almacenados y vistas — el mismo flujo que SSDT.

Problema frecuente: una incompatibilidad de plataforma de destino en el archivo .sqlproj causará errores de compilación si el proyecto fue creado contra una versión diferente de SQL Server.

Schema Compare y Schema Designer

La extensión también incluye Schema Compare (diferencia entre tu proyecto y la base de datos desplegada) y Schema Designer (edición visual del esquema sin escribir DDL a mano).

Desarrolladores de Microsoft Fabric

La configuración es idéntica, pero comienza desde el portal de Fabric y conecta la base de datos a Git primero antes de abrirla en VS Code. Microsoft tiene una guía dedicada: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

Conclusión

La migración es un flujo guiado de una sola vez, no una reconstrucción manual. Instala las tres herramientas, ejecuta el ADS Migration Toolkit, restaura tus atajos de teclado y estarás de vuelta a la normalidad en menos de 10 minutos.

Consulta el artículo completo para capturas de pantalla paso a paso y el tutorial específico de Fabric.

Este cambio ayuda cuando hay que equilibrar velocidad de entrega, consistencia de plataforma y gobernanza.

Siguientes pasos practicos

Valida la funcionalidad en un piloto .NET pequeno con datos realistas.
Define observabilidad y un plan de rollback antes de escalar.
Documenta el patron para reutilizarlo en otros equipos.

Fuente

Articulo original: https://devblogs.microsoft.com/azure-sql/azure-data-studio-is-retired-move-your-azure-sql-workflow-to-vs-code-in-10-minutes/

El Azure MCP Server Ahora es un .mcpb — Instálalo sin Ningún Runtime

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

¿Sabes qué era molesto de configurar servidores MCP? Necesitabas un runtime. Node.js para la versión npm, Python para pip/uvx, .NET SDK para la variante dotnet, Docker si querías contenedores. Solo para conectar una herramienta a tu cliente IA.

El Azure MCP Server acaba de cambiar eso. Ahora está disponible como .mcpb — un MCP Bundle — y la configuración es arrastrar y soltar.

¿Qué es un MCP Bundle?

Piénsalo como una extensión de VS Code (.vsix) o una extensión de navegador (.crx), pero para servidores MCP. Un archivo .mcpb es un archivo ZIP autónomo que incluye el binario del servidor y todas sus dependencias. Todo lo necesario para ejecutarlo en tu plataforma, empaquetado junto.

El resultado: descargas un archivo, lo abres en un cliente compatible y el servidor funciona. Sin runtime que instalar, sin package.json que gestionar, sin conflictos de versiones.

Cómo instalarlo

1. Descarga el bundle para tu plataforma

Ve a la página de GitHub Releases y descarga el archivo .mcpb para tu OS y arquitectura. Asegúrate de elegir el correcto — osx-arm64 para Apple Silicon, osx-x64 para Mac Intel, etc.

2. Instala en Claude Desktop

La forma más fácil: arrastra y suelta el archivo .mcpb en la ventana de Claude Desktop mientras estás en la página de configuración de Extensiones (☰ → Archivo → Configuración → Extensiones). Revisa los detalles del servidor, haz clic en Instalar y confirma.

3. Autentícate en Azure

az login

Eso es todo. El Azure MCP Server usa tus credenciales de Azure existentes.

Qué puedes hacer con él

Una vez instalado, tienes acceso a más de 100 herramientas de servicios Azure directamente desde tu cliente IA:

Consultar y administrar Cosmos DB, Storage, Key Vault, App Service, Foundry
Generar comandos az CLI para cualquier tarea
Crear plantillas Bicep y Terraform
Obtener recomendaciones de arquitectura y diagnósticos

Prueba prompts como:

“Lista todos los grupos de recursos en mi suscripción”
“Genera una plantilla Bicep para una app web con base de datos SQL”

¿Qué método de instalación usar?

Método	Ideal para
`.mcpb`	Usuarios de Claude Desktop que quieren cero configuración
Extensión VS Code	Desarrolladores en VS Code + GitHub Copilot
npm/npx	Desarrolladores que ya tienen Node.js
Docker	Pipelines CI/CD y contenedores

Para empezar

Descarga: GitHub Releases
Repositorio: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

Consulta el post completo para consejos de solución de problemas.

VS Code 1.118: Copilot CLI Obtiene Nombres de Sesión, Insignias de Modelo y TypeScript 7.0 Nightly

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Visual Studio Code 1.118 es un lanzamiento pequeño y enfocado — principalmente refinamientos de Copilot CLI — pero hay algunas cosas a destacar.

Copilot CLI: las sesiones tienen nombres reales

Las APIs de título de sesión del SDK de Copilot CLI ahora se usan como fuente de verdad para los nombres de sesión. Antes obtenías etiquetas auto-generadas; ahora las sesiones muestran el nombre real del SDK. Mejora de calidad de vida que hace mucho menos confusa la navegación entre múltiples sesiones de agente.

Cambia de sesión más rápido con atajos de teclado

La app de Agents ahora tiene Ctrl+1, Ctrl+2, etc. asignados para cambiar rápidamente entre sesiones. Si estás ejecutando múltiples sesiones de Copilot CLI en paralelo, esto elimina mucho clic con el ratón.

Insignias de modelo en el chat

Las respuestas de Copilot CLI en el panel de chat ahora muestran una insignia de modelo — puedes ver de un vistazo qué modelo manejó cada solicitud.

Selección automática de modelo en Copilot CLI

La selección automática de modelo — previamente disponible en otras partes de Copilot — ahora funciona también en el agente Copilot CLI.

Opt-in a TypeScript 7.0 nightly

Ahora puedes optar por probar los nightly de TypeScript 7.0 directamente desde la configuración de VS Code. TypeScript 7.0 es un lanzamiento importante (la beta llegó hace unos días), y el path de opt-in facilita la prueba sin cambiar tu instalación global de TypeScript.

Bajo el capó: limpieza de `node-pty`

El SDK de Copilot CLI ahora resuelve node-pty desde VS Code via hostRequire en lugar de copiar binarios a la carpeta prebuilds del SDK. Cambio interno que simplifica la distribución.

Consulta las notas de versión completas.

Foundry Toolboxes: Un único endpoint para todas las herramientas de tus agentes

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Esta publicación fue traducida automáticamente. Para la versión original, haz clic aquí.

Aquí hay un problema que parece aburrido hasta que lo sufres en carne propia: tu organización está construyendo múltiples agentes de IA, cada uno necesita herramientas, y cada equipo las conecta desde cero. La misma integración de búsqueda web, la misma config de Azure AI Search, la misma conexión al servidor MCP de GitHub — pero en otro repositorio, por otro equipo, con otras credenciales y sin ninguna gobernanza compartida.

Microsoft Foundry acaba de lanzar Toolboxes en preview pública, y es una respuesta directa a ese problema.

¿Qué es un Toolbox?

Un Toolbox es un bundle de herramientas con nombre, reutilizable, que defines una vez en Foundry y expones a través de un único endpoint compatible con MCP. Cualquier runtime de agente que hable MCP puede consumirlo — no estás bloqueado en Foundry Agents.

La propuesta es simple: build once, consume anywhere. Define las herramientas, configura la autenticación de forma centralizada (OAuth passthrough, identidad administrada de Entra), publica el endpoint. Cada agente que necesite esas herramientas se conecta al endpoint y las obtiene todas.

Sin configuración por herramienta. Sin gestión de credenciales por agente.

Los cuatro pilares (dos disponibles hoy)

Pilar	Estado	Qué hace
Discover	Próximamente	Encuentra herramientas aprobadas sin buscar manualmente
Build	Disponible hoy	Agrupa herramientas en un bundle reutilizable
Consume	Disponible hoy	Un único endpoint MCP expone todas las herramientas
Govern	Próximamente	Auth centralizada + observabilidad en todas las llamadas

Hoy el foco está en Build y Consume. Suficiente para eliminar la fricción más inmediata.

Empezando en la práctica

El SDK es Python primero por ahora. Comienzas creando un AIProjectClient y luego construyes un toolbox:

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

Luego creas una versión del toolbox con las herramientas que quieres agrupar:

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Buscar en documentación y responder a issues de GitHub.",
 tools=[
 {"type": "web_search", "description": "Buscar documentación pública"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Una vez publicado, Foundry te da un endpoint unificado que cualquier runtime MCP puede consumir. Un punto de conexión, todas las herramientas.

No estás bloqueado en Foundry Agents

Los Toolboxes se crean y gestionan en Foundry, pero la superficie de consumo es el protocolo MCP abierto. Puedes usarlos desde agentes personalizados con Microsoft Agent Framework o LangGraph, GitHub Copilot y otros IDEs compatibles con MCP, o cualquier runtime que hable MCP.

Por qué importa ahora

La ola de multi-agentes está llegando a producción. Los equipos están construyendo 5, 10, 20 agentes — y el problema de la configuración de herramientas escala rápido. Cada nuevo agente es una nueva superficie para configuración duplicada, credenciales desactualizadas y comportamiento inconsistente.

Los Toolboxes no resuelven la gobernanza y el discovery todavía (esos pilares están por venir), pero la base de Build + Consume es suficiente para empezar a centralizar. Cuando llegue el pilar Govern, tendrás una capa de herramientas observable y controlada centralmente para toda tu flota de agentes.

Conclusión

Esto es pronto — preview pública, SDK Python primero, con Discover y Govern todavía por llegar. Pero el modelo es sólido, y el diseño nativo de MCP significa que funciona con las herramientas que ya estás construyendo. Echa un vistazo al anuncio oficial para empezar.

Hooks de azd en Python, TypeScript y .NET: adiós a los scripts de shell

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Esta publicación fue traducida automáticamente. Para la versión original, haz clic aquí.

Si alguna vez has tenido un proyecto completamente en .NET y aun así tuviste que escribir scripts Bash solo para los hooks de azd, conoces bien ese dolor. ¿Por qué cambiar a sintaxis de shell en un paso de pre-provisioning cuando todo lo demás en el proyecto es C#?

Esa frustración tiene solución oficial. La Azure Developer CLI acaba de lanzar soporte multi-lenguaje para hooks, y es exactamente tan bueno como suena.

Hooks, brevemente, por si no los conoces

Los hooks son scripts que se ejecutan en puntos clave del ciclo de vida de azd — antes del provisioning, después del despliegue, y más. Se definen en azure.yaml y permiten inyectar lógica personalizada sin modificar la CLI.

Antes solo se admitían Bash y PowerShell. Ahora puedes usar Python, JavaScript, TypeScript o .NET — y azd se encarga del resto automáticamente.

Cómo funciona la detección

Simplemente apuntas el hook a un archivo y azd infiere el lenguaje por la extensión:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Eso es todo. Sin config adicional. Si la extensión es ambigua, puedes añadir kind: python (o el que corresponda) para especificarlo explícitamente.

Detalles importantes por lenguaje

Python

Coloca un requirements.txt o pyproject.toml junto al script (o en cualquier directorio padre) y azd crea un entorno virtual, instala dependencias y ejecuta el script:

hooks/
├── setup.py
└── requirements.txt

Sin gestión manual de virtualenv. azd busca hacia arriba desde el script el archivo de proyecto más cercano.

JavaScript y TypeScript

El mismo patrón — pon un package.json cerca del script y azd ejecutará npm install primero. Para TypeScript, usa npx tsx sin paso de compilación ni tsconfig.json:

hooks/
├── seed.ts
└── package.json

¿Quieres usar pnpm o yarn? Hay una opción config.packageManager para eso.

.NET

Dos modos disponibles:

Modo proyecto: Si hay un .csproj junto al script, azd ejecuta dotnet restore y dotnet build automáticamente.
Modo single-file: En .NET 10+, puedes poner un archivo .cs independiente y se ejecuta directamente con dotnet run script.cs. Sin archivo de proyecto.

hooks:
 postprovision:
 run: ./hooks/migrate.cs

Si ya estás en .NET 10, el modo single-file es la opción más limpia para scripts simples de migración o seeding. Sin scaffolding, sin .csproj que mantener.

Config por ejecutor

Cada lenguaje soporta un bloque config opcional para ajustar los valores por defecto:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postdeploy:
 run: ./hooks/seed.py
 config:
 virtualEnvName: .venv
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

También puedes mezclar formatos en el mismo bloque hooks: — distintos lenguajes para distintos eventos del ciclo de vida, overrides por plataforma para Windows vs. Linux, lo que necesites.

Por qué importa para desarrolladores .NET

La respuesta aburrida es “consistencia”. Pero en la práctica va más allá. Los hooks eran el último lugar de un proyecto basado en azd que te obligaba a usar otro lenguaje. Ahora todo el pipeline de despliegue — código de app, scripts de infraestructura y hooks del ciclo de vida — puede vivir en un solo lenguaje.

Más concreto: puedes reutilizar tus utilidades .NET existentes en los hooks. ¿Tienes una librería compartida para gestión de esquemas de base de datos? Simplemente referencíala en el proyecto del hook. ¿Tienes un script Python de seeding que ya escribiste? Ponlo directamente en azure.yaml.

Conclusión

Es uno de esos cambios que parecen pequeños pero que eliminan mucha fricción del día a día con azd. El soporte multi-lenguaje para hooks ya está disponible — revisa el post oficial para la documentación completa y el repositorio de azd en GitHub para probarlo en tu próximo proyecto.

Windows App Dev CLI v0.3: F5 desde la terminal y automatización de UI para agentes

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Esta publicación fue traducida automáticamente. Para la versión original, haz clic aquí.

La experiencia F5 de Visual Studio es fantástica. Pero tener que abrir VS solo para lanzar y depurar una app Windows empaquetada es excesivo cuando estás en un pipeline de CI, ejecutando un workflow automatizado, o — cada vez más — cuando un agente de IA está haciendo las pruebas.

Windows App Development CLI v0.3 acaba de salir y lo aborda directamente con dos funciones destacadas: winapp run y winapp ui.

winapp run: F5 desde cualquier sitio

winapp run toma una carpeta de app sin empaquetar y un manifiesto, y hace todo lo que VS hace en un debug launch: registra un paquete loose, lanza la app y preserva el LocalState entre re-deploys.

# Construye tu app, luego ejecútala como app empaquetada
winapp run ./bin/Debug

Funciona para WinUI, WPF, WinForms, Console, Avalonia y más. Los modos están pensados tanto para desarrolladores como para workflows automatizados:

--detach: Lanza y devuelve el control a la terminal inmediatamente. Perfecto para CI/automation.
--unregister-on-exit: Limpia el paquete registrado al cerrar la app. Ejecuciones de test limpias.
--debug-output: Captura mensajes OutputDebugString y excepciones en tiempo real. Añade --symbols para PDBs del Microsoft Symbol Server.

Nuevo paquete NuGet: dotnet run para apps empaquetadas

Para desarrolladores .NET hay un nuevo paquete NuGet: Microsoft.Windows.SDK.BuildTools.WinApp.

Añádelo al proyecto (o deja que winapp init lo haga), y dotnet run maneja todo el inner loop: build, preparar un paquete loose-layout, registrar en Windows y lanzar — todo en un paso.

# Deja que winapp init lo configure
winapp init

# O instala directamente
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

Funciona con WinUI, WPF, WinForms, Console, Avalonia. Sin comandos adicionales, sin registro manual. Solo dotnet run.

winapp ui: UI Automation desde la línea de comandos

Este es el que abre los escenarios agénticos. winapp ui te da acceso completo de UI Automation a cualquier app Windows en ejecución — WPF, WinForms, Win32, Electron, WinUI3 — todo desde la terminal.

Lo que puedes hacer:

Listar todas las ventanas de nivel superior
Navegar el árbol completo de UI Automation de cualquier ventana
Buscar elementos por nombre, tipo o ID de automatización
Hacer clic, invocar y establecer valores
Tomar capturas de pantalla
Esperar a que aparezcan elementos — ideal para sincronización de tests

Combina winapp ui con winapp run y tienes un workflow completo build → lanzar → verificar desde la terminal. Un agente puede ejecutar tu app, inspeccionar el estado de UI, interactuar con ella programáticamente y validar el resultado.

Otras novedades

winapp unregister: Elimina un paquete sideloaded cuando terminas.
winapp manifest add-alias: Añade un uap5:AppExecutionAlias para lanzar la app por nombre desde la terminal.
Tab completion: Configura completado con un solo comando para PowerShell.
Package.appxmanifest por defecto: Ahora winapp init crea Package.appxmanifest (convención VS) en lugar de appxmanifest.xml.

Cómo obtenerlo

winget install Microsoft.WinAppCli
# o
npm install -g @microsoft/winappcli

La CLI está en preview pública. Consulta el repositorio en GitHub para documentación completa y el anuncio original para todos los detalles.

VS Code 1.117: Los Agentes Están Obteniendo Sus Propias Ramas de Git y Estoy Totalmente a Favor

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

La línea entre “asistente de IA” y “compañero de equipo de IA” sigue haciéndose más delgada. VS Code 1.117 acaba de salir y las notas de la versión completas están cargadas, pero la historia está clara: los agentes se están convirtiendo en ciudadanos de primera clase en tu flujo de trabajo de desarrollo.

Esto es lo que realmente importa.

El modo Autopilot finalmente recuerda tu preferencia

Antes, tenías que volver a activar Autopilot cada vez que iniciabas una nueva sesión. Molesto. Ahora tu modo de permisos persiste entre sesiones y puedes configurar el valor por defecto.

El Agent Host soporta tres configuraciones de sesión:

Default — las herramientas piden confirmación antes de ejecutarse
Bypass — aprueba todo automáticamente
Autopilot — totalmente autónomo, responde sus propias preguntas y sigue adelante

Si estás creando un nuevo proyecto .NET con migraciones, Docker y CI — configúralo en Autopilot una vez y olvídate. Esa preferencia se mantiene.

Worktree y aislamiento de git para sesiones de agentes

Esta es la grande. Las sesiones de agentes ahora soportan aislamiento completo con worktrees y git. Eso significa que cuando un agente trabaja en una tarea, obtiene su propia rama y directorio de trabajo. Tu rama principal queda intacta.

Mejor aún — Copilot CLI genera nombres de rama significativos para estas sesiones de worktree. Se acabó el agent-session-abc123. Obtienes algo que realmente describe lo que el agente está haciendo.

Para desarrolladores .NET que manejan múltiples ramas de features o corrigen bugs mientras una tarea larga de scaffolding corre, esto es un cambio total. Puedes tener un agente construyendo tus controladores de API en un worktree mientras tú depuras un problema en la capa de servicios en otro. Sin conflictos. Sin stashing. Sin desorden.

Subagentes y equipos de agentes

El Agent Host Protocol ahora soporta subagentes. Un agente puede lanzar otros agentes para manejar partes de una tarea. Piénsalo como delegar — tu agente principal coordina, y agentes especializados se encargan de las piezas.

Esto es temprano, pero el potencial para flujos de trabajo .NET es obvio. Imagina un agente manejando tus migraciones de EF Core mientras otro configura tus pruebas de integración. No estamos totalmente ahí todavía, pero que el soporte del protocolo aterrice ahora significa que las herramientas vendrán rápido.

La salida del terminal se incluye automáticamente cuando los agentes envían input

Pequeño pero significativo. Cuando un agente envía input al terminal, la salida del terminal ahora se incluye automáticamente en el contexto. Antes, el agente tenía que hacer un turno extra solo para leer lo que pasó.

Si alguna vez viste a un agente ejecutar dotnet build, fallar, y luego tomar otro viaje de ida y vuelta solo para ver el error — esa fricción desapareció. Ve la salida inmediatamente y reacciona.

La app de Agents en macOS se auto-actualiza

La app independiente de Agents en macOS ahora se auto-actualiza. No más descargas manuales de nuevas versiones. Simplemente se mantiene al día.

Las cosas más pequeñas que vale la pena saber

Los hovers de package.json ahora muestran tanto la versión instalada como la última disponible. Útil si manejas herramientas npm junto con tus proyectos .NET.
Las imágenes en comentarios JSDoc se renderizan correctamente en hovers y completados.
Las sesiones de Copilot CLI ahora indican si fueron creadas por VS Code o externamente — práctico cuando saltas entre terminales.
Copilot CLI, Claude Code y Gemini CLI son reconocidos como tipos de shell. El editor sabe lo que estás ejecutando.

La conclusión

VS Code 1.117 no es un volcado de features llamativas. Es infraestructura. Aislamiento con worktrees, permisos persistentes, protocolos de subagentes — estos son los bloques de construcción para un flujo de trabajo donde los agentes manejan tareas reales y paralelas sin pisar tu código.

Si estás construyendo con .NET y todavía no te has metido en el flujo de trabajo con agentes, honestamente, ahora es el momento de empezar.

Deja de vigilar tu terminal: el modo desacoplado de Aspire cambia el flujo de trabajo

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Cada vez que ejecutas un AppHost de Aspire, tu terminal desaparece. Bloqueada. Ocupada hasta que presionas Ctrl+C. ¿Necesitas ejecutar un comando rápido? Abre otra pestaña. ¿Quieres revisar los logs? Otra pestaña. Es una pequeña fricción que se acumula rápido.

Aspire 13.2 soluciona esto. James Newton-King escribió todos los detalles, y honestamente, esta es una de esas funcionalidades que cambia inmediatamente tu forma de trabajar.

Modo desacoplado: un comando, terminal de vuelta

aspire start

Ese es el atajo para aspire run --detach. Tu AppHost arranca en segundo plano y recuperas tu terminal de inmediato. Sin pestañas extra. Sin multiplexor de terminal. Solo tu prompt, listo para usar.

Gestionando lo que está en ejecución

La cuestión es que ejecutar en segundo plano solo es útil si puedes gestionar lo que hay ahí fuera. Aspire 13.2 incluye un conjunto completo de comandos CLI para exactamente eso:

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

Esto convierte el CLI de Aspire en un gestor de procesos completo. Puedes iniciar múltiples AppHosts, verificar su estado, seguir sus logs y apagarlos — todo desde una sola sesión de terminal.

Combínalo con el modo aislado

El modo desacoplado se combina naturalmente con el modo aislado. ¿Quieres ejecutar dos instancias del mismo proyecto en segundo plano sin conflictos de puertos?

aspire start --isolated
aspire start --isolated

Cada uno obtiene puertos aleatorios, secretos separados y su propio ciclo de vida. Usa aspire ps para ver ambos, aspire stop para detener el que ya no necesites.

Por qué esto es enorme para los agentes de código

Aquí es donde se pone realmente interesante. Un agente de código trabajando en tu terminal ahora puede:

Iniciar la app con aspire start
Consultar su estado con aspire describe
Revisar logs con aspire logs para diagnosticar problemas
Detenerla con aspire stop cuando termine

Todo sin perder la sesión de terminal. Antes del modo desacoplado, un agente que ejecutara tu AppHost se bloqueaba a sí mismo en su propia terminal. Ahora puede iniciar, observar, iterar y limpiar — exactamente como querrías que funcione un agente autónomo.

El equipo de Aspire se volcó en esto. Ejecutar aspire agent init configura un archivo de habilidades de Aspire que enseña estos comandos a los agentes. Así, herramientas como el agente de código de Copilot pueden gestionar tus cargas de trabajo de Aspire directamente.

Para cerrar

El modo desacoplado es una mejora de flujo de trabajo disfrazada de un simple flag. Dejas de cambiar contexto entre terminales, los agentes dejan de bloquearse a sí mismos, y los nuevos comandos CLI te dan visibilidad real de lo que está en ejecución. Es práctico, es limpio, y hace que el ciclo de desarrollo diario sea notablemente más fluido.

Lee el post completo para todos los detalles y obtén Aspire 13.2 con aspire update --self.

Docker Sandbox permite a los agentes de Copilot refactorizar tu código sin poner en riesgo tu máquina

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Si usaste el modo agente de Copilot para algo más que ediciones pequeñas, conocés el dolor. Cada escritura de archivo, cada comando en terminal — otro prompt de permisos. Ahora imaginá eso multiplicado por 50 proyectos. No es divertido.

El equipo de Azure acaba de publicar un post sobre Docker Sandbox para agentes de GitHub Copilot, y honestamente, es una de las mejoras más prácticas que he visto en herramientas agénticas. Usa microVMs para darle a Copilot un entorno completamente aislado donde puede hacer de todo — instalar paquetes, ejecutar builds, correr tests — sin tocar tu sistema host.

Qué te da realmente Docker Sandbox

La idea central es simple: levantar una microVM liviana con un entorno Linux completo, sincronizar tu workspace dentro de ella, y dejar que el agente de Copilot opere libremente adentro. Cuando termina, los cambios se sincronizan de vuelta.

Esto es lo que lo hace más que simplemente “ejecutar cosas en un contenedor”:

Sincronización bidireccional del workspace que preserva rutas absolutas. La estructura de tu proyecto se ve idéntica dentro del sandbox. Sin fallos de build por rutas.
Docker daemon privado corriendo dentro de la microVM. El agente puede construir y ejecutar contenedores sin montar jamás el socket de Docker de tu host. Eso es importante para la seguridad.
Proxies de filtrado HTTP/HTTPS que controlan lo que el agente puede alcanzar en la red. Vos decidís qué registries y endpoints están permitidos. ¿Ataques a la cadena de suministro por un npm install malicioso dentro del sandbox? Bloqueados.
Modo YOLO — sí, así lo llaman. El agente corre sin prompts de permisos porque literalmente no puede dañar tu host. Toda acción destructiva está contenida.

Por qué los desarrolladores .NET deberían prestar atención

Pensá en el trabajo de modernización que tantos equipos están enfrentando ahora mismo. Tenés una solución .NET Framework con 30 proyectos, y necesitás moverla a .NET 9. Son cientos de cambios en archivos — archivos de proyecto, actualizaciones de namespaces, reemplazos de APIs, migraciones de NuGet.

Con Docker Sandbox, podés apuntar un agente de Copilot a un proyecto, dejarlo refactorizar libremente dentro de la microVM, ejecutar dotnet build y dotnet test para validar, y solo aceptar los cambios que realmente funcionan. Sin riesgo de que accidentalmente destruya tu entorno de desarrollo local mientras experimenta.

El post también describe ejecutar una flota de agentes en paralelo — cada uno en su propio sandbox — trabajando en diferentes proyectos simultáneamente. Para soluciones .NET grandes o arquitecturas de microservicios, eso ahorra una cantidad enorme de tiempo. Un agente por servicio, todos corriendo aislados, todos validados independientemente.

El ángulo de seguridad importa

Acá está lo que la mayoría pasa por alto: cuando dejás que un agente de IA ejecute comandos arbitrarios, le estás confiando toda tu máquina. Docker Sandbox invierte ese modelo. El agente tiene autonomía total dentro de un entorno desechable. El proxy de red asegura que solo pueda descargar de fuentes aprobadas. Tu filesystem host, tu Docker daemon y tus credenciales quedan intactos.

Para equipos con requisitos de compliance — y eso es la mayoría de las empresas .NET — esta es la diferencia entre “no podemos usar IA agéntica” y “podemos adoptarla de forma segura”.

Conclusión

Docker Sandbox resuelve la tensión fundamental de la programación agéntica: los agentes necesitan libertad para ser útiles, pero libertad en tu máquina host es peligroso. Las microVMs te dan ambas cosas. Si estás planificando cualquier refactorización o modernización de .NET a gran escala, vale la pena configurar esto ahora. La combinación de la inteligencia de código de Copilot con un entorno de ejecución seguro es exactamente lo que los equipos de producción estaban esperando.

Las herramientas Azure MCP ahora vienen integradas en Visual Studio 2022 — Sin extensión necesaria

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

Si has estado usando las herramientas Azure MCP en Visual Studio a través de la extensión separada, ya conoces el proceso — instalar el VSIX, reiniciar, cruzar los dedos para que no se rompa, gestionar incompatibilidades de versiones. Esa fricción se acabó.

Yun Jung Choi anunció que las herramientas Azure MCP ahora se incluyen directamente como parte de la carga de trabajo de desarrollo Azure en Visual Studio 2022. Sin extensión. Sin VSIX. Sin el baile de reiniciar.

Qué significa esto realmente

A partir de Visual Studio 2022 versión 17.14.30, el Azure MCP Server viene incluido con la carga de trabajo de desarrollo Azure. Si ya tienes esa carga de trabajo instalada, solo necesitas activarlo en GitHub Copilot Chat y listo.

Más de 230 herramientas en 45 servicios de Azure — accesibles directamente desde la ventana de chat. Lista tus cuentas de almacenamiento, despliega una app ASP.NET Core, diagnostica problemas en App Service, consulta Log Analytics — todo sin abrir una pestaña del navegador.

Por qué esto importa más de lo que parece

La cosa con las herramientas de desarrollo es esta: cada paso extra es fricción, y la fricción mata la adopción. Tener MCP como extensión separada significaba incompatibilidades de versiones, fallos en la instalación, y una cosa más que mantener actualizada. Integrarlo en la carga de trabajo significa:

Una sola vía de actualización a través del Visual Studio Installer
Sin desviaciones de versión entre la extensión y el IDE
Siempre actualizado — el MCP Server se actualiza con las versiones regulares de VS

Para equipos que estandarizan en Azure, esto es muy importante. Instalas la carga de trabajo una vez, activas las herramientas, y están ahí para cada sesión.

Qué puedes hacer con esto

Las herramientas cubren todo el ciclo de vida del desarrollo a través de Copilot Chat:

Aprender — pregunta sobre servicios de Azure, buenas prácticas, patrones de arquitectura
Diseñar y desarrollar — obtén recomendaciones de servicios, configura el código de tu aplicación
Desplegar — aprovisiona recursos y despliega directamente desde el IDE
Solucionar problemas — consulta logs, verifica el estado de los recursos, diagnostica problemas en producción

Un ejemplo rápido — escribe esto en Copilot Chat:

List my storage accounts in my current subscription.

Copilot llama a las herramientas Azure MCP detrás de escena, consulta tus suscripciones, y devuelve una lista formateada con nombres, ubicaciones y SKUs. Sin necesidad del portal.

Cómo activarlo

Actualiza a Visual Studio 2022 17.14.30 o superior
Asegúrate de tener instalada la carga de trabajo Azure development
Abre GitHub Copilot Chat
Haz clic en el botón Select tools (el icono de las dos llaves)
Activa Azure MCP Server

Eso es todo. Se mantiene activado entre sesiones.

Una advertencia

Las herramientas están desactivadas por defecto — necesitas activarlas manualmente. Y las herramientas específicas de VS 2026 no están disponibles en VS 2022. La disponibilidad de herramientas también depende de los permisos de tu suscripción de Azure, igual que en el portal.

El panorama general

Esto es parte de una tendencia clara: MCP se está convirtiendo en el estándar para exponer herramientas de la nube en los IDEs de desarrollo. Ya hemos visto el lanzamiento estable de Azure MCP Server 2.0 e integraciones de MCP en VS Code y otros editores. Tenerlo integrado en el sistema de cargas de trabajo de Visual Studio es la progresión natural.

Para los que somos desarrolladores .NET y vivimos en Visual Studio, esto elimina una razón más para cambiar de contexto al portal de Azure. Y sinceramente, mientras menos cambio de pestañas, mejor.

azd update — Un solo comando para gobernar todos tus gestores de paquetes

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

¿Conoces ese mensaje de “Hay una nueva versión de azd disponible” que aparece cada pocas semanas? ¿Ese que ignoras porque no recuerdas si instalaste azd con winget, Homebrew o ese script de curl que ejecutaste hace seis meses? Bueno, eso por fin tiene solución.

Microsoft acaba de lanzar azd update — un único comando que actualiza Azure Developer CLI a la última versión sin importar cómo lo instalaste originalmente. Windows, macOS, Linux — da igual. Un solo comando.

Cómo funciona

azd update

Eso es todo. Si quieres acceso anticipado a nuevas funcionalidades, puedes cambiar a la build diaria de insiders:

azd update --channel daily
azd update --channel stable

El comando detecta tu método de instalación actual y usa el mecanismo de actualización apropiado internamente. Se acabó el “espera, ¿usé winget o choco en esta máquina?”

El pequeño detalle

azd update viene a partir de la versión 1.23.x. Si estás en una versión anterior, necesitarás hacer una última actualización manual usando tu método de instalación original. Después de eso, azd update se encarga de todo en adelante.

Comprueba tu versión actual con azd version. Si necesitas una instalación desde cero, la documentación de instalación te cubre.

Por qué importa

Es una pequeña mejora de calidad de vida, pero para los que usamos azd a diario para desplegar agentes de IA y apps de Aspire en Azure, estar actualizado significa menos momentos de “ese bug ya estaba corregido en la última versión”. Una cosa menos en la que pensar.

Lee el anuncio completo y el análisis más detallado de Jon Gallant para más contexto.

.NET Aspire 13.2 Quiere Ser el Mejor Amigo de Tu Agente de IA

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

¿Conoces ese momento cuando tu agente de IA escribe código sólido, te emocionas, y luego todo se desmorona cuando intenta ejecutar la cosa? Conflictos de puertos, procesos fantasma, variables de entorno incorrectas — de repente tu agente está quemando tokens depurando problemas de arranque en vez de construir funcionalidades.

El equipo de Aspire acaba de publicar un post muy bien pensado sobre exactamente este problema, y su respuesta es convincente: Aspire 13.2 está diseñado no solo para humanos, sino para agentes de IA.

El problema es real

Los agentes de IA son increíbles escribiendo código. Pero enviar una app full-stack funcional involucra mucho más que generar archivos. Necesitas iniciar servicios en el orden correcto, gestionar puertos, configurar variables de entorno, conectar bases de datos y obtener retroalimentación cuando algo se rompe. Ahora mismo, la mayoría de agentes manejan todo esto por prueba y error — ejecutando comandos, leyendo errores, intentando de nuevo.

Le metemos instrucciones en Markdown, skills personalizados y prompts para guiarlos, pero son impredecibles, no se pueden compilar y cuestan tokens solo para parsear. El equipo de Aspire dio en el clavo con la idea central: los agentes necesitan compiladores y APIs estructuradas, no más Markdown.

Aspire como infraestructura para agentes

Esto es lo que Aspire 13.2 trae a la mesa del desarrollo agéntico:

Todo tu stack en código tipado. El AppHost define tu topología completa — API, frontend, base de datos, caché — en TypeScript o C# compilable:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Un agente puede leer esto para entender la topología de la app, agregar recursos, conectar componentes y compilar para verificar. El compilador le dice inmediatamente si algo está mal. Sin adivinanzas, sin prueba y error con archivos de configuración.

Un solo comando para gobernarlos a todos. En vez de que los agentes malabareen docker compose up, npm run dev y scripts de arranque de bases de datos, todo es simplemente aspire start. Todos los recursos se lanzan en el orden correcto, en los puertos correctos, con la configuración correcta. Los procesos de larga duración tampoco cuelgan al agente — Aspire los gestiona.

Modo aislado para agentes en paralelo. Con --isolated, cada ejecución de Aspire obtiene sus propios puertos aleatorios y secretos de usuario separados. ¿Tienes múltiples agentes trabajando en git worktrees? No colisionarán. Esto es enorme para herramientas como los agentes en segundo plano de VS Code que crean entornos paralelos.

Ojos de agente a través de telemetría. Aquí es donde se pone realmente potente. El CLI de Aspire expone datos OpenTelemetry completos durante el desarrollo — trazas, métricas, logs estructurados. Tu agente no solo lee la salida de consola esperando lo mejor. Puede rastrear una petición fallida entre servicios, perfilar endpoints lentos e identificar exactamente dónde se rompen las cosas. Eso es observabilidad de nivel producción en el ciclo de desarrollo.

La analogía de los parachoques de boliche

El equipo de Aspire usa una gran analogía: piensa en Aspire como los parachoques de una pista de boliche para agentes de IA. Si el agente no es perfecto (y no lo será), los parachoques evitan que tire canaletas. La definición del stack previene mala configuración, el compilador atrapa errores, el CLI maneja la gestión de procesos y la telemetría provee el ciclo de retroalimentación.

Combina esto con algo como Playwright CLI, y tu agente puede realmente usar tu app — haciendo clic en flujos, revisando el DOM, viendo cosas rotas en telemetría, arreglando el código, reiniciando y probando de nuevo. Construir, ejecutar, observar, arreglar. Ese es el ciclo de desarrollo autónomo que hemos estado persiguiendo.

Primeros pasos

¿Nuevo en Aspire? Instala el CLI desde get.aspire.dev y sigue la guía de inicio.

¿Ya usas Aspire? Ejecuta aspire update --self para obtener la 13.2, luego apunta tu agente de código favorito a tu repo. Te sorprenderá lo mucho más lejos que llega con los guardrails de Aspire.

Para cerrar

Aspire 13.2 ya no es solo un framework para aplicaciones distribuidas — se está convirtiendo en infraestructura esencial para agentes. Definiciones de stack estructuradas, arranque con un comando, ejecuciones paralelas aisladas y telemetría en tiempo real le dan a los agentes de IA exactamente lo que necesitan para pasar de escribir código a enviar apps.

Lee el post completo del equipo de Aspire para todos los detalles y videos de demostración.

El Modo Aislado de Aspire Resuelve la Pesadilla de Conflictos de Puertos en Desarrollo Paralelo

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Si alguna vez intentaste ejecutar dos instancias del mismo proyecto al mismo tiempo, conoces el dolor. El puerto 8080 ya está en uso. El puerto 17370 está ocupado. Mata algo, reinicia, malabarea variables de entorno — es un asesino de productividad.

Este problema está empeorando, no mejorando. Los agentes de IA crean git worktrees para trabajar de forma independiente. Los agentes en segundo plano levantan entornos separados. Los desarrolladores hacen checkout del mismo repo dos veces para ramas de funcionalidades. Cada uno de estos escenarios choca con la misma pared: dos instancias de la misma app peleando por los mismos puertos.

Aspire 13.2 resuelve esto con un solo flag. James Newton-King del equipo de Aspire escribió todos los detalles, y es una de esas funcionalidades de “¿por qué no teníamos esto antes?”

La solución: `--isolated`

aspire run --isolated

Eso es todo. Cada ejecución obtiene:

Puertos aleatorios — no más colisiones entre instancias
Secretos de usuario aislados — cadenas de conexión y claves API permanecen separados por instancia

Sin reasignación manual de puertos. Sin malabarismo de variables de entorno. Cada ejecución obtiene un entorno limpio y libre de colisiones automáticamente.

Escenarios reales donde esto brilla

Múltiples checkouts. Tienes una rama de funcionalidad en un directorio y un bugfix en otro:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Ambos se ejecutan sin conflictos. El dashboard muestra qué está corriendo y dónde.

Agentes en segundo plano en VS Code. Cuando el agente en background de Copilot Chat crea un git worktree para trabajar en tu código de forma independiente, puede necesitar ejecutar tu AppHost de Aspire. Sin --isolated, eso es una colisión de puertos con tu worktree principal. Con él, ambas instancias simplemente funcionan.

El skill de Aspire que viene con aspire agent init instruye automáticamente a los agentes a usar --isolated cuando trabajan en worktrees. Así que el agente en background de Copilot debería manejar esto de forma nativa.

Tests de integración junto al desarrollo. ¿Necesitas ejecutar tests contra un AppHost en vivo mientras sigues construyendo funcionalidades? El modo aislado le da a cada contexto sus propios puertos y configuración.

Cómo funciona internamente

Cuando pasas --isolated, el CLI genera un ID de instancia único para la ejecución. Esto impulsa dos comportamientos:

Aleatorización de puertos — en vez de vincularse a puertos predecibles definidos en la configuración de tu AppHost, el modo aislado elige puertos aleatorios disponibles para todo — el dashboard, los endpoints de servicio, todo. El service discovery se ajusta automáticamente, así que los servicios se encuentran entre sí sin importar qué puertos les tocaron.
Aislamiento de secretos — cada ejecución aislada obtiene su propio almacén de secretos de usuario, identificado por el ID de instancia. Las cadenas de conexión y claves API de una ejecución no se filtran a otra.

Tu código no necesita cambios. El service discovery de Aspire resuelve los endpoints en tiempo de ejecución, así que todo se conecta correctamente sin importar la asignación de puertos.

Cuándo usarlo

Usa --isolated cuando ejecutes múltiples instancias del mismo AppHost simultáneamente — ya sea desarrollo paralelo, tests automatizados, agentes de IA o git worktrees. Para desarrollo de instancia única donde prefieras puertos predecibles, el aspire run regular sigue funcionando bien.

Para cerrar

El modo aislado es una funcionalidad pequeña que resuelve un problema real y cada vez más común. A medida que el desarrollo asistido por IA nos empuja hacia más flujos paralelos — múltiples agentes, múltiples worktrees, múltiples contextos — la capacidad de simplemente levantar otra instancia sin pelear por puertos es esencial.

Lee el post completo para todos los detalles técnicos y pruébalo con aspire update --self para obtener la 13.2.

Esa Configuración de Ventanas Flotantes de Visual Studio Que No Conocías (Pero Deberías)

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Si usas múltiples monitores con Visual Studio (y honestamente, ¿quién no lo hace hoy en día?), probablemente hayas experimentado la molestia: las ventanas flotantes de herramientas desaparecen cuando minimizas el IDE principal, siempre se quedan encima de todo lo demás, y no aparecen como botones separados en la barra de tareas. Funciona para algunos flujos de trabajo, pero para configuraciones con múltiples monitores es frustrante.

Mads Kristensen del equipo de Visual Studio compartió una configuración poco conocida que cambia completamente cómo se comportan las ventanas flotantes. Un desplegable. Eso es todo.

La configuración

Tools > Options > Environment > Windows > Floating Windows

El desplegable “These floating windows are owned by the main window” tiene tres opciones:

None — independencia total. Cada ventana flotante tiene su propia entrada en la barra de tareas y se comporta como una ventana normal de Windows.
Tool Windows (predeterminado) — los documentos flotan libremente, las ventanas de herramientas quedan vinculadas al IDE.
Documents and Tool Windows — comportamiento clásico de Visual Studio, todo vinculado a la ventana principal.

Por qué “None” es la mejor opción para configuraciones con múltiples monitores

Configúralo en None y de repente todas tus ventanas flotantes de herramientas y documentos se comportan como aplicaciones reales de Windows. Aparecen en la barra de tareas, permanecen visibles cuando minimizas la ventana principal de Visual Studio, y dejan de forzarse al frente de todo.

Combina esto con PowerToys FancyZones y es un cambio total. Crea diseños personalizados a través de tus monitores, coloca tu Explorador de Soluciones en una zona, el depurador en otra, y los archivos de código donde quieras. Todo se mantiene en su lugar, todo es accesible de forma independiente, y tu espacio de trabajo se siente organizado en lugar de caótico.

Recomendaciones rápidas

Usuarios avanzados con múltiples monitores: Configura en None, combina con FancyZones
Flotadores ocasionales: Tool Windows (predeterminado) es un buen punto medio
Flujo de trabajo tradicional: Documents and Tool Windows mantiene todo clásico

Consejo pro: Ctrl + doble clic en la barra de título de cualquier ventana de herramientas para flotarla o anclarla instantáneamente. No se necesita reiniciar después de cambiar la configuración.

Conclusión

Es una de esas configuraciones de “no puedo creer que no lo sabía”. Si las ventanas flotantes en Visual Studio alguna vez te han molestado, ve a cambiar esto ahora mismo.

Lee el post completo para los detalles y capturas de pantalla.

VS Code 1.116 — La App de Agentes Obtiene Navegación por Teclado y Autocompletado de Contexto de Archivos

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

VS Code 1.116 es la versión de abril de 2026, y aunque es más ligera que algunas actualizaciones recientes, los cambios son enfocados y significativos — especialmente si estás usando la app de Agentes a diario.

Esto es lo que llegó, basado en las notas de la versión oficial.

Mejoras en la app de Agentes

La app de Agentes sigue madurando con pulido de usabilidad que marca una diferencia real en los flujos de trabajo diarios:

Atajos de teclado dedicados — ahora puedes enfocar la vista de Cambios, el árbol de archivos dentro de Cambios, y la vista de Personalizaciones del Chat con comandos dedicados y atajos de teclado. Si has estado haciendo clic por toda la app de Agentes para navegar, esto trae flujos de trabajo completamente controlados por teclado.

Diálogo de ayuda de accesibilidad — presionar Alt+F1 en el cuadro de entrada del chat ahora abre un diálogo de ayuda de accesibilidad que muestra los comandos y atajos disponibles. Los usuarios de lectores de pantalla también pueden controlar la verbosidad de los anuncios. La buena accesibilidad beneficia a todos.

Autocompletado de contexto de archivos — escribe # en el chat de la app de Agentes para activar el autocompletado de contexto de archivos dentro de tu espacio de trabajo actual. Esta es una de esas pequeñas mejoras de calidad de vida que aceleran cada interacción — no más escribir rutas completas de archivos al referenciar código.

Resolución de enlaces CSS `@import`

Una buena para los desarrolladores frontend: VS Code ahora resuelve las referencias CSS @import que usan rutas de node_modules. Puedes hacer Ctrl+clic a través de imports como @import "some-module/style.css" cuando usas bundlers. Pequeño pero elimina un punto de fricción en los flujos de trabajo CSS.

Conclusión

VS Code 1.116 trata sobre refinamiento — hacer la app de Agentes más navegable, más accesible y más amigable con el teclado. Si pasas tiempo significativo en la app de Agentes (y sospecho que muchos de nosotros lo hacemos), estos cambios se acumulan.

Revisa las notas de la versión completas para la lista completa.

VS Code 1.115 — Notificaciones de Terminal en Segundo Plano, Modo Agente SSH y Más

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

VS Code 1.115 acaba de lanzarse, y aunque es una versión más ligera en cuanto a funcionalidades destacadas, las mejoras relacionadas con agentes son genuinamente útiles si trabajás con asistentes de código con IA todos los días.

Déjame resaltar lo que realmente vale la pena saber.

Las terminales en segundo plano ahora se comunican con los agentes

Esta es la funcionalidad estrella. Las terminales en segundo plano ahora notifican automáticamente a los agentes cuando los comandos terminan, incluyendo el código de salida y la salida de la terminal. Las solicitudes de entrada en terminales en segundo plano también se detectan y se muestran al usuario.

¿Por qué importa esto? Si usaste el modo agente de Copilot para ejecutar comandos de compilación o suites de tests en segundo plano, conocés el dolor del “¿ya terminó eso?” — las terminales en segundo plano eran básicamente disparar-y-olvidar. Ahora el agente recibe una notificación cuando tu dotnet build o dotnet test termina, ve la salida y puede reaccionar en consecuencia. Es un cambio pequeño que hace que los flujos de trabajo impulsados por agentes sean significativamente más confiables.

También hay una nueva herramienta send_to_terminal que permite a los agentes enviar comandos a terminales en segundo plano con confirmación del usuario, solucionando el problema donde run_in_terminal con un timeout movía las terminales al segundo plano y las dejaba como solo lectura.

Hosting remoto de agentes por SSH

VS Code ahora soporta conectarse a máquinas remotas por SSH, instalando automáticamente el CLI e iniciándolo en modo host de agentes. Esto significa que tus sesiones de agentes de IA pueden apuntar a entornos remotos directamente — útil para desarrolladores .NET que compilan y prueban en servidores Linux o VMs en la nube.

Seguimiento de ediciones en sesiones de agentes

Las ediciones de archivos realizadas durante sesiones de agentes ahora se rastrean y restauran, con diffs, deshacer/rehacer y restauración de estado. Si un agente hace cambios en tu código y algo sale mal, podés ver exactamente qué cambió y revertirlo. Tranquilidad para dejar que los agentes modifiquen tu codebase.

Reconocimiento de pestañas del navegador y otras mejoras

Algunas mejoras adicionales de calidad de vida:

Seguimiento de pestañas del navegador — el chat ahora puede rastrear y enlazar a pestañas del navegador abiertas durante una sesión, para que los agentes puedan referenciar páginas web que estás viendo
Pegado de archivos en la terminal — pegá archivos (incluyendo imágenes) en la terminal con Ctrl+V, arrastrar y soltar, o clic derecho
Cobertura de tests en el minimapa — los indicadores de cobertura de tests ahora se muestran en el minimapa para una vista visual rápida
Pellizcar para zoom en Mac — el navegador integrado soporta gestos de pellizcar para zoom
Derechos de Copilot en Sesiones — la barra de estado muestra información de uso en la vista de Sesiones
Favicon en Ir a Archivo — las páginas web abiertas muestran favicons en la lista de selección rápida

Conclusión

VS Code 1.115 es una versión incremental, pero las mejoras de agentes — notificaciones de terminal en segundo plano, hosting de agentes por SSH y seguimiento de ediciones — se suman a una experiencia notablemente más fluida para el desarrollo asistido por IA. Si estás usando el modo agente de Copilot para proyectos .NET, estos son el tipo de mejoras de calidad de vida que reducen la fricción diaria.

Mirá las notas de la versión completas para cada detalle.

Aspire 13.2 incluye una CLI de documentación — y tu agente de IA también puede usarla

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

¿Conocés ese momento cuando estás metido hasta el cuello en un Aspire AppHost, conectando integraciones, y necesitás verificar exactamente qué parámetros espera la integración de Redis? Hacés alt-tab al navegador, buscás por aspire.dev, entrecerrás los ojos mirando los docs de la API, y volvés a tu editor. Contexto perdido. Flujo roto.

Aspire 13.2 acaba de lanzar una solución para eso. La CLI aspire docs te permite buscar, explorar y leer documentación oficial de Aspire directamente desde tu terminal. Y como está respaldada por servicios reutilizables, los agentes de IA y skills pueden usar los mismos comandos para consultar docs en lugar de alucinar APIs que no existen.

El problema que esto realmente resuelve

David Pine lo clava en el post original: los agentes de IA eran terribles ayudando a los desarrolladores a construir apps con Aspire. Recomendaban dotnet run en vez de aspire run, referenciaban learn.microsoft.com para docs que viven en aspire.dev, sugerían paquetes NuGet desactualizados, y — mi favorito personal — alucinaban APIs que no existen.

¿Por qué? Porque Aspire fue específico de .NET por mucho más tiempo del que lleva siendo políglota, y los LLMs trabajan con datos de entrenamiento que preceden las últimas funcionalidades. Cuando le das a un agente de IA la capacidad de buscar los docs actuales, deja de adivinar y empieza a ser útil.

Tres comandos, cero pestañas del navegador

La CLI es refrescantemente simple:

Listar todos los docs

aspire docs list

Devuelve cada página de documentación disponible en aspire.dev. ¿Necesitás salida legible por máquina? Agregá --format Json.

Buscar un tema

aspire docs search "redis"

Busca tanto en títulos como en contenido con puntuación de relevancia ponderada. El mismo motor de búsqueda que alimenta la herramienta de documentación internamente. Obtenés resultados rankeados con títulos, slugs y puntuaciones de relevancia.

Leer una página completa (o solo una sección)

aspire docs get redis-integration

Transmite la página completa como markdown a tu terminal. ¿Necesitás solo una sección?

aspire docs get redis-integration --section "Add Redis resource"

Precisión quirúrgica. Sin hacer scroll por 500 líneas. Solo la parte que necesitás.

El ángulo del agente de IA

Acá es donde se pone interesante para los que desarrollamos con herramientas de IA. Los mismos comandos de aspire docs funcionan como herramientas para agentes de IA — a través de skills, servidores MCP, o wrappers simples de CLI.

En vez de que tu asistente de IA invente APIs de Aspire basándose en datos de entrenamiento obsoletos, puede llamar a aspire docs search "postgres", encontrar los docs oficiales de integración, leer la página correcta, y darte el enfoque documentado. Documentación en tiempo real y actual — no lo que el modelo memorizó hace seis meses.

La arquitectura detrás de esto es intencional. El equipo de Aspire construyó servicios reutilizables (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) en lugar de una integración única. Eso significa que el mismo motor de búsqueda funciona para humanos en la terminal, agentes de IA en tu editor, y automatización en tu pipeline de CI.

Escenarios del mundo real

Consultas rápidas en terminal: Estás tres archivos adentro y necesitás los parámetros de configuración de Redis. Dos comandos, noventa segundos, de vuelta al trabajo:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Desarrollo asistido por IA: Tu skill de VS Code envuelve los comandos de la CLI. Preguntás “Agregá una base de datos PostgreSQL a mi AppHost” y el agente busca los docs reales antes de responder. Sin alucinaciones.

Validación en CI/CD: Tu pipeline valida configuraciones de AppHost contra documentación oficial de forma programática. La salida --format Json se conecta limpiamente con jq y otras herramientas.

Bases de conocimiento personalizadas: ¿Estás construyendo tu propia herramienta de IA? Enviá la salida JSON estructurada directamente a tu base de conocimiento:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Sin web scraping. Sin API keys. Los mismos datos estructurados que usa internamente la herramienta de documentación.

La documentación siempre está actualizada

Esta es la parte que más aprecio. La CLI no descarga una captura estática — consulta aspire.dev con caché basado en ETag. En el momento en que los docs se actualizan, tu CLI y cualquier skill construido sobre ella lo refleja. Sin copias obsoletas, sin momentos de “pero el wiki decía…”.

Para cerrar

aspire docs es una de esas funcionalidades pequeñas que resuelve un problema real de forma limpia. Los humanos obtienen acceso a documentación nativa de terminal. Los agentes de IA obtienen una forma de dejar de adivinar y empezar a referenciar docs reales. Y todo está respaldado por la misma fuente de verdad.

Si estás construyendo con .NET Aspire y todavía no probaste la CLI, ejecutá aspire docs search "tu-tema-aquí" y fijate cómo se siente. Después considerá envolver esos comandos en cualquier skill de IA o configuración de automatización que estés usando — tus agentes te lo van a agradecer.

Mirá el análisis profundo de David Pine sobre cómo se armó la herramienta de documentación, y la referencia oficial de la CLI para todos los detalles.

azd ahora te permite ejecutar y depurar agentes IA localmente — Esto es lo que cambió en marzo 2026

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Siete versiones en un mes. Eso es lo que el equipo del Azure Developer CLI (azd) publicó en marzo 2026, y la función estrella es la que estaba esperando: un bucle local de ejecución y depuración para agentes IA.

PC Chan publicó el resumen completo, y aunque hay mucho contenido, déjame filtrarlo a lo que realmente importa para desarrolladores .NET que construyen apps con IA.

Ejecutar y depurar agentes IA sin desplegar

Esta es la grande. La nueva extensión azure.ai.agents añade un conjunto de comandos que te dan una experiencia de bucle interno adecuada para agentes IA:

azd ai agent run — inicia tu agente localmente
azd ai agent invoke — le envía mensajes (local o desplegado)
azd ai agent show — muestra el estado del contenedor y su salud
azd ai agent monitor — transmite logs del contenedor en tiempo real

Antes, probar un agente IA significaba desplegarlo en Microsoft Foundry cada vez que hacías un cambio. Ahora puedes iterar localmente, probar el comportamiento de tu agente, y solo desplegarlo cuando estés listo. Si has estado construyendo agentes con el Microsoft Agent Framework o Semantic Kernel, esto cambia tu flujo de trabajo diario.

El comando invoke funciona tanto contra agentes locales como desplegados, lo que significa que puedes usar el mismo flujo de pruebas sin importar dónde esté corriendo el agente. Ese es el tipo de detalle que te ahorra mantener dos conjuntos de scripts de prueba.

GitHub Copilot configura tu proyecto azd

azd init ahora ofrece una opción “Set up with GitHub Copilot (Preview)”. En lugar de responder prompts manualmente sobre la estructura de tu proyecto, un agente Copilot genera la configuración por ti. Verifica que el directorio de trabajo esté limpio antes de modificar archivos y pide consentimiento de herramientas MCP por adelantado.

Cuando un comando falla, azd ahora ofrece troubleshooting asistido por IA: elige una categoría (explicar, guiar, solucionar o saltar), deja que el agente sugiera una corrección, y reintenta — todo sin salir de la terminal. Para configuraciones de infraestructura complejas, eso ahorra tiempo real.

Container App Jobs y mejoras de despliegue

Algunas funciones de despliegue que vale la pena mencionar:

Container App Jobs: azd ahora despliega Microsoft.App/jobs a través de la configuración existente host: containerapp. Tu plantilla Bicep determina si el destino es un Container App o un Job — sin configuración extra.
Timeouts configurables: Nueva flag --timeout en azd deploy y un campo deployTimeout en azure.yaml. Sin más adivinanzas sobre el límite predeterminado de 1200 segundos.
Fallback de build remoto: Cuando falla el build remoto en ACR, azd hace fallback automático a Docker/Podman local.
Validación preflight local: Los parámetros de Bicep se validan localmente antes de desplegar, detectando parámetros faltantes sin un viaje de ida y vuelta a Azure.

Pulido en la experiencia de desarrollador

Algunas mejoras más pequeñas que se suman:

Detección automática de pnpm/yarn para proyectos JS/TS
Soporte para pyproject.toml para paquetes Python
Directorios de plantillas locales — azd init --template ahora acepta rutas del sistema de archivos para iteración offline
Mejores mensajes de error en modo --no-prompt — todos los valores faltantes reportados de una vez con comandos de resolución
Variables de entorno de build inyectadas en todos los subprocesos de build (.NET, Node.js, Java, Python)

La última es sutil pero importante: tu build .NET ahora tiene acceso a las variables de entorno de azd, lo que significa que puedes hacer inyección de configuración en tiempo de compilación sin scripting adicional.

Para cerrar

El bucle de depuración local de agentes IA es la estrella de esta versión, pero la acumulación de mejoras de despliegue y refinamiento de DX hace que azd se sienta más maduro que nunca. Si estás desplegando apps .NET en Azure — especialmente agentes IA — esta actualización vale la pena.

Revisa las notas completas de la versión para todos los detalles, o comienza con la instalación de azd.

Azure DevOps por fin arregla el editor Markdown que todos odiaban

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Si usas Azure Boards, probablemente has vivido esto: estás leyendo la descripción de un work item, tal vez revisando los criterios de aceptación, y accidentalmente haces doble clic. Boom — estás en modo edición. No querías editar nada. Solo estabas leyendo.

Dan Hellem anunció la corrección, y es uno de esos cambios que suenan pequeños pero realmente eliminan fricción de tu flujo de trabajo diario.

Qué cambió

El editor Markdown para campos de texto de work items ahora abre en modo vista previa por defecto. Puedes leer e interactuar con el contenido — seguir enlaces, revisar formato — sin preocuparte por entrar accidentalmente en modo edición.

Cuando realmente quieres editar, haces clic en el ícono de edición en la parte superior del campo. Cuando terminas, sales explícitamente al modo vista previa. Simple, intencional, predecible.

Eso es. Ese es el cambio.

Por qué importa más de lo que parece

El hilo de feedback de la comunidad sobre esto era largo. El comportamiento de doble clic para editar se introdujo con el editor Markdown en julio 2025, y las quejas empezaron casi inmediatamente. El problema no eran solo las ediciones accidentales — era que toda la interacción se sentía impredecible.

Para equipos que hacen planificación de sprints, refinamiento de backlog o revisión de código con Azure Boards, este tipo de micro-fricción se acumula. Cada entrada accidental al modo edición es un cambio de contexto. Cada momento de “espera, ¿cambié algo?” es atención desperdiciada.

Estado del despliegue

Ya se está implementando para un subconjunto de clientes y se expandirá a todos en las próximas dos o tres semanas.

Para cerrar

No toda mejora necesita ser una función titular. A veces la mejor actualización es simplemente eliminar algo molesto. Esta es una de esas — una pequeña corrección de UX que hace que Azure Boards se sienta menos hostil para las personas que solo quieren leer sus work items en paz.

Bookmark Studio trae navegación por slots y compartir a los marcadores de Visual Studio

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Los marcadores en Visual Studio siempre han sido… aceptables. Pones uno, navegas al siguiente, olvidas cuál es cuál. Funcionan, pero nunca han sido una función que llamarías poderosa.

Mads Kristensen acaba de lanzar Bookmark Studio, una extensión experimental que llena exactamente los vacíos que probablemente has encontrado si usas marcadores regularmente.

Navegación por slots

Los marcadores se pueden asignar a slots del 1 al 9 y saltar directamente con Alt+Shift+1 hasta Alt+Shift+9. Los nuevos marcadores obtienen automáticamente el siguiente slot disponible.

El Gestor de Marcadores

Una nueva ventana de herramientas muestra todos tus marcadores en un solo lugar con filtrado por nombre, archivo, ubicación, color o slot.

Organización con etiquetas, colores y carpetas

Los marcadores pueden tener opcionalmente etiquetas, colores y agruparse en carpetas. Toda la metadata se almacena por solución.

Exportar y compartir

Bookmark Studio permite exportar marcadores como texto plano, Markdown o CSV. Puedes incluir rutas de marcadores en descripciones de PR o compartir caminos de investigación con compañeros.

Marcadores que siguen al código

Bookmark Studio rastrea los marcadores relativos al texto al que están anclados, así que no se desplazan a líneas incorrectas mientras editas.

Para cerrar

Bookmark Studio no reinventa nada. Toma una función que ha sido “suficiente” durante años y la hace genuinamente útil. Descárgalo del Visual Studio Marketplace.

La actualización de marzo de Visual Studio te permite crear agentes Copilot personalizados — y find_symbol es clave

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Visual Studio acaba de recibir su actualización de Copilot más significativa hasta ahora. Mark Downie anunció la versión de marzo, y el titular son los agentes personalizados — pero honestamente, la herramienta find_symbol podría ser la función que más cambie tu flujo de trabajo.

Agentes Copilot personalizados en tu repo

¿Quieres que Copilot siga los estándares de código de tu equipo, ejecute tu pipeline de build, o consulte tus docs internos? Ahora puedes construir exactamente eso.

Los agentes personalizados se definen como archivos .agent.md que colocas en .github/agents/ en tu repositorio. Cada agente tiene acceso completo al workspace, comprensión del código, herramientas, tu modelo preferido, y conexiones MCP a servicios externos.

Agent skills: paquetes de instrucciones reutilizables

Los skills se cargan automáticamente desde .github/skills/ en tu repo o ~/.copilot/skills/ en tu perfil. Piensa en los skills como experiencia modular que puedes mezclar y combinar.

find_symbol: navegación con reconocimiento de lenguaje

La nueva herramienta find_symbol le da al modo agente de Copilot navegación de símbolos basada en servicios de lenguaje. En lugar de buscar texto, el agente puede encontrar todas las referencias a un símbolo, acceder a información de tipos, declaraciones y alcance.

Para desarrolladores .NET, esto es una mejora enorme — las bases de código C# con jerarquías de tipos profundas e interfaces se benefician enormemente.

Perfilar tests con Copilot

Hay un nuevo comando Profile with Copilot en el menú contextual del Test Explorer. Selecciona un test, haz clic en perfilar, y el Profiling Agent lo ejecuta y analiza automáticamente.

Perf tips durante debugging en vivo

La optimización de rendimiento ahora ocurre mientras depuras. Visual Studio muestra tiempo de ejecución y señales de rendimiento inline. ¿Ves una línea lenta? Haz clic en el Perf Tip y pídele a Copilot sugerencias de optimización.

Corregir vulnerabilidades de NuGet desde Solution Explorer

Cuando se detecta una vulnerabilidad en un paquete NuGet, verás un enlace Fix with GitHub Copilot directamente en Solution Explorer.

Para cerrar

Agentes personalizados y skills son el titular, pero find_symbol es la joya oculta — cambia fundamentalmente la precisión de Copilot al refactorizar código .NET. Combinado con profiling en vivo y corrección de vulnerabilidades, esta actualización hace que las funciones de IA de Visual Studio se sientan genuinamente prácticas.

Descarga Visual Studio 2026 Insiders para probarlo todo.

Del portátil a producción: desplegando agentes de IA en Microsoft Foundry con dos comandos

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

¿Conoces esa brecha entre “funciona en mi máquina” y “está desplegado y sirviendo tráfico”? Para agentes de IA, esa brecha ha sido dolorosamente amplia. Necesitas provisionar recursos, desplegar modelos, configurar identidad, montar monitoreo — y eso es antes de que alguien pueda realmente llamar a tu agente.

El Azure Developer CLI acaba de convertir esto en un asunto de dos comandos.

El nuevo flujo de trabajo `azd ai agent`

Déjame mostrarte cómo se ve esto realmente. Tienes un proyecto de agente de IA — digamos un agente concierge de hotel. Funciona localmente. Quieres que corra en Microsoft Foundry.

azd ai agent init
azd up

Eso es todo. Dos comandos. azd ai agent init genera la infraestructura como código en tu repositorio, y azd up provisiona todo en Azure y publica tu agente. Obtienes un enlace directo a tu agente en el portal de Foundry.

Qué pasa por debajo

El comando init genera plantillas Bicep reales e inspeccionables en tu repositorio:

Un Foundry Resource (contenedor de nivel superior)
Un Foundry Project (donde vive tu agente)
Configuración de despliegue de modelo (GPT-4o, etc.)
Identidad administrada con asignaciones de roles RBAC apropiadas
azure.yaml para el mapa de servicios
agent.yaml con metadatos del agente y variables de entorno

La parte clave: todo esto es tuyo. Es Bicep versionado en tu repositorio. Puedes inspeccionarlo, personalizarlo y hacer commit junto con el código de tu agente. Sin cajas negras mágicas.

El ciclo interno de desarrollo

Lo que realmente me gusta es la historia de desarrollo local. Cuando estás iterando sobre la lógica del agente, no quieres redesplegar cada vez que cambias un prompt:

azd ai agent run

Esto inicia tu agente localmente. Combínalo con azd ai agent invoke para enviar prompts de prueba, y tienes un ciclo de retroalimentación rápido. Editar código, reiniciar, invocar, repetir.

El comando invoke es inteligente con el enrutamiento también — cuando un agente local está corriendo, lo apunta automáticamente. Cuando no, apunta al endpoint remoto.

Monitoreo en tiempo real

Esta es la característica que me convenció. Una vez que tu agente está desplegado:

azd ai agent monitor --follow

Cada petición y respuesta que fluye a través de tu agente se transmite a tu terminal en tiempo real. Para depurar problemas en producción, esto es invaluable. Sin buscar en log analytics, sin esperar a que las métricas se agreguen — ves lo que está pasando ahora mismo.

El set completo de comandos

Aquí la referencia rápida:

Comando	Qué hace
`azd ai agent init`	Genera un proyecto de agente Foundry con IaC
`azd up`	Provisiona recursos Azure y despliega el agente
`azd ai agent invoke`	Envía prompts al agente remoto o local
`azd ai agent run`	Ejecuta el agente localmente para desarrollo
`azd ai agent monitor`	Transmite logs en tiempo real del agente publicado
`azd ai agent show`	Verifica la salud y estado del agente
`azd down`	Limpia todos los recursos Azure

Por qué esto importa para desarrolladores .NET

Aunque el ejemplo del anuncio está basado en Python, la historia de infraestructura es agnóstica al lenguaje. Tu agente .NET obtiene el mismo scaffolding Bicep, la misma configuración de identidad administrada, el mismo pipeline de monitoreo. Y si ya estás usando azd para tus apps .NET Aspire o despliegues Azure, esto encaja directamente en tu flujo de trabajo existente.

La brecha de despliegue para agentes de IA ha sido uno de los mayores puntos de fricción en el ecosistema. Pasar de un prototipo funcional a un endpoint de producción con identidad, networking y monitoreo adecuados no debería requerir una semana de trabajo DevOps. Ahora requiere dos comandos y unos minutos.

Para cerrar

azd ai agent está disponible ahora. Si has estado posponiendo el despliegue de tus agentes de IA porque la configuración de infraestructura parecía demasiado trabajo, dale una oportunidad. Revisa el tutorial completo para el paso a paso completo incluyendo integración de app de chat frontend.

Developer Tools | The .NET Blog

VS Code 1.119: OpenTelemetry para sesiones de agentes, integración del navegador y seguridad

Trazado OpenTelemetry para sesiones de agentes

Los agentes ahora pueden acceder a las pestañas del navegador

Uso optimizado de tokens

Confianza y seguridad

Cambio rápido a vista previa de Markdown

VS Code Agents (vista previa Insiders)

Azure Data Studio se retira: mueve tu flujo de Azure SQL a VS Code

Qué instalar

Migrar tus conexiones y configuraciones de ADS

Recuperar el músculo del F5

SQL Database Projects: esquema como código

Schema Compare y Schema Designer

Desarrolladores de Microsoft Fabric

Conclusión

Siguientes pasos practicos

Fuente

El Azure MCP Server Ahora es un .mcpb — Instálalo sin Ningún Runtime

¿Qué es un MCP Bundle?

Cómo instalarlo

Qué puedes hacer con él

¿Qué método de instalación usar?

Para empezar

VS Code 1.118: Copilot CLI Obtiene Nombres de Sesión, Insignias de Modelo y TypeScript 7.0 Nightly

Copilot CLI: las sesiones tienen nombres reales

Cambia de sesión más rápido con atajos de teclado

Insignias de modelo en el chat

Selección automática de modelo en Copilot CLI

Opt-in a TypeScript 7.0 nightly

Bajo el capó: limpieza de node-pty

Foundry Toolboxes: Un único endpoint para todas las herramientas de tus agentes

¿Qué es un Toolbox?

Los cuatro pilares (dos disponibles hoy)

Empezando en la práctica

No estás bloqueado en Foundry Agents

Por qué importa ahora

Conclusión

Hooks de azd en Python, TypeScript y .NET: adiós a los scripts de shell

Hooks, brevemente, por si no los conoces

Cómo funciona la detección

Detalles importantes por lenguaje

Python

JavaScript y TypeScript

.NET

Config por ejecutor

Por qué importa para desarrolladores .NET

Conclusión

Windows App Dev CLI v0.3: F5 desde la terminal y automatización de UI para agentes

winapp run: F5 desde cualquier sitio

Nuevo paquete NuGet: dotnet run para apps empaquetadas

winapp ui: UI Automation desde la línea de comandos

Otras novedades

Cómo obtenerlo

VS Code 1.117: Los Agentes Están Obteniendo Sus Propias Ramas de Git y Estoy Totalmente a Favor

El modo Autopilot finalmente recuerda tu preferencia

Worktree y aislamiento de git para sesiones de agentes

Subagentes y equipos de agentes

La salida del terminal se incluye automáticamente cuando los agentes envían input

La app de Agents en macOS se auto-actualiza

Las cosas más pequeñas que vale la pena saber

La conclusión

Deja de vigilar tu terminal: el modo desacoplado de Aspire cambia el flujo de trabajo

Modo desacoplado: un comando, terminal de vuelta

Gestionando lo que está en ejecución

Combínalo con el modo aislado

Por qué esto es enorme para los agentes de código

Para cerrar

Docker Sandbox permite a los agentes de Copilot refactorizar tu código sin poner en riesgo tu máquina

Qué te da realmente Docker Sandbox

Por qué los desarrolladores .NET deberían prestar atención

El ángulo de seguridad importa

Conclusión

Las herramientas Azure MCP ahora vienen integradas en Visual Studio 2022 — Sin extensión necesaria

Qué significa esto realmente

Por qué esto importa más de lo que parece

Qué puedes hacer con esto

Cómo activarlo

Una advertencia

El panorama general

Bajo el capó: limpieza de `node-pty`

La solución: `--isolated`

Resolución de enlaces CSS `@import`

El nuevo flujo de trabajo `azd ai agent`