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)

Mit dem rasanten Wachstum von APIs steigt auch die Notwendigkeit für deren qualitativ hochwertige Entwicklung. Doch viele APIs sind schlecht programmiert, was zu einer ineffizienten Nutzung und schlechter Developer Experience führt. In unserem Workshop API-Design und -Entwicklung mit HTTP, REST und OpenAPI zeigen wir Ihnen, wie Sie effiziente und benutzerfreundliche APIs entwickeln und geben Ihnen Best Practices für das Design von HTTP-basierten REST-Schnittstellen.

Der Workshop umfasst eine Einführung in HTTP und REST sowie das Design von RESTful APIs. Sie lernen, wie Sie HTTP- und REST-Standards korrekt anwenden, standardisierte Referenzdokumentationen erstellen und für API-Konsistenz sorgen. Sie machen sich mit der OpenAPI-Spezifikation vertraut und lernen, wie Sie OpenAPI-Beschreibungen für REST APIs erstellen und die Qualität dieser Beschreibungen überprüfen können.

Interaktives Lernen und Üben

Der Workshop ist interaktiv gestaltet und besteht aus Theorie- und Praxisblöcken. Während der Übungen arbeiten Sie in Kleingruppen und wenden die Standards und Werkzeuge praktisch an. Anhand von Beispielen aus der langjährigen Praxiserfahrung der Trainer können Sie das Gelernte direkt anwenden und vertiefen.

Diese Schulung richtet sich an Entwickler und Entwicklerinnen, die HTTP, REST und OpenAPI noch nicht angewendet haben oder ihr Wissen bezüglich dieser Standards auffrischen möchten. Besonders wichtig sind diese Standards für Entwicklungsteams, deren APIs von anderen Teams oder sogar Externen verwendet werden.

Ihre Trainer Daniel Kocot und Miriam Greis arbeiten gemeinsam in einem Team der codecentric AG und betreuen dort Kunden im Bereich API-Entwicklung mit dem Schwerpunkt API Experience & Operations. Ein besonderes Augenmerk liegt dabei auf der kontinuierlichen Verbesserung und Automatisierung von Prozessen.

(ilk)