Letzten Herbst saß ich bei einem Maschinenbauer mit 80 Mitarbeitenden. Die hatten ein kleines .NET-Team — drei Entwickler, ein externer DevOps-Berater, der zweimal pro Monat vorbeischaute. Wenn ein Build in der Pipeline rot wurde, lag das Binlog irgendwo auf dem Azure DevOps-Server, und niemand wusste mehr genau, wie man das Structured Log Viewer-Tool überhaupt öffnet. Der einzige der das konnte, war der externe Berater. Also warteten alle bis zu seinem nächsten Termin — oder schrieben ihm eine WhatsApp.
Das ist kein Einzelfall. Es ist ein Muster. Und genau in dieses Muster schlägt Microsoft jetzt eine Lösung vor, die ich mir ernst nehmen will.
Was Microsoft vorschlägt
Der .NET Blog beschreibt, wie das microsoft/testfx-Repository bereits in Production läuft: Ein MCP-Server (Model Context Protocol) analysiert beim Build-Fehler automatisch das Binlog, extrahiert die Root Cause und postet einen strukturierten Kommentar direkt in den Pull Request. Kein Mensch lädt einen Log herunter, kein Mensch öffnet einen Viewer. Der Agent nennt die MSBuild-Version, die Anzahl der gebauten Projekte, die genauen Fehlerstellen bis auf Zeile und Spalte — und schlägt im gleichen Atemzug eine Korrektur vor.
Das Ganze läuft als Container in GitHub Actions, ist explizit als advisory markiert (entscheidet also nicht über Merge oder nicht-Merge), und kann on-demand durch einen PR-Kommentar /analyze-build-failure erneut getriggert werden. Der Artikel liefert echte Outputs, keine Mockups — inklusive einem konkreten Beispiel mit einem IDE0055-Formatierungsfehler, der sauber identifiziert und erklärt wurde. Das Handwerk stimmt.
Wie das bei KMU wirklich landet
Jetzt kommt das, was im Artikel fehlt — nicht weil der Autor es nicht kann, sondern weil sein Kontext ein anderer ist.
Was sofort Sinn ergibt: Der Kern-Use-Case ist valide, gerade für kleinere Teams. Wenn ein Junior-Entwickler einen PR einreicht, der Build rot wird und er keine Ahnung hat warum — dann ist ein automatischer Kommentar mit "Hier, Zeile 47, das ist dein Problem, so würdest du es fixen" tatsächlich wertvoll. Das reduziert Rückfragen, beschleunigt den Review-Zyklus und entlastet die eine Person im Team, die Build-Probleme wirklich versteht.
Was die meisten KMU noch nicht haben: GitHub Actions mit Agentic Workflows. Der Artikel nennt das selbst: "GitHub Agentic Workflows are still evolving, so treat these as a reference implementation to copy from rather than a turnkey feature every repository has today." Viele mittelständische .NET-Teams arbeiten mit Azure DevOps Pipelines, Jenkins oder TeamCity. Dort ist dieser Workflow nicht out-of-the-box verfügbar — da muss jemand portieren. Das ist machbar, aber es ist kein Copy-Paste-Job.
Was unterschätzt wird: Der Setup-Aufwand für die MCP-Infrastruktur selbst. Ein Container in der CI-Pipeline, der ein binäres MSBuild-Log live öffnet und 23 Tools bereitstellt — das ist kein npm install und fertig. Du brauchst jemanden, der versteht, was da passiert, wenn der Container nicht startet, wenn das Binlog unerwartet groß ist, wenn die Token-Kosten des LLM-Calls explodieren weil ein monorepo-Build 200 Projekte hat. In Teams mit drei bis fünf Entwicklern und ohne dedizierten DevOps-Engineer ist das eine reale Hürde.
Was komplett fehlt: Eine Aussage zu Kosten. Microsoft nennt "efficiency claims backed by evaluation data" — aber evaluation data ist nicht dasselbe wie ein Business Case. Wieviel kostet ein LLM-Call für eine typische Binlog-Analyse? Läuft das gegen ein Azure OpenAI-Deployment, gegen GPT-4o, gegen ein lokal gehostetes Modell? Für ein Team, das 50 PRs pro Woche hat und bei jedem fehlgeschlagenen Build einen Analyse-Call triggert — da können schnell dreistellige Beträge pro Monat entstehen, die niemand eingeplant hat. Das ist kein Killerargument gegen den Ansatz, aber es ist eine Frage, die ich bei jedem Mandat zuerst stelle.
Was wirklich interessant ist, aber kaum betont wird: Das Degradation-Pattern. Wenn das Binlog nicht geparst werden kann, postet der Agent trotzdem einen Kommentar — mit einem Link zurück zur Build-Run. Das klingt trivial, ist aber professionell gedacht. Schlechte Automatisierung scheitert laut und hinterlässt Chaos. Diese Implementation scheitert leise und informiert trotzdem. Das ist der Unterschied zwischen einem Proof-of-Concept und etwas, das in Production überlebt.
Meine Empfehlung
Wenn du ein .NET-Team mit mehr als fünf Entwicklern hast, auf GitHub Actions bist und Build-Fehler regelmäßig zu Rückfragen oder Wartezeiten führen — dann ist das eine Investition wert, die sich in Wochen rechnet. Ich würde es nicht als erstes KI-Projekt angehen (zu viele Moving Parts für den Einstieg), aber als zweites oder drittes — wenn das Team verstanden hat, wie MCP-Server funktionieren — macht das Sinn.
Wenn du auf Azure DevOps bist: Schau dir das Konzept an, aber warte noch drei bis sechs Monate. Die Tooling-Lücke zwischen GitHub Agentic Workflows und ADO-Pipelines ist heute noch spürbar, und ich würde nicht wollen, dass du sechs Stunden in eine Portierung investierst, nur damit Microsoft das in Q3 nativ unterstützt.
Wenn dein Team kleiner als fünf Entwickler ist und Build-Fehler eher selten sind: Überspring das. Der Aufwand übersteigt den Nutzen. Investiere die Zeit lieber in bessere lokale Linting-Konfiguration, die Fehler schon vor dem Commit abfängt.
Eine Sache würde ich in jedem Fall machen, unabhängig von der Teamgröße: Den Artikel lesen und verstehen, wie MCP-Server in CI-Pipelines integriert werden können. Das Pattern — ein spezialisierter Server, der schreibgeschützt auf Build-Artefakte zugreift und einem LLM strukturierte Daten liefert — ist nicht .NET-spezifisch. Dasselbe Prinzip funktioniert für Webpack-Build-Outputs, für Gradle-Logs, für Terraform-Fehlermeldungen. Wer das einmal verstanden hat, sieht plötzlich fünf andere Stellen in seiner Pipeline, wo dasselbe Pattern hilft.
Der vollständige Original-Beitrag von .NET Blog (MS): MCP Beyond the Chat Window: Build Diagnostics in CI
Hast du ein .NET-Team und fragst dich, ob das für euch konkret umsetzbar ist — oder willst du einfach wissen, ob der Aufwand sich lohnt, bevor du Zeit investierst?
— Bernhard