GitHub Copilot | The .NET Blog

Actualización de Abril del Azure DevOps MCP Server: Consultas WIQL, Auth PAT y MCP Apps Experimental

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

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

El Azure DevOps MCP Server sigue mejorando. La actualización de abril de Dan Hellem cubre tanto los servidores local como remoto, y hay algunas adiciones genuinamente útiles.

Soporte de Consultas WIQL

La nueva herramienta wit_query_by_wiql permite ejecutar consultas Work Item Query Language directamente desde tu cliente MCP. Tus sesiones de Copilot pueden ahora obtener conjuntos precisos de work items sin filtrar manualmente.

Personal Access Tokens en el Servidor Local

El servidor MCP local ahora soporta autenticación PAT — importante para escenarios de integración donde la autenticación interactiva no está disponible.

Anotaciones MCP en el Servidor Remoto

Etiquetas de metadatos para herramientas de solo lectura, destructivas y de mundo abierto — fundamentales para la fiabilidad de los agentes.

Consolidación de Herramientas Wiki

5 herramientas separadas de wiki → 2 herramientas más capaces. Menos herramientas = mejor rendimiento del LLM.

Experimental: MCP Apps

Flujos de trabajo empaquetados que se ejecutan dentro del entorno del servidor MCP. La idea es correcta — más composición de flujos de trabajo en la capa MCP, menos encadenamiento ad-hoc de herramientas.

Post original de Dan Hellem: Azure DevOps MCP Server April Update.

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.

¿68 Minutos al Día Re-Explicando Código a Copilot? Hay una Solución

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

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

¿Conoces ese momento en que tu sesión de Copilot llega al /compact y el agente olvida completamente lo que estabas haciendo? Pasas los siguientes cinco minutos re-explicando la estructura de archivos, el test fallido, los tres enfoques que ya intentaste. Y luego vuelve a pasar. Y otra vez.

Desi Villanueva lo midió: 68 minutos al día — solo en re-orientación. No escribiendo código. No revisando PRs. Solo poniéndole al día a la IA en cosas que ya sabía.

Resulta que hay una razón concreta por la que esto pasa, y una solución concreta.

La Mentira de la Ventana de Contexto

Tu agente viene con un número grande en la caja. 200K tokens. Suena masivo. En la práctica es un techo, no una garantía.

Aquí está la matemática real:

200K de contexto total
Menos ~65K para herramientas MCP cargadas al inicio (~33%)
Menos ~10K para archivos de instrucciones como AGENTS.md o copilot-instructions.md

Eso te deja aproximadamente 125K antes de escribir una sola palabra. Y empeora — los LLMs no se degradan de forma gradual al llenarse el contexto. Tienen un tope al llegar al 60% de capacidad. El modelo empieza a perder cosas mencionadas hace 30 turnos, contradice respuestas anteriores, alucina nombres de archivos que declaró con confianza hace 10 minutos. La industria llama a esto el problema del “lost in the middle”.

Límite efectivo: 45K tokens antes de que la calidad se degrade. Eso son tal vez 20-30 turnos de conversación activa antes de que el agente empiece a derivar. Por eso estás usando /compact cada 45 minutos — no porque hayas llenado 200K tokens, sino porque el modelo ya está “podrido” a los 120K.

El Impuesto de la Compactación

Cada /compact te cuesta el estado de flujo. Llevas 30 minutos en una sesión de depuración. El agente conoce la estructura de archivos, el test fallido, la hipótesis. Luego llega la advertencia.

Ignorarla → el agente se vuelve progresivamente más tonto, alucina el estado anterior
Ejecutar /compact → el agente tiene un resumen de 2 párrafos de una investigación de 30 minutos

De cualquier manera pierdes. De cualquier manera estás narrando tu propio proyecto como si fuera un empleado nuevo en su primer día.

La parte cruel: la memoria ya existe. Copilot CLI escribe cada sesión en una base de datos SQLite local en ~/.copilot/session-store.db — cada archivo tocado, cada turno, cada checkpoint. Todo está en el disco. El agente simplemente no puede leerlo.

auto-memory: Una Capa de Recall, No un Sistema de Memoria

Esa es la idea central detrás de auto-memory: no construyas un nuevo sistema de memoria — construye una capa de consulta de solo lectura sobre el que ya existe.

pip install auto-memory

~1.900 líneas de Python. Cero dependencias. Se instala en 30 segundos.

En lugar de inundar el contexto con resultados de grep, le das al agente acceso quirúrgico a lo que realmente importa:

Operación	Tokens	Qué obtienes
`grep -r "auth" src/`	~5.000–10.000	500 resultados, la mayoría irrelevantes
`find . -name "*.py"`	~2.000	Todos los archivos Python, sin contexto
Re-orientación del agente	~2.000	Tú explicando lo que ya debería saber
`auto-memory files --json --limit 10`	~50	Los 10 archivos que tocaste ayer

Una mejora de 200x. El agente se salta la excavación arqueológica y va directo a lo que importa.

¿Por Qué Importa Esto para Desarrolladores .NET?

Si usas GitHub Copilot CLI para trabajo con .NET — scaffolding de servicios, depuración de queries EF Core, iterando en componentes Blazor — el problema del context rot golpea igual de fuerte. Soluciones complejas con múltiples proyectos y librerías compartidas son exactamente el tipo de código donde el agente pierde el hilo más rápido.

Resumiendo

El context rot es una restricción arquitectónica real, no un bug que se parchará. auto-memory lo soluciona dándole a tu agente un mecanismo de recall barato y preciso en lugar de re-exploración costosa y ruidosa. Si haces desarrollo serio asistido por IA con GitHub Copilot CLI, vale la pena el install de 30 segundos.

Échale un vistazo: auto-memory en GitHub. Post original de Desi Villanueva: I Wasted 68 Minutes a Day Re-Explaining My Code.

azd + GitHub Copilot: Configuración de proyectos con IA y resolución inteligente de errores

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Este artículo fue traducido automáticamente. Para ver la versión original en inglés, haz clic aquí.

¿Conoces ese momento en que quieres desplegar una app existente en Azure y te quedas mirando un azure.yaml en blanco, intentando recordar si tu API Express debería usar Container Apps o App Service? Ese momento acaba de volverse mucho más corto.

El Azure Developer CLI (azd) ahora se integra con GitHub Copilot de dos formas muy concretas: scaffolding asistido por IA durante azd init, y resolución inteligente de errores cuando los despliegues fallan. Ambas funciones se quedan completamente en tu terminal, que es exactamente donde quiero que estén.

Configuración con Copilot durante azd init

Cuando ejecutas azd init, ahora aparece la opción “Set up with GitHub Copilot (Preview)”. Selecciónala y Copilot analiza tu codebase para generar el azure.yaml, las plantillas de infraestructura y los módulos Bicep — basándose en tu código real, no en suposiciones.

azd init
# Selecciona: "Set up with GitHub Copilot (Preview)"

Para que funcione necesitas:

azd 1.23.11 o superior — comprueba con azd version o actualiza con azd update
Una suscripción activa de GitHub Copilot (Individual, Business o Enterprise)
GitHub CLI (gh) — azd pedirá login si es necesario

Lo que me parece genuinamente útil es que funciona en los dos sentidos. ¿Construyendo desde cero? Copilot te ayuda a configurar los servicios Azure correctos desde el principio. ¿Tienes una app existente que llevas tiempo sin desplegar? Apunta Copilot hacia ella y genera la configuración sin que tengas que reestructurar nada.

Lo que hace realmente

Imagina que tienes una API Express en Node.js con dependencia de PostgreSQL. En lugar de decidir manualmente entre Container Apps o App Service, y luego escribir Bicep desde cero, Copilot detecta tu stack y genera:

Un azure.yaml con los ajustes correctos de language, host y build
Un módulo Bicep para Azure Container Apps
Un módulo Bicep para Azure Database for PostgreSQL

Y hace comprobaciones previas antes de tocar nada — verifica que tu directorio git esté limpio, pide consentimiento para las herramientas del servidor MCP. Nada ocurre sin que sepas exactamente qué va a cambiar.

Resolución de errores potenciada por Copilot

Los errores de despliegue son inevitables. Parámetros faltantes, problemas de permisos, disponibilidad de SKUs — y el mensaje de error raramente te dice lo único que realmente necesitas saber: cómo solucionarlo.

Sin Copilot, el ciclo es: copiar el error → buscar en docs → leer tres respuestas irrelevantes de Stack Overflow → ejecutar algunos comandos az CLI → volver a intentarlo y rezar. Con Copilot integrado en azd, ese ciclo se colapsa. Cuando cualquier comando azd falla, ofrece inmediatamente cuatro opciones:

Explain — descripción en lenguaje natural de qué salió mal
Guidance — instrucciones paso a paso para solucionarlo
Diagnose and Guide — análisis completo + Copilot aplica la solución (con tu aprobación) + reintento opcional
Skip — gestionarlo tú mismo

Lo clave: Copilot ya tiene contexto sobre tu proyecto, el comando que falló y la salida del error. Sus sugerencias son específicas para tu situación, no documentación genérica.

Ejemplos reales donde brilla

Proveedor de recursos no registrado:

ERROR: deployment failed: MissingSubscriptionRegistration:
The subscription is not registered to use namespace 'Microsoft.App'.

Esto falla a cualquiera que despliega en una suscripción nueva. Copilot puede registrar el proveedor y relanzar el despliegue automáticamente.

SKU no disponible:

ERROR: deployment failed: SkuNotAvailable:
The requested VM size 'Standard_D2s_v3' is not available in location 'westus'.

Copilot explica qué tamaño de VM o región está bloqueado y sugiere alternativas disponibles en tu suscripción.

Colisión de nombre de cuenta de almacenamiento:

ERROR: deployment failed: StorageAccountAlreadyTaken:
The storage account named 'myappstorage' is already taken.

La unicidad global le pasa a todo el mundo al menos una vez. Copilot sugiere añadir el nombre del entorno o un sufijo aleatorio a tus parámetros Bicep.

Configurar un comportamiento predeterminado

Si siempre quieres la misma opción, salta el prompt interactivo:

azd config set copilot.errorHandling.category troubleshoot

Opciones: explain, guidance, troubleshoot, fix, skip. También puedes habilitar auto-fix y reintento:

azd config set copilot.errorHandling.fix allow

Vuelve al modo interactivo en cualquier momento:

azd config unset copilot.errorHandling.category

Por qué importa esto para los desarrolladores .NET

Si estás construyendo en Azure — ya sea una app .NET Aspire, una API en contenedor, o cualquier otra cosa — azd es la herramienta que debes conocer. Esta integración con Copilot elimina la última barrera de fricción que antes hacía que necesitaras una chuleta para empezar.

La pieza de scaffolding es genial para proyectos brownfield. Tienes una app ASP.NET Core funcionando localmente perfectamente, pero llevarla a Azure siempre ha requerido algo de conocimiento de infraestructura. Ahora Copilot tiende ese puente. Y la función de resolución de errores es algo que desearía haber tenido la última vez que pasé 45 minutos depurando un error SkuNotAvailable en tres regiones diferentes.

Conclusión

Esta es exactamente el tipo de integración de Copilot que aporta valor real — no IA por el gusto de la IA, sino IA que entiende tu contexto y te ahorra tiempo real. Pruébalo ejecutando azd update para obtener la última versión, y usa azd init en tu próximo proyecto. El equipo está trabajando en funciones más profundas incluyendo personalización de infraestructura asistida por Copilot, así que ahora es un buen momento para apuntarte a la investigación de usuarios.

Lee el anuncio original aquí.

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

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

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.

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

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

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.

La evaluación de modernización de GitHub Copilot es la mejor herramienta de migración que aún no estás usando

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

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

Migrar una aplicación legacy de .NET Framework a .NET moderno es una de esas tareas que todos saben que deberían hacer pero nadie quiere empezar. Nunca es solo “cambiar el target framework.” Son APIs que desaparecieron, paquetes que ya no existen, modelos de hosting que funcionan completamente diferente, y un millón de pequeñas decisiones sobre qué containerizar, qué reescribir y qué dejar como está.

Jeffrey Fritz acaba de publicar una inmersión profunda en la evaluación de modernización de GitHub Copilot, y honestamente, es el mejor tooling de migración que he visto para .NET. No por la generación de código — eso ya es estándar. Por el documento de evaluación que produce.

No es solo un motor de sugerencias de código

La extensión de VS Code sigue un modelo de Evaluar → Planificar → Ejecutar. La fase de evaluación analiza todo tu código base y produce un documento estructurado que captura todo: qué necesita cambiar, qué recursos de Azure aprovisionar, qué modelo de despliegue usar. Todo lo posterior — infraestructura como código, containerización, manifiestos de despliegue — fluye de lo que la evaluación encuentra.

La evaluación se almacena en .github/modernize/assessment/ en tu proyecto. Cada ejecución produce un reporte independiente, así que acumulas un historial y puedes rastrear cómo evoluciona tu postura de migración a medida que corriges issues.

Dos formas de empezar

Evaluación Recomendada — el camino rápido. Elige entre dominios curados (Actualización Java/.NET, Cloud Readiness, Seguridad) y obtén resultados significativos sin tocar configuración. Genial para una primera mirada a dónde está tu aplicación.

Evaluación Personalizada — el camino dirigido. Configura exactamente qué analizar: cómputo objetivo (App Service, AKS, Container Apps), SO objetivo, análisis de containerización. Elige múltiples destinos Azure para comparar enfoques de migración lado a lado.

Esa vista de comparación es genuinamente útil. Una app con 3 issues obligatorios para App Service podría tener 7 para AKS. Ver ambos ayuda a decidir el hosting antes de comprometerse con un camino de migración.

El desglose de issues es accionable

Cada issue viene con un nivel de criticidad:

Obligatorio — debe corregirse o la migración falla
Potencial — podría impactar la migración, necesita juicio humano
Opcional — mejoras recomendadas, no bloquean la migración

Y cada issue enlaza a archivos afectados y números de línea, proporciona una descripción detallada de qué está mal y por qué importa para tu plataforma objetivo, da pasos concretos de remediación (no solo “arregla esto”), e incluye enlaces a documentación oficial.

Puedes asignar issues individuales a desarrolladores y tienen todo lo que necesitan para actuar. Esa es la diferencia entre una herramienta que te dice “hay un problema” y una que te dice cómo resolverlo.

Las rutas de actualización cubiertas

Para .NET específicamente:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Cada ruta de actualización tiene reglas de detección que saben qué APIs fueron eliminadas, qué patrones no tienen equivalente directo, y qué issues de seguridad necesitan atención.

Para equipos que gestionan múltiples aplicaciones, también hay un CLI que soporta evaluaciones batch multi-repo — clona todos los repos, evalúalos todos, obtén reportes por app más una vista de portafolio agregada.

Mi opinión

Si estás sentado sobre aplicaciones legacy de .NET Framework (y seamos honestos, la mayoría de los equipos empresariales lo están), esta es la herramienta con la que empezar. Solo el documento de evaluación vale el tiempo — convierte un vago “deberíamos modernizar” en una lista concreta y priorizada de elementos de trabajo con caminos claros hacia adelante.

El flujo de trabajo colaborativo también es inteligente: exporta evaluaciones, compártelas con tu equipo, impórtalas sin re-ejecutar. ¿Revisiones de arquitectura donde los que toman decisiones no son los que ejecutan las herramientas? Cubierto.

Para cerrar

La evaluación de modernización de GitHub Copilot transforma la migración de .NET de un proyecto aterrador e indefinido en un proceso estructurado y rastreable. Empieza con una evaluación recomendada para ver dónde estás, luego usa evaluaciones personalizadas para comparar destinos Azure y construir tu plan de migración.

Lee el walkthrough completo y descarga la extensión de VS Code para probarlo en tu propio código.

La Ingeniería de Plataformas Agéntica Se Está Haciendo Real — Git-APE Muestra Cómo

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

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

La ingeniería de plataformas ha sido uno de esos términos que suena genial en conferencias pero que normalmente significa “construimos un portal interno y un wrapper de Terraform.” La verdadera promesa — infraestructura self-service que realmente sea segura, gobernada y rápida — siempre ha estado a unos pasos de distancia.

El equipo de Azure acaba de publicar la Parte 2 de su serie sobre ingeniería de plataformas agéntica, y esta es sobre la implementación práctica. Lo llaman Git-APE (sí, el acrónimo es intencional), y es un proyecto open source que usa agentes de GitHub Copilot más servidores Azure MCP para convertir solicitudes en lenguaje natural en infraestructura validada y desplegada.

Qué hace Git-APE realmente

La idea central: en vez de que los desarrolladores aprendan módulos de Terraform, naveguen por UIs de portales o abran tickets al equipo de plataforma, hablan con un agente de Copilot. El agente interpreta la intención, genera Infrastructure-as-Code, la valida contra políticas y despliega — todo dentro de VS Code.

Aquí está la configuración:

git clone https://github.com/Azure/git-ape
cd git-ape

Abre el workspace en VS Code, y los archivos de configuración del agente son descubiertos automáticamente por GitHub Copilot. Interactúas con el agente directamente:

@git-ape deploy a function app with storage in West Europe

El agente usa Azure MCP Server internamente para interactuar con los servicios de Azure. La configuración de MCP en las opciones de VS Code habilita capacidades específicas:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Por qué esto importa

Para los que construimos en Azure, esto cambia la conversación de ingeniería de plataformas de “cómo construimos un portal” a “cómo describimos nuestras barreras de seguridad como APIs.” Cuando la interfaz de tu plataforma es un agente de IA, la calidad de tus restricciones y políticas se convierte en el producto.

El blog de la Parte 1 planteó la teoría: APIs bien descritas, esquemas de control y barreras explícitas hacen las plataformas agent-ready. La Parte 2 lo demuestra funcionando con herramientas reales. El agente no genera recursos ciegamente — valida contra mejores prácticas, respeta convenciones de nomenclatura y aplica las políticas de tu organización.

La limpieza es igual de sencilla:

@git-ape destroy my-resource-group

Mi opinión

Seré honesto — esta es más sobre el patrón que sobre la herramienta específica. Git-APE en sí es una demo/arquitectura de referencia. Pero la idea subyacente — agentes como la interfaz de tu plataforma, MCP como protocolo, GitHub Copilot como host — es hacia donde se dirige la experiencia del desarrollador empresarial.

Si eres un equipo de plataforma buscando cómo hacer tu herramienta interna amigable para agentes, no hay mejor punto de partida. Y si eres un desarrollador .NET preguntándote cómo se conecta esto con tu mundo: el Azure MCP Server y los agentes de GitHub Copilot funcionan con cualquier carga de trabajo de Azure. Tu API ASP.NET Core, tu stack .NET Aspire, tus microservicios contenerizados — todo puede ser el objetivo de un flujo de despliegue agéntico.

Para cerrar

Git-APE es una mirada temprana pero concreta a la ingeniería de plataformas agéntica en la práctica. Clona el repo, prueba la demo y empieza a pensar en cómo las APIs y políticas de tu plataforma necesitarían verse para que un agente las use de forma segura.

Lee el post completo para el walkthrough y videos de demostración.

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

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

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.

GitHub Copilot | The .NET Blog

Actualización de Abril del Azure DevOps MCP Server: Consultas WIQL, Auth PAT y MCP Apps Experimental

Soporte de Consultas WIQL

Personal Access Tokens en el Servidor Local

Anotaciones MCP en el Servidor Remoto

Consolidación de Herramientas Wiki

Experimental: MCP Apps

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

¿68 Minutos al Día Re-Explicando Código a Copilot? Hay una Solución

La Mentira de la Ventana de Contexto

El Impuesto de la Compactación

auto-memory: Una Capa de Recall, No un Sistema de Memoria

¿Por Qué Importa Esto para Desarrolladores .NET?

Resumiendo

azd + GitHub Copilot: Configuración de proyectos con IA y resolución inteligente de errores

Configuración con Copilot durante azd init

Lo que hace realmente

Resolución de errores potenciada por Copilot

Ejemplos reales donde brilla

Configurar un comportamiento predeterminado

Por qué importa esto para los desarrolladores .NET

Conclusión

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

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

La evaluación de modernización de GitHub Copilot es la mejor herramienta de migración que aún no estás usando

No es solo un motor de sugerencias de código

Dos formas de empezar

El desglose de issues es accionable

Las rutas de actualización cubiertas

Mi opinión

Para cerrar

La Ingeniería de Plataformas Agéntica Se Está Haciendo Real — Git-APE Muestra Cómo

Qué hace Git-APE realmente

Por qué esto importa

Mi opinión

Para cerrar

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

Agentes Copilot personalizados en tu repo

Agent skills: paquetes de instrucciones reutilizables

find_symbol: navegación con reconocimiento de lenguaje

Perfilar tests con Copilot

Perf tips durante debugging en vivo

Corregir vulnerabilidades de NuGet desde Solution Explorer

Para cerrar

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