Developer Experience | The .NET Blog

Rivedere le pull request dentro Visual Studio è esattamente il tipo di riduzione dell'attrito che mi piace

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

Questo articolo è stato tradotto automaticamente. Leggi l’originale qui.

Il browser si è preso fin troppo del flusso di lavoro di code review per troppo tempo.

Per questo sono molto contento di vedere Visual Studio spingersi ancora di più verso la revisione end-to-end delle pull request dentro l’IDE.

È una di quelle funzionalità che magari non generano grandi titoli, ma possono migliorare in modo concreto lo sviluppo quotidiano.

Il valore principale è semplice: meno context switching

Quando il tuo ciclo di review vive in parte nell’IDE e in parte nel browser, l’attrito si accumula:

apri la PR altrove
ispezioni le modifiche in uno strumento
torni alla solution per approfondire
cambi ancora per commentare o approvare

Non è catastrofico. È solo inefficiente.

Se Visual Studio ti permette di aprire, ispezionare, commentare, approvare e fare merge dallo stesso ambiente di lavoro, quello è un vero guadagno di produttività.

L’opzione “review senza checkout” è particolarmente buona

Una parte che mi piace particolarmente è la possibilità di fare review senza fare checkout del branch della PR.

Può sembrare piccolo, ma è perfetto per:

passaggi di review rapidi
richieste di feedback innescate da interruzioni
mantenere intatto il branch corrente e lo stato locale

È esattamente il tipo di flessibilità di cui hanno bisogno i buoni strumenti di code review.

La mia opinione

Non è una funzionalità rivoluzionaria.

È qualcosa di meglio: qualcosa di pratico.

Per i team che passano la maggior parte della giornata in Visual Studio, un supporto più stretto alla revisione PR significa meno interruzioni del workflow e un percorso più fluido dall’ispezione all’azione.

Per me è un miglioramento che vale la pena.

Pubblicazione originale: Revisione delle pull request senza lasciare Visual Studio

Gli Agent Harness Contano Perché i Prompt Non Bastano

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

Il nuovo walkthrough su claw e harness di Microsoft Agent Framework è un utile promemoria che gli agenti reali hanno bisogno di un guscio runtime attorno al modello: strumenti, pianificazione, memoria, sessioni e un ciclo di esecuzione pratico.

Aspire in VS Code 13.4 Stringe il Ciclo di Sviluppo in Tutti i Modi Giusti

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

I migliori aggiornamenti degli strumenti sono quelli che si sentono dopo qualche giorno, non quelli che sembrano belli solo nelle note di rilascio.

È così che vedo Aspire in VS Code 13.4.

Questo aggiornamento riguarda tutto il miglioramento del ciclo interno: creare progetti più velocemente, fare debug di risorse in linguaggi misti in modo più naturale, mostrare salute e comandi direttamente nell’editor e tenere il dashboard vicino senza renderlo l’unico posto in cui puoi lavorare.

È un’ottima direzione.

Il grande vantaggio è meno cambio di contesto

Se usi Aspire seriamente, di solito ti muovi attraverso diverse superfici:

codice AppHost
terminale
dashboard
log
sessioni di debug
endpoint dei servizi

Ciò che 13.4 fa bene è ridurre l’attrito tra queste superfici.

La nuova esperienza VS Code rende più visibile lo stato dell’app esattamente dove stai già lavorando:

salute delle risorse nell’editor
comandi accanto alle dichiarazioni delle risorse
accesso più facile al dashboard
accesso ai log dal contesto AppHost
un pannello che rimane utile anche prima che il debug completo inizi

Sembra piccolo finché non lo fai ogni giorno.

Il debug di stack misti conta più di quanto si pensi

Uno dei punti più forti di questo aggiornamento è la storia più naturale per il debug di C#, TypeScript, Python, Go, app browser e Azure Functions in un unico flusso guidato da Aspire.

Questo riflette la forma reale delle app moderne molto meglio che fingere che tutto viva in un unico runtime.

Per gli sviluppatori .NET in particolare, questo è prezioso perché molti di noi ora costruiscono sistemi che mescolano progetti API, frontend, worker e servizi AI-adiacenti in linguaggi diversi.

Il fatto che Aspire stia rendendo tutto questo più unificato all’interno di VS Code è un miglioramento molto pratico.

Il supporto TypeScript AppHost in GA è anche significativo

Non ignorerei il lato TypeScript AppHost di questo rilascio.

Aspire che diventa più naturale sia per C# che per TypeScript allarga chi può lavorare nello stesso modello di sistema senza flussi di lavoro di seconda classe. Questo conta per team dove codice platform, codice frontend e orchestrazione dei servizi vivono tutti vicini.

Il mio parere

Aspire 13.4 in VS Code non riguarda una funzionalità killer. Riguarda levigare gli spigoli nel ciclo quotidiano:

iniziare più velocemente
vedere più stato dove scrivi codice
fare debug in modo più naturale
passare a log e dashboard solo quando necessario

È esattamente come dovrebbe evolversi un buon tooling.

Se già usi Aspire, questo aggiornamento vale l’installazione. Se ti stai ancora chiedendo se VS Code sia una sede seria per lo sviluppo basato su Aspire, la risposta sta diventando sempre più ovvia.

Post originale: Aspire in VS Code: the 13.4 developer loop

Il nuovo Plan agent in Visual Studio risolve un problema molto reale del workflow IA

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

Questo articolo è stato tradotto automaticamente. Leggi l’originale qui.

Uno dei workflow di coding IA più frustranti è quando l’implementazione parte troppo in fretta.

Il codice può perfino essere tecnicamente corretto, ma sta risolvendo la versione sbagliata del problema che avevi in mente.

Volevi un refactor. È partita una riscrittura. Volevi un miglioramento circoscritto. Ha toccato metà progetto. Volevi parlare delle opzioni. È saltato direttamente ai cambiamenti dei file.

Per questo il nuovo Plan agent in Visual Studio è un’aggiunta così utile.

Questo risolve un vero problema di workflow, non solo un problema estetico

Il post originale descrive una situazione molto familiare: “Il codice non è sbagliato… semplicemente non è quello che volevi.”

Quella frase è perfetta.

Perché il punto debole di tanto sviluppo assistito dall’IA non è se il modello riesce a produrre codice. È se il workflow crea abbastanza spazio per concordare la forma desiderata del lavoro prima che inizi l’implementazione.

Questo conta soprattutto per:

funzionalità grandi
codebase non familiari
refactor non banali
cambiamenti sensibili all’architettura
lavoro che richiede una revisione del team prima di iniziare a modificare

In queste situazioni, saltare direttamente all’implementazione è spesso la mossa sbagliata.

La pianificazione non è overhead quando il task è reale

Penso che i team a volte sottovalutino quanto tempo perdono iniziando l’implementazione troppo presto.

Se l’agent:

tocca i file sbagliati
sceglie l’approccio sbagliato
ignora un vincolo chiave
trascura un edge case necessario

allora l’inizio “rapido” diventa, alla fine, un workflow più lento.

Per questo mi piace questa funzione.

Lascia spazio per:

domande di chiarimento
stesura del piano
modifica diretta del piano
condivisione del piano prima che inizino le modifiche al codice

Non è burocrazia. Spesso è semplicemente buona ingegneria.

Il file di piano in markdown è una scelta intelligente

Un dettaglio che mi piace particolarmente è che ogni piano viene salvato in .copilot/plans/plan-{title}.md.

Questo rende tangibile la fase di pianificazione.

Significa che il piano non resta intrappolato dentro un transcript di chat. Diventa qualcosa che puoi:

rivedere
modificare
versionare mentalmente
discutere con il team
passare all’implementazione in modo più deliberato

Questo fa sembrare la funzione molto più seria di un semplice preambolo temporaneo prima della generazione del codice.

È qui che i workflow IA iniziano a rispettare il processo del team

Penso che questo sia uno dei segnali più forti che questi tool stanno maturando.

I migliori workflow IA per sviluppatori non sono quelli che eliminano tutti i passaggi intermedi. Sono quelli che migliorano i passaggi intermedi giusti.

E la pianificazione è uno di quei passaggi.

Se il piano è forte, l’implementazione diventa più facile. Se il piano è debole, l’implementazione diventa rumorosa.

Questa funzione lo riconosce direttamente.

La mia opinione

Non si tratta solo di una comodità IA.

È un miglioramento del workflow.

E per funzionalità reali e refactor reali, è esattamente il tipo di miglioramento che può risparmiare molto churn inutile, rumore di review e rework del tipo “non era questo che intendevo”.

Penso che sempre più esperienze di agent finiranno per aver bisogno di qualcosa del genere.

Visual Studio ci è arrivato prima, in un modo che risulta utile.

Pubblicazione originale: Pianifica prima di costruire: introduzione del Plan agent in Visual Studio

Il tuo dev loop è pieno di conoscenza tribale, e Aspire dà la risposta giusta

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

Questo articolo è stato tradotto automaticamente. Leggi l’originale qui.

Questo potrebbe essere uno dei post più importanti su Aspire per capire perché il prodotto conta.

Non perché annunci una grande nuova funzionalità.

Perché dà un nome a un problema che quasi tutti i team di engineering hanno sentito e non tutti hanno descritto bene:

il dev loop è pieno di conoscenza tribale.

Quella frase colpisce perché è vera.

Il problema non è la mancanza di tool

L’argomento centrale dell’articolo originale è ottimo: spesso i team non mancano di infrastruttura, script, dashboard o comandi.

Quello che manca è un modello coerente che trasformi tutta la conoscenza operativa nascosta intorno all’app in qualcosa di visibile e ripetibile.

La vera architettura di molte app vive in:

la cronologia della shell
script sparsi
frammenti di README
thread Slack
l’unico senior engineer che conosce l’ordine delle operazioni

Non è un dev loop sostenibile per gli umani.

E certamente non lo è per gli agent.

La citazione che penso riassuma tutto il post

C’è una frase nell’articolo originale che secondo me cattura molto bene il punto generale:

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

Questa è tutta la tesi in una sola riga.

E sinceramente, è una delle migliori spiegazioni in una sola frase di Aspire che abbia visto finora.

Perché conta più adesso che un anno fa

Penso che questo post funzioni particolarmente bene nel momento attuale perché lo sviluppo assistito dall’IA cambia il costo dell’ambiguità.

Gli umani possono compensare sistemi incompleti in modo sorprendentemente efficace.

Ricordiamo:

quale script va eseguito per primo
quale environment variable è segretamente necessaria
quale terminal mostra di solito i log utili
quale servizio va riavviato due volte per ragioni che nessuno ha documentato

Gli agent sono molto peggiori con questo tipo di folclore operativo nascosto.

Quindi, se vogliamo che gli agent diventino davvero utili in repository reali, dobbiamo rendere il system più esplicito, non meno.

Per questo penso che il framing di Aspire sia importante.

Il valore reale di Aspire non è solo orchestration

Un errore comune è pensare ad Aspire solo come a un launcher di app distribuite o a un aiuto di orchestration locale.

Questa è una visione troppo piccola.

La value proposition più forte è che Aspire dà all’app:

un model
una shape
risorse nominate
dipendenze esplicite
surface per health e operations
comandi che umani e automazione possono capire

Questo cambia il dev loop più di quanto a volte si realizzi.

Perché, una volta che l’app smette di essere un mucchio di convenzioni implicite e diventa un sistema con un model reale, varie cose diventano più facili nello stesso momento:

onboarding
debugging
setup ripetibile
consistenza CI
workflow assistiti da IA

È molta leva da una sola scelta di design.

Mi piace במיוחד l’angolo “commands as first-class operations”

Un altro punto dell’articolo originale che merita più attenzione è il passaggio dalle istruzioni nel README a comandi associati alle risorse.

È un cambiamento apparentemente piccolo ma in realtà grande.

Invece di dire:

esegui questo script, poi quello, e magari un altro se il primo fallisce

puoi modellare le operazioni direttamente nel contesto dell’app.

Questo rende più facile scoprirle per gli umani.

E significa che gli agent non devono indovinare l’intenzione dalla prosa.

È il tipo di cosa che trasforma un’app da “operabile se la conosci già” a “operabile by design”.

Cosa ne trarrei come team lead

Se guardassi il dev loop del mio team attraverso questa lente, mi farei alcune domande dirette:

quanto del nostro setup dipende dalla memoria?
quante azioni critiche di sviluppo esistono solo nei docs o nei thread chat?
quanto spesso i nuovi contributor rimangono bloccati da un comportamento invisibile del system?
un tool di automazione o un coding agent potrebbe capire la topologia della nostra app dal repo stesso?

Se la risposta all’ultima domanda è “per niente”, allora questo post dovrebbe colpire un nervo utile.

La mia opinione

Questo è un framing molto forte del vero valore di Aspire.

Non è solo orchestration.

È rendere il model dell’app abbastanza esplicito da far sì che il system sia più facile da operare, capire e automatizzare.

Questo conta per gli umani. Conta per i team. E conta ancora di più ora che gran parte dello sviluppo moderno si sta muovendo verso workflow assistiti da agent.

È esattamente il tipo di articolo che aiuta a spiegare perché Aspire sembri sempre più rilevante oltre la semplice etichetta di marketing .NET.

Pubblicazione originale: Il tuo dev loop è pieno di conoscenza tribale— title: “Il tuo dev loop è pieno di conoscenza implicita, e Aspire ha la risposta giusta” date: 2026-06-01 author: “Emiliano Montesdeoca” description: “Un nuovo post su Aspire fa un punto molto forte: molti team non mancano di tool, manca invece un modello applicativo coerente che trasformi la conoscenza operativa nascosta in qualcosa che umani, script e agent possano davvero usare.” tags:

Aspire
Developer Experience
AI
Dev Loop
.NET

Questo articolo è stato tradotto automaticamente. Leggi l’originale qui.

Potrebbe essere uno dei post di Aspire più importanti per capire perché il prodotto conta.

Non perché annunci una grande nuova funzionalità.

Perché dà un nome a un problema che quasi ogni team di engineering ha sentito e non tutti hanno descritto bene:

il dev loop è pieno di conoscenza implicita.

Quella frase colpisce perché è vera.

Il problema non è la mancanza di tool

L’argomento centrale dell’articolo originale è eccellente: ai team spesso non mancano infrastrutture, script, dashboard o command.

Quello che manca è un modello coerente che trasformi tutta la conoscenza operativa nascosta attorno all’applicazione in qualcosa di visibile e ripetibile.

La vera architettura di molte app vive in:

la shell history
script sparsi
frammenti di README
thread Slack
quell’unico senior engineer che conosce l’ordine delle operazioni

Questo non è un dev loop sostenibile per gli umani.

E sicuramente non lo è per gli agent.

La citazione che, secondo me, riassume tutto il post

C’è una frase nell’articolo originale che, secondo me, cattura molto bene il punto generale:

“Le applicazioni esistono già come sistemi. Aspire rende espliciti quei sistemi, perché i sistemi espliciti scalano meglio della conoscenza implicita.”

Questa è l’intera tesi in una sola riga.

E, onestamente, è una delle spiegazioni di Aspire in una frase più forti che abbia visto finora.

Perché questo conta più adesso che un anno fa

Penso che questo post funzioni particolarmente bene adesso perché lo sviluppo assistito dall’IA cambia il costo dell’ambiguità.

Gli umani riescono a compensare sistemi incompleti in modo sorprendente.

Ricordiamo:

quale script eseguire per primo
quale variabile d’ambiente è segretamente necessaria
quale terminal di solito mostra i log utili
quale servizio va riavviato due volte per motivi che nessuno ha documentato

Gli agent sono molto peggiori in questo tipo di folklore operativo nascosto.

Quindi, se vogliamo che gli agent diventino davvero utili nei repository reali, dobbiamo rendere il sistema più esplicito, non meno.

Ecco perché penso che questo framing di Aspire sia importante.

Il vero valore di Aspire non è solo l’orchestrazione

Un errore comune con Aspire è pensarlo solo come un distributd app launcher o un aiuto di orchestrazione locale.

È un quadro troppo piccolo.

La proposta di valore più forte è che Aspire dà all’applicazione:

un modello
una forma
risorse nominate
dipendenze esplicite
superfici per salute e operazioni
comandi che umani e automazione possono capire insieme

Questo cambia il dev loop molto più di quanto a volte si riconosca.

Perché, quando l’app smette di essere una pila di convenzioni implicite e diventa un sistema con un modello reale, diverse cose diventano più facili tutte insieme:

onboarding
debugging
configurazione ripetibile
coerenza CI
workflow assistiti dall’IA

È un enorme effetto leva da una sola scelta di design.

Mi piace in particolare l’angolo “comandi come operazioni di prima classe”

Un altro punto del post originale che, secondo me, merita più attenzione è il passaggio dalle istruzioni README ai comandi legati alle risorse.

È un cambiamento più grande di quanto sembri.

Invece di dire:

esegui questo script, poi quello, e magari quest’altro se il primo fallisce

puoi modellare le operazioni direttamente nel contesto dell’app.

Questo significa che gli umani possono scoprirle più facilmente.

E significa che gli agent non devono indovinare l’intento dalla prosa.

È il tipo di cosa che trasforma un’app da “operabile se già la conosci” a “operabile by design”.

Cosa ne trarrei io come team lead

Se guardassi il dev loop del mio team attraverso questa lente, mi farei alcune domande dirette:

quanto della nostra configurazione dipende dalla memoria?
quante azioni critiche di sviluppo esistono solo in doc o thread di chat?
quanto spesso i nuovi contributor si bloccano per un comportamento invisibile del sistema?
un tool di automazione o un coding agent potrebbe capire la topologia della nostra app dal solo repo?

Se la risposta all’ultima domanda è “nemmeno lontanamente”, allora questo post dovrebbe toccare un nervo utile.

La mia opinione

Questa è una cornice molto forte per il vero valore di Aspire.

Non è solo orchestrazione.

Si tratta di rendere il modello dell’app abbastanza esplicito da far sì che il sistema sia più facile da operare, capire e automatizzare.

Questo conta per le persone. Conta per i team. E conta ancora di più adesso che gran parte dello sviluppo moderno si sta muovendo verso workflow assistiti da agent.

Questo è esattamente il tipo di articolo che aiuta a spiegare perché Aspire sembra sempre più rilevante, oltre alla semplice etichetta di marketing .NET.

Pubblicazione originale: Il tuo dev loop è pieno di conoscenza implicita

I test end-to-end ermetici di Aspire sono il tipo di modello che più team dovrebbero adottare

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

Questo articolo è stato tradotto automaticamente. Per la versione originale, clicca qui.

I test end-to-end flaky sono costosi in un modo che non sempre compare su una dashboard.

Non si limitano a fallire. Allenano lentamente il team a smettere di fidarsi del ciclo di feedback.

Per questo questo articolo su Azure Chaos Studio + Aspire mi ha colpito subito. Non è un annuncio di prodotto appariscente. È una storia di ingegneria molto concreta su come far smettere ai test end-to-end di sembrare una trattativa con la fortuna.

E sinceramente? Penso che più team dovrebbero adottare questo modello.

L’idea di base è semplice, ma il vantaggio è enorme

La mossa chiave è dare a ogni test il proprio ambiente ermetico ed effimero, con servizi reali, dipendenze reali e un avvio esplicito basato sullo stato di salute.

Letto in una frase, sembra ovvio. Nei sistemi reali è molto più difficile, soprattutto quando entrano in gioco dipendenze cloud, ambienti condivisi e servizi distribuiti.

L’articolo originale descrive il problema in modo molto chiaro: gli ambienti di test condivisi portano “cross-talk, flaky behavior e messaggi di gruppo del tipo ‘chi ha rotto staging?’” come costo del mestiere.

Quella frase fa sorridere perché fa male.

Troppi team accettano questo compromesso come se fosse normale. Io non credo che dovrebbero.

Perché questo modello conta oltre i test

Quello che mi piace di più qui è che l’articolo non dice solo: “abbiamo reso i test più affidabili”.

Sta in realtà dicendo qualcosa di più grande:

se il tuo sistema distribuito è difficile da riprodurre, difficile da isolare e difficile da verificare, tutto il tuo ciclo di engineering rallenta.

Questo non influisce solo sulla CI.

Influisce su:

quanto i developer si sentono sicuri nel fare refactoring
quanto rapidamente vengono diagnosticate le regressioni
quanto è sicuro provare cambiamenti architetturali più grandi
quanta fiducia il team ripone nella validazione automatica

E nel 2026 influisce anche su quanto utile possa diventare lo sviluppo assistito dall’IA.

La citazione più importante del post

C’è una frase nell’articolo che secondo me vale la pena ripetere:

“Gli agenti non devono essere perfetti. Devono essere verificabili.”

È un framing eccellente.

Si passa molto tempo a chiedersi se gli agenti di coding con IA siano abbastanza affidabili per aiutare su lavoro non banale. Io penso che la domanda migliore sia se i nostri sistemi sono abbastanza testabili da valutare correttamente quel lavoro.

Se un agente propone un refactoring significativo e il tuo unico segnale di sicurezza è una pila di controlli end-to-end fragili e semi-casuali che girano su un ambiente condiviso, allora il problema non è solo l’agente.

Il problema è il tuo modello di validazione.

Questo modello Aspire lo migliora in modo drastico.

Cosa rende questa implementazione particolarmente buona

Diversi elementi della storia originale fanno sì che questo sia molto più di un generico post “abbiamo migliorato i test”.

1. Un vero grafo di servizi, non un teatro di falsi mock

I test non si basano su una pila di mock scollegati che fingono di fare validazione end-to-end.

Eseguono i binari reali, collegano emulatori dove possibile e usano lo stesso application model impiegato nello sviluppo locale.

Questo conta.

Perché nel momento in cui i test end-to-end diventano teatro di mock contro mock, smettono di dirti qualcosa di affidabile sulla composizione reale.

2. Avvio basato sulla salute invece di sleep magici

Questo punto è più grande di quanto sembri.

L’articolo dice chiaramente che i test aspettano la reale health con WaitForResourceHealthyAsync, invece di affidarsi a ipotesi arbitrarie sui tempi.

È una differenza enorme.

Una suite che dice “dormi 30 secondi e spera per il meglio” sta sostanzialmente documentando incertezza. Una suite che aspetta la reale readiness sta documentando l’intento del sistema.

3. Lo stesso modello guida sviluppo locale e test

Mi piace molto perché si allinea con le storie Aspire più forti in generale.

Lo stesso application model guida:

lo sviluppo locale
il wiring dei servizi
le dipendenze emulate
i controlli di health
l’orchestrazione di test ermetici

Questo riduce il drift, e il drift è uno dei killer silenziosi della fiducia.

Questo tipo di investimento nella devex viene sottovalutato

Uno dei motivi per cui volevo che questo post fosse più lungo di una semplice reazione è che penso che questi miglioramenti di engineering vengano spesso sottovalutati.

Non sono appariscenti.

Non si demoano come una nuova funzionalità AI.

E non sempre producono una singola slide che entusiasma i dirigenti.

Ma nel tempo creano qualcosa di molto più prezioso: un team che può andare più veloce senza mentire a se stesso sulla qualità.

È una cosa enorme.

L’articolo dice che ora eseguono circa 90 test ermetici, inclusi scenari come outage di zona, fallimento DNS e fallimento della replica geografica. Non è solo una migliore igiene dei test. È un modello di fiducia molto più forte per una piattaforma distribuita.

Cosa prenderei da questo se gestissi un sistema .NET distribuito

Se oggi lavori con servizi distribuiti, Aspire e pipeline CI/CD, questo è ciò che prenderei subito:

smetti di normalizzare la flaky behavior negli ambienti condivisi
passa a gate di avvio basati sulla salute ogni volta che puoi
tratta AppHost come codice di orchestrazione reale, di livello production
costruisci controlli end-to-end che validino la composizione dei servizi, non solo la correttezza di ciascun servizio isolatamente
se stai adottando lo sviluppo assistito dall’IA, investi prima nella verificabilità prima di inseguire una maggiore ampiezza dell’automazione

Questo ultimo punto è quello che più team devono sentire.

La mia opinione

Questo è uno dei post Aspire più forti di questo gruppo perché risolve un problema molto pratico.

Non cerca di impressionarti con l’astrazione. Mostra come rendere i test end-to-end più deterministici, più utili e più affidabili in un vero sistema distribuito.

E una volta che si vede il collegamento con lo sviluppo assistito dagli agenti, il modello diventa ancora più convincente.

Se la tua storia di test end-to-end dipende ancora da ambienti condivisi, conoscenza nascosta di setup e un po’ di preghiera, vale davvero la pena studiarlo.

Post originale: How Azure Chaos Studio ships with hermetic Aspire end-to-end tests