Apple hat im Rahmen seiner Erwiderung auf das aktuelle DMA-Verfahren der EU-Kommission mehrere Vorschläge unterbreitet, wie das Digitalgesetz, von dem sich der Konzern schikaniert fühlt, verbessert werden könnte. Sollte der Digital Markets Act nicht zurückgezogen werden, um ihn gegen ein „legislatives Instrument [auszutauschen], das für seine Zwecke passt“, sollten mindestens tiefe Änderungen erfolgen, schreibt der Konzern.

Grundrechte auch für Gatekeeper

So fordert Apple die Schaffung einer unabhängigen europäischen Behörde, die außerhalb der Europäischen Kommission agiert, damit sie „geschützt vor politischer Einmischung“ in der Lage sein, „eine vorhersehbare, gerechte, ausgewogene und dem Gesetzestext entsprechende Anwendung des DMA zu gewährleisten, die die Grundrechte achtet“. Die neue DMA-Behörde solle die relevanten EU-Behörden aus den Bereichen Datenschutz und Cybersicherheit einbeziehen, wenn es um Anordnungen gehe, die die „fundamentalen Rechte auf Privatsphäre und Onlinesicherheit der Nutzer“ beeinträchtigen.

Schließlich stört sich Apple am Begriff der sogenannten „effective compliance“ und fordert eine Klarstellung. Das Unternehmen sieht sich laut eigenen Angaben mit ständig wechselnden Aussagen und Ansprüchen der EU-Kommission konfrontiert, die nur schwer umzusetzen sind. Zudem erhofft sich Apple eine Überprüfung der „übergreifende Verhältnismäßigkeit“. Diese solle die Europäische Kommission ausdrücklich dazu verpflichten, die Interessen der Endnutzer zu berücksichtigen, wenn es um Sicherheit, Datenschutz, Integrität und Innovation gehe. „Außerdem sollte sie die Bedeutung der Grundrechte von Gatekeepern anerkennen, wie beispielsweise Rechte an geistigem Eigentum und das Recht, ihr Geschäft zu betreiben, unter anderem durch Produktdifferenzierung.“

EU weist Apples DMA-Forderungen zurück

Die EU-Kommission hat unterdessen Apples Forderung, den DMA zu stoppen oder zumindest zu ändern, offiziell abgelehnt. Sprecher Thomas Regnier, für digitale Angelegenheiten zuständig, sagte laut einem Bericht von France24, Apple habe schließlich „jeden kleinen Teil des DMA seit Beginn“ in Frage gestellt.

Man sei daher „nicht überrascht“ von den Forderungen. Regnier sagte, es sei einzig Sache Brüssels, „zu entscheiden, wie wir den DMA durchsetzen wollen und wer den DMA durchsetzt“. Zuletzt hatte Apple eine Strafe in Höhe von 500 Millionen Euro für DMA-Verstöße aufgebrummt bekommen, gegen die das Unternehmen vorgeht.

(bsc)

Einzelne KI-Agenten können nicht nur Entwicklerteams unterstützen – ein einzelner Entwickler kann auch zum Product Owner werden und einen Agentenschwarm an die Arbeit schicken. Rüdiger Berlich, Titelautor der iX 10/2025, hat einen Blick in die mögliche Zukunft geworfen und mit dem Open-Source-Werkzeug Claude Flow eine Threadpool-Bibliothek für C++ erzeugt. Er erklärt, worauf experimentierfreudige Entwickler achten sollten.

Ein Entwickler dirigiert einen Agentenschwarm – wie muss man sich diese Arbeitsweise vorstellen?

Nun, der Entwickler dirigiert nicht wirklich – es geht eher darum, den Schwarm nur in die richtige Richtung zu schicken. Claude Flow ist ja selber ein Orchestrierungsframework mit dem Ziel, möglichst große Teile der Entwicklung zu automatisieren. Hierfür wird der Schwarm durch einen oder mehrere spezialisierte KI-Agenten angeleitet. Zuvorderst steht dabei die „Queen“, die ihren „Hive“ steuert. Die Arbeit mit dem Schwarm ähnelt deshalb weniger der Zusammenarbeit mit einem einzelnen Agenten, die ja durchaus interaktiv erfolgen kann. Vielmehr möchte man möglichst große Blöcke der Entwicklung parallel abarbeiten lassen, was Interaktivität weitgehend ausschließt. Die eigentliche Arbeit des Entwicklers findet deshalb bereits statt, bevor der Schwarm seinem Ziel entgegen schwebt.

Natürlich kann man Synchronisationspunkte zwischen Mensch und Maschine einbauen. Ganz klar sollte man auch, nachdem die Queen den Erfolg verkündet hat, die Ergebnisse prüfen. Man kann aber auch die Entwicklung so strukturieren, dass sie in Phasen läuft, nach denen menschliche Interaktion gewünscht ist. So wird man sicherlich zunächst mit der Architektur beginnen, die in einem nur kleinen Schwarm entwickelt wird. Man könnte sich etwa Architekturdiagramme vorschlagen und die KI eine API entwerfen lassen. Wenn die Architektur steht, lässt man den Schwarm losfliegen.

Erfahrene Entwickler werden dadurch nicht überflüssig, sondern sind im Gegenteil als Kontroll- und Steuerinstanz besonders wichtig. Sie rutschen aber zunehmend in die Rolle eines Product Owners mit Architekturverantwortung, wenn auch für kleinere Komponenten. Das bedeutet auch, dass man die Anforderungen sehr genau analysieren sollte, bestenfalls in einem formalen Requirements Engineering. Nur wenn man selber genau weiß, was entwickelt werden soll, kann man erwarten, dass die KI auch das richtige Problem löst. Neben der Validierung spielt dann auch noch die Verifikation eine Rolle. Die Entscheidungsgewalt liegt aber weiter beim Menschen, und die Möglichkeit zur Überprüfung der Ergebnisse sollte genutzt werden.

Wenn die Agenten einander zuarbeiten, potenziert das doch auch die Halluzinationen? Wie geht man damit um?

Es stimmt, dass Agenten halluzinieren. Noch schlimmer ist aber, dass KIs eine unendliche Zahl an meist validen Lösungen vorschlagen können, sodass sich eine Entwicklung quasi verlaufen kann und man zu komplexe Lösungen erhält. Dies lässt sich durch das Requirements Engineering mit genauen Vorgaben zur „Definition of Done“ eingrenzen. Dazu gibt es inhärente Kontrollmechanismen: Denn wenn die genaue Spezifikation dessen stimmt, was entwickelt werden soll, wird die Arbeit ja zwischen Subagenten aufgeteilt.

Wenn jetzt einer davon in die Wüste galoppiert, passen die Einzellösungen nicht zueinander und Tests schlagen fehl. Agenten können hierauf reagieren und die Fehler finden. Claude Flow unterstützt übrigens auch Test Driven Development, sodass von vornherein weniger Fehler entstehen. So kontrolliert sich die Entwicklung quasi selber. Spezialisierte Quality-Assurance-Agenten könnten auch eine aktive Kontrolle ausüben und etwa regelmäßig Code Reviews durchführen, auf die die Entwickler-Agenten reagieren müssen. Am Ende liegt die Ergebnisverantwortung bei der Queen, mit der der menschliche Auftraggeber sich auch streiten kann. Ein solcher Austausch kann dann durchaus groteske Züge annehmen, weil heutigen KIs eine Art Persönlichkeit antrainiert wird.

Insgesamt ähnelt die Arbeit mit Schwärmen übrigens sehr schnell einer agilen Entwicklung. Die Aufgabe wird analysiert, strukturiert, priorisiert und in Teilpakete aufgeteilt. Die Queen kann Entwicklungsphasen vorschlagen, nach deren Ende ein bestimmtes Ziel erreicht sein muss. Man entwickelt dann in Sprints mit Sprintzielen und der Vorstellung der Ergebnisse, entweder gegenüber einer KI oder dem Menschen. Es gibt also explizite Kontrollfunktionen und Schwarm-immanente, implizite Kontrolle, die ein Auseinanderlaufen der Entwicklung verhindern. Letztlich ist Kontrolle immer notwendig, auch wenn Zeitdruck und die sich durch KIs verkürzenden Innovationszyklen dazu verleiten, Abkürzungen zu nehmen. Insgesamt beschleunigt die Nutzung von Agentenschwärmen wie Claude Flow die Entwicklung und verbessert die Erfolgsrate gegenüber Einzelagenten.

Was braucht es dafür grob gesagt an Tools, Umgebung und Sicherheitsvorkehrungen, damit der Schwarm loscoden kann?

Der Schwarm soll autonom entwickeln. Die Arbeitsumgebung ist deshalb nicht anders als das, was ein menschlicher Entwickler erwartet. Man wird ein am besten lokales git haben, Compiler, Build-Umgebungen wie etwa CMake und alles, was man für die Architekturerstellung benötigt, zum Beispiel PlantUML. Die Kommunikation kann über Markdown-Dokumente strukturiert werden, sodass sich ein entsprechender Editor empfiehlt.

Autonome Entwicklung heißt auch, dass man der KI recht weitreichenden Zugriff auf das Hostsystem geben muss. Das kann auch bedeuten, dass die KI-Agenten selbstständig benötigte Pakete nachinstallieren, was so wohl nur unter einem Linux-System möglich ist und Root-Privilegien erfordert. Ein gesundes Maß an Vorsicht ist dabei sinnvoll. Um also nicht jedes Mal das System neu aufsetzen zu müssen, nachdem die KI das Steuer in der Hand hatte, empfiehlt sich die Verwendung einer VM. Unter Ubuntu bietet sich dafür das leichtgewichtige Multipass an.

Möchte man mehr Kontrolle, so kann man die Kommunikationsmöglichkeiten der VM von Hostseite aus auf bestimmte Endpoints einschränken. Wenn man nach dem initialen Einrichten der VM einen Snapshot erstellt, kann man immer wieder auf einen bekannten Stand der VM zurücksetzen und muss die KI nicht jedes Mal neu initialisieren. Ein Docker-Container ginge dabei sicherlich auch.

Die Installation von Claude Flow und dem von ihm benötigten Claude Code erfolgt über den npm-Paketmanager. Man sollte sich dessen bewusst sein – unlängst gab es ja Berichte über kontaminierte Pakete. Das betrifft jede Umgebung, die npm verwendet und ist nicht speziell für Claude Flow und Claude Code. Wir sind heute auch noch nicht an dem Punkt, an dem man leistungsfähige Coding-KIs mit vertretbarem Aufwand lokal einsetzen kann. Ein No-Go sind also Projekte, bei denen kein Teil der Code-Basis nach außen dringen darf.

Rüdiger, danke für die Antworten! Mehr Details zum Coden mit KI-Schwarm gibt es in der neuen iX. Außerdem zeigen wir, was agentische KI eigentlich ausmacht, und werfen einen kritischen Blick darauf, welche Security-Risiken KI-Agenten mit sich bringen. All das und viele weitere Themen finden Leser im Oktober-Heft, das jetzt im heise Shop oder am Kiosk erhältlich ist.

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(axk)

Wenn Softwarefehler auftreten, passiert das meistens unbemerkt und unauffällig, gelegentlich aber auch höchst spektakulär und kostspielig. Von fehlgeschlagenen Raumfahrtmissionen über Börsencrashs bis hin zu fehlerhaften medizinischen Geräten gibt es eine lange Liste berühmter Softwarepannen. Wer sie studiert, stellt schnell fest: Die meisten dieser Fehler wirken auf den ersten Blick wie einmalige Katastrophen, sind in Wahrheit aber Wiederholungen bekannter Muster.

Diese Artikelserie stellt neun dieser typischen Fehlerklassen vor, die in der Praxis immer wieder auftauchen – unabhängig von Branche oder Technologie. In jeder Kategorie wird die Serie ein konkretes Beispiel vorstellen, dessen Ursachen analysieren und daraus ableiten, was Softwareentwicklerinnen und Softwareentwickler langfristig lernen können.

Der Bug in der Rechenanlage

Eine der beliebtesten Anekdoten der Softwaregeschichte ist die von Grace Hopper und der berühmten Motte. 1947 arbeitete Grace Hopper an der Harvard-Mark-II-Rechenanlage, in der sich eine echte Motte in einem Relais verfangen hatte. Nachdem ein Teammitglied sie gefunden und entfernt hatte, klebte dieser sie mit dem Kommentar „first actual case of bug being found“ ins Protokollbuch. Dieses Protokollbuch wird heute in einem Smithsonian Museum in Washington ausgestellt.

Diese Episode ist zu einer Legende der IT-Kultur geworden – das Wort „Bug“ wurde damals aber nicht erfunden. Schon Thomas Edison sprach 1878 in Briefen über „Bugs“ in Maschinen, also kleine, schwer zu findende Fehler. Trotzdem prägte Grace Hopper die Vorstellung, dass Softwarefehler etwas sind, das man wie ein Insekt finden und entfernen kann.

Doch die Realität ist oft subtiler: Bugs sind meist Symptome systematischer Schwächen. Hinter fast jeder spektakulären Panne steckt ein Muster, das sich in abgewandelter Form immer und immer wieder findet. Deshalb lohnt sich ein Blick nicht nur auf die einzelnen Vorfälle, sondern vor allem auf die Fehlerkategorien, die sie repräsentieren.

Teil 1: Einheiten und Maße: Wenn Zahlen irreführend werden

Am Beginn dieser Serie steht ein Thema, mit dem Entwicklerinnen und Entwickler jeden Tag wie selbstverständlich hantieren – und das vielleicht gerade deshalb so gefährlich ist. Es wird allzu leicht unterschätzt: Die Rede ist vom Umgang mit Zahlen.

Kaum ein Beispiel für Softwarefehler wird so häufig genannt wie der Verlust der NASA-Sonde Mars Climate Orbiter im Jahr 1999. Ziel der Mission war es, die Marsatmosphäre zu untersuchen. Nach einer monatelangen Reise näherte sich die Sonde dem Planeten – und verglühte. Die Ursache war fast grotesk simpel: Die Entwickler hatten in der Software metrische und imperiale Maßeinheiten verwechselt. Das Ergebnis war ein systematischer Navigationsfehler, der die Sonde auf eine zu niedrige Umlaufbahn führte.

Dieser Vorfall zeigt, dass Zahlen ohne Kontext gefährlich sind. Eine Zahl wie 350 kann das Maß einer Geschwindigkeit, einer Kraft oder einer Energie bedeuten – oder eben etwas ganz anderes. Solange eine Software Daten als rohe Zahlen behandelt, besteht die Gefahr, dass jemand sie falsch missinterpretiert. In großen Projekten mit mehreren Teams potenziert sich dieses Risiko, wenn jede Seite implizite Annahmen trifft, die niemand irgendwo explizit dokumentiert oder technisch abgesichert hat.

Aus Sicht der Qualitätssicherung sind solche Fehler besonders tückisch, denn Unit Tests können ebenso wie Integrationstests durchaus korrekt durchlaufen – solange die falschen Einheiten konsistent falsch sind. Das Problem zeigt sich oft erst in der Realität, wenn Sensoren, Aktoren oder externe Systeme ins Spiel kommen, deren Daten den zuvor getroffenen Annahmen nicht entsprechen. Die Lehre aus diesem Vorfall ist klar: Zahlen brauchen Bedeutung. Moderne Programmiersprachen und Frameworks bieten verschiedene Möglichkeiten, diese Bedeutung explizit zu machen:

• Value Objects oder Wrapper-Typen: Statt double oder float kommt ein eigener Typ wie ForceInNewton oder VelocityInMetersPerSecond zum Einsatz. Damit wird die Einheit Teil der Typinformation. Manche Programmiersprachen, beispielsweise F#, bieten Unterstützung für Einheiten sogar bereits als Teil der Sprache an.
• Bibliotheken für physikalische Einheiten: Sie ermöglichen automatische Umrechnungen und erzwingen korrekte Kombinationen.
• Schnittstellenverträge und End-to-End-Tests: API-Definitionen sollten Einheiten benennen. Tests mit echten Daten decken Diskrepanzen auf, bevor sie zu Katastrophen führen.

Neben diesen technischen Maßnahmen spielt außerdem auch die Teamkultur eine große Rolle. Projekte, die früh auf eine gemeinsame Sprache für ihre Daten achten – sei es durch Domain-Driven Design (DDD) oder einfach durch konsequente Dokumentation –, vermeiden solche Fehler deutlich häufiger.

Der Verlust des Mars Climate Orbiter hat die NASA hart getroffen. Doch er hat auch dazu geführt, dass Entwicklerinnen und Entwickler zumindest in manchen Projekten stärker auf Einheitenfehler achten und diese Fehlerklasse seither (hoffentlich) ernster nehmen. Für Softwareteams im Alltag gilt dasselbe: Wer Zahlen ohne Kontext weitergibt, lädt zum nächsten Bug geradezu ein.

Im nächsten Teil lesen Sie: Überlauf, Arithmetik und Präzision: Wenn Zahlen kippen

(who)