In dieser Episode sprechen Richard Seidl und Daniel Knott über KI im Testen, Agenten und praktische Werkzeuge. Sie beleuchten Use Cases wie Dokumentanalyse, Testdaten und Copiloten, erklären das MCP-Konzept und ordnen ein, wo messbarer Mehrwert entsteht.

Knott hat aus eigener Erfahrung auch festgestellt, dass KI nochmal einen ganz anderen Blick auf Daten und Datenzusammenhänge eröffnet, um dann bessere Entscheidungen treffen zu können.

Gleichzeitig thematisieren sie Risiken durch generierten Code, technische Schulden und spätere Refactorings. Für Testerinnen und Tester rücken Systemverständnis, Domänenwissen und klare Kommunikation in den Mittelpunkt, ebenso die Schärfung von Pyramide und Quadranten.

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Was bewegt die Software-Test-Community heute? – Daniel Knott“ und steht auf YouTube bereit.

(mai)

Jedes Jahr ist der Open Source Summit EU eine gute Option, um sich über den Status quo von quelloffener Software zu informieren. Vom 25. bis 29. August 2025 lädt die Linux Foundation EU nach Amsterdam ein. Der erste Konferenztag war natürlich mit verschiedenen Ankündigungen gespickt. Beispielsweise wandert das Projekt DocumentDB unter die Fittiche der Linux Foundation. Diese NoSQL-Datenbank ist kompatibel mit MongoDB und mit der MIT-Lizenz versehen. Über eine Erweiterung versteht sie sogar Postgre und kann so bestimmte Anwendungsfälle aus der SQL-Welt ebenfalls bedienen. Das Projekt stammte ursprünglich aus dem Hause Microsoft, hat aber inzwischen auch Entwickler und Beteiligungen von anderen Unternehmen – unter anderem AWS, Google und Cockroach Labs. Der Übertritt zur Linux Foundation macht diese Herstellerneutralität noch einmal deutlich.

KI-Agenten schnell und einfach

Das erste KI-Zeichen kommt von Solo.io, denn deren Projekt Agent Gateway ist nun ebenfalls unter der Obhut der Linux-Foundation. Die Software ist eine sogenannte Data-Plane für KI-Agenten beziehungsweise deren Plattform. Sie unterstützt unter anderem die bekannten Protokolle MCP (Model Context Protocol) und A2A (Agent2Agent). Neben Solo.io arbeiten hier auch Entwickler von AWS, Cisco, Huawei, IBM, Microsoft und Red Hat mit. Wiederum soll der Wechsel zur Linux Foundation die Herstellerneutralität unterstreichen. Apropos Agent, diese muss man ja eventuell erst einmal entwickeln. Diese Anfangshürde will das Projekt Strands Agents verkleinern. Das Versprechen lautet: KI-Agenten mit wenigen Code-Zeilen bauen. Strands Agent ist ein für Python geschriebener Baukasten samt Entwicklungsumgebung. Mit pip install strands-agents strands-agents-tools lässt sich diese installieren. Laut der Dokumentation genügen dann quasi vier Zeilen Python-Code, um einen sehr einfachen Agenten zu bauen.

So rechnet sich Open Source

Doch zurück zum Thema Open Source im Allgemeinen und auch durch eine europäische Brille. Laut einem Bericht der Linux Foundation finden 90 Prozent der befragten europäischen Firmen einen stabilen oder gar wachsenden Wert durch quelloffene Software. Als Argumente dienen bessere Software-Qualität, erhöhte Wettbewerbsfähigkeit durch Zusammenarbeit in Open-Source-Projekten und höhere Produktivität. Die größte Verbreitung kommt mit 64 Prozent aus der Kategorie Betriebssystem, gefolgt von Container-Technologie (55 Prozent) und Web- beziehungsweise Anwendungsentwicklung (54 Prozent). Da Open Source die Basis des modernen Internets ist, ist die quelloffene Software inzwischen ein fundamentaler und kritischer Baustein heutiger IT-Infrastruktur. Die zugehörigen Projekte benötigen Entwickler und Leiter, aber auch finanzielle Mittel.

Beispielhaft sei hier an das Dilemma rund um NTP und deren Lösung mit der Core Infrastructure Initiative (CII) der Linux Foundation erinnert. Dieser Ansatz skaliert aber nicht. Der natürliche Weg ist, dass die Hersteller, welche Open Source in eigenen Produkten verwenden, auch in die jeweiligen Projekte investieren. Diese Idee hat inzwischen Fahrt aufgenommen. Firmen beschäftigen Entwickler, die an strategisch wichtigen quelloffenen Projekten beteiligt sind. Oder sie zahlen in Fonds der Linux Foundation oder anderen Gremien ein. Hier gibt es nun auch den Begriff COSS (Commercial Open Source Software). Grob gesagt ist das ein Produkt oder eine Dienstleistung, die fundamental auf einem oder mehreren Software-Projekten beruht.

Die Linux Foundation hat jetzt einen Bericht zu COSS-Firmen veröffentlicht. Gehen diese an die Börsen, sind sie durchschnittlich siebenmal höher im Wert als die Pendants, welche nicht auf Open Source beruhen. Sind sie Teil einer Akquisition, dann beträgt der Faktor sogar 14. COSS-Firmen sind überwiegend (90 Prozent) im Bereich Infrastruktur aktiv. Von den an der Börse vertretenen COSS-Firmen stammen zu 65 Prozent aus den USA. Platz zwei belegt die EU mit 25 Prozent. Open Source ist also omnipräsent in der IT-Welt und hat einen anerkannten Wert – auch hart in Euros ausgedrückt.

(fo)

Willkommen zur dreizehnten Ausgabe der KI-Navigator-Kolumne der DOAG KI Community!

Generative KI-Tools helfen Einzelnen dabei, Texte zu schreiben, zu programmieren oder Bilder zu erstellen. Aber sie verändern auch, wie Teams zusammenarbeiten. Intelligente Agenten können künftig komplette Aufgabenbereiche in Teams übernehmen und Aufgaben nach Expertise zuweisen, die nächsten Arbeitsschritte aus Diskussionen ableiten oder Softwaretests generieren.

Das stellt bewährte Methoden des Projektmanagements und der Softwareentwicklung auf den Prüfstand. KI-basierte Systeme unterscheiden sich grundlegend von bisheriger Software: Statt klar definierter Regeln im Programmcode treffen probabilistische Modelle teils unsichere Vorhersagen. Das Regelwerk der Modelle kann sich über die Zeit verändern, wenn die ML-Verfahren neue Zusammenhänge in den Daten aufdecken.

Die Ergebnisse der Systeme sind heute schon teilweise besser als die von Menschen. So wird der Einsatz von KI in der Softwareentwicklung zum „Outsourcing Deluxe“. Eine Herausforderung dabei ist, dass KI-basierte Systeme komplex und teils mit unseren menschlichen Ansätzen nicht erklärbar sind.

All das hat Auswirkungen auf die Arbeitsweise in Teams. Sogar agile Arbeitsansätze wie Scrum geraten unter Druck – nicht, weil die Methoden überholt sind, sondern weil die Teams sie an die neuen Bedingungen anpassen müssen.

Um diese Veränderung besser zu verstehen, haben wir Experten aus dem Bereich Agilität und Data Science zusammengebracht und den Einfluss von KI auf Agilität erörtert. Die ersten Ergebnisse dieses Erfahrungsaustauschs zeigen wir in dieser Ausgabe der KI-Kolumne.

Passen KI und agile Methoden zusammen?

In den vergangenen Jahren galten agile Methoden als Wundermittel, um komplexe Probleme zu lösen und mit den rasanten Veränderungen am Markt bezüglich Kundenanforderungen und Technologie mithalten zu können. Methoden wie Scrum operationalisieren agile Prinzipien in der Teamarbeit und sollen Unternehmen befähigen, Veränderungen zu antizipieren und darauf zielgerichtet zu reagieren. Im weiteren Verlauf legt dieser Artikel den Fokus auf Scrum, genauer gesagt die agilen Events und Rollen innerhalb des Scrum-Frameworks.

In der Theorie scheint es, als würden agile Methoden und KI wunderbar zusammenwirken. Sowohl KI-Projekte als auch die agilen Methoden fordern ein hypothesengetriebenes, iterativ-inkrementelles Arbeiten und ermöglichen eine Fehlerkultur. Trotzdem oder gerade deshalb entbrannte im Rahmen unseres Workshops eine rege Diskussion zwischen den Agilisten und den stärker explorativ arbeitenden Data Scientists, die sich in zwei Richtungen entwickelte.

KI in agile Arbeitsweise integrieren

Die erste Richtung drehte sich um die Frage, wie KI dabei helfen kann, agile Produktentwicklung zu optimieren. In der Softwareentwicklung ist beispielsweise nicht jede Tätigkeit komplex, sondern viele Aktivitäten sind gut einschätzbar und planbar. Das führt in der Praxis dazu, dass Sprintziele oft mit konkreten Features oder Aufgaben gleichgesetzt werden und somit der Fokus häufig auf gesteigerter Effizienz liegt: mehr Software in weniger Zeit. Im Rahmen der KI-Navigator-Kolumne haben Semjon Mössinger und Bastian Weinlich fünf Stufen der KI-Nutzung in der Softwareentwicklung beschrieben. Für nahezu jede Aktivität in der Softwareentwicklung gibt es bereits Tools, um den Prozess (teilweise) zu automatisieren. Die folgende Tabelle nennt einige Beispiele von KI-Anwendungen im Softwareentwicklungsprozess.

Produkte mit KI-Anteil entwickeln

Die zweite Richtung der Diskussion drehte sich um die Frage, wie Teams agile Methoden verändern müssen, wenn sie datengetriebene, KI-basierte Systeme statt klassischer Software entwickeln. Diese Systeme verarbeiten große, oft unstrukturierte Datenmengen, deren Qualität entscheidend für die Leistungsfähigkeit der späteren Anwendung ist. Die Entwicklung ist von Hypothesen getrieben, die das Team testet und anpasst, und orientiert sich nur wenig an konkreten Anforderungen. Ergebnisse entstehen nicht linear, sondern durch Exploration und Experimentieren. Das Validieren der Ergebnisse ist besonders komplex, da ein KI-Modell oft nur als Ganzes sinnvoll testbar ist und isolierte Zwischenergebnisse wenig Aussagekraft besitzen. Zudem gilt es, KI-Anwendungen regelmäßig nachzutrainieren und an neue Daten anzupassen, um aktuell und leistungsfähig zu bleiben.

Agile Methoden wie Scrum setzen prinzipiell auf klar strukturierte Rhythmen: Sprintplanung, Review, Retrospektive. Sie verfolgen das Ziel, früh sichtbare Ergebnisse zu liefern, die sich iterativ verbessern lassen. In der Theorie passen agile Methoden somit gut zur Entwicklung von Produkten, die zumindest einen KI-Anteil haben. Insbesondere die schnellen Iterationen, das Fördern funktionsübergreifender Zusammenarbeit und die hohe Anpassungsfähigkeit an geänderte Anforderungen durch häufige Feedbackschleifen schaffen scheinbar ideale Voraussetzungen für die KI-Entwicklung. So können Teams flexibel auf neue Erkenntnisse reagieren und den Entwicklungsprozess kontinuierlich verbessern.

In der Praxis stoßen agile Implementierungen bei KI- und Data-Science-Projekten jedoch an ihre Grenzen. Data Scientists beklagen übermäßigen Aufwand durch die Pflege oder Definition von Issues oder fühlen sich gedrängt, am Ende des Sprints ein Zwischenergebnis der explorativen Arbeit zu zeigen. Auch Sprintziele lassen sich nur schwer als präzises Ergebnis definieren. Die Rolle des Product Owners verliert an Kontur, da ein kontinuierlicher Erkenntnisgewinn das Produkt deutlich verändert. Einige Teams improvisieren daher und können so ihre methodische Klarheit verlieren, was zu einem ineffektiven Methodeneinsatz führen kann.