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

software-architektur.tv: Lernen & LLMs – Was und wie wollen wir lernen?


LLMs verändern, wie wir arbeiten. Aber verändern sie auch, wie wir lernen – und was es überhaupt bedeutet, etwas zu wissen?

Weiterlesen nach der Anzeige

Die Frage „Was sollen wir lernen, um bessere Software-Architekt:innen zu werden?“ stellt sich heute neu. Wie verändert sich die Rolle von Trainer:innen, Curricula und Zertifizierungen? Und was passiert mit unserem Verständnis von Expertise, wenn ein guter Prompt vermeintlich vieles ersetzt?

In dieser Fishbowl-Diskussion treffen LLM-Begeisterte auf LLM-Skeptiker, angehende Architekt:innen auf erfahrene Trainer:innen und iSAQB-Mitglieder – und alle bringen ihre eigene Perspektive mit. Keine Keynote, keine Slides. Nur offene Fragen, echte Meinungen und eine Diskussion, die auch unbequeme Antworten zulässt.

Fragen ohne einfache Antworten:

  • Was unterscheidet Wissen von Können – und was davon bleibt relevant?
  • Wie verändern sich Lernen, Mentoring und Wissensweitergabe im LLM-Zeitalter?
  • Was bedeuten die iSAQB-Zertifizierungen noch, wenn LLMs Wissensfragen beantworten?
  • Brauchen wir neue Lernkulturen – in Teams, Organisationen und Communities?

Das Publikum ist nicht nur Zuschauer. Vor Ort ist die Grenze zwischen Publikum und Panel fließend – wer etwas beitragen möchte, tut es einfach.

Mit Carola Lilienthal, Lars Hupel, Dr. Guido Gryczan und Dr. Gernot Starke, Moderation Eberhard Wolff. Live vom iSAQB Software Architecture Forum 2026. Wer vor Ort dabei sein will: Mit dem Code SATV15SAF gibt es 15 % Rabatt.

Weiterlesen nach der Anzeige

Die Ausstrahlung findet am Dienstag, 16. Juni 2026, live ab 17: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 iX (heise Developer) über die Episoden.


(map)



Source link

Weiterlesen

Entwicklung & Code

Open Knowledge Format: KI-Wissen als Markdown-Dateien


Google Cloud hat mit dem Open Knowledge Format (OKF) eine offene Spezifikation vorgestellt, die Kontextwissen für KI-Systeme und Agenten plattformübergreifend nutzbar machen soll. Das Format richtet sich an Unternehmen, die Metadaten, Dokumentationen, Runbooks oder fachliche Definitionen zentral für den KI-Einsatz bereitstellen wollen. Google hat die Unterstützung für OKF bereits in den eigenen Knowledge Catalog integriert.

Weiterlesen nach der Anzeige

Mit dem Format greift Google einen Ansatz auf, der sich unter Entwicklern von KI-Agenten in den vergangenen Monaten verbreitet hat. Statt Agenten immer wieder dieselben Informationen aus Wikis, Datenkatalogen oder Dokumentationen heraussuchen zu lassen, legen Teams ihr Wissen strukturiert als Sammlung von Markdown-Dateien ab. KI-Forscher Andrej Karpathy hat dieses Muster als „LLM Wiki“ beschrieben. Verwandte Konzepte stecken in Obsidian-Vaults, in Konfigurationsdateien für Agenten wie AGENTS.md oder CLAUDE.md sowie in sogenannten „Metadata as Code“-Repositories.

Diese Ansätze nutzen zwar ähnliche Bausteine – Markdown-Dateien, Metadatenfelder und Querverweise –, bleiben aber meist auf einzelne Teams, Werkzeuge oder Anbieter beschränkt. Wissen lässt sich so kaum zwischen verschiedenen KI-Systemen wiederverwenden. Genau hier setzt Google an: OKF soll die nötigen Konventionen festlegen, mit denen unterschiedliche Werkzeuge dieselben Wissensbestände lesen und schreiben können – ohne Übersetzungsschicht und ohne herstellereigenes SDK.

Ein OKF-Bundle besteht aus einem Verzeichnis von Markdown-Dateien. Jede Datei beschreibt genau ein Konzept, etwa eine Datenbanktabelle, einen Datensatz, eine API, eine Geschäftsmetrik, ein Runbook oder ein Playbook. Das YAML-Frontmatter enthält strukturierte Felder wie type, title, description, resource, tags und timestamp.

Die einzelnen Dateien verknüpfen sich über gewöhnliche Markdown-Links. So entsteht ein Wissensgraph, der die Beziehungen zwischen den Konzepten abbildet. Die Dokumentation einer Bestelltabelle kann etwa auf Kunden- und Produktdaten sowie auf die Definition einer Umsatzkennzahl verweisen. Ein KI-Agent bekommt damit nicht nur einzelne Dokumente, sondern auch deren fachliche Zusammenhänge.

Weiterlesen nach der Anzeige

Google beschreibt in der Ankündigung OKF ausdrücklich als Format und nicht als Plattform. Die Spezifikation soll unabhängig von Cloud-Anbietern, Datenbanken, KI-Modellen oder Agenten-Frameworks funktionieren. Den Standard halten die Entwickler bewusst schlank: Verpflichtend ist allein ein Typfeld, alle weiteren Strukturen und Metadaten dürfen die Anwender selbst festlegen. OKF schreibt damit nur die Interoperabilität vor, nicht aber ein einheitliches Inhaltsmodell.

Zusammen mit der Spezifikation liefert Google mehrere Referenzimplementierungen aus. Dazu zählt ein Enrichment-Agent für BigQuery, der Tabellen und Views analysiert und daraus automatisch OKF-Dokumente erzeugt. In einem zweiten Durchlauf reichert ein Sprachmodell die Dokumente um Schemainformationen, Dokumentation, Quellenangaben und Join-Beziehungen an. Hinzu kommt ein statischer HTML-Viewer, der einen OKF-Bestand als interaktiven Wissensgraphen darstellt, ganz ohne Backend.

Zum Ausprobieren stellt Google Beispielbestände für Datensätze aus GA4 E-Commerce, Stack Overflow und öffentlichen Bitcoin-Datensätzen bereit. Spezifikation, Beispielcode und Referenzimplementierungen liegen auf GitHub.

Die Spezifikation liegt bislang in Version 0.1 vor. Google bezeichnet sie als Ausgangspunkt und will sie gemeinsam mit der Community rückwärtskompatibel weiterentwickeln. Produzenten und Konsumenten des Formats – etwa Datenkataloge, Suchsysteme oder KI-Agenten – sollen dabei unabhängig voneinander entstehen.


(fo)



Source link

Weiterlesen

Entwicklung & Code

US-Regierung erzwingt Abschaltung von Anthropics KI Fable 5 und Mythos 5


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Anthropic muss seine KI-Modelle Fable 5 und Mythos 5 für alle Kunden weltweit abschalten. Auslöser ist nach Darstellung des Unternehmens eine Exportkontrolldirektive der US-Regierung, die am 12. Juni 2026 eingegangen sei und ausländischen Staatsangehörigen den Zugriff auf beide Modelle untersagt – auch ausländischen Anthropic-Mitarbeitern innerhalb der USA. Alle übrigen Claude-Modelle seien von der Anordnung nicht betroffen. Die Maßnahme reiht sich in eine bereits zuvor eskalierte Auseinandersetzung zwischen Anthropic und Teilen der US-Sicherheitsbürokratie ein.

Weiterlesen nach der Anzeige

Wie Anthropic in einer Stellungnahme erklärt, habe die Behörde keine konkreten technischen Details zu den angeführten nationalen Sicherheitsbedenken genannt. Nach dem Verständnis des Unternehmens geht die Regierung davon aus, dass eine Methode existiere, um Fable 5 zu „jailbreaken“, also dessen Schutzmechanismen zu umgehen. Anthropic bezeichnet die Maßnahme als „Missverständnis“ und arbeitet an der Wiederherstellung des Zugangs.


Screenshot der Startseite von Claude.

Screenshot der Startseite von Claude.

Beim Start von Claude verweist Anthropic auf die Erklärung, warum Fable 5 derzeit für alle Kunden deaktiviert ist.

Die beanstandete Technik beschreibt Anthropic als verbal überlieferten, potenziell nicht-universellen Jailbreak. Im Kern bestehe er darin, das Modell anzuweisen, eine bestimmte Codebasis zu lesen und Softwarefehler zu beheben. Eine Demonstration dieser Technik habe man geprüft und dabei lediglich eine kleine Zahl bereits bekannter, geringfügiger Schwachstellen gefunden, die auch andere öffentlich verfügbare Modelle aufspüren könnten – das Unternehmen nennt in diesem Zusammenhang ausdrücklich OpenAIs GPT-5.5.

Aus Sicht von Anthropic handelt es sich dabei um eine alltägliche Fähigkeit, wie sie Sicherheitsfachleute täglich bei legitimen Code-Reviews und beim Bugfixing nutzen. Der entscheidende Unterschied liege nicht in der Funktion selbst, sondern im Kontext: Derselbe Vorgang könne in einem Sicherheitsreview erwünscht sein, in einem anderen Szenario aber als potenzieller Missbrauch gewertet werden. Einen universellen Jailbreak, der die Schutzmechanismen von Fable 5 grundsätzlich aushebelt, habe man bislang nicht gefunden.

Anthropic verweist auf eine sogenannte „Defense-in-Depth-Strategie“: Jailbreaks sollen entweder eng begrenzt oder sehr aufwendig sein und werden durch Monitoring ergänzt, das erfolgreiche Angriffe schnell erkennen soll. Für Fable 5 gelte zudem eine 30-tägige Datenspeicherungspflicht, um Umgehungsversuche analysieren und eindämmen zu können. Unser Test von Fable 5 bestätigt, dass Anthropic Classifier vor das eigentliche Modell schaltet und bei heiklen Eingaben teils auf das Vorgängermodell Opus 4.8 zurückfällt.

Weiterlesen nach der Anzeige

Die zuvor kommunizierten Schutzmaßnahmen seien in einer Vorabprüfung über Tausende Stunden Red-Teaming getestet worden – gemeinsam mit der US-Regierung, dem britischen AI Safety Institute (UK AISI), privaten Organisationen und internen Teams. Die Ergebnisse hätten deutlich über denen früherer Modelle gelegen. Eine vollständig unabhängige Auditierung, etwa durch europäische Forschungseinrichtungen, ist nach derzeitigem Stand allerdings nicht belegt: Eine komplette Offenlegung der Schutzlogik oder der internen Classifier-Architektur gab es nicht. Während Fable 5 mit zusätzlichen Schutzmechanismen für die öffentliche Nutzung versehen wurde, gilt Mythos als restriktivere Variante.

Anthropic räumt ein, dass perfekte Jailbreak-Resistenz für kein Modell erreichbar sei. Zugleich widerspricht das Unternehmen der Auffassung, dass ein einzelner „unwahrscheinlicher Jailbreak den Widerruf eines kommerziellen Modells mit Hunderten Millionen Nutzern rechtfertige“. Würde man diesen Maßstab branchenweit anlegen, käme das einem Stopp neuer Frontier-Modelle gleich.

Die jetzige Anordnung trifft auf ein bereits angespanntes Verhältnis. Anfang März 2026 hatte das US-Verteidigungsministerium Anthropic als „supply chain risk“ eingestuft. In einem aktuellen Blogbeitrag erklärte CEO Dario Amodei, man halte die Einstufung als „supply chain risk“ für rechtlich nicht tragfähig und wolle sie vor Gericht anfechten. Der zugrunde liegende US‑Statut 10 U.S.C. § 3252 sei eng auf spezifische Lieferkettenrisiken bei nationalen Sicherheitssystemen zugeschnitten und verlange, dass das Ministerium darlegt, warum weniger eingriffsintensive Maßnahmen („less intrusive measures“) nicht vernünftigerweise zur Verfügung stehen.

Der Konflikt drehte sich nach Anthropics Darstellung um die Weigerung, Claude uneingeschränkt für massenhafte inländische Überwachung und vollautonome Waffensysteme freizugeben. Ob die aktuelle Exportdirektive primär eine Sicherheitsmaßnahme oder politischer Druck auf einen renitenten Anbieter ist, lässt sich aus den veröffentlichten Quellen nicht beweisen. Plausibel erscheint jedoch, dass der vorangegangene Streit das Verhältnis erheblich verschlechtert und die Eskalation begünstigt hat.

Für hiesige Anbieter ist ein direkt vergleichbarer, einzelmodellbezogener Eingriff in der EU nicht ersichtlich. Während das US-Exportkontrollrecht auf außenwirtschaftliche Zugriffssperren zielt, verfolgt der EU AI Act einen risikobasierten Ansatz mit Marktaufsicht, Transparenz- und Dokumentationspflichten. In Deutschland soll die Bundesnetzagentur die zentrale Marktüberwachungsbehörde werden; den entsprechenden Gesetzentwurf (KI-MIG) hat der Bundestag am 11. Juni 2026 beschlossen, die Zustimmung des Bundesrats steht noch aus. Eine globale Abschaltung eines einzelnen Modells als Maßnahme der Exportkontrolle ist in dieser Logik so nicht vorgesehen.

Lesen Sie auch


(vza)



Source link

Weiterlesen

Beliebt