En el artículo de Aspire vimos cómo orquestar todos los servicios de tu aplicación con un solo comando y obtener observabilidad gratis con el dashboard. En los comentarios del post, Rubén Gomez nos comentaba cómo era usar Aspire con un MCP — como cerrar un círculo. Eso me dio la idea de este artículo.
Si tengo que reconocerlo, yo era de las personas más escépticas con Aspire cuando Microsoft lo anunció. Una nueva tooling que dentro del ecosistema de Microsoft funciona perfectamente, pero que viene a cubrir un escenario dentro del desarrollo de Kubernetes como es Docker Compose, en el que ya muchos productos lo tienen listo y funcionando.
Con la llegada de la IA, quizás alguna tarea tediosa como es migrar de versión de Framework es algo tan trivial, que seguramente el numéro de busquedas, articulos, tutoriales este año se ha reducido bastante, sin embargo yo creo que este año es algo mucho más importante que en los anteriores. El motivo es que el subir una versión del framework puede ser algo tan sencillo como cambiar un csproj, y subir las versiones de los nuget correspondiente. Pero eso es realmente lo que se considera subir una versión? Yo no y me explico si tu subess tu proyecto a NET 10 pero aun tienes alguna dependencia de algún nuget que este en versiones anteriores te funcionará, sin embargo es algo que se penaliza en el rendimiento, seguridad de tu aplicación y luego cuando se muestra un gran problema de alguna plataforma nos pondremos manos a la cabeza que como puede pasar eso si esta todo a ahora a la última versión.
Llevamos ya un tiempo hablando de cómo la IA afecta al trabajo de los desarrolladores. Hay artículos, estudios, debates y opiniones para todos los gustos. Pero hay un rol sobre el que se habla mucho menos: el Engineering Manager.
En el artículo anterior vimos cómo las Skills nos permiten que un agente revise el trabajo de otro, reduciendo el cuello de botella del ingeniero. Pero el análisis acabó con una conclusión incómoda: la skill detectó 9 issues, dos de ellos críticos — datos de dominio perdidos en runtime — y no fueron errores del agente. El agente implementó exactamente lo que se le pidió. El problema estaba en los requisitos: se describió el qué y el cómo, pero nadie pensó en el impacto sobre el resto del sistema.
