Developer Productivity | 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.

Aspire 13.2: Soporte para Bun, Mejores Contenedores y Menos Fricción en el Debug

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

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

Si llevas tiempo construyendo backends .NET con frontends JavaScript en Aspire, la versión 13.2 es el tipo de actualización que mejora tu día sin anunciar grandes cambios. Sin nuevos paradigmas llamativos. Solo mejoras sólidas a cosas que eran levemente molestas.

Bun es Ahora Ciudadano de Primera Clase

La característica principal: soporte para Bun en apps Vite. Una llamada fluida, listo.

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

Si tu equipo ya usa Bun — con sus tiempos de instalación dramáticamente más rápidos — Aspire ya no te hace pelear contra la corriente.

Yarn es Más Confiable

Los usuarios de Yarn reciben algo igualmente importante: menos fallos misteriosos. Aspire 13.2 mejora la fiabilidad de withYarn() con addViteApp().

Mejoras en Contenedores

Pull Policy Explícita

const worker = await builder.addContainer("worker", "myorg/worker:latest")
 .withImagePullPolicy(ImagePullPolicy.Never);

Perfecto para flujos donde construyes imágenes localmente y quieres que Compose use exactamente esa sin ir al registry.

PostgreSQL 18+ Funciona Correctamente

PostgreSQL 18 cambió su estructura interna de directorios, lo que rompía silenciosamente el mapeo de volúmenes. Aspire 13.2 lo corrige.

Mejoras de Depuración

DebuggerDisplayAttribute en tipos core — valores útiles en el debugger en lugar de árboles de objetos
Mensajes de error más claros para WaitFor
BeforeResourceStartedEvent se dispara en el momento correcto

Resumiendo

Aspire 13.2 es una versión de calidad enfocada. Vale la pena actualizar, especialmente si usas PostgreSQL 18 con volúmenes de datos.

Post original de David Pine: Aspire 13.2: Bun Support and Container Enhancements.

¿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.