Developer Experience | The .NET Blog

Pull Requests direkt in Visual Studio zu prüfen, ist genau die Art von Reibungsreduktion, die ich mag

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

Dieser Beitrag wurde automatisch übersetzt. Lies das Original hier.

Der Browser stiehlt dem Code-Review-Workflow schon viel zu lange zu viel Aufmerksamkeit.

Deshalb freue ich mich sehr zu sehen, dass Visual Studio weiter in Richtung End-to-End-Pull-Request-Review direkt in der IDE geht.

Das ist eine dieser Funktionen, die vielleicht keine riesigen Schlagzeilen machen, aber den Alltag spürbar verbessern können.

Der Hauptwert ist simpel: weniger Kontextwechsel

Wenn dein Review-Loop teilweise in der IDE und teilweise im Browser lebt, summiert sich die Reibung:

das PR woanders öffnen
die Änderungen in einem Tool ansehen
wieder zur Solution wechseln, um tiefer zu prüfen
noch einmal wechseln, um zu kommentieren oder freizugeben

Das ist nicht katastrophal. Es ist einfach ineffizient.

Wenn Visual Studio es dir erlaubt, ein PR zu öffnen, zu prüfen, zu kommentieren, freizugeben und zusammenzuführen, alles aus derselben Arbeitsumgebung heraus, dann ist das ein echter Produktivitätsgewinn.

Die Option „review ohne Checkout“ ist besonders angenehm

Ein Punkt, den ich besonders mag, ist die Möglichkeit, ohne Checkout des PR-Branches zu reviewen.

Das klingt klein, ist aber perfekt für:

schnelle Review-Durchgänge
unterbrochene Feedback-Anfragen
den aktuellen Branch und den lokalen Zustand unverändert zu lassen

Das ist genau die Art von Flexibilität, die gute Code-Review-Tools brauchen.

Meine Einschätzung

Das ist keine revolutionäre Funktion.

Es ist etwas Besseres: etwas Praktisches.

Für Teams, die den Großteil des Tages in Visual Studio verbringen, bedeutet stärkeres PR-Review-Support weniger Workflow-Unterbrechungen und einen glatteren Weg von der Prüfung zur Aktion.

Das ist in meinen Augen eine lohnenswerte Verbesserung.

Originalbeitrag: Pull Requests prüfen, ohne Visual Studio zu verlassen

Agent-Harnesses sind wichtig, weil Prompts nicht ausreichen

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

Einer der häufigsten Fehler in der Agent-Entwicklung ist zu glauben, der Prompt sei das Produkt.

Ist er nicht.

Die neue Agent-Harness-und-Claw-Walkthrough des Microsoft Agent Framework-Teams ist wertvoll, weil sie den Fokus auf den Teil legt, der wirklich bestimmt, ob sich ein Agent nutzbar anfühlt: die Laufzeithülle um das Modell.

Dazu gehören:

Werkzeuge (Tools)
Planung (Planning)
Sitzungszustand (Session State)
Speicher (Memory)
Ausführungsmodi
eine nutzbare Konsole oder Schnittstelle für Iterationen

Dort hören Agenten auf, clevere Demos zu sein, und fühlen sich an wie Software.

Das Harness-Muster ist praxistauglich

Was mir gefällt, ist, wie zugänglich die Idee ist.

Sie beginnen mit einem Chat-Client.

Dann wickeln Sie ihn in ein Harness mit Anweisungen und Werkzeugen.

Dann führen Sie ihn durch eine Shell aus, die Planung, Aufgaben, Sitzungen und Streaming-Interaktion unterstützt.

Das ist ein gesundes Muster, weil es Zuständigkeiten klar trennt:

das Modell übernimmt die logische Schlussfolgerung
das Harness übernimmt das Laufzeitverhalten
die App entscheidet, welche Werkzeuge und Erfahrungen wichtig sind

Das passt sehr gut zur Arbeitsweise von .NET-Entwicklern

Die Harness-Idee passt auch gut zur .NET-Denkweise.

Wir arbeiten in der Regel besser, wenn Laufzeitverhalten explizit und komponierbar ist. Middleware, Pipelines, Optionen, Provider und Adapter fühlen sich in dieser Welt natürlich an.

Deshalb glaube ich, dass Agent Framework gute Chancen hat, bei .NET-Entwicklern anzukommen. Es zwingt niemanden in eine magische Abstraktion. Es gibt Ihnen strukturierte Laufzeitbausteine, die Sie zusammenschalten können.

Meine Meinung

Der nützlichste Teil dieses Beitrags ist die Erinnerung daran, dass Agenten mehr brauchen als ein gutes Modell und einen cleveren Anweisungstext.

Sie brauchen eine Laufzeithülle, die ihnen Struktur, Speicher, Werkzeugzugriff, Planung und eine brauchbare Entwicklerschleife bietet.

Das gibt Ihnen das Harness.

Und ehrlich gesagt, deshalb lohnt es sich, auf dieses Muster zu achten.

Originalbeitrag: Meet your agent harness and claw

Aspire in VS Code 13.4 zieht die Entwicklerschleife in genau der richtigen Weise an

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

Die besten Tooling-Updates sind die, die man nach ein paar Tagen spürt, nicht die, die nur in Release-Notes gut aussehen.

So liest sich Aspire in VS Code 13.4 für mich.

Bei diesem Update geht es ganz um die Straffung der inneren Schleife: Projekte schneller erstellen, Debugging gemischtsprachiger Ressourcen natürlicher gestalten, Health und Befehle direkt im Editor anzeigen und das Dashboard nahe halten, ohne es zum einzigen Arbeitsort zu machen.

Das ist eine sehr gute Richtung.

Der große Gewinn ist weniger Kontextwechsel

Wenn Sie Aspire ernsthaft nutzen, bewegen Sie sich normalerweise über mehrere Oberflächen:

AppHost-Code
Terminal
Dashboard
Logs
Debug-Sessions
Service-Endpunkte

Was 13.4 gut macht, ist die Reibung zwischen diesen Oberflächen zu reduzieren.

Die neue VS Code-Erfahrung macht mehr vom App-Status genau dort sichtbar, wo Sie bereits arbeiten:

Ressourcen-Health im Editor
Befehle neben Ressourcendeklarationen
einfacherer Dashboard-Zugriff
Log-Zugriff aus dem AppHost-Kontext
ein Panel, das auch vor vollständigem Debugging-Start nützlich bleibt

Das klingt klein, bis man es jeden Tag tut.

Debugging gemischter Stacks ist wichtiger als man denkt

Einer der stärksten Teile dieses Updates ist die natürlichere Geschichte zum Debuggen von C#, TypeScript, Python, Go, Browser-Apps und Azure Functions in einem einzigen Aspire-gesteuerten Flow.

Das spiegelt die reale Form moderner Apps viel besser wider, als so zu tun, als ob alles in einer einzigen Laufzeit lebt.

Besonders für .NET-Entwickler ist das wertvoll, weil viele von uns jetzt Systeme bauen, die API-Projekte, Frontends, Worker und KI-bezogene Dienste in verschiedenen Sprachen mischen.

Die Tatsache, dass Aspire dies in VS Code einheitlicher gestaltet, ist eine sehr praktische Verbesserung.

Meine Meinung

Aspire 13.4 in VS Code dreht sich nicht um eine Killer-Feature. Es geht darum, die rauen Kanten in der täglichen Schleife zu glätten:

schneller starten
mehr Status dort sehen, wo Sie codieren
natürlicher debuggen
nur bei Bedarf zu Logs und Dashboard springen

Genau so sollte sich gutes Tooling weiterentwickeln.

Originalquelle: Aspire in VS Code: the 13.4 developer loop

Der neue Plan-Agent in Visual Studio löst ein sehr reales KI-Workflow-Problem

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

Dieser Beitrag wurde automatisch übersetzt. Lies das Original hier.

Einer der frustrierendsten KI-Coding-Workflows ist der, bei dem die Implementierung viel zu schnell beginnt.

Der Code kann sogar technisch vollkommen in Ordnung sein, aber er löst die falsche Version des Problems, das du im Kopf hattest.

Du wolltest ein Refactoring. Es begann mit einem Rewrite. Du wolltest eine begrenzte Verbesserung. Es berührte die halbe Anwendung. Du wolltest die Optionen durchsprechen. Es sprang direkt zu Dateiänderungen.

Deshalb ist der neue Plan-Agent in Visual Studio eine so nützliche Ergänzung.

Das löst ein echtes Workflow-Problem, nicht nur ein kosmetisches

Der Originalbeitrag beschreibt eine sehr bekannte Situation: “Der Code ist nicht falsch … er ist nur nicht das, was du wolltest.”

Dieser Satz ist perfekt.

Denn die Schwachstelle in vielen KI-gestützten Workflows ist nicht, ob das Modell Code erzeugen kann. Es ist, ob der Workflow genug Raum schafft, um sich vor dem Implementieren auf die beabsichtigte Form der Arbeit zu einigen.

Das ist besonders wichtig für:

größere Features
unbekannte Codebasen
nicht triviale Refactorings
architekturkritische Änderungen
Arbeit, die vor dem Editieren ein Team-Review braucht

In solchen Situationen ist der direkte Sprung in die Implementierung oft der falsche Schritt.

Planung ist kein Overhead, wenn die Aufgabe real ist

Ich denke, Teams unterschätzen manchmal, wie viel Zeit sie verlieren, wenn sie zu früh mit der Implementierung beginnen.

Wenn der Agent:

die falschen Dateien anfasst
den falschen Ansatz wählt
eine wichtige Einschränkung übersieht
einen nötigen Edge Case ignoriert

dann wird der vermeintlich „schnelle“ Start insgesamt zum langsameren Workflow.

Deshalb gefällt mir diese Funktion.

Sie schafft Raum für:

klärende Fragen
das Entwerfen eines Plans
das direkte Bearbeiten des Plans
das Teilen des Plans, bevor Codeänderungen beginnen

Das ist keine Bürokratie. Das ist oft einfach gute Ingenieursarbeit.

Die Markdown-Plan-Datei ist eine kluge Wahl

Ein Detail, das ich besonders mag, ist, dass jeder Plan unter .copilot/plans/plan-{title}.md gespeichert wird.

Dadurch wird der Planungsschritt greifbar.

Der Plan steckt nicht in einem Chat-Transcript fest. Er wird zu etwas, das du:

prüfen
bearbeiten
gedanklich versionieren
mit dem Team besprechen
bewusster in die Implementierung überführen

Das lässt die Funktion deutlich ernster wirken als nur eine vorübergehende Einleitung vor der Codegenerierung.

Hier beginnen KI-Workflows, den Teamprozess zu respektieren

Ich denke, das ist eines der stärkeren Zeichen dafür, dass diese Tools reifer werden.

Die besten KI-Entwickler-Workflows sind nicht diejenigen, die alle Zwischenschritte entfernen. Es sind diejenigen, die die richtigen Zwischenschritte verbessern.

Und Planung ist einer dieser Schritte.

Wenn der Plan stark ist, wird Implementierung einfacher. Wenn der Plan schwach ist, wird Implementierung laut und chaotisch.

Diese Funktion erkennt das direkt an.

Meine Einschätzung

Das ist nicht nur eine KI-Nettheit.

Es ist eine Workflow-Verbesserung.

Und bei echten Features und echten Refactorings ist es genau die Art von Verbesserung, die viel unnötiges Churn, Review-Lärm und „Das meinte ich nicht“-Nacharbeit sparen kann.

Ich denke, immer mehr Agentenerlebnisse werden irgendwann etwas wie das brauchen.

Visual Studio ist dort früher angekommen, und zwar auf eine nützliche Art.

Originalbeitrag: Vor dem Bauen planen: den Plan-Agenten in Visual Studio vorstellen

Dein Dev-Loop ist voller Tribal Knowledge, und Aspire gibt die richtige Antwort

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

Dieser Beitrag wurde automatisch übersetzt. Lies das Original hier.

Das könnte einer der wichtigsten Aspire-Beiträge sein, um zu verstehen, warum das Produkt relevant ist.

Nicht, weil er ein großes neues Feature ankündigt.

Sondern weil er ein Problem benennt, das fast jedes Engineering-Team schon gespürt hat, aber nicht jedes Team gut beschrieben hat:

Der Dev-Loop ist voller Tribal Knowledge.

Diese Formulierung trifft, weil sie wahr ist.

Das Problem ist nicht der Mangel an Tools

Das Kernargument des Originalartikels ist hervorragend: Teams fehlt oft nicht an Infrastruktur, Skripten, Dashboards oder Befehlen.

Was ihnen fehlt, ist ein kohärentes Modell, das das ganze versteckte Betriebswissen rund um die Anwendung in etwas Sichtbares und Wiederholbares verwandelt.

Die eigentliche Architektur vieler Apps lebt in:

der Shell-History
verstreuten Skripten
README-Schnipseln
Slack-Threads
dem einen Senior Engineer, der die Reihenfolge der Operationen kennt

Das ist kein nachhaltiger Dev-Loop für Menschen.

Und ganz sicher auch keiner für Agents.

Das Zitat, das für mich den ganzen Beitrag auf den Punkt bringt

Es gibt einen Satz im Originalartikel, der den größeren Punkt sehr gut trifft:

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

Das ist die gesamte Argumentation in einer Zeile.

Und ehrlich gesagt ist es eine der stärksten Ein-Zeilen-Erklärungen für Aspire, die ich bisher gesehen habe.

Warum das jetzt mehr zählt als vor einem Jahr

Ich denke, dieser Beitrag trifft besonders gut in der aktuellen Lage, weil KI-gestützte Entwicklung die Kosten von Unschärfe verändert.

Menschen können unvollständige Systeme erstaunlich gut kompensieren.

Wir merken uns:

welches Skript zuerst laufen muss
welche Umgebungsvariable heimlich erforderlich ist
welches Terminal normalerweise die nützlichen Logs zeigt
welcher Dienst aus Gründen, die niemand dokumentiert hat, zweimal neu gestartet werden muss

Agents sind bei dieser Art von versteckter Betriebsfolklore deutlich schlechter.

Wenn wir also wollen, dass Agents in echten Repositories wirklich nützlich werden, müssen wir das System expliziter machen, nicht weniger.

Deshalb halte ich das Aspire-Framing für wichtig.

Der eigentliche Wert von Aspire ist nicht nur Orchestrierung

Ein häufiger Fehler ist, Aspire nur als verteilten App-Launcher oder lokalen Orchestrierungshelfer zu sehen.

Das ist ein zu kleines Bild.

Der stärkere Wert ist, dass Aspire der Anwendung:

ein Modell
eine Form
benannte Ressourcen
explizite Abhängigkeiten
Oberflächen für Health und Operations
Befehle gibt, die Menschen und Automation verstehen können

Das verändert den Dev-Loop stärker, als vielen manchmal bewusst ist.

Denn sobald die App keine Ansammlung impliziter Konventionen mehr ist und stattdessen ein System mit echtem Modell wird, werden mehrere Dinge gleichzeitig einfacher:

Onboarding
Debugging
wiederholbares Setup
CI-Konsistenz
KI-gestützte Workflows

Das ist eine Menge Hebelwirkung aus einer Designentscheidung.

Besonders gut gefällt mir der „Commands as first-class operations“-Gedanke

Ein weiterer Punkt aus dem Originalbeitrag, der mehr Aufmerksamkeit verdient, ist der Wechsel von README-Anweisungen zu ressourcengebundenen Befehlen.

Das ist eine täuschend große Veränderung.

Statt zu sagen:

führe dieses Skript aus, dann jenes, und vielleicht noch dieses andere, wenn das erste scheitert

kann man Operationen direkt im Kontext der App modellieren.

Das macht sie für Menschen leichter auffindbar.

Und es bedeutet, dass Agents die Absicht nicht aus Prosa erraten müssen.

Das ist die Art von Sache, die eine Anwendung von „operierbar, wenn man sie schon kennt“ zu „operierbar by design“ macht.

Was ich als Teamleiter daraus mitnehmen würde

Wenn ich den Dev-Loop meines eigenen Teams durch diese Linse betrachten würde, hätte ich ein paar klare Fragen:

wie viel unseres Setups hängt vom Gedächtnis ab?
wie viele kritische Dev-Aktionen existieren nur in Doku oder Chat-Threads?
wie oft hängen neue Contributors an unsichtbarem Systemverhalten fest?
könnte ein Automatisierungstool oder Coding-Agent unsere App-Topologie direkt aus dem Repo verstehen?

Wenn die Antwort auf die letzte Frage „nicht einmal annähernd“ lautet, sollte dieser Beitrag einen nützlichen Nerv treffen.

Meine Einschätzung

Das ist ein sehr starkes Framing für den eigentlichen Wert von Aspire.

Es geht nicht nur um Orchestrierung.

Es geht darum, das App-Modell so explizit zu machen, dass das System leichter zu betreiben, zu verstehen und zu automatisieren ist.

Das ist wichtig für Menschen. Es ist wichtig für Teams. Und es ist noch wichtiger, jetzt da sich so viel moderne Entwicklung in Richtung agentenunterstützter Workflows bewegt.

Das ist genau die Art von Beitrag, die erklärt, warum Aspire über das reine .NET-Marketinglabel hinaus zunehmend relevant wirkt.

Originalbeitrag: Dein Dev-Loop ist voller Tribal Knowledge— title: “Dein Dev-Loop steckt voller implizitem Wissen, und Aspire hat die richtige Antwort” date: 2026-06-01 author: “Emiliano Montesdeoca” description: “Ein neuer Aspire-Beitrag bringt einen starken Punkt auf den Tisch: Vielen Teams fehlt nicht tooling, sondern ein konsistentes Anwendungsmodell, das verborgenes Betriebswissen in etwas verwandelt, das Menschen, Skripte und Agents wirklich nutzen können.” tags:

Aspire
Developer Experience
AI
Dev Loop
.NET

Dieser Beitrag wurde automatisch übersetzt. Lies das Original hier.

Das könnte einer der wichtigsten Aspire-Beiträge sein, um zu verstehen, warum das Produkt wichtig ist.

Nicht, weil er eine riesige neue Funktion ankündigt.

Sondern weil er ein Problem benennt, das fast jedes Engineering-Team gespürt hat, aber nicht jedes gut beschrieben hat:

Der Dev-Loop steckt voller implizitem Wissen.

Dieser Satz trifft, weil er stimmt.

Das Problem ist nicht der Mangel an Tools

Das Kernargument des Originalbeitrags ist ausgezeichnet: Teams fehlt oft nicht die Infrastruktur, nicht die Skripte, nicht die Dashboards und nicht die Befehle.

Was ihnen fehlt, ist ein kohärentes Modell, das das ganze verborgene Betriebswissen rund um die Anwendung in etwas Sichtbares und Wiederholbares verwandelt.

Die eigentliche Architektur vieler Apps lebt in:

der Shell-History
verstreuten Skripten
README-Schnipseln
Slack-Threads
dem einen Senior Engineer, der die Reihenfolge der Schritte kennt

Das ist kein nachhaltiger Dev-Loop für Menschen.

Und ganz sicher auch keiner für Agents.

Das Zitat, das meiner Meinung nach den ganzen Beitrag zusammenfasst

Es gibt einen Satz im Originalbeitrag, der den größeren Punkt sehr gut trifft:

“Anwendungen existieren bereits als Systeme. Aspire macht diese Systeme explizit, weil explizite Systeme besser skalieren als implizites Wissen.”

Das ist die gesamte Argumentation in einem Satz.

Und ehrlich gesagt ist es eine der stärksten Ein-Satz-Erklärungen für Aspire, die ich bisher gesehen habe.

Warum das jetzt wichtiger ist als vor einem Jahr

Ich denke, der Beitrag trifft den aktuellen Moment besonders gut, weil KI-gestützte Entwicklung die Kosten von Ambiguität verändert.

Menschen können unvollständige Systeme erstaunlich gut kompensieren.

Wir erinnern uns:

welches Skript zuerst ausgeführt werden muss
welche Umgebungsvariable heimlich nötig ist
welches Terminal normalerweise die nützlichen Logs zeigt
welcher Dienst aus Gründen, die niemand dokumentiert hat, zweimal neu gestartet werden muss

Agents sind bei dieser Art von verborgenem Betriebswissen deutlich schlechter.

Wenn wir wollen, dass Agents in echten Repositories wirklich nützlich werden, müssen wir das System expliziter machen, nicht weniger.

Deshalb halte ich dieses Aspire-Framing für wichtig.

Der eigentliche Wert von Aspire ist nicht nur Orchestrierung

Ein häufiger Fehler bei Aspire ist, es nur als Distributed-App-Launcher oder lokale Orchestrierungshilfe zu sehen.

Das ist zu klein gedacht.

Der stärkere Wert ist, dass Aspire der Anwendung gibt:

ein Modell
eine Form
benannte Ressourcen
explizite Abhängigkeiten
Health- und Operations-Schnittstellen
Befehle, die Menschen und Automatisierung gleichermaßen verstehen können

Das verändert den Dev-Loop mehr, als vielen bewusst ist.

Denn sobald die App keine Ansammlung impliziter Konventionen mehr ist und zu einem System mit echtem Modell wird, werden mehrere Dinge auf einmal einfacher:

Onboarding
Debugging
wiederholbare Einrichtung
CI-Konsistenz
KI-gestützte Workflows

Das ist viel Hebelwirkung aus einer Designentscheidung.

Besonders gut gefällt mir der Aspekt „Befehle als First-Class-Operationen“

Ein weiterer Punkt aus dem Originalbeitrag, der mehr Aufmerksamkeit verdient, ist der Wechsel von README-Anweisungen zu ressourcenbezogenen Befehlen.

Das ist ein täuschend großer Schritt.

Statt zu sagen:

führe dieses Skript aus, dann jenes, und vielleicht noch dieses andere, wenn das erste fehlschlägt

kann man Operationen direkt im Anwendungskontext modellieren.

Das heißt, Menschen können sie leichter entdecken.

Und Agents müssen die Absicht nicht aus Fließtext erraten.

Das ist die Art von Sache, die eine Anwendung von „operierbar, wenn man sie schon kennt" zu „operierbar by design" macht.

Was ich daraus als Teamleiter mitnehmen würde

Wenn ich den Dev-Loop meines Teams durch diese Linse betrachten würde, würde ich ein paar direkte Fragen stellen:

Wie viel unserer Einrichtung hängt von Erinnerung ab?
Wie viele kritische Dev-Aktionen existieren nur in Dokus oder Chat-Threads?
Wie oft werden neue Mitwirkende durch unsichtbares Systemverhalten blockiert?
Könnte ein Automatisierungstool oder Coding-Agent unsere App-Topologie aus dem Repo selbst verstehen?

Wenn die Antwort auf die letzte Frage „nicht einmal annähernd" ist, sollte dieser Beitrag einen nützlichen Nerv treffen.

Meine Einschätzung

Das ist ein sehr starkes Framing für den eigentlichen Wert von Aspire.

Es geht nicht nur um Orchestrierung.

Es geht darum, das Anwendungsmodell so explizit zu machen, dass das System leichter zu betreiben, zu verstehen und zu automatisieren ist.

Das ist wichtig für Menschen. Es ist wichtig für Teams. Und es ist noch wichtiger jetzt, wo sich so viel moderne Entwicklung in Richtung agentenassistierter Workflows bewegt.

Das ist genau die Art von Artikel, die hilft zu erklären, warum Aspire über das reine .NET-Marketinglabel hinaus immer relevanter wirkt.

Originalbeitrag: Dein Dev-Loop steckt voller implizitem Wissen

Hermetische Aspire-End-to-End-Tests sind ein Muster, das mehr Teams übernehmen sollten

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion hier klicken.

Flaky End-to-End-Tests sind teuer, und das auf eine Art, die nicht immer auf einem Dashboard sichtbar wird.

Sie schlagen nicht einfach fehl. Sie trainieren das Team langsam darauf, dem Feedback-Loop nicht mehr zu vertrauen.

Genau deshalb hat mich dieser Azure Chaos Studio + Aspire-Beitrag sofort angesprochen. Es ist keine glitzernde Produktankündigung. Es ist eine bodenständige Engineering-Geschichte darüber, wie man End-to-End-Tests so gestaltet, dass sie sich nicht mehr wie ein Pokerspiel gegen das Glück anfühlen.

Und ehrlich gesagt? Ich glaube, mehr Teams sollten dieses Muster übernehmen.

Die Grundidee ist einfach, aber der Nutzen ist riesig

Der entscheidende Schritt ist, jedem Test seine eigene hermetische, temporäre Umgebung mit echten Diensten, echten Abhängigkeiten und einem expliziten, zustandsbasierten Start zu geben.

Wenn man das in einem Satz liest, klingt es offensichtlich. In realen Systemen ist es jedoch deutlich schwieriger, vor allem wenn Cloud-Abhängigkeiten, geteilte Umgebungen und verteilte Dienste ins Spiel kommen.

Der Originalartikel beschreibt das Problem sehr klar: Geteilte Testumgebungen bringen “Cross-Talk, die Flakes und die Gruppenchats à la ‘wer hat Staging kaputt gemacht?’” als Teil der Betriebskosten mit sich.

Dieser Satz ist lustig, weil er schmerzhaft wahr ist.

Zu viele Teams akzeptieren diesen Tausch als normal. Ich finde nicht, dass sie das sollten.

Warum dieses Muster über Tests hinaus wichtig ist

Am besten gefällt mir hier, dass der Artikel nicht einfach sagt: “Wir haben unsere Tests zuverlässiger gemacht.”

Eigentlich sagt er etwas Größeres:

Wenn dein verteiltes System schwer zu reproduzieren, schwer zu isolieren und schwer zu verifizieren ist, wird sich dein gesamter Engineering-Loop verlangsamen.

Das betrifft nicht nur CI.

Es betrifft:

wie sicher Entwickler refaktorieren
wie schnell Regressionen diagnostiziert werden
wie sicher größere architektonische Änderungen ausprobiert werden können
wie viel Vertrauen das Team in automatisierte Validierung setzt

Und 2026 betrifft es auch, wie nützlich KI-gestützte Entwicklung werden kann.

Das wichtigste Zitat im Beitrag

Es gibt einen Satz im Artikel, der meiner Meinung nach unbedingt wiederholt werden sollte:

“Agenten müssen nicht perfekt sein. Sie müssen überprüfbar sein.”

Das ist eine hervorragende Perspektive.

Viele fragen sich, ob KI-Coding-Agenten zuverlässig genug sind, um bei nicht-trivialer Arbeit zu helfen. Ich denke, die bessere Frage ist, ob unsere Systeme testbar genug sind, um diese Arbeit korrekt zu beurteilen.

Wenn ein Agent eine sinnvolle Refaktorisierung vorschlägt und dein einziges Sicherheitsignal aus einem Haufen fragiler, halbzufälliger End-to-End-Checks in einer geteilten Umgebung besteht, dann liegt das Problem nicht nur beim Agenten.

Das Problem ist dein Validierungsmodell.

Dieses Aspire-Muster verbessert das dramatisch.

Was diese Umsetzung besonders gut macht

Mehrere Teile der Ursprungsgeschichte machen daraus mehr als nur einen vagen “Wir haben unsere Tests verbessert”-Beitrag.

1. Echte Service-Graphen statt Fake-Theater

Die Tests bauen nicht auf einem Haufen entkoppelter Mocks auf, die so tun, als wären sie End-to-End-Validierung.

Sie führen die echten Binärdateien aus, verdrahten Emulatoren, wo es geht, und verwenden dasselbe Anwendungsmodell wie im lokalen Development.

Das ist wichtig.

Denn sobald End-to-End-Tests zu Mock-gegen-Mock-Theater werden, sagen sie dir nichts Verlässliches mehr über die echte Zusammensetzung aus.

2. Zustandsbasiertes Starten statt magischer Sleeps

Dieser Punkt ist größer, als er auf den ersten Blick wirkt.

Der Artikel hebt ausdrücklich hervor, dass die Tests auf echte Gesundheit mit WaitForResourceHealthyAsync warten, statt auf willkürliche Timing-Schätzungen zu setzen.

Das ist ein riesiger Unterschied.

Eine Test-Suite, die sagt: “Schlaf 30 Sekunden und hoff auf das Beste”, dokumentiert im Grunde Unsicherheit. Eine Suite, die auf echte Bereitschaft wartet, dokumentiert die Absicht des Systems.

3. Dasselbe Modell treibt lokale Entwicklung und Tests an

Das gefällt mir besonders, weil es zu den stärksten Aspire-Geschichten insgesamt passt.

Dasselbe App-Modell treibt:

die lokale Entwicklung
das Verdrahten der Dienste
emulierte Abhängigkeiten
Health Checks
die Orchestrierung hermetischer Tests

Das reduziert Drift, und Drift ist einer der stillen Killer von Vertrauen.

Diese Art von DevEx-Investition wird oft unterschätzt

Ein Grund, warum ich wollte, dass dieser Beitrag länger wird als nur eine schnelle Reaktion, ist, dass ich glaube, dass solche Engineering-Verbesserungen oft unterschätzt werden.

Sie sind nicht flashy.

Sie demoen sich nicht wie ein neues KI-Feature.

Sie erzeugen auch nicht immer eine einzelne Folie, die Führungskräfte begeistert.

Aber sie schaffen mit der Zeit etwas viel Wertvolleres: ein Team, das schneller vorankommen kann, ohne sich selbst über die Qualität etwas vorzumachen.

Das ist eine große Sache.

Im Artikel steht, dass sie inzwischen etwa 90 hermetische Tests ausführen, inklusive Szenarien wie Zonenausfälle, DNS-Fehler und Ausfälle bei der geografischen Replikation. Das ist nicht nur bessere Testhygiene. Das ist ein deutlich stärkeres Vertrauensmodell für eine verteilte Plattform.

Was ich daraus mitnehmen würde, wenn ich ein verteiltes .NET-System betreiben würde

Wenn du heute mit verteilten Diensten, Aspire und CI/CD-Pipelines arbeitest, würde ich daraus sofort Folgendes mitnehmen:

Hör auf, Flakiness in geteilten Umgebungen als normal hinzunehmen
Wechsle, wo immer möglich, zu auf Gesundheit basierenden Start-Gates
Behandle den AppHost als echte Orchestrierungslogik auf Produktionsniveau
Baue End-to-End-Checks, die die Service-Komposition validieren, nicht nur die Korrektheit einzelner Dienste
Wenn du KI-gestützte Entwicklung einführst, investiere zuerst in Überprüfbarkeit, bevor du nach mehr Automatisierungsbreite jagst

Genau dieser letzte Punkt ist der, den mehr Teams hören sollten.

Meine Einschätzung

Das ist einer der stärksten Aspire-Beiträge in diesem Batch, weil er ein sehr praktisches Problem löst.

Er versucht nicht, dich mit Abstraktion zu beeindrucken. Er zeigt, wie man End-to-End-Tests deterministischer, nützlicher und vertrauenswürdiger in einem echten verteilten System macht.

Und sobald man die Verbindung zur agentenunterstützten Entwicklung sieht, wird das Muster noch überzeugender.

Wenn dein End-to-End-Test-Ansatz immer noch von geteilten Umgebungen, verborgenem Setup-Wissen und ein bisschen Gebet abhängt, solltest du dir das unbedingt ansehen.

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