Connect with us

Künstliche Intelligenz

Software ist ein Werkzeug, kein Selbstzweck: Plädoyer für mehr Fachlichkeit


close notice

This article is also available in
English.

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

Wir entwickeln Software nicht, weil es so schön ist. Wir entwickeln sie, um fachliche Probleme zu lösen. Diese Unterscheidung klingt banal, aber sie geht in der täglichen Arbeit vieler Teams verloren. Ich beobachte seit Jahren, wie Diskussionen in Entwicklungsteams ablaufen: Es geht um Frameworks, um Architekturstile, um die neueste Technologie. Es geht darum, ob man besser auf Microservices oder auf einen Modulithen setzt, ob man dieses oder jenes Tool verwendet, ob die Code-Coverage hoch genug ist. Worüber erstaunlich selten gesprochen wird: das fachliche Problem, das die Software eigentlich lösen soll.

Weiterlesen nach der Anzeige


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Das ist kein Zufall und keine Nachlässigkeit. Es ist ein strukturelles Problem unserer Branche. Wir haben uns so sehr an technische Debatten gewöhnt, dass wir gar nicht mehr merken, wie weit wir uns von der eigentlichen Aufgabe entfernt haben. Dieser Artikel ist ein Versuch, das sichtbar zu machen – und ein Plädoyer dafür, den Blick wieder auf das Wesentliche zu richten.

Warum reden wir lieber über Technologie als über Fachlichkeit? Die Antwort ist unbequem, aber nachvollziehbar: Technologie ist greifbar. Sie lässt sich vergleichen, messen, bewerten. Man kann Benchmarks lesen, Dokumentationen studieren, Tutorials durcharbeiten. All das passiert in einer Welt, die Entwicklerinnen und Entwickler kennen und kontrollieren.

Fachliche Probleme sind anders. Sie sind oft vage formuliert, widersprüchlich, und sie erfordern Gespräche mit Menschen, die eine andere Sprache sprechen – nicht im linguistischen Sinne, sondern im Sinne von Denkweisen und Prioritäten. Eine Fachexpertin interessiert sich nicht dafür, ob das System auf Kubernetes läuft. Sie will wissen, ob es ihre Arbeit erleichtert. Das sind verschiedene Welten, und die Brücke zwischen ihnen zu bauen, ist anstrengend.

Hinzu kommt ein strukturelles Problem: Die Branche belohnt technische Expertise stärker als Domänenwissen. Wer sich mit der neuesten Technologie auskennt, gilt als kompetent. Wer die Fachdomäne einer Versicherung oder eines Logistikunternehmens versteht, wird selten auf Konferenzen eingeladen. Das prägt, worauf Entwicklerinnen und Entwickler ihre Energie richten. Und so entstehen Teams, die technisch auf der Höhe der Zeit sind, aber nicht wirklich verstehen, welches Problem sie lösen.

Weiterlesen nach der Anzeige

Nirgends zeigt sich der Technologie-Tunnelblick deutlicher als in der Debatte um Architekturstile. Nehmen Sie die Diskussion um Microservices versus Monolith. In den 2010er-Jahren galt es fast als Naturgesetz, dass Microservices die bessere Wahl sind. Wer einen Monolithen baute, musste sich rechtfertigen. Wer Microservices einsetzte, galt als modern.

Aber was ist eigentlich die fachliche Begründung für Microservices? Im Kern geht es darum, Teile eines Systems unabhängig voneinander entwickeln, deployen und skalieren zu können. Das ist sinnvoll, wenn unterschiedliche Teams an verschiedenen Teilen arbeiten, wenn diese Teile unterschiedliche Lebenszyklen haben, wenn sie unterschiedlich stark genutzt werden. Es ist weniger sinnvoll, wenn ein kleines Team ein überschaubares System baut, bei dem alles zusammenhängt.

Trotzdem entscheiden sich Teams für Microservices, ohne diese Fragen zu stellen. Die Entscheidung fällt nicht auf Basis der Domäne, sondern auf Basis dessen, was gerade als Best Practice gilt. Das Ergebnis sind verteilte Systeme mit all ihrer Komplexität (Netzwerkkommunikation, Eventual-Consistency, Debugging über Servicegrenzen hinweg, …), ohne dass diese Komplexität durch einen fachlichen Nutzen gerechtfertigt wäre.

Die Architektur sollte aus der Domäne folgen, nicht umgekehrt. Wenn das fachliche Problem eine klare Trennung von Verantwortlichkeiten nahelegt, können Microservices die richtige Antwort sein. Wenn das Problem überschaubar ist und die Teile eng zusammenhängen, ist ein gut strukturierter Monolith oft die bessere Wahl. Aber diese Abwägung findet zu selten statt. Stattdessen wird der Architekturstil zur Glaubensfrage, losgelöst von der Realität des Problems.

Ähnlich verhält es sich mit Design-Prinzipien. DRY, SOLID, Clean-Code: Diese Begriffe kennt jede Entwicklerin und jeder Entwickler. Sie werden in Büchern gelehrt, in Code-Reviews eingefordert, in Vorstellungsgesprächen abgefragt. Aber sie werden oft so behandelt, als wären sie universelle Gesetze, die immer und überall gelten.

Nehmen Sie DRY (Don’t Repeat Yourself). Das Prinzip besagt, dass jede Information im System nur einmal repräsentiert sein sollte. Das klingt einleuchtend. Duplikation führt zu Inkonsistenzen, erschwert Änderungen, erhöht die Fehleranfälligkeit. Soweit die Theorie.

In der Praxis führt die dogmatische Anwendung von DRY oft zu einem anderen Problem: falschen Abstraktionen. Zwei Stellen im Code sehen ähnlich aus, also werden sie zusammengefasst. Aber allzu oft sehen sie nur zufällig ähnlich aus, fachlich haben sie nichts miteinander zu tun. Doch nun sind sie gekoppelt, und wenn sich eine Stelle ändern muss, muss die Abstraktion angepasst werden, die auch die andere Stelle betrifft. Die vermeintliche Vereinfachung wird zur Komplexitätsfalle.

Die Frage, ob Duplikation akzeptabel ist, lässt sich nicht ohne fachlichen Kontext beantworten. Wenn zwei Codestellen dasselbe fachliche Konzept repräsentieren, sollten sie zusammengeführt werden. Wenn sie verschiedene Konzepte repräsentieren, die nur zufällig gleich implementiert sind, sollten sie getrennt bleiben. Aber diese Unterscheidung erfordert ein Verständnis der Domäne – und genau das fehlt oft.

Dasselbe gilt für SOLID, für Clean-Code-Regeln, für jedes Prinzip. Sie sind Heuristiken, keine Gesetze. Ihr Nutzen hängt vom Kontext ab. Eine Klasse mit mehr als 200 Zeilen ist nicht automatisch schlecht. Eine Methode mit drei Parametern ist nicht automatisch besser als eine mit fünf. Es kommt darauf an, was die Klasse oder Methode tut, welches fachliche Konzept sie repräsentiert, wie sie verwendet wird. Wer Prinzipien ohne Kontext anwendet, optimiert für technische Metriken statt für fachliche Klarheit.

Apropos Metriken: Auch bei der Qualitätsmessung zeigt sich der Technologie-Tunnelblick. Test-Coverage ist das prominenteste Beispiel. Eine hohe Coverage gilt als Zeichen guter Qualität. Teams setzen sich Ziele: 80 Prozent, 90 Prozent, manchmal 100 Prozent. Tools visualisieren die Abdeckung, Dashboards zeigen Trends, Code-Reviews fordern Tests für jede neue Zeile.

Aber was misst Test-Coverage eigentlich? Sie misst, wie viel Code von Tests ausgeführt wird. Sie misst nicht, ob die richtigen Dinge getestet werden. Sie misst nicht, ob die Tests sinnvolle Szenarien abdecken. Und sie misst schon gar nicht, ob die Software das fachliche Problem löst.

Es ist möglich, 100 Prozent Coverage zu erreichen und trotzdem eine Software zu haben, die am Bedarf vorbeigeht. Die Tests prüfen, dass der Code macht, was er macht, aber niemand hat jemals geprüft, ob das, was er macht, auch das Richtige ist. Die Anforderungen waren missverstanden, die Domäne war nicht durchdrungen, die Gespräche mit den Fachexpertinnen und Fachexperten haben nicht stattgefunden. Der Code ist technisch einwandfrei und fachlich wertlos.

Ähnlich verhält es sich mit statischen Analysen, Linting-Regeln, Komplexitätsmetriken. Sie alle messen technische Eigenschaften des Codes. Sie können helfen, bestimmte Probleme zu vermeiden. Aber sie können nicht messen, was wirklich zählt: ob die Software das richtige Problem auf die richtige Weise löst. Wer sich auf diese Metriken verlässt, verwechselt technische Sauberkeit mit fachlicher Qualität.

Wie lässt sich der Fokus verschieben? Es gibt Ansätze, die dabei helfen können: Domain-Driven Design (DDD), Event-Storming, Domain-Storytelling & Co. Sie alle haben gemeinsam, dass sie die Fachlichkeit in den Mittelpunkt stellen. Sie fordern, dass Entwicklerinnen und Entwickler mit Fachexpertinnen und Fachexperten sprechen, dass der Code die Sprache der Domäne spricht, dass Architekturentscheidungen aus dem fachlichen Kontext abgeleitet werden.

Aber hier lauert eine Falle: Auch diese Ansätze können zum Selbstzweck werden. Ich habe kürzlich darüber geschrieben, wie Domain-Driven Design dieses Schicksal ereilt hat. Die Kernbeobachtung: DDD wurde akademisiert. Was als einfache Idee begann („verstehe die Domäne und sprich die Sprache des Business“) ist zu einem Katalog von Patterns geworden, über den Entwicklerinnen und Entwickler diskutieren, statt mit Fachexpertinnen und Fachexperten zu reden.

Das ist bezeichnend. Selbst ein Ansatz, der explizit den Fachfokus propagiert, wurde von uns als Branche in etwas Technisches verwandelt. Wir diskutieren, ob etwas ein Aggregat oder eine Entity ist, statt zu fragen, wie die Fachleute das Konzept nennen. Wir zeichnen Bounded-Context-Diagramme, statt die Grenzen aus der Domäne abzuleiten. Wir lernen die Patterns auswendig, statt die Domäne zu verstehen. Der Sog der Technologie ist so stark, dass er selbst Ansätze vereinnahmt, die gegen ihn gerichtet sind.

Die Lösung liegt nicht in neuen Methoden oder besseren Tools. Sie liegt in einer Haltungsänderung. Wir müssen akzeptieren, dass die schwierige Arbeit, also die Gespräche mit Fachexpertinnen und Fachexperten, das Ringen um Verständnis, das Aushalten von Unsicherheit, nicht durch Technik ersetzt werden kann. Wir müssen den Mut aufbringen, weniger über Frameworks zu reden und mehr über Probleme. Wir müssen uns eingestehen, dass technische Eleganz kein Wert an sich ist, wenn sie nicht im Dienst der Fachlichkeit steht.

Softwareentwicklung ist angewandte Problemlösung. Wir werden nicht dafür bezahlt, schönen Code zu schreiben. Wir werden dafür bezahlt, Probleme zu lösen. Das klingt banal, aber es hat weitreichende Konsequenzen.

Es bedeutet, dass die beste Architektur nicht die eleganteste ist, sondern die, die das fachliche Problem am besten adressiert. Es bedeutet, dass Prinzipien und Patterns Werkzeuge sind, keine Ziele. Es bedeutet, dass technische Schulden manchmal akzeptabel sind, wenn sie die schnellere Lösung eines dringenden fachlichen Problems ermöglichen. Es bedeutet, dass wir unseren Erfolg nicht an Coverage-Zahlen oder Clean-Code-Metriken messen sollten, sondern daran, ob die Software ihren Zweck erfüllt.

Das erfordert ein Umdenken. Es erfordert, dass wir unsere Komfortzone verlassen und uns auf das einlassen, was unbequem ist: die Kommunikation mit Menschen, die anders denken als wir. Es erfordert Demut, also die Einsicht, dass wir als Entwicklerinnen und Entwickler nicht die Expertinnen und Experten für die Domäne sind, auch wenn wir gerne so tun. Es erfordert Pragmatismus, also die Bereitschaft, technisch suboptimale Lösungen zu akzeptieren, wenn sie fachlich besser passen.

Ich plädiere nicht dafür, technische Qualität zu ignorieren. Guter Code ist wichtig. Saubere Architektur ist wichtig. Tests sind wichtig. Aber all das ist Mittel zum Zweck, nicht Selbstzweck. Wenn wir das vergessen, bauen wir technisch ausgefeilte Systeme, die niemand benötigt. Wir optimieren für Metriken, die nichts aussagen. Wir führen Debatten, die nichts bringen.

Die Frage, die wir uns in jedem Projekt, bei jeder Entscheidung stellen sollten, ist einfach: Hilft das, das fachliche Problem besser zu lösen? Wenn ja, machen wir weiter. Wenn nein, sollten wir innehalten und uns fragen, ob wir gerade der Technologie dienen oder der Fachlichkeit. Die Antwort darauf bestimmt, ob wir Softwareentwicklung als Handwerk betreiben oder als Selbstzweck.


(rme)



Source link

Künstliche Intelligenz

„Meilenstein“: Zoox mit dem bislang größten Expansionsschritt


Die Amazon-Tochter Zoox wird ihren Robotaxi-Service in San Francisco und Las Vegas ausbauen und die Tests seiner autonomen Fahrzeuge in Austin und Miami auf die nächste Stufe heben. Das kündigte das US-amerikanische Robotertaxi-Unternehmen am Dienstag an und spricht dabei selbst vom „bisher größten Meilenstein“. Die Entwicklungen seien die bisher wichtigste Serviceerweiterung und ein weiterer Schritt, um Zoox noch mehr Fahrgästen in den Vereinigten Staaten zugänglich zu machen.

Weiterlesen nach der Anzeige

„Dieses Jahr steht ganz im Zeichen des Wachstums. Wir setzen die gewonnenen Erkenntnisse aktiv um, um unseren Robotaxi-Service sicher und zuverlässig im ganzen Land zu skalieren und noch mehr Fahrgästen unser einzigartiges Erlebnis zu bieten“, erklärte Zoox-CEO Aicha Evans in einer Mitteilung. Nach eigenen Angaben ist Zoox das einzige Unternehmen „mit einem vollautonomen Fahrdienst in einem speziell dafür entwickelten Robotaxi“.

Zoox plant, sein Angebot in San Francisco deutlich auszubauen. Das Unternehmen hatte dort seinen autonomen Taxidienst im vergangenen Jahr gestartet und will nun seinen Service im Vergleich zum aktuellen Umfang vervierfachen. Ab dem Frühjahr sollen dabei dicht bewohnte und stark nachgefragte Stadtviertel wie Marina, North Beach, Chinatown und Pacific Heights als Zoox-Standorte hinzukommen.

Gleichzeitig will der Robotaxi-Anbieter in der Casino-Metropole Las Vegas expandieren und noch mehr Sehenswürdigkeiten und Veranstaltungsorte entlang des Strips abdecken. Die Anzahl der Zoox-Standorte sei mehr als verdoppelt worden; so seien das Las Vegas Convention Center sowie die meisten großen Hotels am Strip hinzugekommen. „Dank unserer Partnerschaften mit Sphere und der T-Mobile Arena bieten wir außerdem einen ersten, begrenzten Service für stark frequentierte Veranstaltungen an diesen Standorten an“, erklärte Zoox. In Las Vegas bietet Zoox seinen Robotaxi-Service seit vergangenem Herbst an.

In Austin und Miami wird das Unternehmen künftig seine eigens entwickelten autonomen Fahrzeuge aucgh auf öffentlichen Straßen einsetzen. „Wir testen unsere Technologie in diesen Märkten seit Mitte 2024 mit der umgerüsteten Zoox-Testflotte und freuen uns, die nächste Phase unserer Einführung zu erreichen“, so Zoox in der Pressemitteilung. Zunächst werden Fahrten in einem kleinen Gebiet beider Städte für Zoox-Mitarbeiter, deren Familien und Freunde angeboten, bevor die Einsatzgebiete im Laufe des Jahres schrittweise erweitert werden.

Nach Angaben von Zoox haben seine Fahrzeuge bereits fast zwei Millionen autonome Meilen zurückgelegt und mehr als 350.000 Fahrgäste befördert. Mehr als eine halbe Million Menschen hätten sich auf die Warteliste des Unternehmens eingetragen. Man erweitere die Service- und technischen Funktionen ständig, um kürzere Wartezeiten und ein besseres Fahrgefühl bieten zu können, so Zoox. Die Robotaxi-Testflotte des Unternehmens ist aktuell in zehn verschiedenen US-Märkten aktiv. Erst Anfang des Monats weitete die Amazon-Tochter ihre Tests auf Dallas und Phoenix aus. Hinzu kommen die bereits erwähnten Standorte San Francisco, Las Vegas, Austin und Miami, sowie Seattle, Los Angeles, Atlanta und Washington D.C.

Weiterlesen nach der Anzeige


(akn)



Source link

Weiterlesen

Künstliche Intelligenz

Rechtslage Deepfakes: Es ist kompliziert


Täuschend echt wirkende Filme und Bilder von Personen lassen sich mit Computertechnik immer einfacher erstellen. Die Leistungsfähigkeit allgemein verfügbarer KI-Modelle nimmt rasant zu, die Ergebnisse können sich inzwischen mit echten Filmproduktionen messen. Mit der leichten Verfügbarkeit auf Plattformen wie X nimmt auch der Missbrauch zu.

Weiterlesen nach der Anzeige

Bekannt sind etwa Betrugsversuche, bei denen die Täter KI-Werkzeuge einsetzen. Die sind wegen der Betrugsabsicht der Regel bereits strafbar. Weniger klar ist die Rechtslage bei Missbrauch von Bildern von Privatpersonen, sei es in Kombination mit KI-Elementen oder als reine KI-Produkte, sogenannten Deepfakes.

Die Debatte über eine mögliche Strafbarkeitslücke bei pornografischen Deepfakes ist in Deutschland neu entfacht, nachdem die Schauspielerin Collien Fernandes in der vergangenen Woche mit Vorwürfen gegen ihren Ex-Mann Christian Ulmen an die Öffentlichkeit gegangen ist.

Intensiv diskutiert wird dabei unter anderem die Frage, ob KI-Anbieter und Plattformbetreiber stärker in die Pflicht genommen werden müssen. Denn weder die deutsche noch die europäische Rechtslage bieten bislang einen wirksamen Schutz vor derartigen Taten – was jedoch nicht bedeutet, dass Täter nicht dennoch belangt werden könnten. Doch in der Praxis ist das offenbar kaum durchzusetzen.

Bislang sind die verschiedenen Regularien ein buntes Puzzle. Vor allem das Allgemeine Persönlichkeitsrecht steht bislang im Zentrum der rechtlichen Möglichkeiten. Doch der Anspruch auf Entfernung und anschließend Unterlassung weiterer Verbreitung ist in der Praxis gegenüber den Betreibern und Urhebern kaum durchzusetzen, wenn diese von außerhalb des europäischen Rechtsraumes agieren. Zudem ist derjenige, der eine Entfernung verlangt, in der Nachweispflicht.

Die meisten sexualisierten Deepfakes werden nicht unter Klarnamen veröffentlicht – hier eine Auskunft beim Anbieter zu erhalten, wer den Upload vorgenommen hat, scheitert in der Realität ebenfalls regelmäßig. Und auch andere Wege scheiden aus: Zwar kann etwa die Verwendung von urheberrechtlich geschützten Werken ein Rechtsverstoß sein oder auch die Entstellung eines Originalbildes. Doch realistisch sind Ansprüche auf dieser Grundlage kaum durchsetzbar.

Weiterlesen nach der Anzeige

Das Land Bayern hatte 2024 deshalb über den Bundesrat einen Regelungsvorschlag für einen neuen Paragrafen 201b im Strafgesetzbuch eingebracht: „Verletzung von Persönlichkeitsrechten durch digitale Fälschung.“ Systematisch würde der sich an den Regelungsgehalt des §201a anschließen, die mit Freiheits- oder Geldstrafe belegte „Verletzung des höchstpersönlichen Lebensbereichs und von Persönlichkeitsrechten durch Bildaufnahmen“. Genau hier will wohl auch das Bundesjustizministerium (BMJV) mit seinem erwarteten Vorschlag ansetzen.

Der bayrische Vorschlag von 2024 betraf das Zugänglichmachen „mit computertechnischen Mitteln hergestellter oder veränderter Medieninhalte“, wenn sie den Anschein von „wirklichkeitsgetreuen Bild- oder Tonaufnahmen“ erweckten. Diese Definition war sehr weit gefasst und dürfte in der nun anstehenden Formulierung des BMJV nicht wiederholt werden.

Ein Problem bliebe auch: Die Erstellung als solche wäre weiterhin nicht strafrechtlich bewehrt. Denn die Strafbarkeit würde erst aus der Verbreitung entstehen – etwa einem Versand per Messenger oder dem Upload auf Plattformen. Was jemand lokal auf seinem Endgerät etwa mit Fotos oder Videomaterial macht und dort abspeichert, wäre davon nicht umfasst.

Das will Bundesjustizministerin Stefanie Hubig (SPD) nun ändern. Die Straftat soll bereits mit der Erstellung sexualisierter Deepfakes begangen und somit verfolgbar werden. So stünden auch das Sich-Verschaffen und der Besitz von einschlägigem Material unter Strafe und nicht erst die aktive Verbreitung.

Würde ein neuer §201b StGB der Systematik des §201a folgen, wäre aber auch hier zu erwarten, dass es sich im Regelfall um ein sogenanntes Antragsdelikt handelt: Betroffene – in den meisten Fällen Frauen – müssten dann den Antrag auf Strafverfolgung stellen. Nur im Ausnahmefall wäre dann die eine Verfolgung aufgrund öffentlichen Interesses möglich. Dennoch setzt Hubig auf die abschreckende Wirkung der Strafbarkeit.

Allerdings muss bei einer strafrechtlichen Regelung zur Erstellung und Verbreitung von Deepfakes auch in Zukunft immer eine Abwägung stattfinden, ob ein Deepfake nicht doch zulässig ist. Während im Bereich der sexualisierten Darstellungen eine legale Nutzungsform selten der Fall sein dürfte, ist das etwa bei – mitunter auch geschmacklosen – Satirebeiträgen viel eher möglich. Und auch zur Medien-, Kunst- und Wissenschaftsfreiheit muss das Strafrecht fein abgrenzen, um unbeabsichtigte Kollateralschäden zumindest weitgehend auszuschließen.

Außen vor aus der innerdeutschen Gesetzgebung sind unterdessen die Anbieter selbst: Die Haftungsregularien für die Anbieter sind europarechtlich abschließend geregelt – vor allem der Digital Services Act (DSA) spielt hier eine Rolle. Allerdings würde eine Anpassung des Strafgesetzbuches auch hier die Anbieter vielleicht zu einem schnelleren Eingreifen verpflichten können: per Meldeweg gemeldete Straftaten müssen von den Anbietern geprüft werden.

Zudem könnten für die Beweissicherung etablierte Verfahren zwischen Anbietern und Strafverfolgern genutzt werden, was den Verfolgungsdruck auf Täter künftig erhöhen könnte. Doch auch dabei hängt viel von der Kooperationsbereitschaft der Plattformen ab. Ob die dann auch die Wiederveröffentlichung bereits beanstandeter Inhalte unterdrücken, ist kaum seriös vorhersagbar.

Nur ein Grund, warum Politiker und Aufsichtsbehörden in der EU fordern: Die Betreiber generativer KI-Modelle sollten bereits die Erstellung sexualisierter Inhalte von vornherein unterdrücken, wenn ihre Modelle hierfür genutzt werden könnten.


(vbr)



Source link

Weiterlesen

Künstliche Intelligenz

Mozilla cq: Stack Overflow für KI-Agenten


Mozilla AI hat mit cq ein Open-Source-Projekt vorgestellt, das als gemeinsame Wissensbasis für KI-Coding-Agenten dienen soll. Der Name leitet sich vom Dialog (colloquy) ab, genauer gesagt einem strukturierten Austausch von Ideen. Das erklärte Ziel: Agenten sollen nicht länger isoliert arbeiten und dabei wiederholt auf dieselben Fehler stoßen, sondern voneinander lernen können.

Weiterlesen nach der Anzeige

Wie Peter Wilson in einem Blogeintrag bei Mozilla erklärt, arbeiten KI-Agenten aktuell stets unabhängig voneinander. Trifft ein Agent auf ein unbekanntes Problem – etwa eine API mit unerwartetem Verhalten oder eine fehlerhafte CI/CD-Konfiguration –, muss er es eigenständig lösen: Code schreiben, Fehler auslösen, diagnostizieren, von vorn beginnen. Stößt ein anderer Agent auf dasselbe Problem, wiederholt sich der gesamte Prozess. Das kostet Token und Rechenleistung.

Verschärft wird die Situation laut Mozilla dadurch, dass die Trainingsdaten der Modelle veralten. Gleichzeitig sind Plattformen wie Stack Overflow, die einst als zentrale Wissensquelle dienten und deren Inhalte in die Trainingsdaten der Modelle einflossen, von einem massiven Nutzerschwund betroffen. Konkret verweist Mozilla auf einen Rückgang von über 200.000 Fragen pro Monat auf dem Höhepunkt 2014 auf unter 4.000 im Dezember 2025.

cq setzt auf einen dezentralen Wissensaustausch: Bevor ein Agent eine unbekannte Aufgabe angeht, fragt er die sogenannten „cq commons“ ab. Hat ein anderer Agent das Problem bereits gelöst, steht die Lösung sofort zur Verfügung. Lernt ein Agent etwas Neues, kann er dieses Wissen zurück in die Datenbank einspeisen. Andere Agenten bestätigen es durch praktische Nutzung oder markieren es als veraltet. Wissen soll so durch Anwendung Vertrauen aufbauen, nicht durch bloße Autorität.

Mozilla verweist in diesem Zusammenhang auf eine Vertrauenslücke: 84 Prozent der Entwickler nutzen demnach KI-Tools oder planen dies, doch 46 Prozent vertrauen der Genauigkeit der Ergebnisse nicht – ein Anstieg gegenüber 31 Prozent im Vorjahr. Wissen, das von mehreren Agenten in unterschiedlichen Codebasen bestätigt wurde, könne hier mehr Gewicht haben als die Einzelantwort eines Modells, so die Hoffnung von Mozilla.

Ein erster funktionsfähiger Prototyp von cq umfasst Plugins für die Coding-Agenten Claude Code und OpenCode. Hinzu kommen ein MCP-Server (Model Context Protocol) für den lokalen Wissensspeicher, eine Team-API zum Teilen innerhalb von Organisationen, eine Benutzeroberfläche für menschliche Überprüfung sowie Container zum Aufsetzen des Gesamtsystems. Die Entwicklung begann nach Angaben von Mozilla erst Anfang März, entsprechend handelt es sich offiziell um einen frühen Proof of Concept.

Weiterlesen nach der Anzeige

Technische Details zu cq finden sich auf der Projektseite auf GitHub.

Mozilla legt cq ausdrücklich als herstellerunabhängiges Projekt aus. Nicht jeder nutze dieselben Coding-Agenten, und Entwicklern sollte kein bestimmtes Werkzeug vorgeschrieben werden, heißt es im Blogbeitrag. Der bisherige Ansatz, Wissen in Markdown-Dateien innerhalb von Repositories abzulegen, stoße an Grenzen. Stattdessen brauche es ein dynamisches System, das Vertrauen über die Zeit aufbaue.

Peter Wilson verweist explizit darauf, dass sich die Idee mit einem jüngst veröffentlichten Beitrag von KI-Forscher Andrew Ng deckt. Er hatte ebenfalls ein „Stack Overflow für KI-Coding-Agenten“ angeregt. Entsprechend sieht Mozilla darin eine Bestätigung des eigenen Ansatzes und ruft die Entwickler-Community auf, sich an der Gestaltung von cq zu beteiligen.


(fo)



Source link

Weiterlesen

Beliebt