Microsoft hat seine Entwicklungsumgebung Visual Studio 2026 im März mit neuen Features versehen, die sich vor allem um Künstliche Intelligenz (KI) drehen. Alle neuen Funktionen sind in der Insiders-Version verfügbar.

Agent Skills und benutzerdefinierte Agenten

In Visual Studio können Entwicklerinnen und Entwickler nun benutzerdefinierte Copilot-Agenten erstellen. Diese können beispielsweise den Coding-Standards des Teams folgen oder interne Dokumentation durchsuchen. Die spezialisierten Copilot-Agenten können Zugriff auf Workspace-Awareness, Codeverständnis, Tools, das bevorzugte Modell und Verbindungen via Model Context Protocol (MCP) zu externen Wissensquellen erhalten.

Dazu spezifizieren Entwickler die gewünschten Anpassungen in einer .agent.md-Datei, fügen diese im Repository zu .github/agents/ hinzu und können dann den neuen Agenten im Agent Picker auswählen. Wurde kein Modell festgelegt, verwendet der KI-Agent das im Model Picker gewählte Modell.

Mit Skills lassen sich die KI-Agenten ebenfalls versehen. Die Agenten beziehen Skills automatisch aus verschiedenen Stellen im Repo, etwa .github/skills/, oder aus dem User-Profil, etwa ~/.copilot/skills/. Jeder Skill besitzt ein eigenes Verzeichnis mit einer SKILL.md-Datei, die der Agent-Skill-Spezifikation entspricht. Agent Skills sind ein offenes Format, um KI-Agenten mit spezialisiertem Wissen auszustatten.

Copilot behebt NuGet-Vulnerabilities

Der KI-Copilot kann nun auch dabei helfen, Vulnerabilities zu beheben. Direkt aus dem Solution Explorer heraus können Entwicklerinnen und Entwickler die Benachrichtigung „Fix with GitHub Copilot“ anwählen, wenn eine Vulnerability erkannt wurde, die NuGet betrifft, das Paketverwaltungssystem für .NET. Beim Durchklicken analysiert Copilot die Schwachstelle und kann entsprechende Dependency-Updates empfehlen sowie implementieren.

Weitere Updates betreffen unter anderem die Verwendung von MCP: Admins können festlegen, welche MCP-Server innerhalb ihrer Organisation erlaubt sind, und nur diese lassen sich dann in Visual Studio verwenden. Bei anderen Servern erscheint eine Fehlermeldung.

Die neuen Features lassen sich im Insiders-Build nutzen. Weitere Informationen zu den Updates liefert Microsofts Entwicklerblog.

(mai)

Die Open-Source-Community und die Mitglieder des Technical Steering Committee (TSC) von Node.js diskutieren derzeit, ob Pull Requests zu Node.js künftig abgelehnt werden sollen, wenn sie mithilfe von KI entstanden sind. Das ist jedoch aus mehreren Gründen unrealistisch: KI ist längst ein Teil des Entwicklungsprozesses, die Maintainer können die Herkunft von Code kaum verlässlich prüfen und es gibt keine objektiven Kriterien, um KI-Unterstützung eindeutig von menschlicher Arbeit zu unterscheiden. Zudem ist ein Verbot nicht sinnvoll, da es die ohnehin knappen Ressourcen der Community weiter belasten würde und es auch keine verantwortungsvolle Governance ersetzt.

Debatte um Node.js

Kritik an KI-generierten Pull Requests ist zwar nicht neu, hat aber durch diesen aktuellen Fall eine neue Dimension erreicht und betrifft hier ein kritisches Element der Software-Infrastruktur: Die Plattform Node.js bildet in zahlreichen Anwendungen entweder die technische Basis oder dient als Grundlage für Build- und Entwicklungswerkzeuge.

Auslöser der aktuellen Diskussion ist ein umfangreicher Pull Request mit mittlerweile über 21.000 Zeilen Code. Der Autor Matteo Collina, ein erfahrener Node.js-Contributor, hat offengelegt, dass er das Feature teilweise mit Claude Code entwickelt, den generierten Code aber gründlich überprüft habe. In seinem Blogartikel führt er aus, dass er sich bei der Umsetzung des Features auf die Architektur, das API-Design und die Code Review konzentriert habe, während er die langweilige Schreibarbeit wie die Implementierung der Methodenvarianten, Tests und Dokumentation der KI überlassen habe.

Bei dem Feature handelt es sich nicht um eine kosmetische Änderung oder zusätzliche Tests, sondern um ein komplett neues Kernfeature: VFS, ein virtuelles Dateisystem, das es ermöglicht, Dateien und Module direkt aus dem Speicher statt vom realen Dateisystem zu laden. Dieses Feature greift tief in das Dateisystem-Modul und das Modulsystem von Node.js selbst ein. Überspitzt gesagt, stellt sich die Frage: Darf KI Kernfeatures eines kritischen Open-Source-Projekts implementieren?

Umgang mit KI-Flut und ihren Risiken

Eine einfache Antwort gibt es darauf nicht. Der Fall zeigt aber sehr deutlich eines der Grundprobleme, mit denen viele Open-Source-Projekte aktuell konfrontiert sind. Viele Projekte werden regelrecht mit KI-generierten Beiträgen überflutet. Diese reichen von kleinen Rechtschreibkorrekturen in der Dokumentation bis hin zu tiefgreifenden Architektur-Features. Die Maintainer stehen zunehmend vor der Entscheidung, ob sie KI-generierten Code grundsätzlich zulassen oder verbieten sollen. Neben den offensichtlichen Vorteilen wie Effizienzsteigerung und einer niedrigeren Einstiegshürde für neue Beitragende gibt es mehrere ernst zu nehmende Bedenken.

Diese betreffen zum einen das Copyright, denn KI-generierter Code ist in der Regel nicht urheberrechtlich geschützt. Anders sieht es bei KI-unterstütztem Code aus. Hier hängt es vom Einzelfall ab. Zudem besteht das Risiko, dass Modelle versehentlich proprietären Code reproduzieren und so zu Urheberrechtsproblemen führen. Diese Unsicherheit führt dazu, dass manche Maintainer KI-Beiträge grundsätzlich ablehnen möchten.

Zweitens wird die Qualität des Codes kritisch gesehen. KI-Agenten neigen dazu, sehr viel Code zu produzieren. Sowohl Autorinnen und Autoren als auch Maintainer müssen sicherstellen, dass der Code den Qualitäts- und Architekturstandards des Projekts genügt. Statische Analyse kann nur einen Teil davon abdecken. Aspekte, die die Architektur betreffen, müssen meist manuell überprüft werden. Gerade bei umfangreichen Beiträgen steigt das Risiko, dass suboptimale oder schwer wartbare Lösungen in den Code gelangen.

Und drittens nimmt der Aufwand für die Maintainer zu. Durch die Menge an generiertem Code verschiebt sich der Schwerpunkt vieler Maintainer vom Schreiben von Code hin zur Code Review. Dieser Aspekt nimmt teilweise so überhand, dass manche sich nur noch mit Code Reviews beschäftigen. Bei vielen Open-Source-Projekten entsteht das Problem, dass die Beiträge automatisiert übermittelt werden, sodass kaum noch menschliche Interaktion erforderlich ist. In der Flut aus KI-generierten Beiträgen können wertvolle Bugfixes oder Feature-Implementierungen leicht untergehen.

Trotz dieser Risiken ist ein generelles Verbot von KI-generiertem Code in der Praxis kaum durchsetzbar. Viele Entwicklerinnen und Entwickler nutzen Copilot, Cursor und andere Werkzeuge für die Entwicklung, und hier auch in unterschiedlichem Ausmaß, von einfachen Inline-Vervollständigungen bis hin zu agentenbasiertem Coding. Hier stellt sich die Frage: Was ist noch ein smartes Feature der Entwicklungsumgebung und was ist KI-gestütztes Coding, oder auch: Wo ist die Grenze zwischen „menschlich“ und „KI-gestützt“? Und wie soll man sie erkennen? Gerade bei kleineren Beiträgen ist es faktisch unmöglich festzustellen, ob der Code von einer KI stammt oder nicht.

Die Linux Foundation verfolgt hier einen pragmatischen Ansatz. Gemäß ihrer Richtlinie ist KI-generierter Code grundsätzlich erlaubt. Die Nutzungsbedingungen des KI-Tools dürfen jedoch keine Restriktionen enthalten, die der Lizenz des Projekts widersprechen. Der KI-generierte Code darf zudem keine Urheberrechtsverletzungen verursachen; die Nutzung des generierten Codes muss erlaubt sein. Dabei gilt, dass die KI assistieren darf, der Mensch aber der verantwortliche Autor bleibt.

Transparenz gehört zu den grundlegenden Prinzipien im verantwortungsvollen Umgang mit generativer KI. Das gilt nicht nur für die Entwicklung solcher Systeme, sondern ebenso für ihre Nutzung: Entwickler sollten offenlegen, wenn sie Code mithilfe von KI-Werkzeugen entwickelt haben. Einige Open-Source-Projekte haben entsprechende Offenlegungspflichten in ihre Contribution-Richtlinien aufgenommen, zum Beispiel der Terminal-Emulator Ghostty. Das Webframework Django hat eine AI Assistance Disclosure in das offizielle Pull-Request-Template integriert.

Verlässliche Richtlinien statt KI-Verbot

Die Diskussion um den Umgang mit KI ist für jedes Projekt, auch im Open-Source-Bereich, sehr wichtig, und sie wird auch nicht beendet sein. Stattdessen müssen wir uns kontinuierlich mit dem Thema beschäftigen, denn die Werkzeuge und Modelle entwickeln sich kontinuierlich weiter. Die Qualität wird immer besser und auch die Erfahrungen mit den Werkzeugen und ihrem Umgang nehmen zu.

Es braucht verlässliche Richtlinien, um Projekte und ihre Maintainer zu schützen. Ein generelles Verbot von KI ist wenig realistisch und auch nicht zielführend. Es wirkt eher wie ein reflexartiges Abwehren neuer Technologien. Sinnvoller ist es, Verantwortung klar zu definieren, Transparenz einzufordern und die Qualitätssicherung zu stärken. Das ist jedoch nicht nur die Aufgabe der Maintainer, die aktuell schon unter der Situation leiden, sondern einer jeden Entwicklerin und eines jeden Entwicklers, die zu Open-Source-Projekten beitragen möchten.

(mai)

Bei der Verwendung von LLMs für Software-Architektur geht es meistens um das Erstellen von Architektur. In dieser Episode von software-architektur.tv spricht Eberhard Wolff mit Prof. Dr. Michael Stal, Principal Key Expert Engineer bei der Siemens AG, über dessen Erfahrungen bei der Benutzung von LLMs für die Code-Analyse.

Den vollmundigen Versprechen mancher Anbieter und Influencer für generative KI steht die praktische Realität gegenüber, dass die Beschränkungen von LLMs zu vielen Problemen führen, ganz besonders beim Softwareengineering. Die Analyse großer Softwarearchitekturen und Codebasen durch LLMs scheitert unter anderem an dem beschränkten Kontextfenster der Foundation-Modelle. Das gilt im Umkehrschluss auch für deren Generierung. Wie sich diese Problematik zumindest teilweise umgehen lässt, möchte iX-Blogger Michael Stal anhand geeigneter Techniken zeigen.

Livestream am 2. April

Die Ausstrahlung findet am Donnerstag, 2. April 2026, live ab 14:30 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren berichtet heise Developer über die Episoden.

(map)