Microsoft Build 2026 und der leise Wechsel zu agent-native Development
· 3 min read · Filippo Spinella · AI, GitHub Copilot, Microsoft Build, Developer Tools
Microsoft Build 2026 hatte einen klaren Unterton: Die nächste Phase von Software-Agenten ist keine schönere Chatbox. Es geht darum, Agenten einen Schreibtisch, eine Checkliste, eine Sandbox und einen Verantwortlichen zu geben.
Die offiziellen Signale kamen aus dem Microsoft Build 2026 live blog, dem Microsoft-Beitrag AI alone won't change your business. The system running it will und GitHubs Ankündigung der GitHub Copilot app. Zusammen gelesen sagen sie: Agents werden Teil des Entwicklungssystems, nicht ein Zubehör daneben.
Das Nützliche ist angenehm langweilig
Ein Agent, der eine Patch-Datei schreibt, ist interessant. Ein Agent, der in einem isolierten Worktree arbeitet, Checks ausführt, einen sichtbaren Trace behält, eine Pull Request öffnet und am richtigen Approval-Gate stoppt, ist deutlich nützlicher.
Das ist der Wechsel, den ich in Build 2026 sehe. Weniger Magie. Mehr Betriebsmodell.
Die Copilot App von GitHub wirkt wie ein Kontrollraum für Agent-Arbeit: Sessions, Repositories, Issues, Pull Requests und parallele Aufgaben an einem Ort. Das Detail, das ich mag, sind Worktrees. Jeder Versuch kann in einem eigenen Raum leben. Man kann ihn vergleichen, verwerfen oder übernehmen, ohne die eigenen Dateien zu zertrampeln.
Sandboxes sind kein Nebenthema
Wenn ein Agent Code ausführen kann, braucht er einen sicheren Ort, um falsch zu liegen. Genau dafür sind Sandboxes wichtig. Lokal oder in der Cloud erlauben sie Tests, ohne den Laptop oder die Produktion zum Experiment zu machen.
Das klingt nicht glamourös, ist aber der Unterschied zwischen Demo und Workflow. Ein guter Agent sollte Tests ausführen, Fehler lesen, erneut versuchen und zeigen können, was geändert wurde. Er sollte aber so begrenzt sein, dass ein Fehler klein bleibt.
Foundry und Agent Framework zeigen Richtung Produktion
Foundry und Microsoft Agent Framework erzählen dieselbe Geschichte auf Enterprise-Ebene. Hosted Agents, Toolboxes, Tracing, Evaluation, Memory, Middleware und Agent Controls klingen nach Infrastruktur. Genau deshalb sind sie wichtig.
Sobald Unternehmen viele Agents bauen, lautet die Frage nicht mehr können wir einen bauen. Sie lautet: wem gehört er, worauf darf er zugreifen, wie evaluieren wir ihn, woran sehen wir Verbesserung, und wie schalten wir ihn aus?
Review wird zum Engpass
Die Falle bei agentic development ist zu glauben, mehr Agents bedeuten automatisch mehr ausgelieferte Arbeit. Vielleicht bedeuten sie nur mehr Pull Requests vor müden Reviewern.
Ich würde Adoption mit drei Zahlen messen:
- spart oder kostet sie Reviewer-Zeit;
- wie oft bestehen Änderungen Checks ohne Babysitting;
- wie oft erklärt der Trace die Begründung gut genug, um dem Diff zu vertrauen.
Wenn der Reviewer alles neu rekonstruieren muss, ist der Workflow nicht fertig. Die Last wurde nur verschoben.
Wo ich starten würde
Ich würde mit stumpfen, klar begrenzten Aufgaben starten: Dependency Updates, Testfixes, kleine Refactorings, Antworten auf Review-Kommentare, Release Notes, Migrationen mit starken Tests.
Für jede Aufgabe würde ich Isolation, Checks, Trace und eine menschliche Merge-Entscheidung verlangen. Der Agent macht die Beinarbeit. Das Team besitzt weiter das Ergebnis.
Meine Einschätzung
Build 2026 lässt agent-native development weniger wie ein Schlagwort wirken und mehr wie ein Operations-Problem. Gewinnen werden nicht Teams, die Agents alles machen lassen. Gewinnen werden Teams, die ein System bauen, in dem Agents vorankommen, ohne die Spur zu verstecken.
Das ist die reife Version dieser Welle: AI ersetzt Review nicht. AI macht genug strukturierte Arbeit, damit Review schärfer wird.