Kategorie: Erklärer

In einem Unternehmen arbeiten mehrere KI-Agenten: einer hilft bei der Einstellung, ein anderer bearbeitet Gehaltsabrechnungen, ein dritter prüft Reisekosten. Jeder hat Zugriff auf sensible Daten. Sicherheitsverantwortliche können nicht überprüfen, ob diese Agenten sicher sind. Workday adressiert dieses Problem mit Agent Passport.

Agenten führen echte Geschäftsprozesse aus. Sie verarbeiten Bezüge, genehmigen Urlaubsanträge oder ändern Stammdaten. Ein unsicherer Agent kann Daten preisgeben, Compliance-Regeln verletzen oder für negative Schlagzeilen sorgen. Workday will mit Agent Passport einen Sicherheitsstandard für alle KI-Agenten schaffen – unabhängig vom Anbieter.

Was ist Agent Passport?

Agent Passport testet jeden KI-Agenten vor dem Einsatz in der Produktion und überwacht ihn kontinuierlich. Die Tests folgen öffentlichen Standards wie OWASP LLM Top 10, NIST AI RMF und MITRE ATLAS. Das Ergebnis ist ein signierter, prüfbarer Bericht. Er dokumentiert, welche Sicherheitsaspekte getestet wurden und wer den Test durchgeführt hat. So entsteht ein Nachweis – vergleichbar mit einem digitalen Reisepass.

Jeder Agent bekommt einen eigenen Pass, der drei Ebenen umfasst. Die erste Ebene definiert Vertrauensbereiche, die Workday vorgibt und regelmäßig aktualisiert: Schutz vor Angriffen, sicheres Verhalten zur Laufzeit und menschliche Aufsicht. Die zweite Ebene enthält konkrete, prüfbare Behauptungen, die an öffentliche Standards gebunden sind – etwa Resistenz gegen Prompt Injection. Die dritte Ebene besteht aus signierten Testergebnissen eines unabhängigen Partners. Workday startet mit Cisco als erstem Attestor.

Warum Unabhängigkeit entscheidend ist

Viele Plattformen testen ihre eigenen Agenten. Das ist ein Interessenkonflikt. Ein Sicherheitslabel vom selben Anbieter ist wenig aussagekräftig. Workday setzt auf offene Standards und unabhängige Partner. Cisco bringt Cisco AI Defense mit. Es bestätigt, dass ein Agent resistent gegen Befehls-Manipulation ist, keine sensiblen Daten preisgibt und schädliche Aktionen blockiert. Das ist wichtig bei Agenten, die auf Gehaltsdaten, Sozialleistungen oder Finanzinformationen zugreifen.

Durch die Bindung an öffentliche Standards können Sicherheitsteams Agenten verschiedener Anbieter auf derselben Grundlage vergleichen. Haben zwei Agenten denselben Prüfpunkt von verschiedenen Partnern bestanden, wissen Unternehmen, dass sie gegen denselben Maßstab getestet wurden. Das schafft Transparenz und Vergleichbarkeit.

Laufzeitüberwachung und sofortige Reaktion

Ein einmaliger Test reicht nicht. Agenten können sich durch Updates oder Angriffe verändern. Agent Passport überwacht jeden Agenten kontinuierlich. Versucht ein Agent eine Aktion, wird in Echtzeit entschieden: zugelassen, blockiert oder umgeleitet. Ein Widerruf kann alle betroffenen Agenten automatisch stoppen oder umkonfigurieren. Das gibt Sicherheitsteams Kontrolle.

Die Tests decken die heute relevantesten Angriffe auf Large Language Models ab: Prompt Injection, Jailbreak, Goal Hijacking, System Prompt Extraction, Leaks von Mitarbeiterdaten und unsichere Antworten. Jeder Test ist mit einer öffentlichen Standard-ID verknüpft.

Verfügbarkeit und Ausblick

Agent Passport wird voraussichtlich in der zweiten Jahreshälfte 2026 für erste Kunden verfügbar sein. Die allgemeine Verfügbarkeit ist für Ende 2026 geplant. Die Partnerschaft zwischen Workday und Cisco ist aktiv, die gemeinsamen Fähigkeiten werden in den kommenden Quartalen ausgerollt. Workday stellt klar: Entwickler können über Workday Build eigene Agenten bauen und durch Agent Passport prüfen lassen.

Agent Passport ist ein Schritt, um KI-Agenten sicher im Unternehmen einzusetzen. Es schafft Transparenz und gibt Sicherheitsteams ein Werkzeug, um die vielen Agenten zu kontrollieren. Ob sich der Ansatz als Standard etabliert, hängt von der Übernahme durch Anbieter und Kunden ab. Für Unternehmen, die Workday nutzen, bietet es mehr Kontrolle über ihre KI-Assistenten. Das ist in einer Zeit zunehmender Automatisierung ein Gewinn.

Quelle: newsroom.workday.com

Es ist drei Uhr morgens. Dein Dienst zeigt erhöhte Fehlerraten, du wirst per Pager geweckt. Liegt es an meinem Service? Hängt ein Problem bei einem anderen Dienst damit zusammen? Welche Teams muss ich alarmieren? Diese Situation beschreiben die Entwickler von Netflix in einem aktuellen Blogbeitrag. Sie nennen es das „3-Uhr-morgens-Problem“. Ihre Lösung: eine Echtzeit-Service-Topologie-Karte, die alle Abhängigkeiten zwischen den tausenden Microservices visualisiert.

Das Puzzle mit tausend Teilen

Netflix betreibt eine massive, verteilte Architektur mit tausenden Microservices. Jeder Dienst erfüllt eine bestimmte Aufgabe – von der Authentifizierung über die Personalisierung bis zur Streaming-Optimierung. Wenn ein Nutzer auf „Play“ drückt, löst das eine Kaskade von Service-to-Service-Aufrufen aus. Diese Abhängigkeiten sind oft nur den Entwicklern im Kopf bekannt oder in veralteten Architekturdiagrammen festgehalten. In einer Umgebung, in der mehrmals täglich neue Versionen ausgerollt werden, ändern sich diese Abhängigkeiten ständig.

Die Ingenieure bei Netflix stellten fest, dass ein zentrales Werkzeug fehlt, um diese Verbindungen in Echtzeit zu verstehen. Herkömmliche Observability-Tools liefern Metriken, Logs und Traces – jedes zeigt nur einen Ausschnitt. Eine Metrik sagt dir, dass ein Dienst langsam ist, aber nicht, welche anderen Dienste er aufruft. Ein Trace zeigt den Pfad einer einzelnen Anfrage, aber nicht das gesamte Abhängigkeitsnetzwerk. Entwickler mussten bisher aus mehreren Quellen mühsam ein Gesamtbild zusammensetzen – in einer Stresssituation um drei Uhr morgens ist das fehleranfällig und zeitraubend.

Die Autoren des Blogbeitrags – Parth Jain, Rakesh Sukumar, Yingwu Zhao, Renzo Sanchez und Nathan Fisher – analysierten über vier Jahre Supportanfragen von Ingenieuren. Immer wieder tauchten dieselben drei Fragen auf: „Welche Dienste hängen von mir ab?“, „Was ist der Blast Radius, wenn ich meinen Dienst runterfahre?“, „Kommt der Fehler von einem vorgelagerten Dienst oder von mir selbst?“. Diese Fragen sind fundamental für das Troubleshooting in verteilten Systemen. Netflix wollte Antworten geben – schnell, genau und in Echtzeit.

Die Anforderungen an eine lebende Karte

Bevor sie mit dem Bau begannen, definierten die Entwickler klare Anforderungen. Erstens: Die Karte muss in Echtzeit aktualisiert werden. Ein Topologie-Plan, der einige Stunden alt ist, nützt nichts, wenn Services mehrmals täglich deployen. Zweitens: Die Abfragen müssen extrem schnell sein – unter einer Sekunde. Wenn ein Ingenieur um drei Uhr morgens nach Abhängigkeiten sucht, darf die Antwort keine Minute dauern. Drittens: Die Karte muss mehrere Perspektiven abdecken. Netzwerkverbindungen allein sagen nicht, welche APIs genau aufgerufen werden. Es braucht die Netzwerkebene, die Anwendungsebene und die Ebene der tatsächlichen Anfragepfade.

Viertens: Die Daten müssen angereichert sein. Es reicht nicht zu wissen, dass Service A mit Service B spricht. Man muss auch den Health-Status, die Verfügbarkeitsstufe, die Geschäftsdomäne und das verantwortliche Team sehen. Fünftens: Die Karte muss visuell und programmatisch zugänglich sein. Entwickler brauchen eine grafische Oberfläche zur Erkundung, aber auch Automatisierungssysteme wie Blast-Radius-Rechner oder Incident-Response-Tools müssen per API darauf zugreifen können.

Aus früheren Experimenten hatten die Entwickler gelernt: Keine einzige Datenquelle liefert ein vollständiges Bild. Netzwerkdaten zeigen alle Verbindungen, aber ohne Anwendungskontext. Anwendungsmetriken geben Details zu Endpunkten, aber nur für instrumentierte Dienste. Traces zeigen reale Anfragepfade, aber unterliegen Sampling. Die Lösung: drei unabhängige Quellen kombinieren.

Drei Datenquellen, drei Graphen, einheitliche Sicht

Die Netflix-Ingenieure entschieden sich für einen Multi-Layer-Ansatz. Sie bauten drei separate Graphen – einen für jede Perspektive – die physikalisch getrennt gespeichert werden. Jeder Graph lebt in einem eigenen Datenspeicher: der Netzwerk-Graph in einer Graphdatenbank-Partition, der IPC-Graph in einer weiteren Partition und der Tracing-Graph in einem columnar Storage für analytische Abfragen. Wenn ein Entwickler eine einheitliche Sicht anfordert, führt das System gleichzeitige Abfragen in allen drei Partitionen durch und merged die Ergebnisse. Das geht in unter einer Sekunde.

1. eBPF-Netzwerkflüsse (Netzwerkebene)
Mit eBPF, einer Technologie zur dynamischen Instrumentierung des Linux-Kernels, erfassen die Entwickler Netzwerk-Flow-Records. Diese zeigen, welche Services sich über IP-Adressen und Ports verbinden. Der Vorteil: Jeder Dienst wird erfasst, unabhängig davon, ob er instrumentiert ist. So entsteht eine vollständige Karte aller Netzwerkverbindungen – auf Cluster- und Applikationsebene. Die Einschränkung: Man sieht nur, dass Service A mit Service B spricht, aber nicht, welche API-Endpunkte (z. B. /api/v1/users vs. /api/v1/orders) aufgerufen werden.

2. IPC-Metriken (Anwendungsebene)
Netflix sammelt Metriken zu Inter-Process Communication (IPC) aus den instrumentierten Diensten. Diese Metriken werden von den Anwendungen selbst ausgestoßen, wenn sie über gRPC, GraphQL oder REST andere Dienste aufrufen. Sie enthalten reichhaltige Informationen: konkrete Endpunkte, Fehlerraten, Latenzverteilungen, Protokolldetails. Diese Ebene liefert detaillierte Applikationstopologie – aber nur für Dienste, die solche Metriken emittieren. Nicht alle Services tun das.

3. End-to-End-Tracing (Anfrageebene)
Die dritte Quelle ist das verteilte Tracing. Netflix verfolgt einzelne Anfragen durch das gesamte System – allerdings nur einen Teil der Anfragen, um die Performance nicht zu beeinträchtigen (Sampling). Aus den aggregierten Traces bauen sie einen Topologie-Graphen, der zeigt, wie Anfragen tatsächlich fließen. Das ist besonders wertvoll, weil es konditionale Logik und Feature-Flags abbildet: Nicht immer ruft Service A Service B auf – nur unter bestimmten Bedingungen. Entwickler können die aggregierte Ansicht oder einzelne Traces auf der Karte anzeigen lassen, um konkrete Anfragepfade nachzuvollziehen.

Wie die drei Schichten zusammenwirken

Die Stärke des Systems liegt in der Kombination. Der Netzwerk-Graph sorgt für Vollständigkeit: Jede Verbindung wird erfasst, auch von nicht instrumentierten Diensten. Der IPC-Graph liefert den Anwendungskontext: Welche Endpunkte, welche Protokolle, welche Fehlerquote? Der Tracing-Graph zeigt das reale Laufzeitverhalten: Welche Pfade werden tatsächlich durchlaufen? Keine der drei Ebenen allein wäre ausreichend. Zusammen ergeben sie eine aktuelle Karte der Infrastruktur.

Entwickler können jede Ebene einzeln betrachten oder die vereinigte Ansicht nutzen. Die vereinigte Ansicht vereint Knoten und Kanten aus allen drei Partitionen und bewahrt die jeweiligen Eigenschaften. Ein Knoten kann Netzwerk-, IPC- und Tracing-Attribute tragen. Im Incident-Fall sieht der Ingenieur sofort, welche Dienste in welcher Art verbunden sind, welchen Health-Status sie haben und welche Teams verantwortlich sind. Per Klick kann er in die detaillierten Metriken, Logs oder Traces abtauchen – ohne zwischen verschiedenen Tools hin- und herspringen zu müssen.

Die Autoren betonen, dass die Skalierbarkeit eine der größten Herausforderungen war. Lösungen, die bei tausend Knoten funktionieren, versagen bei der Größenordnung von Netflix. Auch die Datenqualität war kritisch: Unvollständige oder falsche Abhängigkeitsinformationen können während eines Incidents zu Fehlentscheidungen führen. Deshalb setzen sie auf multiple Quellen, die sich gegenseitig validieren. Und auf Echtzeit: Da sich die Topologie ständig ändert, wird der Graph kontinuierlich aktualisiert – nicht einmal pro Stunde, sondern quasi in Echtzeit.

Was das konkret bedeutet

Mit Service Topology haben die Entwickler bei Netflix ein Werkzeug geschaffen, das genau die drei Fragen beantwortet, die sie immer wieder hörten: Wer hängt von wem ab? Was ist der Blast Radius? Wo liegt die Ursache? Die Karte ist keine statische Architekturzeichnung, sondern ein aktuelles Abbild der Systemstruktur. Für die Ingenieure bedeutet das weniger Stress in Incidents, schnellere Root-Cause-Analysen und eine bessere Grundlage für Entscheidungen über Wartungsarbeiten oder neue Deployments.

Die Architektur ist nicht auf Netflix beschränkt. Jedes Unternehmen mit einer Vielzahl von Microservices steht vor ähnlichen Herausforderungen. Der Ansatz, mehrere Datenquellen zu kombinieren und physisch getrennte Graphen parallel abzufragen, ist übertragbar – auch wenn die konkrete Implementierung auf die Netflix-eigene Observability-Plattform zugeschnitten ist. Das Prinzip bleibt: Eine Echtzeit-Topologiekarte ist keine Spielerei, sondern eine Notwendigkeit für zuverlässige verteilte Systeme.

Als Entwickler oder Architekt solltest du überlegen, ob dein Unternehmen ebenfalls eine solche Karte braucht. Vielleicht beginnst du nicht mit drei Quellen, sondern mit einer – etwa mit Tracing-Daten. Der wichtigste Punkt: Verlass dich nicht auf ein einziges Signal. Kombiniere Netzwerk-, Anwendungs- und Anfragedaten, um ein vollständiges Bild zu erhalten. In der Welt der Microservices ist die Abhängigkeitstopologie die Landkarte deines Systems – und ohne aktuelle Karte tappst du im Dunkeln.

Quelle: netflixtechblog.com

Du gibst eine kurze Beschreibung ein. Sekunden später liefert die KI Code. Diese Werkzeuge haben die Softwareentwicklung verändert. Was früher selbst geschrieben wurde, entsteht jetzt schnell. Was bedeutet das für deine Rolle und deine Fähigkeiten?

Carson Gross, Entwickler von htmx, hat sich damit beschäftigt. Sein Fazit: Code ist billiger geworden – im Aufwand, nicht in der Qualität. Diese Billigkeit bringt eine andere teure Ressource: das Verständnis. Verstehen wird teurer, weil es nicht mehr beim Schreiben entsteht, sondern erst hinterher durch Lesen und Analysieren. Das ist ein Unterschied, den wir beachten sollten.

Die Illusion der schnellen Lösung

Du kennst das Gefühl: Du hast eine komplexe Aufgabe, die KI liefert einen Lösungsvorschlag, und du denkst: „Passt schon.“ Aber wie oft nimmst du dir Zeit, jede Zeile zu verstehen? Selten. Darin liegt die Gefahr. Gross vergleicht das mit einer Szene aus Fantasia: Der Zauberlehrling verzaubert einen Besen. Anfangs läuft es gut, dann wird der Besen schneller, unkontrollierter, bis das Labor unter Wasser steht. Er verliert die Kontrolle – weil er die Magie nicht verstanden hat.

In der KI-Entwicklung passiert dir das Gleiche. Die Modelle können Code in einem Tempo produzieren, das kein Mensch nachvollziehen kann. Sie haben keine Angst vor Komplexität, keine Intuition für Architektur, kein Verständnis für Konsequenzen. Sie generieren weiter, basierend auf Wahrscheinlichkeiten. Du stehst vor einem Berg Code, den du weder verstehen noch warten kannst. Der Zauberlehrling wird zum Gefangenen seiner Werkzeuge.

Komplexität bleibt der Feind

Gross sagt, Menschen unterschätzen exponentielles Wachstum. Komplexität kann schnell zunehmen. Jede neue Funktion, Abhängigkeit, Codepfad multipliziert die Wechselwirkungen. Es gab schon vor KI „prolific coders“. Ihre Projekte endeten oft in einem „unmodifiable steady state“. Änderungen erzeugen so viele Fehler, wie sie beheben. Das System ist tot, funktioniert aber noch.

KI-Modelle sind die extremsten prolific coders. Sie schreiben pausenlos, ohne Rücksicht auf Strukturen oder Systemgrenzen. Lässt du sie gewähren, landest du schnell in dieser Sackgasse. Code wird billig, Komplexität unbezahlbar. Weil die KI keine Angst hat, wirst du zum Bremser, zum Kontrolleur, der die Magie im Zaum hält.

Der subtraktive Ingenieur: Weniger ist mehr

Gross schlägt ein neues Leitbild vor: den subtraktiven Ingenieur. Er sagt nicht „Ja, mehr Code“, sondern „Nein, Code entfernen“. Er prüft jede Zeile, hinterfragt ihre Notwendigkeit, sucht Vereinfachungen. Sein Stolz ist nicht die Menge des geschaffenen, sondern des verhinderten oder entfernten Codes. Er ist Bildhauer, nicht Bauarbeiter. Er meißelt weg, bis das Wesentliche bleibt.

Das heißt nicht, dass du nichts mehr selbst programmierst. Deine Kernkompetenz verschiebt sich vom Produzieren zum Reduzieren. Du wirst zum Hüter der Übersichtlichkeit und zum Wächter gegen unnötige Komplexität. Du musst verstehen, was die KI produziert, und entscheiden, ob es gebraucht wird. Das erfordert Systemverständnis und eine klare Vorstellung von guter Architektur. Das kannst du vielleicht schon, aber jetzt wird es wichtiger.

Praktische Konsequenzen für deinen Alltag

Konkret: Erstens – verwende KI inkrementell. Lass nicht zu, dass sie dir einen Monat Arbeit in fünf Minuten vorsetzt. Zerlege Aufgaben in kleine Einheiten, deren Output du vollständig verstehst. Zweitens – priorisiere das Verstehen. Lies Code wie einen Vertrag. Wenn du ihn nicht verstehst, unterschreibe nicht. Drittens – entwickle ein Gespür für unnötige Komplexität. Frage bei jeder Funktion: Brauchen wir das? Gibt es eine einfachere Lösung? Kann ich bestehenden Code umbauen?

Gross sagt, sein Vorschlag ist nicht neu. Es gab schon immer Entwickler, die lieber polieren als neu schreiben, die lieber Nein sagen. In der KI-Ära wird diese Haltung zur Überlebensstrategie. Wer nur darauf setzt, mit der KI um die Wette zu schreiben, verliert, weil die KI

Quelle: htmx.org

Du öffnest ChatGPT, stellst eine Frage und bekommst in Sekunden eine Antwort. Das wirkt wie Magie, ist aber das Ergebnis einer komplexen und fragilen Lieferkette. Hinter jeder Antwort steckt ein großes Sprachmodell, aber auch physikalische Prozesse: Seltene Erden, Mikrochips, Kühlung von Rechenzentren. Diese Infrastruktur wird in den nächsten Jahrzehnten entscheiden, wer wirtschaftlich und politisch die Oberhand behält.

Bisher lautete die Formel für Wirtschaftswachstum: mehr Menschen plus höhere Produktivität gleich mehr Wohlstand. Mit KI fällt der erste Faktor weg. Maschinen ersetzen menschliche Arbeit, weit über einfache Automatisierung hinaus. Das Bruttoinlandsprodukt eines Landes hängt dann nicht mehr von der Bevölkerungszahl ab, sondern davon, wie produktiv die verbleibenden Menschen mit Maschinen sind. Diese Maschinen – die Hardware, die KI antreibt – sind der Produktionsfaktor. Und sie sind extrem skalierbar: Ein Chip arbeitet rund um die Uhr, ohne Pause, ohne Gehaltsverhandlung. Die Nachfrage nach dieser neuen Arbeit ist praktisch unendlich. Der Engpass liegt im Angebot, nicht im Bedarf.

Ein Blick zurück hilft. Die letzten zwanzig Jahre waren das goldene Zeitalter der Software. Einmal geschriebener Code ließ sich zu minimalen Kosten millionenfach verteilen. Das führte zu Unternehmen mit enormen Margen und prägte eine Generation von Entwicklern und Investoren. Venture Capital wurde zum Motor, Unicorn-Status das Ziel. Hardware galt als langweiliges Commodity-Geschäft. Wer Chips herstellte, kämpfte mit zyklischen Umsätzen und hohen Investitionen. Die Folge: Immer weniger Ingenieure für Elektrotechnik und Halbleiter, immer mehr Softwareentwickler. Lange war das kein Problem, weil Hardware verfügbar war. Heute rächt sich diese Schieflage.

Mit dem Launch von ChatGPT 2022 änderte sich alles. KI wurde für die breite Masse erfahrbar. Softwareentwickler integrierten KI-Funktionen, stießen aber auf eine Überraschung: Die Kosten für die Inferenz – die Berechnung einer Antwort – skalieren mit der Nutzerzahl. Das ist fundamental anders als bei klassischer Software, deren Grenzkosten gegen Null gehen. Ein SaaS-Produkt mit KI hat plötzlich echte Herstellungskosten. GPUs wurden knapp, Lieferketten ächzten. Gleichzeitig sanken die Kosten für Softwareentwicklung selbst, weil KI-Modelle beim Programmieren halfen. Paradox: Es wurde billiger, Konkurrenzprodukte zu bauen, aber teurer, sie zu betreiben. Die Börsenbewertungen vieler Softwarefirmen korrigierten sich.

Die Nachfrage nach Rechenleistung kommt nicht nur von Startups. Auch Hyperscaler wie Amazon, Google und Microsoft migrieren CPU-Workloads auf KI-Beschleuniger. Soziale Medien nutzen maschinelles Lernen. Nationen und etablierte Unternehmen setzen KI für Effizienz ein. Und die Nutzer fordern mehr: längere Kontextfenster, niedrigere Latenz, höhere Genauigkeit. Jede Verbesserung macht KI nützlicher, aber auch rechenhungriger. Das Jevons-Paradox greift: Effizienzsteigerung führt nicht zu weniger Verbrauch, sondern zu mehr. Wie eine ausgebaute Autobahn, die bald wieder voll ist. So laden KI-Effizienzverbesserungen zu neuen Anwendungen ein, die mehr Rechenleistung fressen.

Um die Dynamik zu verstehen, betrachtet man drei Ebenen des KI-Skalierens. Früher zählte das Pre-Training – das einmalige Trainieren eines Modells. Dann kam die Inferenz: die Nutzung durch Anwender. Heute gibt es eine dritte Welle: das Post-Training – Nachjustieren während des Einsatzes. Alle drei Ebenen haben eigene Nachfragekurven, die sich verstärken. Hinzu kommt Spezialisierung. Während OpenAI mit ChatGPT ein generalistisches Modell anbietet, entwickeln Firmen wie Harvey spezialisierte Modelle für die Rechtsbranche. Künftig könnten Modelle für Robotik, Medizin oder Videogenerierung jeweils eigene Nachfrageexplosionen auslösen.

Der Autor des Essays gibt zu, dass er anfangs die Nachfrage linear mit der Nutzerzahl verknüpfte. Ein einfaches Modell: 800 Millionen wöchentliche ChatGPT-Nutzer, 50 Prozent Wachstum pro Jahr, in vier Jahren vielleicht 4 Milliarden. Das greift zu kurz. Maschinen arbeiten nicht nur, wenn ein Mensch eine Frage stellt. Sie arbeiten asynchron, stundenlang, überwachen sich, delegieren an andere Agenten, analysieren riesige Datenmengen. Ein Video-Generierungsmodell braucht das Zehnfache eines Textmodells; ein Weltmodell noch einmal das Zehnfache. Die Nachfrage ist nicht additiv, sondern multiplikativ. Der Autor schätzt den Bedarf an Rechenleistung auf mindestens zwei Größenordnungen über dem heutigen Niveau.

Diese Nachfrage trifft auf eine Lieferkette mit mehreren Engpässen. Der Autor identifiziert fünf Kategorien. Erstens: Unternehmen mit PTSD aus früheren Boom-Bust-Zyklen. Halbleiterfirmen litten unter Nachfrageschwankungen und gelten als zyklisch. Diese Welle könnte struktureller sein. Zweitens: Akteure mit strukturellen Vorteilen, etwa exklusive Beziehungen zu EUV-Lithografiemaschinen. ASML ist das Paradebeispiel – kein Chip der neuesten Generation ohne diese Maschinen. Drittens: Infrastruktur für komplexe Anforderungen, besonders Kühlung und Strom. Rechenzentren verschlingen Energie; wer günstigen Strom liefern kann, sitzt an einer Mautstraße der Zukunft. Viertens: Fortschritte, bei denen ein Unternehmen klar führt, etwa bei Optiken oder Uran. Fünftens: Märkte in Übersee, die westliche Investoren meiden, obwohl die Halbleiterindustrie global ist. Wer China oder Taiwan ignoriert, verpasst einen großen Teil des Puzzles.

Die geopolitische Dimension ist nicht zu unterschätzen. Während USA und Europa eigene Fertigung aufbauen, treibt China eine parallele, unabhängige Halbleiterindustrie voran. Gleichzeitig bleibt das Land auf westliche Ausrüstung angewiesen. Diese Abhängigkeiten schaffen ein fragiles Gleichgewicht. Fest steht: Die Unternehmen, die heute die physikalischen Engpässe der KI kontrollieren – Chipfertigung, Belichtungsmaschinen, Energie – werden in den kommenden Jahrzehnten Macht ausüben wie die Ölkonzerne im 20. Jahrhundert. Sie sind die neuen Mautstraßen der digitalen Wirtschaft.

Was bedeutet das konkret? Wenn wir über KI sprechen, denken wir meist an Algorithmen, Modelle und Daten. Das ist berechtigt, aber unvollständig. Die eigentliche Auseinandersetzung findet auf dem Silizium statt. Wer die Kontrolle über die Chip-Produktion hat, bestimmt, wie schnell KI sich entwickelt und wer Zugang zu den leistungsfähigsten Systemen erhält. Für Investoren und Organisationen, die KI strategisch nutzen wollen, heißt das: Ein Blick auf die Hardware-Lieferkette ist nötig. Es geht nicht mehr nur um Software. Es geht um Silizium, Energie und physikalische Grenzen. Diese Grenzen werden die Zukunft prägen – unsichtbar, aber unausweichlich.

Quelle: silicon-frontier.com

Du öffnest einen Pull Request mit 30 geänderten Dateien. Du scrollst durch die Diff-Ansicht, suchst nach Fehlern, aber nach fünf Dateien lässt die Konzentration nach. Ein Kollege reviewed später und übersieht genau den Nullzeiger, der dich nachts um drei wachhält. Dieses Szenario hatte Alibaba vor Augen, als sie ihr internes KI-Code-Review-Tool entwickelten – und jetzt als Open Source veröffentlichen.

Das Tool heißt Open Code Review (OCR). Es ist kein generischer KI-Agent, den du mit einem Prompt anlernst, sondern ein Hybrid aus deterministischen Pipelines und einem Large-Language-Model-Agenten. Die Maschine übernimmt stupide, aber kritische Prüfungen, während das KI-Modell dort glänzt, wo Kontextverständnis gefragt ist. Schauen wir uns an, was dahintersteckt.

Das Problem mit generischen KI-Agenten

Vielleicht hast du schon Claude Code oder einen anderen universellen Agenten für Code-Reviews eingesetzt. Die Ergebnisse sind oft ernüchternd. Bei großen Änderungssätzen neigen diese Agenten dazu, „Ecken abzuschneiden“ – sie reviewen nur einen Teil der Dateien und lassen andere aus. Die berichteten Probleme sitzen oft nicht auf der richtigen Codezeile; die Positionsangaben driften ab. Und die Qualität schwankt massiv, sobald du den Prompt geringfügig änderst.

Warum passiert das? Die Ursache liegt in einer rein sprachgetriebenen Architektur. Ein LLM hat keine harten Zwänge, keine Garantie, dass es wirklich alle Dateien anschaut oder die Zeilennummern stimmen. Es folgt Wahrscheinlichkeiten, nicht Regeln. Für eine Aufgabe wie Code-Review, bei der es auf Vollständigkeit und Genauigkeit ankommt, ist das ein Problem.

Der Hybrid-Ansatz von Open Code Review

Die Entwickler von Alibaba haben sich für eine klare Trennung entschieden: Deterministische Ingenieurslogik übernimmt alles, was nicht schiefgehen darf. Der KI-Agent kümmert sich um dynamische Entscheidungen, die Kontext erfordern. Stell dir vor, du hast einen Assistenten, der automatisch die richtigen Aktenordner aus dem Regal zieht (deterministisch) – und dann einen zweiten, der die Akten liest und dir die relevanten Stellen zusammenfasst (KI). Beide arbeiten Hand in Hand, aber jeder macht das, was er am besten kann.

Deterministische Säule: Harte Zwänge für kritische Schritte

Die erste Säule ist ein System aus fest programmierten Regeln und Pipelines. Sie garantieren:

• Präzise Dateiauswahl: Das Tool bestimmt exakt, welche Dateien reviewed werden müssen und welche ignoriert werden können. Keine wichtige Änderung wird übersehen.
• Intelligentes Bündeln: Zusammenhängende Dateien – etwa message_en.properties und message_zh.properties – werden zu einem Review-Bundle zusammengefasst. Jedes Bundle läuft als eigener Sub-Agent mit isoliertem Kontext. Das ist eine Divide-and-Conquer-Strategie: Selbst bei sehr großen Changesets bleibt das Tool stabil, und die Reviews laufen nebenläufig.
• Fein abgestimmtes Regel-Matching: Statt das LLM mit allgemeinen Prompts zu füttern, werden spezifische Review-Regeln an die Eigenschaften jeder Datei geknüpft. Das hält den Fokus des Modells scharf und eliminiert Informationsrauschen. Im Vergleich zu rein sprachgesteuerten Regelwerken ist eine Template-Engine stabiler und vorhersagbarer.
• Externe Positionierungs- und Reflexionsmodule: Zwei unabhängige Module korrigieren systematisch die Positionsgenauigkeit und die inhaltliche Korrektheit der KI-Kommentare. So landen die Hinweise exakt auf der richtigen Codezeile und sind inhaltlich treffsicher.

KI-Agent: Dynamische Intelligenz für Kontext und Entscheidungen

Auf der anderen Seite steht der LLM-Agent. Er wird nicht mit einem vagen „Reviewe diesen Code“-Prompt losgeschickt, sondern nutzt speziell für Code-Review optimierte Prompt-Vorlagen. Diese Vorlagen senken den Token-Verbrauch und steigern die Effektivität. Der Agent hat ein maßgeschneidertes Toolset – basierend auf einer Analyse von Millionen von Tool-Call-Traces aus der Produktion. Die Entwickler haben sich angeschaut, welche Werkzeuge wie oft verwendet werden, wie hoch die Wiederholungsraten sind und wie sich neue Tools auf die gesamte Aufrufkette auswirken. Das Ergebnis ist eine stabile, vorhersagbare Tool-Ausstattung, die genau auf Code-Reviews zugeschnitten ist – nicht die generische Toolbox eines Allround-Assistenten.

Mit diesem Setup kann der Agent nicht nur den Diff anschauen, sondern auch den vollständigen Dateiinhalt lesen, im Codebase suchen und andere geänderte Dateien zur Kontextgewinnung heranziehen. Er liefert tiefgehende Reviews, nicht nur oberflächliches Feedback zum Diff.

Wie du Open Code Review nutzt

Du kannst das Tool als CLI installieren – über npm, als Binär von GitHub Releases oder aus dem Quellcode. Der Befehl ocr review startet den Review auf deinem Workspace, einem Branch-Vergleich oder einem einzelnen Commit. Du bestimmst die Ausgabe im Text- oder JSON-Format, die Anzahl der parallelen Reviews und den Timeout.

Ein Beispiel: Um alle Änderungen zwischen main und einem Feature-Branch zu reviewen, reicht ocr review --from main --to feature-branch. Möchtest du vorab sehen, welche Dateien reviewed werden, nutzt du ocr review --preview. Das ist hilfreich, um ein Gefühl für die Abdeckung zu bekommen.

Die Konfiguration des LLM-Anbieters erfolgt über die Kommandozeile – du gibst Endpunkt, API-Key und Modell an. OpenAI-kompatible und Anthropic-Modelle werden unterstützt. Das Tool liest auch die Umgebungsvariablen von Claude Code, sodass du sie nicht doppelt pflegen musst.

Integration in CI/CD und Coding Agents

Open Code Review ist nicht nur für die lokale Nutzung gedacht. Es lässt sich in CI/CD-Pipelines einbauen, um Pull Requests automatisch zu reviewen. Mit dem Flag --format json erhältst du maschinenlesbare Ergebnisse, die dein CI-Skript weiterverarbeiten kann. Alibaba liefert Beispiele für GitHub Actions und GitLab CI mit.

Du kannst das Tool direkt in KI-Coding-Agents wie Claude Code als Slash-Command integrieren. Es gibt fertige Plugins und Skills, die dem Agenten beibringen, ocr aufzurufen, die Ergebnisse zu kategorisieren und sogar automatisch Fixes vorzuschlagen. Das Bindeglied ist immer die installierte CLI – der Agent selbst wird nicht mit der Review-Logik belastet, sondern delegiert an die deterministische Pipeline.

Was das für die Praxis bedeutet

Mit Open Code Review bekommst du ein Werkzeug, das die Stärken von deterministischen Systemen und KI vereint. Du musst keine langen Prompts optimieren oder hoffen, dass der Agent alle Dateien erwischt. Die harten Zwänge garantieren Vollständigkeit und Positionsgenauigkeit – zwei Schwachstellen reiner KI-Lösungen. Gleichzeitig profitiert der KI-Agent von einem spezialisierten Toolset und optimierten Prompts, die aus Jahren Erfahrung bei Alibaba destilliert wurden.

Für Entwicklerteams, die regelmäßig große Code-Reviews durchführen, bedeutet das eine Entlastung. Die KI erledigt Standardprüfungen (Nullzeiger, Thread-Safety, XSS, SQL-Injection) zuverlässig und liefert tiefgehendes Feedback, das sonst nur ein erfahrener Senior-Entwickler geben kann. Weil das Tool Open Source ist, kannst du es an deine eigenen Bedürfnisse anpassen, eigene Regeln definieren oder die Tool-Ausstattung erweitern.

Die Veröffentlichung zeigt einen Trend: KI-Tools für Entwickler werden erwachsener. Statt jedes Problem mit einem allmächtigen LLM zu erschlagen, setzt sich der hybride Ansatz durch – wie in der Luftfahrt, wo Autopilot und Pilot zusammenarbeiten. Open Code Review ist ein Beispiel, wie man KI sinnvoll in bestehende Arbeitsabläufe integriert, ohne die Kontrolle aus der Hand zu geben. Es lohnt sich, einen Blick darauf zu werfen – besonders, wenn du eine verlässliche, automatisierte Code-Review-Lösung suchst.

Quelle: github.com