Connect with us

Entwicklung & Code

Analyse: Darf KI Kernfeatures in kritische Software implementieren?


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.

Weiterlesen nach der Anzeige


Sebastian Springer

Sebastian Springer

Sebastian Springer weckt als Dozent für JavaScript, Sprecher auf zahlreichen Konferenzen und Autor die Begeisterung für professionelle Entwicklung mit JavaScript.

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?


enterJS Integrate AI

enterJS Integrate AI

(Bild: Stone Story / stock.adobe.com)

Webanwendungen mit KI anreichern, sodass sie wirklich besser werden? Der Online-Thementag enterJS Integrate AI am 28. April 2026 zeigt, wie das geht. Frühbuchertickets und Gruppenrabatte sind im Online-Ticketshop verfügbar.

Weiterlesen nach der Anzeige

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.

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)



Source link

Entwicklung & Code

Visual Studio 2026 erlaubt das Erstellen benutzerdefinierter KI-Agenten


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.

Weiterlesen nach der Anzeige

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.

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.

Weiterlesen nach der Anzeige


Die neue Option "Fix with Copilot" soll NuGet-Vulnerabilities beheben.

Die neue Option "Fix with Copilot" soll NuGet-Vulnerabilities beheben.

Die neue Option „Fix with Copilot“ soll NuGet-Vulnerabilities beheben.

(Bild: Microsoft)

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.

Lesen Sie auch


(mai)



Source link

Weiterlesen

Entwicklung & Code

software-architektur.tv: Analyse großer Softwaresysteme mit LLMs


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.

Weiterlesen nach der Anzeige

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.

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)



Source link

Weiterlesen

Entwicklung & Code

Bund veröffentlicht lizenzfreie KI-Werkzeuge | heise online


Die deutsche Verwaltung gilt als Sinnbild für lahme Prozesse und dicke Aktenstapel. Doch beim Thema KI will der Bund zeigen, dass es auch anders geht. Das Bundesministerium für Digitales und Staatsmodernisierung (BMDS) hat mit dem Projekt Spark eine Reihe von KI-Modulen veröffentlicht, die die Arbeitsweise in Behörden grundlegend verändern könnten.

Weiterlesen nach der Anzeige

Eine Besonderheit ist der Ansatz der Veröffentlichung: Unter dem Leitsatz Public Money, Public Code stehen die Anwendungen für jeden auf der Plattform OpenCode zur Verfügung. Damit folgt das BMDS dem Ruf nach digitaler Souveränität und ermöglicht es Kommunen, Firmen und der Zivilgesellschaft, die Werkzeuge ohne Lizenzgebühren zu nutzen und weiterzuentwickeln.

Mit Spark sollen komplexe Planungs- und Genehmigungsverfahren, die bisher Monate oder gar Jahre dauerten, durch eine intelligente operative Assistenz beschleunigt werden. Die Finanzierung erfolgt über den Klima- und Transformationsfonds. Das Projekt soll Beschäftigte in den Genehmigungsbehörden von Routineaufgaben befreien, ohne Menschen zu ersetzen. Vielmehr bereite die KI die Flut an Informationen aus Antragsunterlagen so auf, dass Sachbearbeiter schneller zu einer fundierten Entscheidung kommen könnten. Das letzte Wort habe der Mensch.

Technisch setzt Spark an, wo es bisher am meisten hakt: beim Sichten und Prüfen von Dokumenten. Die veröffentlichten Module decken typische Aufgaben wie die Zusammenstellung relevanter Daten aus Anträgen oder den formalen Check auf Vollständigkeit und Plausibilität ab. Das System soll dabei erkennen, wenn Dokumente fehlen oder Angaben widersprüchlich sind.

Das Herzstück bildet eine mit KI-Agenten unterstützte Rechtsdogmatik. Sie ist direkt an Gesetzesdatenbanken angeschlossen und kann Normen automatisiert dekonstruieren und juristisch bewerten. Im weiteren Verlauf sollen zusätzliche Module folgen, die sich auch der materiellen Prüfung und der Beschlusserstellung widmen.

Digitalminister Karsten Wildberger (CDU) sieht die Republik durch diesen Vorstoß weltweit in einer führenden Rolle bei KI-basierten Verwaltungsanwendungen. Erst im Februar sahnte das Projekt auf dem World Government Summit in Dubai den Preis für die beste KI-Nutzung in staatlichen Dienstleistungen ab. Die offene Bereitstellung des Quellcodes soll nun sicherstellen, dass kreative Köpfe die Module adaptieren und für verschiedene föderale Anforderungen optimieren können. Um diesen Prozess anzukurbeln, plant das BMDS für Juni einen zweitägigen Hackathon.

Weiterlesen nach der Anzeige

Trotz der Euphorie mahnt das BMDS zur Sorgfalt bei der Implementierung. In den Begleitunterlagen findet sich ein Sicherheitshinweis: Der veröffentlichte Code sei als Referenz und Integrationsgrundlage zu verstehen, beinhalte aber keine fertige Sicherheitskonfiguration für den direkten Produktionseinsatz. Betreiber müssen die Anwendungen in ihren jeweiligen IT-Umgebungen härten, Zugriffsrechte definieren und sensible Daten sicher verwalten. Ein dediziertes Security-Review ist zwingend erforderlich, bevor die KI tatsächlich in produktive Genehmigungsverfahren eingebunden wird.

Für Entwickler soll der Einstieg aber hürdenarm sein. Die Module basieren auf einer Docker-Umgebung und lassen sich rasch aufsetzen. Die Konfiguration erfolgt über Skripte. Schnittstellen zu OpenAI-kompatiblen Endpunkten und lokalen Lösungen wie LiteLLM sind vorgesehen.


(mma)



Source link

Weiterlesen

Beliebt