Vom Co-Pilot zum Co-Worker

Künstliche Intelligenz (KI) ist seit Jahren ein zentrales Thema in der Informatik und bedarf keiner großen Einführung. Allerdings ist sie auch mit enormem Hype und Buzzwords verbunden – vieles klingt besser, als es ist. So gibt es auch zahlreiche kritische Stimmen in der Entwickler-Community, die ein großes Risiko bei KI-generiertem Code sehen. Andererseits warnen einige, die zukünftige Rolle des Softwareentwicklers sei gefährdet, und glauben, alles werde bald nur noch durch KI entwickelt. Vor diesem Hintergrund werden wir uns in diesem Artikel mit dem aktuellen Stand der KI-basierten Softwareentwicklung im Microsoft-Technologie-Umfeld auseinandersetzen und Chancen wie Risiken identifizieren.

GitHub als Technologie-Träger

Microsoft hat bei nahezu all seinen Produkten und Services den Zusatz „Copilot“ eingebracht. Von der Marketing-Seite her wird Copilot beinahe schon überstrapaziert; manchmal wirkt es dadurch etwas zu viel. Die Ursprünge liegen beim ersten und bis heute erfolgreichsten Co-Piloten: GitHub Copilot. GitHub hat sich seit der Übernahme durch Microsoft stark gewandelt – vom reinen Code-Hosting mittels Git hin zu einer umfassenden DevOps-Umgebung. In den letzten Jahren wurden zwei Schwerpunkte kontinuierlich ausgebaut: Security und Künstliche Intelligenz.

GitHub Copilot ist ein cloudbasierter KI-Dienst, der auf mehrere Modelle zugreift und in verschiedenen Abo-Modellen angeboten wird. Der Funktionsumfang hat sich stark erweitert, sodass eine kleine Einordnung der Begriffe nötig ist:

• Copilot ist der Überbegriff für alle KI-Features, die GitHub mittels cloudbasierter KI-Modelle zur Verfügung stellt.
• Der häufigste Einsatz erfolgt über die Integration in IDEs beziehungsweise Editoren. GitHub bietet Erweiterungen für VS Code, Visual Studio und JetBrains-IDEs. Von Code-Completion über Fragen zur Codebasis bis hin zur Ausführung von Entwicklungsaufgaben im Agent Mode ist vieles möglich.
• Mit der Coding-Agent-Funktionalität (Preview) kann ein Agent autonom und asynchron Aufgaben übernehmen, die dann als Pull Request zur Prüfung bereitgestellt werden.
• Copilot Spaces dienen dazu, Projektwissen (Code, Dokumentation, Notizen) zu bündeln, damit der Copilot kontextsensitive und präzisere Vorschläge liefert.
• Copilot Spark ist ein Tool zum schnellen Prototyping kleiner Apps – generiert aus natürlicher Sprache und integriert in GitHub-Workflows.

Für den weiteren Teil des Artikels werden wir uns auf den sogenannten Agent-Mode respektive den Coding Agent fokussieren, bei dem GitHub Copilot in der Lage ist, Aufgaben selbstständig zu erledigen und Ergebnisse zu verifizieren. Agentenbasierte Entwicklungsfunktionen gibt es bei verschiedenen Herstellern und Open-Source-Projekten. Microsoft hat kürzlich einen wichtigen Schritt vollzogen: Die „Copilot Chat Extension“ für VS Code wurde unter einer MIT-Lizenz als Open Source bereitgestellt, und relevante Komponenten sollen zudem in den Kern von VS Code integriert werden. Obwohl einige Wettbewerber-Lösungen auf VS Code basieren oder sogar VS Code geforkt haben, sichert sich Microsoft durch diesen Schritt seine starke Marktposition – insbesondere im Bereich der KI-Unterstützung für Entwicklerwerkzeuge.

GitHub Copilot Agent Mode: Vom Prompt zum fertigen Ergebnis

Mit dem Agent Mode hebt GitHub Copilot die Arbeit mit KI-Assistenten auf eine neue Stufe. Während der klassische Copilot hauptsächlich Code-Vervollständigungen vorschlägt oder kleinere Abschnitte editiert, agiert der Agent Mode wie ein kleiner „Autopilot“ für komplexere Entwicklungsaufgaben. Statt lediglich einen Funktionsrumpf zu generieren, plant der Agent eigenständig die nötigen Schritte, führ sie iterativ aus und überprüft die Ergebnisse – bis das gewünschte Ziel erreicht ist.

Der Prozess beginnt mit einem Benutzerprompt: Entwicklerinnen oder Entwickler beschreiben, was sie erreichen möchten – etwa „Füge eine Suchfunktion hinzu“ oder „Führe ein Refactoring dieses Moduls durch“. GitHub Copilot Agent Mode sammelt daraufhin Kontextinformationen aus dem aktuellen Workspace und indexiert die Repository-Dateien, um zu verstehen, welche Stellen des Codes betroffen sind. Mittlerweile unterstützen GitHub und Azure DevOps das Remote-Indexing der Source-Code-Repositories. Somit muss das Indexieren nur einmal zentral auf dem Server erfolgen und nicht auf jedem Client. Zudem kann dem Agent unter die Arme gegriffen werden und der Prompt kann bereits Verweise auf Code-Dateien mit der Hash-Tag-Referenz enthalten. Nachdem der Kontext definiert ist, erstellt der Agent einen Aktionsplan, der aus mehreren Teilschritten besteht: Dateien lesen und analysieren, Code-Änderungen durchführen, Build- oder Testläufe starten und Ergebnisse auswerten.

Dieser „Agent Loop“ ist besonders spannend: Nach jedem Schritt prüft der Agent, ob das Ziel erreicht wurde – beispielsweise ob alle Tests erfolgreich durchlaufen oder Build-Fehler behoben sind. Falls nicht, passt er den Plan an, führt weitere Änderungen durch oder schlägt dem Benutzer oder der Benutzerin Alternativen vor. Dieser Zyklus aus Planen, Ausführen, Prüfen und Korrigieren läuft so lange, bis das definierte Ziel erfüllt ist oder der Nutzer eingreift.

Ein wichtiger Baustein ist der Tool-Zugriff. GitHub Copilot nutzt hierfür interne Funktionen (Dateien lesen/schreiben, Terminal-Befehle ausführen et cetera) und kann über das Model Context Protocol (MCP) auch Programme ausführen oder externe Datenbankquellen oder APIs einbinden – etwa um Issues aus GitHub abzurufen oder Ergebnisse aus einem Test-Framework zu verarbeiten. MCP ist ein offener Standard, der beschreibt, wie KI-Modelle mit Tools interagieren und welche Parameter und Berechtigungen dabei gelten.

Natürlich spielt Sicherheit eine große Rolle. Bevor GitHub Copilot kritische Aktionen wie etwa Terminalkommandos ausführt, erhalten Entwicklerinnen und Entwickler eine Vorschau und können den Schritten zustimmen oder Änderungen vornehmen. Auf Organisationsebene lassen sich außerdem Policies und Scopes festlegen: Administratoren entscheiden, ob der Agent nur lesen oder auch schreiben darf, welche MCP-Server genutzt werden können und ob Aktionen protokolliert werden müssen.

Das Ergebnis ist ein intelligenter, kontrollierbarer Workflow: Entwicklerinnen und Entwickler formulieren ein Ziel, Copilot plant und arbeitet es selbstständig ab. Dieser Prozess ist in Bild 1 veranschaulicht.

Wichtig hierbei ist, dass der Benutzer immer die Kontrolle darüber behält. Zudem können einzelne Schritte rückgängig gemacht werden, und wer für jede Änderung einen Topic- respektive Feature-Branch verwendet, behält im eigenen Entwicklungsprozess auch die Kontrolle über die Integration dieser Änderungen.

In Bild 2 sind die typischen Agent-Mode-Funktionen in VS Code ersichtlich. In der Eingabeaufforderung (1) können neben dem Prompt auch zusätzlicher Kontext, Extensions und Commands angegeben werden. Im Chat-Verlauf (2) sind die Chat-Diskussion sowie die Interaktionen mit Dateien, Verzeichnissen und Kommandos ersichtlich. Soll ein Tool oder ein Built-in-Kommando ausgeführt werden, so muss dies erst durch den Benutzer freigegeben werden (3). Ausführbare Aktionen werden in einer eigenen Shell-Session ausgeführt (4). Der Agent ist über die Shell-Integration in der Lage, das Ausführen des Kommandos abzuwarten und den Output zu analysieren. Die Entwicklerin oder der Entwickler hat die volle Kontrolle darüber, welche Tools eingesetzt werden dürfen. Diese Einstellung ist unter Punkt (5) ersichtlich.

GitHub Coding Agent: dein asynchroner Teamkollege

Während sich der Agent Mode im vorherigen Beispiel wie ein Echtzeit-Copilot verhält, der direkt im Editor arbeitet und einen unterstützt, ist der Coding Agent eher wie ein Teammitglied zu verstehen, das in der Zwischenzeit Aufgaben übernimmt und eigenständig über GitHub arbeitet. Tabelle 1 veranschaulicht dies in einer Gegenüberstellung.

Tabelle 1: Agent Mode versus Coding Agent

Bevor wir weiter in die Funktionen des Coding Agents eintauchen, möchte ich erst eine ganz wichtige Implikation des Coding Agents verdeutlichen. Bislang waren wir mehr oder weniger frei in der Entscheidung, welchen Editor und welche DevOps-Lösung wir verwenden, da die GitHub-Copilot-Extension im Editor läuft und mit den Cloud-Services kommuniziert. Der Coding Agent läuft im GitHub-Actions-Context und erstellt Pull Requests in GitHub. Dies bedeutet zwangsläufig, dass das Code-Repository in GitHub gehostet werden muss. Somit haben Azure-DevOps-Benutzerinnen und Benutzer das Nachsehen. Microsoft arbeitet seit Jahren an der Unternehmensstrategie „Better Together“, die Azure DevOps und GitHub mit Integrationen näher zusammenbringt. Wer Azure DevOps weiterhin nutzen möchte, jedoch nicht auf das Coding-Agent-Feature verzichten kann, muss das entsprechende Git-Repository nach GitHub migrieren. Das bedeutet auch, dass Pull Requests neu in GitHub durchgeführt werden. Work Items, Pipelines et cetera können weiterhin in Azure DevOps verwendet werden. Über die Extensions ist alles ineinander integriert, Commits referenzieren Work Items, und Pipeline Runs werden aus GitHub getriggert. Leider müssen trotz aller Integrationen zwei Umgebungen verwaltet werden. Dafür bekommt man das Beste aus beiden Welten.

Wenn man nun das eigene Repository auf GitHub betreibt und einen entsprechenden GitHub-Copilot-Plan hat, kann der Coding Agent genutzt werden. Der Coding Agent ist grundsätzlich ein bezahlter Dienst, dessen Währung die sogenannten Premium Requests sind. Eine gewisse Anzahl an Premium Requests steht einem je nach GitHub-Copilot-Plan zur Verfügung. Sind diese aufgebraucht, können weitere Premium Requests dazugekauft werden. Keine Angst: Auch hier behält man die volle Kontrolle mittels Freigabe und Budget. Im Unterschied zu den Anfängen des Coding Agents, wo eine einzelne Session 30 bis 50 Premium Requests „verbraten“ hat, zeigt sich Microsoft mittlerweile von der spendablen Seite, und es wird pro Session nur noch ein Premium Request verrechnet. Mit dieser Änderung sind wir in einem sehr lukrativen Bereich angekommen, da viel Arbeit für wenig Geld verrichtet wird. Die Kosten für einen Premium-Request liegen derzeit bei 0,04 US-Dollar. Streng genommen sind das aber nicht alle Kosten, denn der Coding Agent läuft in einer GitHub-Actions-Umgebung, und entsprechend kostet dies zusätzliche Build-Minuten. Der Vollständigkeit halber sei hier ebenfalls erwähnt, dass auch im Agent Mode in der IDE oder im Editor Premium Requests verrechnet werden können – je nach verwendetem Modell.

Ein weiterer Unterschied zwischen Agent Mode und Coding Agent liegt in der Selektion der KI-Modelle. Im Editor muss die Entwicklerin oder der Entwickler das Modell für die Aufgabe selbst auswählen. Beim Coding Agent ist dies automatisiert, und man kann keinen Einfluss auf das Modell nehmen.

Das Verhalten des Copilot Coding Agents ist dem des Agent Mode im Editor sehr ähnlich, jedoch nicht so interaktiv. Getriggert wird die Coding-Agent-Session über ein GitHub Issue. Sobald das Issue dem Benutzer @copilot zugewiesen wird, übernimmt der Coding Agent die Aufgabe. Der Prompt ist also der Inhalt des Issues. Es wird ein neuer Branch erstellt und basierend darauf ein Pull Request angelegt. In Bild 3 ist das Issue ersichtlich, das dem Benutzer @copilot zugewiesen wurde. Mit dem Augen-Emoji unterhalb der Issue Description signalisiert Copilot, dass er das Issue angenommen hat und sich darum kümmert. Kurz darauf wird der Draft Pull Request im Issue referenziert.

Im Pull Request ist die Coding-Agent-Session ersichtlich und kann entsprechend in Echtzeit überwacht werden. Bild 4 zeigt die Live-View der Coding-Agent-Session.

Ähnlich wie im lokalen Agent Mode sehen wir auch hier die einzelnen Schritte, die der Copilot unternimmt, um die Aufgabe zu lösen. In den ersten Schritten ist auch ersichtlich, dass die Coding-Agent-Umgebung eingerichtet wird. Die Session wird in einer GitHub-Actions-Umgebung durchgeführt, und über eine spezielle Workflow-Definition können wir auf dieses Environment Einfluss nehmen – dazu später mehr. Nach beendeter Session sind im Branch die entsprechenden Commits vorhanden, und der Pull Request ist aktualisiert. Bild 5 zeigt diesen Zustand.

Wie ein Arbeitskollege kommentiert Copilot den Pull Request und gibt eine Übersicht über die ausgeführten Arbeiten. Ab hier geht es grundsätzlich so weiter wie bei einem klassischen Pull Request mit menschlichen Autoren. Wir können Checks validieren und unser Feedback über Kommentare kundtun. Nur wenn der Benutzer @copilot im Kommentar erwähnt wird, wird eine weitere Coding-Agent-Session getriggert, in der die Beanstandungen oder Änderungswünsche abgearbeitet werden. Bild 6 zeigt ein weiteres Sicherheitsfeature im Rahmen des Coding Agents: Werden bei einem regulären Pull Request die CI-Workflows automatisch getriggert, muss dies hier erst freigeben werden. Somit kann überprüft werden, dass kein Schadcode oder Fehler in die Workflows eingeschleust wurde. Sind wir mit der Arbeit zufrieden, dann können wir den Pull Request integrieren.

Eine weitere interessante Pull-Request-Funktionalität von Copilot ist, dass dieser auch als Reviewer hinzugezogen werden kann. Somit kann ich zum Beispiel meinen Pull Request erst durch den Copilot reviewen lassen, bevor ein Arbeitskollege zugewiesen wird. Dies trägt ebenfalls zur Effizienz bei, da die kleinen Beanstandungen durch den Copilot identifiziert werden und somit der Pull Request für den Review durch die Arbeitskollegin oder den Arbeitskollegen in einer besseren Qualität vorliegen wird.

Konfiguration des Coding Agents

Damit wir mit dem Coding Agent loslegen können, benötigen wir erst einige Einstellungen. Einerseits müssen wir in unserem Account das Repository für den Coding Agent freischalten. Ist dies erledigt, können wir in den Repository-Einstellungen Sicherheitsfunktionen konfigurieren und Werkzeuge freischalten. Da der Coding Agent sehr autonom agiert, ist es wichtig, die Schranken klar zu definieren. Bild 7 zeigt die Einstellungen auf Repository-Stufe

Per Default ist eine Firewall aktiv. Diese können wir über eine eigene Allow-List feingranular konfigurieren. Wir sollten also die externe Kommunikation auf ein absolutes Minimum einschränken, damit keine sensitiven Daten nach außen gelangen können. Gründe dafür könnten Prompt Injections oder böswillig veränderte Tools sein. Als zusätzliche Werkzeuge können ebenso wie im Editor MCP-Server konfiguriert werden. Diese Syntax ist leicht abweichend, da wir hier auch die einzelnen Tools des MCP-Servers freigeben können. Der Coding Agent hat zwei MCP-Server per Default aktiviert. Dies ist einerseits der GitHub MCP, um mit dem Repository zu interagieren, und der Playwright MCP, damit mit Webseiten interagiert werden kann. Gerade bei der Entwicklung von Webapplikationen ist dies sehr hilfreich, da der Coding Agent so auch Screenshots erstellen und verwenden oder das DOM analysieren kann. Es ist auch möglich, MCP-Server zu verwenden, die eine Authentisierung voraussetzen. Über die Secrets in den Repository-Settings können diese – unter Verwendung eines vordefinierten Prefixes – hinterlegt werden. Ebenso kann der Coding-Agent-Workflow zur Konfiguration von Tools sowie der Authentisierung gegenüber Diensten verwendet werden.

Die Coding-Agent-Session läuft in einer GitHub-Actions-Umgebung. Entsprechend können wir auf diese Session mittels einer Workflow-Definition Einfluss nehmen. Wir können die Größe des Runners definieren, Tools und Abhängigkeiten vorinstallieren, Environment-Variablen aufsetzen, GIT LFS aktivieren oder Firewall-Einstellungen des Agents ändern. Um dies durchzuführen, muss eine Workflow-Definition unter .github/workflows/copilot-setup-steps.yml erstellt werden. Diese Workflow-Definition muss einen Job mit dem Namen copilot-setup-steps beinhalten. Dieser Job wird also zur Initialisierung des Coding-Agent-Environments ausgeführt. Listing 1 zeigt eine solche Workflow-Definition für unsere Beispielapplikation. Wir installieren die Dev-Tools für .NET und Node und initialisieren die Umgebung.

Context, Instructions, Tools und was dies für die Qualität bedeutet

Natürlich hört es sich erst einmal faszinierend an, eine Aufgabe für 0,04 US-Dollar durch den Coding Agent erledigen zu lassen. Doch was schlussendlich zählt, ist die Qualität der Arbeit und ob zusätzliche technische Schulden entstanden sind, die einen dann zu einem späteren Zeitpunkt wieder einholen. Gerade die Top-LLMs wie GPT 5 oder Claude Sonnet 4 liefern gute Analysen und schreiben einwandfreien Code. Je mehr Datengrundlage ein Modell für eine Aufgabe besitzt und je klarer die Rahmenbedingungen und Ziele definiert werden, desto besser ist das Resultat. Weitere wichtige Faktoren sind die Komplexität und der Umfang der Aufgabe. Zum aktuellen Zeitpunkt eignen sich der Agent Mode und der Coding Agent vor allem für Refactorings, kleine Features oder Bugfixing – alles Aufgaben mit einer überschaubaren Komplexität, guten Rahmenbedingungen und klaren Zielen. Hier entstehen durchaus sehr gute Resultate, und die Entwicklerin oder der Entwickler wird maßgeblich entlastet. Eine komplexe Applikation aus einem Prompt als Greenfield-Entwicklung in Auftrag zu geben, wird dagegen wohl oder übel in einer Enttäuschung enden.

Wie kommen wir nun zu guten Resultaten? Wichtig ist, dass der Prompt die Aufgabe und Ziele klar definiert und je nachdem den Kontext bereits unter Angabe von Datei-Referenzen einschränkt. Der Prompt sollte die Dos und Don’ts beinhalten, wie wir unseren Code gerne geschrieben hätten und welche Architekturmuster und Abhängigkeiten wir erwarten. Entsprechend kann das Prompting sehr komplex ausfallen, und wir würden uns abermals wiederholen, was die Gültigkeit von Guidelines und Rahmenbedingungen angeht. Alles, was allgemeingültig ist, können wir deshalb bei GitHub Copilot mittels Instructions hinterlegen. Instructions sind ähnlich zu verstehen wie ein System Prompt, also ein Prompt, der zusätzlich zum eigentlichen Prompt eingefügt und vom KI-Modell verarbeitet wird. Im Repository können wir unter .github/copilot-instructions.md eine allgemeingültige Instruction hinterlegen. Diese wird dem eigentlichen Prompt angefügt. Darin regeln wir alles, was der Copilot bei der Implementierung berücksichtigen soll: Architekturrichtlinien, Coding Guidelines, Code-Struktur und wie automatisierte Tests geschrieben und ausgeführt werden sollen. Hierbei handelt es sich um eine Markdown-Datei, die in natürlicher Sprache geschrieben wird. Im Verzeichnis .github/instructions können weitere Markdown-Dateien mit dem Namensschema <meinname>.instructions.md hinterlegt werden. Diese Dateien werden mit einem Frontmatter-Block ausgestattet, der ein Filterkriterium enthält. Somit werden diese Instructions nur dann eingefügt, wenn die Bedingung erfüllt ist. Auf diese Weise können für bestimmte Source-Dateien oder Verzeichnisse spezifische Instructions hinterlegt werden. Listing 2 zeigt einen Auszug aus einer pfadspezifischen Instruction.

Eine umfangreiche Sammlung von Instructions und Prompts ist im GitHub-Repository „awesome-copilot“ verfügbar.

Copilot verwendet eine Reihe von Tools wie den Dateizugriff, die Shell-Integration oder die Testausführung. Erst so können zum Beispiel Kompilationsfehler erkannt werden oder Testresultate ausgewertet werden. Diese Built-in-Tools sind immer noch sehr generisch, aber wichtig für die Grundfunktionalität. Damit wir dem Agenten weitere Tools zur Verfügung stellen können, können wir eigene Werkzeuge als MCP-Server bereitstellen. Dies beinhaltet nicht nur die Kommunikation mit externen Services, sondern wir können auch domänenspezifische Informationen oder Unternehmensdaten zugänglich machen. Das sind also die Kontextinformationen, die ein generisches KI-Modell nicht kennen kann. Über das MCP-Protokoll können wir diese Informationen strukturiert zur Verfügung stellen.

Doch auch mit allen Instruktionen, Tools und dem richtigen Kontext können wir den KI-Agenten nicht einfach drauflosprogrammieren lassen und die Änderungen blind integrieren. Der lokale Agent Mode arbeitet uns in unserer Entwicklungsumgebung lediglich zu, und wir als Entwickler sind dafür verantwortlich, diese Änderungen zu verifizieren. Der Coding Agent zeigt dies ebenfalls ganz klar auf. Er arbeitet immer in einem dedizierten Branch und erstellt immer einen Pull Request. Generell sollte der Pull Request in jedem Softwareentwicklungsteam immer das Quality Gate darstellen, in dem Code-Änderungen überprüft werden und wo mittels automatisierten Workflows/Pipelines sichergestellt wird, dass wir unsere Qualitäts- und Sicherheitsstandards erreicht haben.

MCPs in der Praxis – Warum sie für Copilot Agent und Coding Agent relevant sind

Das Model Context Protocol (MCP) ist ein noch junges, aber extrem wichtiges Konzept in der Welt der KI-gestützten Entwicklung. Entwickelt wurde es von Anthropic zusammen mit Microsoft und weiteren Partnern, um eine einheitliche Schnittstelle zwischen Agenten und externen Datenquellen oder Tools zu schaffen. Damit kann ein Agent nicht nur auf den aktuellen Code im Workspace zugreifen, sondern sich auch mit Datenbanken, API-Katalogen, Testsystemen oder internen Policies verbinden. Für Entwickler, die mit GitHub Copilot im Agent Mode oder dem Copilot Coding Agent arbeiten, ist MCP die Brücke zwischen „Code generieren“ und „Code im Kontext der Organisation ausführen und validieren“.

Der große Vorteil von MCP-Servern ist, dass sie nicht statisch sind. Ein Instructions-File kann zwar erklären, welche Auth-Library oder welcher Logging-Standard verwendet werden soll, aber es wird schnell veralten und bleibt immer rein beschreibend. Ein MCP-Server dagegen kann zur Laufzeit aktuelle Informationen liefern, Fragen beantworten und sogar strukturierte Antworten geben, die der Agent sofort in Code oder Testfälle umsetzen kann. Gerade in dynamischen Projekten, in denen sich API-Versionen oder Deployment-Ziele regelmäßig ändern, ist dieser Live-Kontext entscheidend.

Technisch unterstützt MCP mehrere Transportarten. Für lokale Tools oder Build-Skripte eignet sich der stdio-Transport, der einfach über Standard-Ein- und -Ausgabe kommuniziert. Wer einen zentralen MCP-Server im Unternehmen bereitstellen will, greift häufig auf HTTP oder SSE (Server-Sent Events) zurück. SSE ist vor allem interessant, wenn der Server dem Client Zwischenergebnisse oder Fortschrittsinformationen schicken soll – etwa während ein langlaufender Test ausgeführt wird oder eine Build-Pipeline Feedback liefert.

Die Anwendungsfälle sind vielfältig. MCPs können externe Systeme abfragen, strukturierte Daten zurückgeben oder auch aktive Aktionen anstoßen. In der Praxis bedeutet das: Ein Agent kann eine Datenbank nach einem Schema fragen, einen Pull Request im Repository erstellen, eine Pipeline triggern oder einen UI-Test ausführen und das Ergebnis direkt zurückmelden. Microsoft hat in mehreren Beiträgen sehr anschaulich gezeigt, wie der Playwright MCP-Server in der Praxis eingesetzt werden kann. So wird im Artikel „The Complete Playwright End-to-End Story, Tools, AI, and Real-World Workflows“ die Vision eines vollständig KI-gestützten Test-Workflows beschrieben: von der Generierung der Tests über deren Ausführung bis hin zur automatischen Verifikation der Ergebnisse. Besonders spannend ist der konkrete Praxisbericht „Microsoft Developer Blog, From Manual Testing to AI-Generated Automation: Our Azure DevOps MCP + Playwright Success Story“, in dem das Azure-DevOps-Team von Microsoft selbst schildert, wie sie manuelle Testfälle durch einen MCP-gestützten Workflow ersetzt haben. Dabei erstellt der Copilot Coding Agent selbstständig Playwright-Skripte, führt sie in der Testumgebung aus und liefert Screenshots und Statusmeldungen zurück. Der Test gilt nur dann als bestanden, wenn der visuelle Zustand exakt dem erwarteten Ergebnis entspricht. Das Ergebnis: drastisch verkürzte Testzyklen, weniger manuelle Klickarbeit und deutlich schnelleres Feedback für Entwicklerteams – ein Paradebeispiel für „Self-Verifying Development“ in der Praxis.

Für .NET-Entwickler sind inzwischen eine Reihe nützlicher MCPs verfügbar, die sich nahtlos in die eigene Entwicklungsumgebung integrieren lassen. Neben GitHub- und Azure-DevOps-MCPs gibt es Anbindungen an Microsoft Docs, die offizielle API-Referenzen liefern, sowie Context7, das dafür sorgt, dass Codebeispiele immer zur verwendeten Version passen. Playwright MCP ist insbesondere für Teams interessant, die End-to-End-Tests schreiben oder bestehende UIs automatisiert verifizieren wollen.

Trotz dieser großen Auswahl kann es sinnvoll sein, einen eigenen MCP-Server zu bauen. Gerade wenn interne Systeme angebunden werden sollen – etwa ein API-Katalog mit projektspezifischen Endpunkten, eine interne Event-Schema-Registry oder eine firmeneigene Wissensdatenbank –, stößt man mit generischen Lösungen schnell an Grenzen. Ein eigener MCP-Server kann genau diese Domäneninformationen bereitstellen und so sicherstellen, dass ein Agent nicht nur syntaktisch korrekten, sondern auch fachlich passenden Code erzeugt. Das .NET-MCP-SDK macht die Implementierung dabei angenehm unkompliziert: Mit wenigen Zeilen Code kann ein eigener Server erstellt werden, der Tools bereitstellt, Anfragen entgegennimmt und Antworten im gewünschten Format zurückgibt.

Auch für Sicherheit ist gesorgt: MCP unterstützt Authentifizierung und Berechtigungen, sodass sensible Informationen nicht ungeschützt in den Agent-Kontext gelangen. IDEs wie VS Code oder Visual Studio sowie der Copilot Coding Agent unterstützen die Konfiguration von Secrets, wodurch Tokens und Passwörter sicher verwaltet werden können.

Unterm Strich bringen MCPs die KI-gestützte Entwicklung auf das nächste Level: weg von statischen Instruktionen, hin zu einem dynamischen, kontextbewussten Dialog zwischen dem Agent und den Systemen, in denen wir täglich arbeiten. Und genau hier entsteht der größte Mehrwert: Der Agent wird nicht nur zum Code-Assistenten, sondern zum echten Teammitglied, das versteht, in welchem Projekt es arbeitet, welche Regeln dort gelten und wie das Ergebnis automatisch überprüft werden kann.

Chancen, Risiken und Sicherheitsmechanismen

Sind nun alle Softwareentwicklerinnen und -entwickler in naher Zukunft arbeitslos? Nein! Auch wenn die KI rasante Fortschritte macht, so kann sie derzeit nicht den Menschen in der Entwicklung ersetzen. Die KI in der Entwicklung kann aber eine deutliche Effizienzsteigerung bewirken. Man bekommt ein kleines Team, das einem zuarbeitet, aber Feedback und Kontrolle benötigt. Ein weiterer Vorteil liegt auch im schnelleren Onboarding neuer Mitarbeiterinnen und Mitarbeiter. In Windeseile werden Fragen zur aktuellen Codebasis beantwortet. Aber auch für bestehende Mitarbeiter ist die Informationsquelle KI von Vorteil. Fragen, die man sich sonst nicht trauen würde, können im „privaten“ Rahmen gestellt werden, und auch die Erklärungen zum bestehenden Code sind stets abrufbereit. Aufgaben wie einfachere Refactorings oder Feature-Erweiterungen, aber auch Unterstützung bei der Testimplementierung können gut an die KI ausgelagert werden, und diese Chance sollte definitiv genutzt werden.

Vertrauen ist gut, Kontrolle ist besser. Genau so sollten wir auch mit der KI-Unterstützung umgehen. Ein blindes Vertrauen in KI-generierten Code wäre fahrlässig. Teilweise mit fast schon menschlich wirkenden Zügen versucht die eine oder andere KI das Ziel zu erreichen, indem sie Tests modifiziert oder abstellt, oder sie versucht so lange etwas, bis es zwar läuft, aber eine große technische Schuld geschaffen wurde. Oftmals hängt dies stark mit dem Prompting, den Rahmenbedingungen, aber auch mit dem verwendeten Modell zusammen. Um dieses Risiko zu minimieren, bedarf es der genau gleichen Mechanismen, die wir hoffentlich bereits im Einsatz haben: Die Isolation der Änderungen in einem dedizierten Branch, welche nur über einen Pull Request integriert werden können. Der Pull Request stellt sicher, dass alle Policies, Coding Guidelines und Security-Prinzipien ebenso erfüllt sind wie die funktionalen Anforderungen. Letzteres ist nur mittels Testautomatisierung möglich. Auch mit KI gilt hier ein Vier-Augen-Prinzip. Code und Tests sollten, wenn möglich, nicht aus der gleichen Feder stammen, und ein Review durch eine andere Person ist unabdingbar.

Neben den fachlichen Risiken gibt es natürlich auch Sicherheitsrisiken, wenn die KI maßgeblich an der Code-Generierung beteiligt ist. GitHub stellt für den Einsatz des durchaus autonomen Coding Agents folgende Maßnahmen zur Verfügung:

• Das Pushen von Code ist dem Coding Agent nur auf den copilot/*-Branch möglich, alle anderen Branches sind per Security Policy tabu.
• Zudem wird niemals ein Workflow automatisch gestartet, der von einer KI-Code-Änderung getriggert worden wäre. So muss der Benutzer entsprechend eine Freigabe tätigen, nachdem er die Gelegenheit hatte, die Änderungen zu verifizieren.
• Der Netzwerkzugriff der Coding-Agent-Umgebung wird durch strikte Firewall-Regeln limitiert, sodass keine Daten ungewollt nach außen dringen können.
• Aber auch Angriffsvektoren wie Prompt-Injection müssen bekämpft werden. So werden etwa versteckte Zeichen in Issues (zum Beispiel HTML-Kommentare in Markdown, nicht ersichtlich im gerenderten Text) entfernt, bevor der Text der KI übergeben wird.

Letztlich ist es wichtig, dass wir unsere Workflows und Pipelines so implementiert haben, dass jede Änderung vor der Integration fachlich und technisch validiert wird. Mit GitHub Advanced Security können wir einfach statische Code-Analysen ausführen und Dependencies auf Schwachstellen und Sicherheitslücken analysieren. Gepaart mit einer guten Testabdeckung bestehend aus sowohl Whitebox- als auch Blackbox-Tests können wir uns guten Gewissens von der KI unter die Arme greifen lassen.

Du möchtest gerne mehr erfahren?

Das freut uns, denn wir veröffentlichen auf developer-world.de/insights in unregelmäßigen Abständen zusätzliche Beiträge, die diese Thematik fortsetzen und ergänzen. Derzeit geplant sind folgende Artikel:

• CoPilot Agent Mode – Konfiguration und Best Practices
• MCP – Integration und Nutzung
• Eigener MCP-Server mit .NET