Die Unmöglichkeit eines verteilten Konsens war das Thema des dritten Teils dieser Serie. Eine andere Form von Unmöglichkeit zeigt sich beim Versuch, ein scheinbar einfaches Konzept messbar zu machen: die Qualität von Code. Anders als bei verteiltem Konsens scheitert dieser Versuch nicht an einem Beweis aus der theoretischen Informatik, sondern an etwas, das sich für die Praxis ebenso unverrückbar anfühlt.

Seit den 1970er-Jahren versucht die Branche, Codequalität zu quantifizieren: Lines of Code, zyklomatische Komplexität, Halstead-Metrik, Maintainability Index, Code Coverage. Jede neue Methodik bringt neue Zahlen mit, jedes IDE-Plug-in zeigt aktuelle Werte an, jede CI-Pipeline produziert Reports. Die Vorstellung dahinter ist verständlich: Wenn sich Codequalität messen lässt, lässt sich Codequalität systematisch verbessern. Wenn sich Codequalität verbessern lässt, lassen sich Wartungskosten senken, Bugs reduzieren und Entwicklungszeiten kürzer planen.

Trotzdem lässt sich allein anhand einer einzelnen Zahl nicht verlässlich sagen, ob ein konkretes Stück Code gut ist. Erfahrene Entwicklerinnen und Entwickler erkennen guten Code beim Lesen, und schlechten ebenso. Das ist keine Frage von Erfahrungswissen, das sich noch nicht in Zahlen fassen ließe, sondern hat strukturelle Gründe. Codequalität ist ein vielschichtiges Konstrukt, dessen wichtigste Dimensionen sich der Quantifizierung entziehen. Und wo Metriken doch existieren, machen sie Probleme, die im Mess- und Anreizsystem selbst angelegt sind.

Vom Sinn und Unsinn klassischer Metriken

Die wohl älteste Codemetrik ist die Anzahl der Programmzeilen, oft als LOC oder SLOC abgekürzt. Sie ist trivial zu erheben und auf den ersten Blick objektiv. Auf den zweiten Blick fragt sich, was sie eigentlich aussagt. Bill Gates wird das Zitat zugeschrieben, Programmierproduktivität in Codezeilen zu messen sei wie Fortschritt im Flugzeugbau am Gewicht zu messen. Die Pointe trifft den Kern: Mehr Codezeilen sind nicht besser, oft sogar schlechter. Eine Funktion in zwei Zeilen ist häufig wartbarer als die gleiche Funktion in zwanzig.

Die zyklomatische Komplexität wurde 1976 von Thomas McCabe eingeführt. Sie zählt die Anzahl unabhängiger Pfade durch eine Funktion und gibt damit ein Maß für die Verzweigungstiefe. Die Idee: Je mehr Pfade, desto mehr Testfälle nötig, desto schwerer der Code zu verstehen. Das ist nicht falsch, aber unvollständig. Eine switch-Anweisung mit zwanzig Fällen hat eine hohe zyklomatische Komplexität, ist aber oft trivial zu verstehen, weil alle Fälle ähnlich strukturiert sind. Eine Funktion mit drei tief geschachtelten if-Anweisungen hat eine niedrigere Komplexität, kann aber schwer durchschaubar sein.

Die Halstead-Metrik, 1977 von Maurice Halstead vorgeschlagen, geht einen anderen Weg. Sie zählt Operatoren und Operanden im Code und leitet daraus Maße für Programmlänge, Schwierigkeitsgrad und benötigten Aufwand ab. Auch hier liegt eine plausible Intuition zugrunde, doch die abgeleiteten Formeln wurden in zahlreichen Studien nur mit gemischtem Erfolg validiert.

Code Coverage misst schließlich nicht den Code selbst, sondern wie viel davon durch Tests ausgeführt wird. Sie ist die populärste Metrik in modernen Entwicklungsumgebungen, gerade weil sie sich automatisch erheben und in Pipelines durchsetzen lässt. Was sie aussagt, ist allerdings begrenzt. Eine Zeile, die einmal von einem Test durchlaufen wurde, gilt als abgedeckt, ganz gleich, ob dieser Test eine sinnvolle Aussage trifft oder nur eine Funktion aufruft, ohne ihre Ausgabe zu prüfen. 100 Prozent Code Coverage bedeuten nicht, dass 100 Prozent des Verhaltens geprüft sind.

Goodharts Gesetz

Diese Schwächen einzelner Metriken sind aber nur ein Teil des Problems. Das tieferliegende Problem hat 1975 der britische Wirtschaftswissenschaftler Charles Goodhart in einer Aussage über Geldpolitik formuliert, die längst weit über die Ökonomie hinaus gilt: Sobald eine Metrik zum Ziel wird, hört sie auf, ein guter Indikator zu sein. Diese Beobachtung ist heute als Goodharts Gesetz bekannt.

Die Mechanik dahinter ist einfach. Solange eine Metrik nur beobachtet wird, korreliert sie womöglich tatsächlich mit der Eigenschaft, die sie messen soll. Sobald aber Anreize an die Metrik gekoppelt werden, beginnen die Beteiligten, gezielt diese Metrik zu optimieren, und nicht die Eigenschaft, die sie eigentlich erfassen sollte. Die Korrelation bricht zusammen.

In der Softwareentwicklung lässt sich das Phänomen in zahlreichen Varianten beobachten. Wer Codezeilen als Produktivitätsmaß heranzieht, erntet aufgeblähten Code mit überflüssigen Hilfsfunktionen und gekünstelten Abstraktionen. Wer Code Coverage als verbindliches Ziel setzt, erntet Tests, die Funktionen aufrufen, ohne deren Ergebnisse zu prüfen. Wer die Anzahl gefundener Bugs als Produktivität von Testenden misst, erntet endlose Diskussionen darüber, was als Bug gilt. Wer geschlossene Tickets als Performance-Indikator verwendet, erntet zerlegte Tickets, die einzeln keinen Wert haben.

Das ist kein Versagen einzelner Beteiligter, sondern eine logische Konsequenz aus dem Anreizsystem. Menschen optimieren das, woran sie gemessen werden. Wenn die Messung nicht das Gleiche misst wie das Ziel, optimieren sie an der eigentlichen Aufgabe vorbei. Goodharts Gesetz ist nicht spezifisch für Software, aber besonders sichtbar in einer Disziplin, in der sich so vieles automatisch erfassen und in Dashboards anzeigen lässt.

Was Weyuker formal gezeigt hat

Auch jenseits des Anreizproblems gibt es einen formaleren Grund, warum die Suche nach der einen Codemetrik scheitern muss. Die Informatikerin Elaine Weyuker formulierte 1988 in einem einflussreichen Aufsatz neun Eigenschaften, die eine sinnvolle Komplexitätsmetrik erfüllen sollte. Diese Eigenschaften sind nicht willkürlich gewählt, sondern geben intuitiven Erwartungen eine formale Form. Wenn ein Programm intuitiv komplexer ist als ein anderes, sollte die Metrik das widerspiegeln. Wenn zwei Programme zu einem zusammengesetzt werden, sollte die Komplexität nicht kleiner werden als die Komplexität jedes einzelnen Bestandteils. Die Reihenfolge der Anweisungen sollte sich auf die Metrik auswirken, weil sie sich auf das Verhalten des Programms auswirkt.

Das Ergebnis von Weyukers Untersuchung war ernüchternd. Keine der zu diesem Zeitpunkt etablierten Metriken erfüllte alle neun Eigenschaften. Lines of Code versagt bereits bei einfachen Anforderungen, weil identische Programme als unterschiedlich eingeordnet werden, sobald die Formatierung variiert. Zyklomatische Komplexität versagt bei der Zusammensetzung, weil zwei sequenziell ausgeführte Funktionen mit jeweils Komplexität fünf zusammen nur eine Komplexität von neun ergeben, nicht von zehn oder mehr. Die Halstead-Metrik versagt bei der Reihenfolge, weil eine Permutation der Anweisungen sie nicht ändert, obwohl das Verhalten ein völlig anderes sein kann.

Spätere Arbeiten haben einzelne Metriken entwickelt, die mehr von Weyukers Eigenschaften erfüllen, aber keine Metrik, die alle erfüllt. Das ist kein Zufall, sondern ein formales Indiz, dass die Suche nach der einen Komplexitätszahl strukturell scheitert. Komplexität ist nicht eindimensional. Verschiedene Aspekte wie Verzweigungstiefe, Datenflusskomplexität, Schnittstellenkomplexität und kognitive Last können nicht alle gleichzeitig in einer einzigen Zahl repräsentiert werden, ohne wesentliche Informationen zu verlieren.

Die multidimensionale Natur von Qualität

Selbst wenn es eine perfekte Komplexitätsmetrik gäbe, wäre damit das Problem der Codequalität nicht gelöst. Codequalität ist nicht gleich Komplexität, und sie ist auch nicht gleich Korrektheit oder Wartbarkeit oder Performance. Sie ist ein Bündel mehrerer Eigenschaften, die teilweise miteinander in Spannung stehen.

Korrektheit bedeutet, dass der Code macht, was er machen soll. Lesbarkeit, dass andere ihn verstehen können. Wartbarkeit, dass er sich verändern lässt, ohne Schaden anzurichten oder Fehler einzubauen. Performance, dass er die nötige Geschwindigkeit erreicht. Sicherheit, dass er sich nicht missbrauchen lässt. Erweiterbarkeit, dass sich neue Funktionen ergänzen lassen. Testbarkeit, dass sich sein Verhalten nachvollziehen lässt. Diese Dimensionen sind nicht orthogonal. Höhere Performance kann Lesbarkeit kosten, weil hochoptimierter Code oft kryptischer ist. Höhere Sicherheit kann Erweiterbarkeit kosten, weil restriktive Schnittstellen weniger Spielraum lassen. Höhere Testbarkeit kann Performance kosten, weil testbarer Code oft mehr Indirektion enthält.

Eine einzelne Metrik kann notwendigerweise nur eine dieser Dimensionen erfassen, oder sie kann mehrere aggregieren und verliert dabei die Information, welche Dimension wie stark beiträgt. Ein Maintainability Index, der aus zyklomatischer Komplexität, Halstead-Metrik und Kommentaranteil berechnet wird, gibt am Ende eine Zahl zwischen null und hundert aus. Diese Zahl mag als Indikator für grobe Trends nützlich sein, aber sie sagt nicht, ob der Code im konkreten Fall gut ist, und schon gar nicht, woran es liegt, wenn er es nicht ist.

Was keine Metrik je erfassen wird

Den vielleicht wichtigsten Aspekt von Codequalität verfehlen die etablierten Metriken aus einem Grund, der oft übersehen wird. Sie konzentrieren sich auf strukturelle Eigenschaften des Codes wie Verzweigungen, Operatoren und Pfade und ignorieren etwas, das für die Verständlichkeit zentral ist: die Namensgebung der Bezeichner.

Zwei Funktionen können bezüglich aller etablierten Metriken identisch sein, in zyklomatischer Komplexität, Halstead-Metrik und Codezeilen. Trotzdem kann die eine deutlich besser verständlich sein als die andere. Eine Funktion berechne(a, b, c) mit den Variablen x, y und z im Rumpf gibt keinen Hinweis darauf, was sie eigentlich macht. Dieselbe Funktion als berechneRechnungssumme(bruttopreis, menge, rabatt) mit den entsprechenden Bezeichnern im Rumpf erschließt sich beim Lesen sofort. Die Struktur des Codes ist identisch, die Verständlichkeit grundlegend verschieden.

Sprechende Namen aus der Fachdomäne machen Code zu einer Form von Dokumentation, die mit dem Code selbst lebt und nicht veraltet. Sie verbinden den Code mit dem Problem, das er löst, und nicht nur mit der Maschine, auf der er läuft. Donald Knuth hat diese Sicht mit dem Begriff des Literate Programming auf die Spitze getrieben. Er versteht Programme als ausführbare Texte, die für Menschen geschrieben sind, und für die Maschine nur sekundär. Eric Evans hat mit Domain-Driven Design einen ähnlichen Anspruch in den industriellen Mainstream gebracht, mit dem Konzept der ubiquitären Sprache: Begriffe aus der Fachdomäne ziehen sich konsistent durch alle Schichten der Software, von Anforderungen über Code bis zu Datenbankschemata.

Diese Aspekte, die Aussagekraft der Namen, die Übereinstimmung mit der Domäne, die Klarheit der Abstraktionen, entziehen sich jeder mechanischen Messung. Eine Metrik, die feststellen würde, ob ein Variablenname „aussagekräftig“ ist, müsste verstehen, wovon der Code handelt, was die Domäne ist und welche Begriffe in dieser Domäne etabliert sind. Sie müsste, kurz gesagt, den Code nicht nur strukturell analysieren, sondern semantisch deuten. Genau dieser Schritt ist von keiner heute existierenden statischen Analyse zu leisten. Auch große Sprachmodelle, die Code zumindest oberflächlich beurteilen können, liefern keine Metriken im engeren Sinne, sondern subjektive Einschätzungen, die sich nicht zuverlässig automatisieren lassen.

Pragmatischer Umgang mit Metriken

Die Konsequenz aus all dem ist nicht, Metriken abzuschaffen. Sie können nützliche Indikatoren sein, solange sie als Hinweise verstanden werden und nicht als Ziele. Eine plötzlich steigende zyklomatische Komplexität in einem Modul kann ein sinnvolles Warnsignal sein. Ein Trend zu fallender Code Coverage kann Anlass für eine Diskussion sein. Eine Funktion mit auffällig vielen Zeilen kann ein Kandidat für ein Refactoring sein.

Was sich aus Goodharts Gesetz und der multidimensionalen Natur von Qualität ergibt, ist ein anderer Umgang mit diesen Werten. Mehrere komplementäre Metriken statt einer einzelnen, weil keine einzelne Metrik die Qualität abdeckt. Trends statt absoluter Werte, weil ein Wert allein wenig aussagt, eine Veränderung aber durchaus. Indikatoren statt Ziele, weil das Koppeln von Anreizen die Aussagekraft zerstört.

Die unersetzliche Rolle bleibt das menschliche Urteil. Code-Reviews sind in fast allen ernsthaften Entwicklungsteams etabliert, nicht aus Tradition, sondern weil sie genau das erfassen, was Metriken nicht abbilden: ob der Code für andere Menschen verständlich ist. Erfahrene Entwicklerinnen und Entwickler bringen ein implizites Qualitätsverständnis mit, das sich nicht in Regeln erschöpft, aber bei der Lektüre eines Pull Requests sofort wirksam wird. Ein gutes Code-Review findet die Probleme, die keine statische Analyse je erkennen würde, nicht weil Werkzeuge nicht genutzt werden, sondern weil Reviewerinnen und Reviewer verstehen, was der Code zu sagen versucht.

Was sich messen lässt, und was nicht

Codequalität entzieht sich der einen Zahl, nicht weil bessere Metriken noch nicht erfunden wurden, sondern weil sie ein vielschichtiges Konstrukt ist, dessen wichtigste Dimensionen sich der Quantifizierung prinzipiell entziehen. Was sich messen lässt, also Zeilen, Pfade, Operatoren, Coverage, sagt etwas über die Struktur des Codes, aber wenig über seine Qualität. Was die Qualität ausmacht, also Klarheit der Absichten, Übereinstimmung mit der Domäne, Aussagekraft der Namen, Angemessenheit der Abstraktionen, lässt sich nicht in Zahlen pressen.

Wer trotzdem versucht, Codequalität auf eine einzelne Zahl zu reduzieren, erreicht meist das Gegenteil des angestrebten Ziels. Goodharts Gesetz wirkt zuverlässig, und Teams, die nach Metriken gesteuert werden, optimieren irgendwann die Metriken statt die Qualität. Wer die Codequalität wirklich verbessern will, kommt um menschliches Urteil nicht herum, ergänzt durch Metriken als Indikatoren, aber nicht ersetzt durch sie.

Eine besonders verführerische Metrik in dieser Reihe ist die Code Coverage. Sie suggeriert, dass mehr abgedeckte Zeilen besser getesteten Code bedeuten, und sie ist in modernen Entwicklungsumgebungen so leicht zu erheben, dass sie schnell zur zentralen Steuerungsgröße wird. Im nächsten Teil dieser Serie zeigt sich, warum auch das Testen selbst an fundamentale Grenzen stößt, mit dem Halteproblem als altem Bekannten in einer neuen Rolle.

(mro)

Der Kubernetes-Spezialist Giant Swarm hat eine Plattform vorgestellt, die KI-Agenten nicht als IDE-Erweiterung, sondern als eigenständige, orchestrierte Workloads innerhalb der eigenen Kubernetes-Infrastruktur betreibt. Das Unternehmen positioniert seine Agent Platform als souverän, kuratiert und auditierbar – KI-Agenten sollen dort laufen, wo die Daten liegen, statt auf „fremden“ Servern.

Im Kern behandelt die Plattform von Giant Swarm Agenten wie jede andere Workload und sie läuft nach Angaben des Unternehmens innerhalb der eigenen Umgebung auf beliebigen Kubernetes-Clustern – in der Cloud, im eigenen Rechenzentrum, am Edge oder sogar in abgeschotteten, air-gapped Netzen. Einen proprietären Kern oder ein SaaS, das mit den Daten „nach Hause telefoniert“, gebe es nicht.

Wie Giant-Swarm-CEO Henning Lange im Blog ausführt, betreibe der Dienstleister seine eigene Flotte von Agenten bereits seit Mitte 2025 auf derselben Plattform-Infrastruktur, unter anderem für Code-Reviews, Incident-Triage und zum Abarbeiten von Backlogs. Die Agent Platform soll ab sofort nun auch anderen Unternehmen offenstehen. Zunächst lädt Giant Swarm ausgewählte Partner und Kunden ein, die Plattform zu testen, der allgemeine Roll-out soll aber noch im Laufe dieses Jahres folgen.

Das neue Angebot soll nicht nur den kuratierten Einsatz von KI-Agenten in produktiven Umgebungen ermöglichen, sondern Unternehmen auch dabei unterstützen, das wachsende Problem von Schatten-KI in den Griff zu bekommen. Eine IDC-Erhebung aus dem vergangenen Jahr habe beispielsweise gezeigt, dass rund 56 Prozent der Beschäftigten KI-Tools nutzten, die ihre Organisation gar nicht bereitgestellt hatte; nur 23 Prozent verwendeten die firmeneigenen Werkzeuge. IBM habe zudem festgestellt, dass jede fünfte Organisation über solche Schatten-KI kompromittiert worden sei, mit im Schnitt 670.000 US-Dollar höheren Kosten pro Vorfall.

Von Agentenläufen zu deterministischen Workflows

Technisch arbeitet die Plattform mit einem Workflow-Engine-Ansatz: Wiederkehrende Muster aus Agentenläufen überführt sie in deterministische MCP-Workflows. Im eigenen Betrieb habe Giant Swarm damit unter anderem die Kosten pro Agentenlauf um den Faktor 2,8 senken können und verzeichne 17-mal weniger Tool Calls. Im Schnitt liefen bei dem Unternehmen rund 500 Agenten parallel. Die eigene Engineering-Organisation profitiere von einem deutlich erhöhten Output. So sei die Zahl der Pull Requests pro Monat im Frühjahr 2026 um mehr als 300 Prozent gegenüber dem Vorjahr gestiegen – bei unveränderter Mitarbeiterzahl.

Die Agenten-Plattform folge den drei Leitprinzipien souverän, kuratiert und Enterprise-ready. Ersteres steht für den Einsatz von Open Source, austauschbare Modelle, Tools und Harnesses sowie volle Datenkontrolle. Kuratiert beschreibe das Versprechen, dass Giant Swarm kontinuierlich den schnell wechselnden Agentenmarkt beobachtet und passende Bausteine zentral integriert. Als Enterprise-ready gilt die Plattform, weil sie von Anfang an mandantenfähigen, sicheren und auditierbaren Betrieb ermögliche.

Die Architektur baut auf der langjährigen Kubernetes-Praxis des Anbieters auf, Giant Swarm betreut seit 2014 Kubernetes-Umgebungen für Kunden. Die Plattform ist cloud-agnostisch und unterstützt AWS, Azure sowie VMware im eigenen Rechenzentrum, auch in hybriden Kombinationen. Als Basis für das Cluster-Lifecycle-Management dient die Cluster API. GitOps behandelt Giant Swarm als First-Class Citizen und nutzt dafür den Flux Operator, damit Änderungen versioniert, nachvollziehbar und reversibel bleiben. Als Developer Portal kommt Backstage zum Einsatz, die Observability stützt sich auf den Grafana-LGTM-Stack mit zentraler Ablage von Metriken, Logs und Traces. Single Sign-on lässt sich mit externen Identitätsanbietern wie Google Workspace oder Microsoft Entra ID koppeln, die Zugriffe steuert Kubernetes RBAC fein granular, ergänzt um Network Policies. Als Referenzkunden nennt Giant Swarm unter anderem Adidas, Vodafone, die Deutsche Telekom und die Börse Stuttgart.

Teil eines größeren Trends

Der Vorstoß fügt sich in eine Entwicklung, die weg von einzelnen Coding-Assistenten und hin zur Orchestrierung ganzer Agentenflotten führt. Das Framework Gas Town, das Steve Yegge im Dezember 2025 entwickelte und Anfang Januar 2026 vorstellte, verfolgt ein verwandtes Ziel: Es orchestriert viele Coding-Agenten nach Kubernetes-Vorbild parallel und kompensiert deren Fehler über eine Orchestrierungsschicht, statt einzelne Agenten zu verbessern.

Dass ein Sprachmodell nicht von allein zum Agenten wird, beschreibt auch das Konzept des Agent Harness: Erst konkrete Software rund um das Modell führt Umgebung, Werkzeuge, Regeln und den Agent Loop zusammen. Giant Swarms Plattform lässt sich als plattformseitige Umsetzung genau dieser Idee lesen – mit dem Zusatzargument, dass die Daten die eigene Umgebung nicht verlassen. Für Unternehmen mit strengen Datenschutz- und Compliance-Anforderungen dürfte gerade der Betrieb On-Premises, Air-gapped oder hybrid das relevante Verkaufsargument sein.

(map)

Die Übernahme des Entwickler-Tools Cursor durch SpaceXAI (ehemals xAI) und die damit einhergehende enge Zusammenarbeit tragen erste Früchte: Mit Grok 4.5 wurde ein neues Flaggschiff-KI-Modell vorgestellt, das besonders in den Bereichen Coding, agentische Aufgaben und Wissensarbeit punkten soll. Zugleich positioniert es sich preislich im günstigen Bereich der Flaggschiff-Modelle. EU-Nutzer müssen sich allerdings noch in Geduld üben. Vermutlich aufgrund der gesetzlichen Anforderungen verschiebt sich die Freigabe für den EU-Raum auf voraussichtlich Mitte Juli, wie SpaceXAI mitteilt.

Grok 4.5 wurde nach Herstellerangaben auf zehntausenden Nvidia-GB300-GPUs trainiert, mit besonderem Fokus auf Datenfilterung, Deduplizierung und Qualitätsbewertung. Im Training wurde es vor allem auf mehrstufige Software-Engineering-Aufgaben mit automatisierter und modellbasierter Bewertung vorbereitet. Das Modell läuft mit rund 80 Tokens pro Sekunde – vergleichbar mit „Flash“-Modellen anderer Anbieter – und soll gegenüber führenden Modellen die doppelte Token-Effizienz bei gleichen Aufgaben bieten.

Deutlich günstiger als andere Topmodelle

Grok 4.5 soll nicht nur schwierige und langlaufende Aufgaben übernehmen können, sondern auch breiter aufgestellt sein, etwa für Arbeiten im juristischen Bereich oder im Finanzsektor. Zudem sollen die Fähigkeiten in der Cybersecurity weiterentwickelt worden sein. Letztgenanntes könnte dem Wunsch der US-Regierung entgegenkommen, die zuletzt die neuen KI-Topmodelle von OpenAI und Anthropic wegen Sicherheitsbedenken ausgebremst hatte.

In Benchmarks positioniert sich das neue Modell zumeist hinter Fable von Anthropic, schneidet in einigen Bereichen aber besser ab als die Top-Modelle Opus 4.8 (Anthropic) und GPT-5.5 (OpenAI). Mit 2 US-Dollar pro Million Input-Tokens und 6 US-Dollar pro Million Output-Tokens ist es vor allem aber deutlich günstiger bei ähnlich hohem Leistungsvermögen: Es liegt deutlich unter GPT-5.5 (5 $/30 $) und unter Claude Opus 4.8 (5 $/25 $).

Kostenlose Testphase

Das Modell ist ab sofort in Grok Build (ehemals Grok CLI), in Cursor (in allen Abos) sowie über die xAI-API-Konsole verfügbar. Für Grok Build und Cursor gibt es zeitlich begrenzt kostenlosen Zugang.

SpaceXAI und Cursor hatten vor einigen Wochen bekannt gegeben, dass SpaceXAI den Hersteller des beliebten Entwickler-Tools für 60 Milliarden US-Dollar übernimmt.

(mki)