Developer Experience | The .NET Blog

Revisar pull requests dentro de Visual Studio es exactamente el tipo de reducción de fricción que me gusta

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

Esta publicación se ha traducido automáticamente. Lee el original aquí.

El navegador ha estado robando demasiada parte del flujo de trabajo de code review durante demasiado tiempo.

Por eso me alegra mucho ver a Visual Studio avanzar más hacia la revisión de pull requests de principio a fin dentro del IDE.

Esta es una de esas funciones que quizá no genere grandes titulares, pero que puede mejorar muchísimo el desarrollo diario.

El valor principal es simple: menos cambio de contexto

Cuando tu bucle de revisión vive en parte dentro del IDE y en parte en el navegador, la fricción se acumula:

abrir el PR en otro lugar
inspeccionar los cambios en una herramienta
volver a la solución para investigar más a fondo
cambiar otra vez para comentar o aprobar

No es catastrófico. Solo es ineficiente.

Si Visual Studio te permite abrir, inspeccionar, comentar, aprobar y hacer merge desde el mismo entorno de trabajo, eso sí es una ganancia real de productividad.

La opción de “review sin checkout” es especialmente buena

Una parte que me gusta especialmente es poder revisar sin hacer checkout de la rama del PR.

Puede sonar pequeño, pero es perfecto para:

pasadas rápidas de review
solicitudes de feedback interrumpidas
mantener intactos tu rama actual y tu estado local

Eso es exactamente el tipo de flexibilidad que necesitan las buenas herramientas de code review.

Mi opinión

Esto no es una función revolucionaria.

Es algo mejor: algo práctico.

Para los equipos que pasan la mayor parte del día en Visual Studio, un soporte más estrecho para revisar PR significa menos interrupciones del flujo de trabajo y un camino más fluido desde la inspección hasta la acción.

En mi opinión, es una mejora que vale la pena.

Publicación original: Revisa pull requests sin salir de Visual Studio

Los Agent Harnesses Importan Porque los Prompts No Son Suficientes

Emiliano Montesdeoca — Sat, 20 Jun 2026 00:00:00 +0000

Uno de los errores más fáciles en el desarrollo de agentes es pensar que el prompt es el producto.

No lo es.

El nuevo walkthrough sobre agent harness y claw del equipo de Microsoft Agent Framework es valioso porque mantiene el enfoque en la parte que realmente determina si un agente se siente usable: el shell de ejecución alrededor del modelo.

Eso incluye:

herramientas
planificación
estado de sesión
memoria
modos de ejecución
una consola o interfaz utilizable para la iteración

Ahí es donde los agentes dejan de ser demos ingeniosos y empiezan a sentirse como software.

El patrón harness es práctico

Lo que me gusta aquí es lo abordable que es la idea.

Empiezas con un cliente de chat.

Luego lo envuelves en un harness con instrucciones y herramientas.

Luego lo ejecutas a través de un shell que soporta planificación, tareas pendientes, sesiones e interacción en streaming.

Ese es un patrón saludable porque separa responsabilidades claramente:

el modelo maneja el razonamiento
el harness maneja el comportamiento en tiempo de ejecución
la app decide qué herramientas y experiencias importan

Esto encaja muy bien con cómo los desarrolladores .NET construyen sistemas

La idea del harness también se mapea bien con la mentalidad .NET.

Generalmente nos va mejor cuando el comportamiento en tiempo de ejecución es explícito y componible. Middleware, pipelines, opciones, providers y adaptadores se sienten naturales en este mundo.

Por eso creo que Agent Framework tiene buenas posibilidades de conectar con los desarrolladores .NET. No está forzando a todos a entrar en una abstracción mágica. Te está dando piezas estructuradas de ejecución que puedes conectar.

Mi opinión

La parte más útil de este post es el recordatorio de que los agentes necesitan más que un buen modelo y un string de instrucciones ingenioso.

Necesitan un shell de ejecución que les dé estructura, memoria, acceso a herramientas, planificación y un bucle de desarrollo funcional.

Eso es lo que el harness te proporciona.

Y honestamente, por eso vale la pena prestar atención a este patrón.

Post original: Meet your agent harness and claw

Aspire en VS Code 13.4 ajusta el bucle de desarrollador en todas las formas correctas

Emiliano Montesdeoca — Tue, 16 Jun 2026 00:00:00 +0000

Las mejores actualizaciones de herramientas son las que se sienten después de unos días, no las que solo se ven bien en las notas de la versión.

Así es como se lee Aspire en VS Code 13.4 para mí.

Esta actualización se trata de ajustar el bucle interno: crear proyectos más rápido, depurar recursos de lenguajes mixtos de forma más natural, mostrar salud y comandos directamente en el editor, y mantener el dashboard cerca sin hacerlo el único lugar donde puedes trabajar.

Esa es una muy buena dirección.

La gran victoria es menos cambio de contexto

Si usas Aspire en serio, normalmente te mueves a través de varias superficies:

código AppHost
terminal
dashboard
registros
sesiones de depuración
endpoints de servicio

Lo que 13.4 hace bien es reducir la fricción entre esas superficies.

La nueva experiencia de VS Code hace que más del estado de la aplicación sea visible exactamente donde ya estás trabajando.

Mi opinión

Aspire 13.4 en VS Code no se trata de una función estrella. Se trata de suavizar los bordes ásperos en el bucle diario.

Fuente original: Aspire in VS Code: the 13.4 developer loop

El nuevo Plan agent de Visual Studio resuelve un problema muy real del flujo de trabajo de IA

Emiliano Montesdeoca — Thu, 11 Jun 2026 00:00:00 +0000

Esta publicación se ha traducido automáticamente. Lee el original aquí.

Uno de los flujos de trabajo de programación con IA más frustrantes es cuando la implementación empieza demasiado rápido.

El código puede incluso ser técnicamente correcto, pero está resolviendo la versión equivocada del problema que tenías en mente.

Querías una refactorización. Empezó una reescritura. Querías una mejora acotada. Tocó medio proyecto. Querías hablar de opciones. Saltó directamente a cambios de archivos.

Por eso el nuevo Plan agent de Visual Studio es una adición tan útil.

Esto resuelve un problema real de workflow, no solo un problema estético

La publicación original describe una situación muy familiar: “El código no está mal… simplemente no es lo que querías.”

Esa frase es perfecta.

Porque el punto débil de mucho desarrollo asistido por IA no es si el modelo puede producir código. Es si el workflow crea suficiente espacio para acordar la forma deseada del trabajo antes de empezar la implementación.

Eso importa especialmente para:

funciones grandes
bases de código desconocidas
refactorizaciones no triviales
cambios sensibles a la arquitectura
trabajo que necesita revisión del equipo antes de empezar a editar

En esas situaciones, saltar directamente a implementar suele ser el movimiento equivocado.

Planificar no es sobrecarga cuando la tarea es real

Creo que los equipos a veces subestiman cuánto tiempo pierden al empezar a implementar demasiado pronto.

Si el agente:

toca los archivos equivocados
elige el enfoque equivocado
pasa por alto una restricción clave
ignora un caso límite necesario

entonces el inicio “rápido” acaba convirtiéndose en un workflow más lento en conjunto.

Por eso me gusta esta función.

Da espacio para:

preguntas de aclaración
redacción del plan
edición directa del plan
compartir el plan antes de que empiecen los cambios de código

Eso no es burocracia. Muchas veces es simplemente buena ingeniería.

El archivo de plan en markdown es una elección inteligente

Un detalle que me gusta especialmente es que cada plan se guarda en .copilot/plans/plan-{title}.md.

Eso hace que el paso de planificación sea tangible.

Significa que el plan no queda atrapado dentro de un transcript de chat. Se convierte en algo que puedes:

revisar
editar
versionar mentalmente
discutir con el equipo
pasar a la implementación de forma más deliberada

Eso hace que la función se sienta mucho más seria que un simple preámbulo temporal antes de generar código.

Aquí es donde los workflows de IA empiezan a respetar el proceso del equipo

Creo que esta es una de las señales más claras de que estas herramientas están madurando.

Los mejores workflows de IA para desarrolladores no son los que eliminan todos los pasos intermedios. Son los que mejoran los pasos intermedios correctos.

Y la planificación es uno de esos pasos.

Si el plan es sólido, implementar es más fácil. Si el plan es débil, la implementación se vuelve ruidosa.

Esta función lo reconoce directamente.

Mi opinión

Esto no es solo una comodidad de IA.

Es una mejora del workflow.

Y para funciones reales y refactorizaciones reales, es exactamente el tipo de mejora que puede ahorrar mucho churn innecesario, ruido de review y rework del tipo “eso no es lo que quise decir”.

Creo que cada vez más experiencias de agentes acabarán necesitando algo así.

Visual Studio llegó antes, y de una forma que se siente útil.

Publicación original: Planifica antes de construir: introduciendo el Plan agent en Visual Studio

Tu dev loop está lleno de conocimiento tribal, y Aspire da la respuesta correcta

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

Esta publicación se ha traducido automáticamente. Lee el original aquí.

Esta puede ser una de las publicaciones más importantes de Aspire para entender por qué importa el producto.

No porque anuncie una gran función nueva.

Porque nombra un problema que casi todos los equipos de ingeniería han sentido y no todos han descrito bien:

el dev loop está lleno de conocimiento tribal.

Esa frase encaja porque es verdad.

El problema no es falta de herramientas

El argumento central del artículo original es excelente: los equipos a menudo no carecen de infraestructura, scripts, dashboards o comandos.

Lo que les falta es un modelo coherente que convierta todo el conocimiento operativo oculto alrededor de la aplicación en algo visible y repetible.

La arquitectura real de muchas apps vive en:

el historial del shell
scripts dispersos
fragmentos de README
hilos de Slack
el único ingeniero senior que conoce el orden de las operaciones

Eso no es un dev loop sostenible para humanos.

Y definitivamente tampoco lo es para agentes.

La cita que creo que captura todo el post

Hay una frase en el artículo original que creo que capta muy bien el punto general:

“Applications already exist as systems. Aspire makes those systems explicit, because explicit systems scale better than tribal knowledge.”

Esa es toda la tesis en una sola línea.

Y sinceramente, es una de las mejores explicaciones de una línea sobre Aspire que he visto hasta ahora.

Por qué esto importa más ahora que hace un año

Creo que este post funciona especialmente bien en el momento actual porque el desarrollo asistido por IA cambia el coste de la ambigüedad.

Los humanos pueden compensar sistemas incompletos sorprendentemente bien.

Recordamos:

qué script hay que ejecutar primero
qué variable de entorno se necesita en secreto
qué terminal suele mostrar los logs útiles
qué servicio hay que reiniciar dos veces por razones que nadie documentó

Los agentes son mucho peores con ese tipo de folclore operativo oculto.

Así que si queremos que los agentes sean realmente útiles en repositorios reales, necesitamos que el sistema sea más explícito, no menos.

Por eso creo que el enfoque de Aspire importa.

El valor real de Aspire no es solo la orquestación

Un error común es pensar en Aspire solo como un lanzador de apps distribuidas o un ayudante de orquestación local.

Eso es una visión demasiado pequeña.

El valor más fuerte es que Aspire le da a la aplicación:

un modelo
una forma
recursos con nombre
dependencias explícitas
superficies de health y operations
comandos que humanos y automatización pueden entender

Eso cambia el dev loop más de lo que a veces la gente se da cuenta.

Porque una vez que la app deja de ser una pila de convenciones implícitas y pasa a ser un sistema con un modelo real, varias cosas se vuelven más fáciles a la vez:

onboarding
debugging
setup repetible
consistencia en CI
workflows asistidos por IA

Eso es mucha palanca a partir de una sola decisión de diseño.

Me gusta especialmente el ángulo de “commands as first-class operations”

Otro punto del artículo original que creo que merece más atención es el paso de las instrucciones del README a comandos asociados a recursos.

Eso es un cambio engañosamente grande.

En vez de decir:

ejecuta este script, luego aquel, y quizá este otro si falla el primero

puedes modelar las operaciones directamente dentro del contexto de la app.

Eso hace que los humanos puedan descubrirlas más fácilmente.

Y significa que los agentes no tienen que adivinar la intención a partir de prosa.

Eso es lo que convierte una aplicación de “operable si ya la conoces” a “operable por diseño”.

Lo que sacaría de esto como team lead

Si mirara el dev loop de mi propio equipo a través de esta lente, me haría unas cuantas preguntas directas:

¿cuánto de nuestro setup depende de la memoria?
¿cuántas acciones críticas de desarrollo solo existen en docs o hilos de chat?
¿con qué frecuencia se bloquea la gente nueva por comportamiento invisible del sistema?
¿podría una herramienta de automatización o un coding agent entender nuestra topología de app solo desde el repo?

Si la respuesta a la última pregunta es “ni de lejos”, entonces este artículo debería tocar una fibra útil.

Mi opinión

Este es un framing muy fuerte del valor real de Aspire.

No es solo orquestación.

Es hacer que el modelo de la app sea lo bastante explícito para que el sistema sea más fácil de operar, entender y automatizar.

Eso importa para las personas. Importa para los equipos. Y importa aún más ahora que tanto del desarrollo moderno se mueve hacia workflows asistidos por agentes.

Este es exactamente el tipo de artículo que ayuda a explicar por qué Aspire se siente cada vez más relevante más allá de la simple etiqueta de marketing de .NET.

Publicación original: Tu dev loop está lleno de conocimiento tribal— title: “Tu ciclo de desarrollo está lleno de conocimiento implícito, y Aspire tiene la respuesta adecuada” date: 2026-06-01 author: “Emiliano Montesdeoca” description: “Una nueva publicación de Aspire deja un argumento muy sólido: a muchos equipos no les faltan herramientas, les falta un modelo de aplicación coherente que convierta el conocimiento operativo oculto en algo que humanos, scripts y agentes puedan usar de verdad.” tags:

Aspire
Developer Experience
AI
Dev Loop
.NET

Esta publicación se ha traducido automáticamente. Lee el original aquí.

Puede que esta sea una de las publicaciones de Aspire más importantes para entender por qué el producto importa.

No porque anuncie una gran funcionalidad nueva.

Porque pone nombre a un problema que casi todos los equipos de ingeniería han sentido y no todos han sabido describir bien:

el ciclo de desarrollo está lleno de conocimiento implícito.

La frase impacta porque es verdad.

El problema no es la falta de herramientas

El argumento central del artículo original es excelente: a los equipos a menudo no les faltan infraestructura, scripts, paneles ni comandos.

Lo que les falta es un modelo coherente que convierta todo el conocimiento operativo oculto alrededor de la aplicación en algo visible y repetible.

La arquitectura real de muchas apps vive en:

el historial de shell
scripts dispersos
fragmentos de README
hilos de Slack
el único ingeniero sénior que sabe el orden de las operaciones

Eso no es un ciclo de desarrollo sostenible para humanos.

Y definitivamente tampoco para agentes.

La cita que, creo, resume todo el post

Hay una frase del artículo original que creo que captura muy bien el punto general:

“Las aplicaciones ya existen como sistemas. Aspire hace explícitos esos sistemas, porque los sistemas explícitos escalan mejor que el conocimiento implícito.”

Ese es el argumento completo en una sola línea.

Y, sinceramente, es una de las explicaciones de Aspire en una sola frase más fuertes que he visto hasta ahora.

Por qué esto importa más ahora que hace un año

Creo que esta publicación encaja especialmente bien en el momento actual porque el desarrollo asistido por IA cambia el coste de la ambigüedad.

Los humanos pueden compensar sistemas incompletos sorprendentemente bien.

Recordamos:

qué script hay que ejecutar primero
qué variable de entorno hace falta en secreto
qué terminal suele mostrar los logs útiles
qué servicio hay que reiniciar dos veces por razones que nadie documentó

Los agentes son mucho peores en ese tipo de folclore operativo oculto.

Así que si queremos que los agentes sean realmente útiles en repositorios reales, tenemos que hacer que el sistema sea más explícito, no menos.

Por eso creo que este marco de Aspire importa.

El valor real de Aspire no es solo la orquestación

Un error frecuente con Aspire es pensar en él solo como un lanzador de apps distribuidas o una ayuda de orquestación local.

Ese marco se queda corto.

La propuesta de valor más fuerte es que Aspire le da a la aplicación:

un modelo
una forma
recursos con nombre
dependencias explícitas
superficies de salud y operaciones
comandos que humanos y automatización pueden entender

Eso cambia el ciclo de desarrollo más de lo que a veces se reconoce.

Porque, cuando la app deja de ser una pila de convenciones implícitas y pasa a ser un sistema con un modelo real, varias cosas se vuelven más fáciles a la vez:

onboarding
debugging
configuración repetible
consistencia de CI
flujos asistidos por IA

Eso es mucha palanca a partir de una sola decisión de diseño.

Me gusta especialmente el ángulo de “comandos como operaciones de primera clase”

Otro punto del post original que creo que merece más atención es el paso de instrucciones en README a comandos vinculados a recursos.

Es un cambio engañosamente grande.

En vez de decir:

ejecuta este script, luego aquel, y quizá este otro si falla el primero

puedes modelar las operaciones directamente dentro del contexto de la aplicación.

Eso significa que los humanos pueden descubrirlas más fácilmente.

Y significa que los agentes no tienen que adivinar la intención a partir de prosa.

Ese es el tipo de cosa que convierte una aplicación de “operable si ya la conoces” a “operable por diseño”.

Lo que yo sacaría de esto como team lead

Si mirara el ciclo de desarrollo de mi equipo a través de esta lente, me haría varias preguntas directas:

¿cuánto de nuestra configuración depende de la memoria?
¿cuántas acciones críticas de desarrollo solo existen en docs o hilos de chat?
¿con qué frecuencia se bloquea a los nuevos contribuyentes por un comportamiento invisible del sistema?
¿podría una herramienta de automatización o un coding agent entender la topología de nuestra app solo a partir del repo?

Si la respuesta a la última es “ni de lejos”, esta publicación debería tocar una fibra útil.

Mi opinión

Esta es una forma muy sólida de explicar el valor real de Aspire.

No es solo orquestación.

Se trata de hacer que el modelo de la app sea lo suficientemente explícito como para que el sistema sea más fácil de operar, entender y automatizar.

Eso importa para las personas. Importa para los equipos. Y importa todavía más ahora que gran parte del desarrollo moderno se está moviendo hacia flujos asistidos por agentes.

Este es exactamente el tipo de artículo que ayuda a explicar por qué Aspire se siente cada vez más relevante más allá de la etiqueta de marketing de .NET.

Publicación original: Tu ciclo de desarrollo está lleno de conocimiento implícito

Las pruebas de extremo a extremo herméticas de Aspire son un patrón que más equipos deberían adoptar

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

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

Las pruebas de extremo a extremo inestables son caras de una manera que no siempre aparece en un panel de control.

No solo fallan. Poco a poco entrenan al equipo para dejar de confiar en el bucle de retroalimentación.

Por eso esta entrada sobre Azure Chaos Studio + Aspire me llamó la atención de inmediato. No es un anuncio de producto llamativo. Es una historia de ingeniería muy concreta sobre cómo hacer que las pruebas de extremo a extremo dejen de sentirse como una negociación con la suerte.

Y, sinceramente, creo que más equipos deberían copiar este patrón.

La idea central es sencilla, pero el beneficio es enorme

La clave es dar a cada prueba su propio entorno hermético y efímero con servicios reales, dependencias reales y un arranque explícito basado en la disponibilidad.

Eso suena obvio cuando lo lees en una sola frase. En sistemas reales es mucho más difícil, sobre todo cuando entran en juego dependencias en la nube, entornos compartidos y servicios distribuidos.

El artículo original explica el problema con mucha claridad: los entornos de prueba compartidos traen “la charla cruzada, la inestabilidad y los mensajes de grupo del tipo ‘¿quién rompió staging?’” como coste de hacer negocio.

Esa frase da risa porque duele.

Demasiados equipos aceptan ese intercambio como algo normal. Yo no creo que deban hacerlo.

Por qué este patrón importa más allá de las pruebas

Lo que más me gusta aquí es que el artículo no se limita a decir: “hicimos nuestras pruebas más fiables”.

En realidad está diciendo algo más grande:

si tu sistema distribuido es difícil de reproducir, difícil de aislar y difícil de verificar, todo tu ciclo de ingeniería se ralentiza.

Eso afecta a algo más que a CI.

Afecta a:

la confianza con la que los desarrolladores refactorizan
la rapidez con la que se diagnostican las regresiones
lo seguro que resulta plantear cambios arquitectónicos más grandes
la confianza que el equipo deposita en la validación automatizada

Y en 2026 también afecta a lo útil que puede llegar a ser el desarrollo asistido por IA.

La cita más importante de la publicación

Hay una línea en el artículo que creo que merece repetirse:

“Los agentes no tienen que ser perfectos. Tienen que poder verificarse.”

Ese es un enfoque excelente.

La gente pasa mucho tiempo preguntándose si los agentes de código con IA son lo bastante fiables para ayudar en trabajo no trivial. Yo creo que la mejor pregunta es si nuestros sistemas son lo bastante testeables para juzgar correctamente ese trabajo.

Si un agente propone una refactorización importante y tu única señal de seguridad es un montón de comprobaciones end-to-end frágiles y semialeatorias que se ejecutan contra un entorno compartido, entonces el problema no es solo el agente.

El problema es tu modelo de validación.

Este patrón de Aspire mejora eso de forma radical.

Qué hace especialmente buena esta implementación

Varias partes de la historia original hacen que esto sea mucho más que una entrada vaga de “hemos mejorado nuestras pruebas”.

1. Grafo real de servicios, no teatro de falsos mocks

Las pruebas no se construyen sobre un montón de mocks desconectados que fingen ser validación end-to-end.

Ejecutan los binarios reales, conectan emuladores donde se puede y usan el mismo modelo de aplicación que se usa para el desarrollo local.

Eso importa.

Porque en cuanto las pruebas end-to-end se convierten en teatro de mock contra mock, dejan de decirte algo fiable sobre la composición real.

2. Arranque basado en disponibilidad en lugar de sleeps mágicos

Esta parte es más grande de lo que parece.

El artículo deja claro que las pruebas esperan la salud real con WaitForResourceHealthyAsync, en lugar de confiar en suposiciones arbitrarias de tiempo.

Eso marca una diferencia enorme.

Una suite que dice “duerme 30 segundos y cruza los dedos” básicamente está documentando incertidumbre. Una suite que espera la disponibilidad real está documentando la intención del sistema.

3. El mismo modelo impulsa el desarrollo local y las pruebas

Esto me gusta mucho porque encaja con las mejores historias de Aspire en general.

El mismo modelo de aplicación impulsa:

el desarrollo local
el cableado de servicios
las dependencias emuladas
las comprobaciones de disponibilidad
la orquestación de pruebas herméticas

Eso reduce la deriva, y la deriva es uno de los asesinos silenciosos de la confianza.

Este tipo de inversión en experiencia de desarrollador se subestima

Una de las razones por las que quería que esta entrada fuese más larga que una reacción rápida es que creo que este tipo de mejoras de ingeniería se subestiman con frecuencia.

No son llamativas.

No se demoan como una nueva función de IA.

Tampoco siempre producen una única diapositiva que entusiasme a los ejecutivos.

Pero con el tiempo crean algo mucho más valioso: un equipo que puede moverse más rápido sin mentirse sobre la calidad.

Eso es muy importante.

El artículo dice que ahora ejecutan unos 90 tests herméticos, incluidos escenarios como caídas de zona, fallos de DNS y fallos de replicación geográfica. Eso no es solo mejor higiene de pruebas. Es un modelo de confianza mucho más sólido para una plataforma distribuida.

Lo que yo sacaría de esto si trabajara en un sistema .NET distribuido

Si hoy trabajas con servicios distribuidos, Aspire y canalizaciones de CI/CD, esto es lo que sacaría de inmediato:

deja de normalizar la inestabilidad en entornos compartidos
migra a puertas de arranque basadas en disponibilidad siempre que puedas
trata AppHost como código real de orquestación de nivel producción
construye comprobaciones end-to-end que validen la composición de servicios, no solo la corrección de cada servicio por separado
si vas a adoptar desarrollo asistido por IA, invierte primero en verificabilidad antes de perseguir más amplitud de automatización

Ese último punto es el que creo que más equipos necesitan oír.

Mi opinión

Esta es una de las entradas más sólidas de Aspire de este lote porque resuelve un problema muy práctico.

No intenta impresionarte con abstracción. Muestra cómo hacer que las pruebas end-to-end sean más deterministas, más útiles y más confiables en un sistema distribuido real.

Y en cuanto ves la conexión con el desarrollo asistido por agentes, el patrón se vuelve todavía más convincente.

Si tu historia de pruebas end-to-end sigue dependiendo de entornos compartidos, conocimiento oculto de configuración y un poco de oración, merece mucho la pena estudiarla.

Artículo original: How Azure Chaos Studio ships with hermetic Aspire end-to-end tests