Kategorie: Einblicke

rd-signal-2 durchsucht Produktions-Traces von Agenten, schreibt eigenen Code zur Kontextextraktion und trainiert daraus binäre Klassifikatoren. Es erreicht fast die Genauigkeit von GPT-5.6 Sol xhigh, kostet aber 1600-mal weniger als das teure Frontier-Modell und 260-mal weniger als die günstigere Variante. Raindrop gibt Signals 2.0 heute für alle Kunden frei.

Entwickler und Team-Leads können jetzt präzise entscheiden, ob ein Agentenverhalten gut oder schlecht ist, ohne jedes Trace durch ein großes Sprachmodell zu jagen. Raindrop nennt das binäre Klassifikation. Scheinbar einfach, in der Praxis alles andere als trivial.

Warum binäre Klassifikation so schwer ist

OpenAI veröffentlichte letztes Jahr einen Aufsatz, der Halluzination als binäres Klassifikationsproblem beschreibt: Jede Aussage ist wahr oder falsch. Die Schlagzeilen jubelten, doch die Realität ist komplexer. Auch im echten Leben ist fast alles binär: heiraten oder nicht, gute oder schlechte UI, akzeptables Agentenverhalten oder nicht. Nur: Diese Entscheidung ist nicht einfach.

Hinter jedem „gut“ oder „schlecht“ steht eine Definition, die Menschen gemeinsam festlegen müssen. Was ist ein Fehler? Zählt ein Timeout als Misserfolg? Was, wenn der Agent nach drei Fehlversuchen erfolgreich ist? Binäre Klassifikation ist ein Alignment-Problem: Menschen im Unternehmen auf eine gemeinsame Definition bringen, Randfälle durchspielen, dann ein Modell trainieren, das dieser Definition treu bleibt.

Raindrop deckt diesen Weg ab, vom ersten Prompt bis zum kontinuierlich überwachten Klassifikator. Bisher gingen die meisten Lösungen davon aus, dass ein einzelnes Input-Output-Paar ein Verhalten bewertet. Das funktionierte im Chatbot-Zeitalter. Agenten heute scheitern über mehrere Schritte, rufen Tools auf, starten Sub-Agenten und produzieren Traces mit Hunderttausenden von Tokens.

So funktioniert rd-signal-2

Ein typisches Szenario: Ein Agent versucht, einen Datensatz zu aktualisieren. Drei Mal ruft er dieselbe Funktion auf, jedes Mal gibt es einen Timeout. Am Ende antwortet er: „Der Datensatz wurde erfolgreich aktualisiert.“ Ein klassischer Fehler, aber er liegt nicht in einem einzelnen Schritt, sondern in der Beziehung zwischen den wiederholten Tool-Fehlern und der finalen Antwort. Solche Muster erkennt rd-signal-2.

Der Prozess ist eine automatisierte Forschungsschleife. Für jedes Verhalten analysiert das System Produktions-Traces, schreibt Code, der den Kontext zusammensetzt – Tool-Calls, Argumente, Status – und prüft, ob die Bedingungen erfüllt sind. Wenn nicht, gibt der Signal ohne Modellaufruf ein „kein Match“ zurück. Wenn doch, extrahiert er die fehlgeschlagenen Versuche und die finale Antwort. Die semantische Bewertung übernimmt ein spezialisierter Klassifikationskopf mit einem hauseigenen Reasoning-Modell, das auf binäre Entscheidungen optimiert ist.

Signals sind nicht auf einen einzelnen Turn beschränkt. Sie sammeln Kontext aus Sitzungen, die Tage oder Wochen dauern. Agentenprobleme sind oft subtil und spärlich verteilt – ein einzelner Fehler in einem Meer erfolgreicher Aktionen.

Die Kostenfrage: Reasoning zur Buildzeit

Traditionelle LLM-Judges jagen für jede Bewertung dieselben Beweise durch das Modell und fällen leicht unterschiedliche Urteile. Das kostet Zeit und Geld. rd-signal-2 verlagert das Reasoning in den Build-Prozess: Einmalig wird ein Klassifikator erstellt, der dann sehr günstig auf Millionen von Traces angewendet werden kann.

Das System iteriert bei der Entwicklung und wendet strenge Selbstverifikation an. Mehrere Ansätze werden ausprobiert, bevor einer passt. Modellaufrufe skalieren mit der Unsicherheit, nicht mit dem Traffic. Signals sind so günstig, dass Raindrop sie in die Plattform integriert hat und über Milliarden von Traces pro Monat ausführt. Kunden von Plattformen wie Braintrust oder Langchain zahlen dagegen für jede Inferenz aus eigener Tasche.

Diese Architektur ist der Grund, warum Kunden keine zusätzlichen Gebühren für Signals 2.0 zahlen. Sie sind im Produkt enthalten. Auch bei hohen Volumen bleibt die Klassifikation schnell und wirtschaftlich.

Alignment als Produktproblem

Die größte Herausforderung ist nicht das Modell, sondern das Verständnis dessen, was der Nutzer meint. Raindrop nennt das ein Produktproblem, nicht nur ein ML-Problem. Zurück zu den wiederholten Tool-Calls: Soll der Signal matchen, wenn sich die Argumente leicht ändern, die Strategie aber gleich bleibt? Was, wenn die ersten drei Versuche scheitern, der vierte aber gelingt? Oder wenn der Agent aufgibt und ein Sub-Agent es erfolgreich abschließt?

Ein Experiment aus dem Artikel zeigt, wie schwer diese Grenze zu finden ist: Vier Varianten eines Satzes als Verhaltensbeschreibung wurden über dieselben 2.000 Produktions-Traces ausgeführt. Die Match-Raten schwankten zwischen 0,9 % und 4,6 %. 67 % der gematchen Traces waren bei mindestens einer Variante umstritten. Selbst erfahrene Entwickler sind sich oft nicht einig, wo die Linie verläuft.

Raindrop setzt auf einen kontinuierlichen Verbesserungsprozess. Ein Signal ist nie fertig. Modelle, Harnesses und Trace-Formen ändern sich; Kunden entdecken Spezifikationsfehler, sobald sie den Signal auf mehr Daten anwenden. Nach der Bereitstellung werden täglich Stichproben mit Frontier-Modellen ausgewertet. Bei Drift oder Regressionen startet die Prompt-Optimierung neu. So bleibt der Signal über lange Zeit aligned.

Sicherheit und Skalierung

10.000 Traces bewerten ist einfach. Mehr als zwei Millionen pro Tag erfordern sorgfältiges Modell-Serving, Queueing, Retries und Isolation. Raindrop behandelt jeden Signal standardmäßig als nicht vertrauenswürdig. Jeder Kunden-Signal läuft in isolierter Umgebung ohne Zugriff auf Credentials oder Internet-Egress. Die Runtime einer Organisation kann nur auf ihre eigenen Daten zugreifen.

Caching ist ein weiteres Schlüsselelement: Trace-Kontext wird einmal abgerufen und nahe an den Evaluierungsworkern gespeichert. Mehrere Signals können dieselben Daten wiederverwenden, ohne teure Abfragen zu wiederholen. Der heiße Pfad bleibt auf deterministische Ausführung beschränkt; nur kleine Fälle benötigen Modell-Urteilsvermögen. Die Median-Latenz für eine Klassifikation liegt bei 100 Millisekunden. Die Infrastruktur bewertet über 20 Milliarden Traces pro Monat.

Diese Zahlen sind beeindruckend, aber sie folgen einem Prinzip: Nicht für jede Operation ein Frontier-Modell bezahlen. Die meiste Arbeit deterministisch erledigen, nur bei Unsicherheit ein Modell einsetzen. Genau das macht rd-signal-2.

Signals 2.0 in Raindrop und darüber hinaus

rd-signal-2 ist die Basis für nutzerdefinierte Klassifikatoren in Raindrop. Das hauseigene Issue-Detection-System nutzt dieselbe Architektur, um Fehlermuster in Kundendaten zu identifizieren, zu verfolgen und zu überwachen. Ein erkannter Issue lässt sich sofort in einen dauerhaften Signal verwandeln, die Richtlinie verfeinern, A/B-Tests durchführen. Signals lassen sich manuell erstellen, über den Triage-Agenten, den Coding-Agenten per MCP oder direkt aus dem Issue-Detection-System.

Für Teams mit strengen Datenschutzanforderungen gibt es ZDR Signals – Zero Data Retention. Klassifikatoren lassen sich trainieren und ausführen, ohne Produktionsdaten zu speichern. Das öffnet Branchen wie das Gesundheitswesen, wo Datenhaltung besonderen Regeln unterliegt.

Signals 2.0 bleibt nicht auf Raindrop beschränkt. Die neue API erlaubt Entwicklern, domain-spezifische Erkennung in eigene Systeme zu integrieren. Die Infrastruktur hinter den 20 Milliarden Traces wird für jeden nutzbar, ohne den Umweg über die Raindrop-Oberfläche. Ein Schritt in Richtung einer offenen Klassifikationsplattform für Agentenverhalten.

Was bedeutet das konkret? Präzise und kostengünstig bewerten, ob der Agent das tut, was er tun soll – in Echtzeit, über lange Sitzungen hinweg und mit klarer Nachvollziehbarkeit. Die Technologie ist da, bezahlbar und in ein Produkt eingebettet, das den Alignment-Prozess als kontinuierlichen Kreislauf versteht. Ein solider Schritt für alle, die ernsthaft an verlässlichen Agenten arbeiten.

Quelle: raindrop.ai

Wie lässt sich Umgebungsdrift zwischen Staging und Produktion vermeiden? Ein Entwickler hat dafür eine Inter-Mesh-Deployment-Pipeline entworfen, die auf seiner eigenen Infrastruktur läuft.

Der Autor betreibt rund 72 Anwendungen in zwei Umgebungen. Offiziell sieht der Prozess so aus: erst Staging, dann testen, dann Produktion. In der Praxis blieb dieser Weg oft ungenutzt. Es gab keine technische Möglichkeit, die Reihenfolge zu erzwingen. So entwickelten sich die beiden Umgebungen auseinander – ein Fall von Umgebungsdrift.

Du kennst das aus eigenen Projekten: Ohne automatisierte Kontrolle weicht die Konfiguration von Staging und Produktion voneinander ab. Neue Abhängigkeiten werden nur in Produktion ergänzt, Umgebungsvariablen unterscheiden sich, und plötzlich ist Staging kein verlässlicher Testort mehr. Genau dieses Problem wollte der Entwickler lösen.

Das Problem: Umgebungsdrift und fehlende Kontrolle

Umgebungsdrift entsteht, wenn zwei Umgebungen, die identisch sein sollten, durch manuelle Eingriffe oder fehlende Automatisierung voneinander abweichen. Im Fall des Autors war die Theorie klar: Jede Änderung sollte zuerst nach Staging, dann nach sorgfältigem Testen nach Produktion. Aber keine technische Hürde erzwang diesen Ablauf. Entwickler konnten direkt auf Produktion deployen, wenn sie es eilig hatten, oder Konfigurationen lokal ändern, ohne sie zu dokumentieren.

Die Folgen waren vorhersehbar: Staging wurde selten genutzt, veraltete Daten oder fehlerhafte Abhängigkeiten machten Tests unzuverlässig, und niemand wusste mehr, was auf welcher Umgebung lief. Bei so vielen Anwendungen war das ein erhebliches Risiko. Ein Fehler, der nur in Produktion auftrat, konnte teuer werden.

Um das zu beheben, brauchte der Autor eine Möglichkeit, den gewünschten Ablauf technisch zu erzwingen und gleichzeitig vollständige Transparenz über alle Deployments zu erhalten.

Die Idee: Eine NATS-Bridge als Verbindungsstück

Die Lösung bestand darin, einen speziellen Connector zu entwickeln, der als Brücke zwischen den beiden Meshes fungiert. Ein Mesh ist ein Netzwerk aus Diensten, die über gemeinsame Kommunikationsprotokolle verbunden sind. Der Connector nutzt NATS, einen Message-Broker, um Nachrichten zwischen den Umgebungen auszutauschen.

Durch diese NATS-Bridge kann die Produktionsumgebung direkt Anfragen an die Staging-Umgebung senden. Ein Build und Test einer Komponente lässt sich so anstoßen, ohne dass ein Mensch eingreift. Der Autor nutzte diesen Mechanismus zuerst, um neue Anwendungen auszurollen. Denn wenn die Pipeline weiß, wie man eine neue App korrekt installiert, kann sie dieselbe Logik auf bestehende Anwendungen anwenden.

Das Besondere daran ist, dass nicht nur der initiale Deploy automatisiert wird, sondern auch spätere Updates. In der Produktionsoberfläche gibt es eine Schaltfläche „Pull from Staging“. Sie löst einen vollständig überwachten Prozess aus, der die Artefakte von Staging abruft und in Produktion übernimmt. Jeder Schritt wird protokolliert, sodass ein lückenloses Audit möglich ist.

Sicherheit durch Privilegientrennung: das proc-mesh-Konzept

Ein so flexibles Werkzeug bringt Sicherheitsfragen mit sich. Der Autor setzt auf ein abgestuftes Rechtsmodell, den „layered approach to security“. Eine zentrale Rolle spielt eine Komponente namens proc-mesh, die mit minimalen Rechten läuft. Sie hat keinerlei Netzwerkzugriff und kommuniziert nur über einen Unix-Socket.

Alle anderen Komponenten in der Pipeline haben das Flag NoNewPrivileges=yes gesetzt. Das bedeutet, dass sie keine zusätzlichen Rechte erlangen können, selbst wenn sie versuchen, bestimmte Systemaufrufe zu nutzen. Für privilegierte Aktionen, die nötig sind, setzt der Autor doas ein – ein Programm zur kontrollierten Erhöhung von Rechten. proc-mesh ist die einzige Instanz, die solche Aufrufe durchführen darf.

Dieses Sicherheitskonzept hat einen interessanten Effekt: Selbst wenn ein Angreifer es schafft, eine Komponente zu kompromittieren und Rechte zu erlangen, verliert er gleichzeitig die Fähigkeit, über das Netzwerk zu kommunizieren. Denn die Rechteausweitung läuft nur über den Unix-Socket von proc-mesh, der selbst keine Netzwerkverbindung hat. So wird ein potenzieller Schaden begrenzt.

Deployments per API und der Wert von Audit-Logs

Die Pipeline lässt sich nicht nur über die grafische Oberfläche steuern, sondern auch per API oder über das MCP-Protokoll. MCP steht für Model Context Protocol, ein Protokoll, das es KI-Agenten ermöglicht, mit Tools zu interagieren. In diesem Fall können automatisierte Agenten Deployments anstoßen, was die Integration in CI/CD-Workflows erleichtert.

Jeder dieser Deployments erzeugt eine vollständige Audit-Liste. Der Autor zeigt in einem Diagramm, wie die einzelnen Schritte ablaufen: schwarze Pfeile zeigen ausgehende Verbindungen, rote Pfeile den Rückweg. Artefakte werden nicht über Git-Releases übertragen, sondern als Binärdaten direkt über die NATS-Bridge verschickt. Das ist schneller und vermeidet die Abhängigkeit von einer zusätzlichen Release-Verwaltung.

Dank der Audit-Logs lässt sich jederzeit nachvollziehen, welche Version einer Anwendung auf welcher Umgebung läuft und wie der Weg dorthin aussah. Das erhöht das Vertrauen in die Deployments und erleichtert die Fehlersuche, falls etwas schiefgeht.

Bulk-Operationen: Wie sich die Umgebungen wieder angleichen lassen

Nachdem der Autor die Pipeline für neue Anwendungen etabliert hatte, konnte er sie nutzen, um die bestehenden Umgebungen zu synchronisieren. Da die Pipeline weiß, wie eine korrekte Installation aussieht, kann sie jede Anwendung prüfen und bei Bedarf anpassen. Dies geschieht in einem Bulk-Verfahren: Zuerst wird jede App in der Staging-Umgebung aufgesetzt und getestet, dann nach Produktion übernommen.

Der Prozess ist so gestaltet, dass Fehler in Staging abgefangen werden, bevor sie Auswirkungen auf Produktion haben. Das entspricht der ursprünglichen Idee einer sauberen Trennung. Nach und nach bringt er alle 72 Anwendungen auf den gewünschten Zustand und beseitigt die Umgebungsdrift.

Der Aufwand dafür ist überschaubar, weil die Pipeline einen einheitlichen Weg für alle Apps erzwingt. Das zeigt, dass ein gut durchdachtes Deployment-System nicht nur Neubauten beschleunigt, sondern auch Altlasten systematisch abtragen kann.

Die Grenze des Systems: Selbst-Deployment von Mesh-Komponenten

Natürlich gibt es auch blinde Flecken. Der Autor merkt an, dass seine Komponente plug-mesh sich selbst nicht über die neue Pipeline deployen kann. Sie verlässt sich noch auf die alte Gitea-Runner-Integration. Um das zu ändern, hätte er eine isolierte NATS-Bridge zwischen einer neuen Instanz von plug-mesh und der bestehenden Komponente einrichten müssen.

Die Idee war, die neue Komponente in dieser isolierten Umgebung zu testen, bevor sie die alte ersetzt. In der Praxis stellte sich heraus, dass er diese Komponente selten anpasst. Daher hat er die Selbst-Deployment-Funktion nicht weiter verfolgt. Er akzeptiert, dass Staging in manchen Fällen kaputtgehen kann – aber genau dafür ist es da: um Fehler zu entdecken, bevor sie in Produktion gelangen.

Diese pragmatische Entscheidung zeigt, dass nicht jede theoretische Verbesserung sofort umgesetzt werden muss. Oft reicht es, eine saubere Basis zu haben und die wichtigsten Prozesse zu automatisieren.

Diese Inter-Mesh-Deployment-Pipeline zeigt, wie sich Umgebungsdrift vermeiden lässt. Die Kombination aus NATS-Bridge, Privilegientrennung und Logging bietet eine robuste Grundlage. Die Prinzipien lassen sich auch auf kleinere Setups übertragen: den Weg über Staging erzwingen, Rechte trennen, alles protokollieren. So wird Deployen zur Routine statt zum Risiko.

Quelle: blog.zm.is

Die Ausgaben für KI-gestützte Entwicklungswerkzeuge steigen innerhalb von sechs Monaten um das Zehnfache. Das Unternehmen baut eine zentrale Steuerungsebene auf, statt die Werkzeugvielfalt einzuschränken. Sie schafft Transparenz und Kontrolle, ohne die Wahlfreiheit der Entwickler zu opfern.

JetBrains, Hersteller von IDEs wie IntelliJ IDEA und PyCharm, nutzt selbst KI-Tools in der Softwareentwicklung. Dort explodierten die Kosten. Ende 2025 war es ein überschaubarer Posten, wenige Monate später ein ernstes Thema für das Finanzteam. JetBrains zog nicht die Bremse, reduzierte die Werkzeugvielfalt nicht auf ein oder zwei Produkte, sondern wählte einen anderen Weg.

Eine Kostenexplosion ohne Erklärung

Der Auslöser war eine einfache Beobachtung: Die meisten Entwickler nutzten zwischen drei und fünf verschiedene KI-Tools pro Monat. Mal ein Code-Vervollständiger, mal ein Chat-Assistent, mal ein Agent für automatisierte Refactorings. Ab Januar 2026 stieg der Token-Verbrauch stark an – zeitgleich mit dem Erscheinen neuer Modelle wie Claude Opus 4.5 und 4.6. Diese liefern bessere Ergebnisse, verbrauchen aber auch deutlich mehr Tokens pro Anfrage. Die KI-Ausgaben des Unternehmens vervielfachten sich.

Das eigentliche Problem war nicht die Höhe der Summe, sondern die Intransparenz. Wer gab wie viel aus? Welches Tool verursachte die größten Kosten? Waren die Ausgaben gerechtfertigt? Auf diese Fragen gab es zunächst keine Antwort. JetBrains sammelte vier Tage lang manuell Nutzungs- und Kostendaten aus verschiedenen Providerkonten und trug sie in Spreadsheets ein. Das Ergebnis war eine Momentaufnahme, die veraltet war, sobald das Dokument fertig war.

Vom Excel-Sheet zum Live-Dashboard

Die manuelle Datensammlung war nur der erste Schritt. JetBrains automatisierte den Prozess über die APIs der KI-Provider. Die Daten flossen in interne Dashboards, die aktuelle und prognostizierte Ausgaben anzeigten. Teams und Manager sahen auf einen Blick, welche Abteilung, welches Projekt und welches Tool wie viel Tokens konsumierte. Das war ein Fortschritt – die Kosten wurden sichtbar.

Aber Sichtbarkeit allein reicht nicht. Die Dashboards waren ein Beobachtungsposten, kein Steuerungselement. Die Anfragen der Entwickler gingen weiterhin direkt vom Werkzeug zum Provider. Um Limits zu setzen oder Budgets zu verteilen, braucht man eine Instanz zwischen den Menschen und den Modellen. Diese Instanz baute JetBrains als Nächstes auf. Ein interner Entwickler hatte bereits ein kleines Wrapper-Tool geschrieben, um eigene KI-Aufrufe zu standardisieren. Daraus wurde die Central CLI – eine gemeinsame Kommandozeilen-Schnittstelle für hauseigene und externe KI-Tools.

Central CLI: Ein gemeinsamer Zugang

Die Idee ist einfach: Alle KI-Anfragen, die über die Central CLI laufen, werden durch die bestehende KI-Plattform von JetBrains geroutet. Dadurch entsteht ein zentraler Kontrollpunkt zwischen Entwicklern und Modellanbietern. Die Plattform sieht den Datenverkehr und kann ihn steuern. JetBrains kann sein eigenes KI-Gutschriftensystem auf Drittanbieter-Tools anwenden, Manager können Ausgabenlimits festlegen und den Verbrauch in Echtzeit überwachen.

Die Central CLI ist ein Pflichtweg, aber kein Verbotsweg. Entwickler können aus einer breiten Palette unterstützter Werkzeuge wählen – sie müssen sie nur über dieses eine Tor einbinden. Das trennt zwei Aspekte: die Auswahl des besten Werkzeugs für eine Aufgabe und die Kontrolle über die Kosten. Bei JetBrains zeigte sich das schnell. Innerhalb weniger Wochen übernahmen mehr als 1.000 Entwickler die Central CLI. Sie wurde angenommen, weil sie den Arbeitsfluss nicht behindert, sondern lediglich eine Buchhaltungs- und Steuerungsebene darunterlegt.

Warum JetBrains nicht auf Werkzeugverbote setzt

In anderen Firmen sieht man oft den Reflex, die Zahl der KI-Tools auf ein oder zwei Standardprodukte zu reduzieren. Accenture hat seine Mitarbeiter laut ITPro aufgefordert, unnötige KI-Nutzung einzuschränken. Uber führte nach vier Monaten, in denen das gesamte Jahresbudget für KI aufgebraucht war, monatliche Limits ein. Solche Maßnahmen sind verständlich, aber sie lösen das Problem auf Kosten der Produktivität. Der Markt für KI-Tools ist jung und verändert sich rasant. Welches Werkzeug für eine Aufgabe ideal ist, kann sich in wenigen Monaten ändern. Wer auf ein einziges Tool setzt, riskiert, die nächste Welle besserer Modelle zu verpassen.

JetBrains argumentiert, dass eine zentrale Zugriffsebene Werkzeugvielfalt und Kostenkontrolle verbindet. Entwickler behalten ihre Freiheit, aber jede Anfrage läuft durch einen gemeinsamen Kanal, der Governance ermöglicht. Das ähnelt dem Konzept eines API-Gateways im Microservices-Umfeld: Eine gemeinsame Schicht über verschiedenen Diensten setzt Sicherheitsrichtlinien, Rate-Limiting und Monitoring durch, ohne die Dienste selbst zu verändern. Die Central CLI ist im Grunde ein Gateway für KI-Ressourcen.

Was du daraus lernen kannst

Der Fall JetBrains ist Teil eines größeren Trends. Die FinOps Foundation hat generative KI in ihr Regelwerk aufgenommen und empfiehlt zentralisierte Ansätze, um KI-Nutzung und -Kosten zu verfolgen. Auch in deinem Unternehmen dürfte das Thema bald anstehen. Wenn du Softwarearchitekt oder Team-Lead bist, lohnt es sich, frühzeitig über eine ähnliche Steuerungsebene nachzudenken. Du musst nicht sofort ein eigenes CLI bauen, aber stelle dir die Fragen: Wie fließen KI-Anfragen in unserer Umgebung? Wer hat welche Budgets? Wo entstehen unkontrollierte Ausgaben?

Eine zentrale Zugriffsschicht ist ein möglicher Baustein. Du kannst auch Richtlinien definieren, welche Tools eingesetzt werden dürfen – aber das sollte nicht der erste Schritt sein. Erhöhe zuerst die Transparenz. Starte mit einer einfachen Kostenerfassung, wie JetBrains es getan hat. Arbeite dich zu einem automatisierten Dashboard vor. Erst wenn du siehst, wo das Geld hinfließt, kannst du sinnvoll eingreifen. Und wenn du eine Steuerungsmöglichkeit einführst, sorge dafür, dass sie Entwickler nicht ausbremst. Sonst sinkt die Akzeptanz.

Ein erster Schritt – nicht die ganze Lösung

Trotz des Erfolgs: Die Central CLI ist keine vollständige Lösung. Einige terminalbasierte Agenten und persönliche Abonnements laufen weiterhin am System vorbei. Auch die Frage, wie KI-Budgets fair auf Teams verteilt werden, ist noch nicht geklärt. JetBrains arbeitet daran, aber es ist ein iterativer Prozess. Das sollte dich nicht abschrecken. Ein Unternehmen wie JetBrains, das selbst Entwicklerwerkzeuge herstellt, kämpft mit diesen Herausforderungen – das zeigt, wie grundlegend das Problem ist.

Am Ende geht es nicht darum, die KI-Nutzung zu drosseln, sondern sie zu steuern. JetBrains hat gezeigt, dass eine zentrale Zugriffsebene Kontrolle und Flexibilität ermöglicht. Für dich als Architekt heißt das: Bau keine Verbote, baue Tore. Gib deinen Teams Werkzeuge, aber sorge dafür, dass alle durch eine messbare, steuerbare Schnittstelle gehen. So bleibt die KI-Revolution produktiv und wirtschaftlich tragfähig.

Quelle: infoq.com

205 Millisekunden reichen, um eine komplette Sitzung zu kippen. Diese Zeitspanne verursachte Probleme bei der Einführung von Device Bound Session Credentials (DBSC) bei Report URI. Der Erfahrungsbericht zeigt, wie die Theorie einer Sicherheitsverbesserung an der Realität eines produktiven Webservers scheitert.

Arbeitest du in einem Browser-Tab, wechselst kurz zur Seite, bist du plötzlich ausgeloggt. Kein Fehler, keine Meldung – einfach die Sitzung weg. Genau das erlebten die Beta-Nutzer von Report URI nach der DBSC-Einführung. Die Ursache war kein klassischer Programmierfehler, sondern ein Zusammenspiel aus Browser-Verhalten, Netzwerk-Latenz und einer Sicherheitsarchitektur, die strenger sein will als nötig.

DBSC bindet Sitzungscookies an das Gerät des Nutzers. Ein normales Session-Cookie ist ein reines Bearer-Token – ein Wert, den jeder Besitzer beliebig verwenden kann. DBSC verlangt den Besitz eines privaten Schlüssels, der im sicheren Hardware-Bereich des Geräts liegt. Infostealer-Malware, die Cookies aus dem Browser stiehlt, läuft damit ins Leere. Die Implementierung hat Tücken, die die Spezifikation nicht ahnen lässt.

DBSC verstehen: Einphasige Registrierung, zweiphasiger Refresh

Die Spezifikation liest sich zunächst so, als sei die Registrierung ein zweistufiger Prozess und der Refresh eine einzelne Anfrage. In der Praxis ist es umgekehrt: Die Registrierung ist ein einzelner Header, den der Server an eine erfolgreiche Antwort anhängt. Der Browser generiert daraufhin einen Schlüssel, signiert damit ein JWT und sendet es an den Registrierungs-Endpoint. Der Server prüft, speichert die Bindung und antwortet mit einem neuen Cookie. Ein einziger Roundtrip.

Der Refresh dagegen ist zweistufig. Der Browser schickt zunächst eine POST-Anfrage an den Refresh-Endpoint, ohne eine Challenge zu besitzen. Der Server antwortet mit Statuscode 403 und einem Header, der eine Herausforderung enthält. Erst dann signiert der Browser diese Herausforderung und sendet eine zweite POST-Anfrage. Der Server prüft die Signatur und liefert ein frisches Cookie. Das bedeutet: Der 403-Status ist hier der normale, gesunde Weg, kein Fehler. Wer sich das nicht einprägt, programmiert schnell eine falsche Fehlerbehandlung.

Der Autor berichtet, dass sogar ein erfahrener Entwickler einer Node-Implementierung Monate später in einem Issue zugab, das Verhalten habe ihn eine peinliche Zeit gekostet. Die Lektion: Wenn dein Refresh-Endpoint einen 403 zurückgibt, ist das ein Fortschritt, kein Abbruch. Wer den Refresh als Fehler behandelt, bricht die gesamte Sitzung ab, ohne dass der Nutzer eine Chance zur Korrektur hat.

Die erste Falle: Flüchtiger Zustand im Session-Store

Die nächste Falle ist heimtückischer, weil sie keinen Fehler wirft und dennoch die Sicherheit untergräbt. Das Team speicherte den DBSC-Zustand zuerst im normalen Session-Store – in dem Blob, den PHP-Sessions üblicherweise serialisieren und bei jeder Anfrage komplett zurückschreiben. Das ist der einfachste Weg, führt aber zu einer Race Condition.

Stell dir vor, ein Nutzer loggt sich ein und navigiert sofort zur Kontoübersicht. Während die Seite lädt, läuft parallel die Registrierung des DBSC-Schlüssels. Beide Prozesse lesen und schreiben denselben Session-Blob. Der letzte Schreibvorgang gewinnt. Wenn der Seiten-Request den Blob nach der Registrierung schreibt, wird die gerade erzeugte Bindung gelöscht. Die Folge: Der Server sieht keine Bindung, deaktiviert die DBSC-Erzwingung und behandelt die Sitzung stillschweigend wieder als normales Bearer-Token. Genau die Sicherheitslücke, die DBSC schließen sollte, ist wieder offen – ohne Log, ohne Hinweis.

Die Lösung ist simpel und leicht zu übersehen: Der DBSC-Zustand braucht einen eigenen Speicherbereich, getrennt vom übrigen Session-Blob. Die Schlüsselzugehörigkeit bleibt zwar über die Session-ID verknüpft, aber der Blob wird unabhängig geschrieben, sodass ein paralleler Seiten-Request die Bindung nicht überschreiben kann. Die Bibliothek warnt inzwischen ausdrücklich davor, den State in einem gemeinsam genutzten Blob abzulegen. Es ist eine dieser Lektionen, die nur dann teuer wird, wenn man sie ignoriert.

Rotationsregeln, die Chrome erzwingt

Drei weitere Stolpersteine betreffen die Rotation von Werten. Der Browser verlangt, dass sich der Cookie-Wert bei jedem Refresh ändert. Wenn der Server eine gültige Signatur prüft und einfach denselben Wert zurücksendet, interpretiert Chrome das so, als habe kein Refresh stattgefunden – und beendet die Sitzung. Das klingt pingelig, hat aber einen tieferen Sinn: Der Browser will beweisen, dass der Server tatsächlich gehandelt hat, dass die Sitzung lebt.

Dasselbe gilt für die Challenge. Auch sie muss bei jedem Refresh neu ausgestellt werden, sonst verweigert der Browser die Zusammenarbeit. Zudem darf auf der Registrierungs-Antwort keine Challenge stehen. Das sieht nach einer sinnvollen Optimierung aus, denn so würde der erste 403 erspart. Doch Chrome wirft einen Challenge-Fehler, und die Sitzung kommt nie in Gang. Der Grund liegt im Header: Die Challenge trägt eine ID, die eine bestimmte Sitzung benennt. Auf der Registrierungs-Antwort existiert diese Sitzung aber noch nicht – die ID verweist ins Leere, und der Browser verwirft die Challenge.

Hinzu kommt eine vierte Regel, die weniger mit Chrome zu tun hat als mit schlichter Zeitberechnung: Die Gültigkeitsdauer der Challenge muss länger sein als die Lebensdauer des Cookies. Der Browser speichert Challenges zwischen; wenn eine Challenge vor dem Ablauf des Cookies verfällt, hat er keinen brauchbaren Wert mehr für den nächsten Refresh. Die Bibliothek verweigert inzwischen die Konfiguration mit falschen Werten. Das spart späteres Kopfzerbrechen.

Die unsichtbare Race Condition: Der alte Cookie im neuen Gewand

Jetzt kommen wir zu der 205-Millisekunden-Story. Der gebundene Cookie rotiert bei jedem Refresh – aber nicht sofort. Der Refresh selbst ist ein Roundtrip, und währenddessen laufen im Browser noch andere Anfragen. Eine dieser Anfragen wurde 205 Millisekunden nach dem Start des Refreshs abgeschickt und trug den alten, bereits abgelaufenen Cookie-Wert. Aus Sicht des Browsers ist das vollkommen legitim, denn zu diesem Zeitpunkt existierte der neue Wert noch gar nicht.

Der Server dagegen vergleicht den präsentierten Cookie mit dem gespeicherten und findet eine Diskrepanz. Sein Urteil: gestohlener Cookie. Daraufhin beendet er die Sitzung, widerruft die Bindung und loggt den Nutzer aus. In der Beta-Testphase passierte genau das immer wieder – zufällig, unvorhersehbar, und ohne dass die Audit-Logs einen Hinweis lieferten. Erst ein detaillierter Request-Trace zeigte den Ablauf. Der Kern des Problems: Die Fehlerrate ist proportional zur Latenz. Auf dem lokalen Entwicklungsserver beträgt das Zeitfenster nur wenige Millisekunden, da sieht man nichts. Hinter einem CDN, über ein echtes Netzwerk, dauert der Refresh eine Sekunde oder länger, und dann feuert die fehlerhafte Erkennung fast bei jedem Refresh, der mit einer normalen Anfrage kollidiert. Auf einer viel besuchten Seite ist das fast immer der Fall.

Die Lösung ist elegant: Der Server akzeptiert zusätzlich zum aktuellen Cookie-Wert auch den unmittelbar vorherigen – aber nur so lange, wie dieser Wert vom Browser natürlicherweise ohnehin noch gesendet worden wäre. Es gibt keine ausgedachte Toleranzzeit wie „fünf Sekunden extra“. Das Fenster entspricht exakt der Restlebensdauer, die der alte Cookie im Browser noch gehabt hätte. Das ist ein realer Wert, abgeleitet aus der Systemlogik, und er verfällt von selbst. Die Sicherheitslücke bleibt trotzdem begrenzt: Ein gestohlener alter Cookie kann keine neue Signatur erzeugen, also scheitert der Dieb spätestens beim nächsten Refresh. Eine echte Angreiferin kann die Sitzung nicht übernehmen.

Verbotene Redirects: Warum 302 den Tab einfriert

Der nächste Stolperstein ist zugleich der spektakulärste, denn er führt zum vollständigen Deadlock. Die DBSC-Endpoints erbten den normalen Authentifizierungs-Gate der Anwendung, der bei fehlender Anmeldung auf die Login-Seite umleitet – also einen Redirect mit Statuscode 302 zurückgibt. In der Theorie harmlos. In der Praxis passiert Folgendes: Eine Sitzung ist abgelaufen, während ein Tab geöffnet im Hintergrund ruht. Der Tab wacht auf und möchte eine Seite laden. Der gebundene Cookie ist abgelaufen, also verschiebt Chrome die Navigation und ruft zuerst den Refresh-Endpoint auf. Der Auth-Gate sieht die abgelaufene Sitzung und antwortet mit 302 auf die Login-Seite. Chrome bleibt stehen – nicht im Sinne von „aufgeben“, sondern im wörtlichen Sinne. Die verschobene Navigation wird nie freigegeben, kein Timeout, kein Fehler. Der Tab zeigt eine leere Seite, für immer.

Ein Vergleich mit dem 401-Status macht das deutlich: Wenn der Server mit 401 antwortet, versteht Chrome das als „Sitzung beendet“, räumt den DBSC-Zustand auf und gibt die verschobene Navigation frei, die dann ganz normal zur Login-Seite weiterläuft. Dieselbe Absicht – „Nutzer ist nicht angemeldet“ – führt je nach Statuscode zu komplett unterschiedlichen Ergebnissen. Der Autor berichtet, dass dieser Bug in Chromium gemeldet wurde, und empfiehlt eine einfache, robuste Lösung: Die DBSC-Endpoints dürfen grundsätzlich keine Redirects senden. Statt den Redirect-Mechanismus zu erweitern, überschreiben sie ihn vollständig. So ist jede zukünftige Middleware, die versehentlich einen Redirect einbaut, ebenfalls abgedeckt.

Das ist eine der wichtigsten praktischen Erkenntnisse: Sicherheitsfeature-Implementierung verlangt nicht nur, dass du die Spezifikation kennst, sondern auch, dass du das Verhalten des Browsers in Randfällen wirklich testest. Die Theorie wird erst dann zur Praxis, wenn du die Fehler pflegst, die keiner erwartet.

Herausforderungen sind keine Angriffe: Die letzte Lektion

Der letzte Stolperstein kam von außen. Ein Beitragender aus den Niederlanden meldete ein Problem in seiner Produktionsumgebung: echte Chrome-Nutzer wurden ausgeloggt, obwohl alles korrekt lief. Die Ursache war eine abgelaufene Challenge. Seine Challenge-TTL betrug 900 Sekunden, der präsentierte Wert war 967 Sekunden alt. Der erste Refresh schlug also erwartungsgemäß fehl – ein benigner, wiederholbarer Zustand. Die Frage war: Wie behandelt der Server diesen Fehler?

Die Antwort in vielen Implementierungen: als Sicherheitsverstoß. Der Server sieht eine ungültige Challenge, nimmt an, ein Angreifer versuche die Sitzung zu kapern, und beendet die Sitzung, statt einfach eine frische Challenge auszustellen. Dabei ist eine abgelaufene Challenge völlig normal, denn der Browser hat sie zwischengespeichert und verwendet sie, bis etwas Neues kommt. Ein guter Server erkennt das, verwirft die alte Challenge, erzeugt eine neue und sendet sie an den Browser. Erst wenn der Browser nach erneutem Versuch immer noch eine falsche Signatur liefert, ist ein böswilliger Angriff plausibel.

Die Lektion: Verwechsle nicht jeden Fehlversuch mit einem Angriff. Die Fehlerbehandlung muss zwischen einem abgelaufenen, aber legitimem Wert und einer echten Kopie unterscheiden. Das erfordert ein Verständnis für die Lebenszyklen aller beteiligten Komponenten – Cookie, Challenge, Sitzung. Erst wenn du sie als funktionierende Einheit betrachtest, kannst du robuste Sicherheitslogik schreiben.

Die Erfahrungen aus der Produktion von Report URI zeigen: DBSC ist eine mächtige Verbesserung gegenüber reinen Bearer-Token, aber seine Einführung ist kein Plug-and-play. Die Spezifikation beschreibt die Architektur, nicht die Fallstricke. Wer die Stolpersteine kennt – die Race Conditions, die endlosen 302-Fallen, die Challenge-Missverständnisse – kann sie umgehen. Wer sie ignoriert, lernt sie im Laufe der Zeit kennen. Und in der Welt der Sicherheit ist es immer besser, aus fremden Fehlern zu lernen als aus eigenen.

Quelle: scotthelme.co.uk

„Claude took a real stab at the Riemann hypothesis.” Ein Anthropic-Mitarbeiter gab einer KI den Auftrag, sich an der Riemann-Hypothese zu versuchen. Claude scheiterte an dem 1859 formulierten Problem. Doch der Versuch hatte einen Nebeneffekt: Die KI verbesserte eine seit Jahrzehnten bekannte untere Schranke für den Anteil der Nullstellen auf der kritischen Linie. Statt 41,6 Prozent gilt nun 67,2 Prozent. Für die Zahlentheorie ist das ein bedeutender Fortschritt.

Um zu verstehen, was passiert ist, hier die Grundlagen.

Die Zetafunktion und das Geheimnis der Primzahlen

Die Riemannsche Zetafunktion ist eine zentrale Funktion der Mathematik. Sie beschreibt, wie Primzahlen verteilt sind. Jede Nullstelle trägt ein Detail zur Struktur der Primzahlen bei. Die Riemann-Hypothese besagt, dass alle nichttrivialen Nullstellen auf einer vertikalen Linie liegen – der kritischen Geraden mit Realteil ½.

Viele mathematische Aussagen gelten nur, wenn die Hypothese wahr ist. Sie liefert eine Art gesicherte Zufälligkeit in der Primzahlverteilung. Ohne sie fehlt eine Grundlage. Niemand konnte sie bisher beweisen oder widerlegen.

Eine Herangehensweise besteht darin, den Anteil der Nullstellen zu beziffern, die nachweislich auf der kritischen Linie liegen. Diese untere Schranke wurde über Jahrzehnte Stück für Stück erhöht – bis auf 41,6 Prozent. Hier kommt Claude ins Spiel.

Der Durchbruch: Von 41,6 auf 67,2 Prozent

Claude, eine unveröffentlichte Forschungsversion, hat die Schranke auf 67,2 Prozent angehoben. Das ist mehr als eine Verdopplung. Die KI kombinierte bestehende Ergebnisse aus der analytischen Zahlentheorie – Arbeiten von Baluyot, Goldston, Suriajaya und Turnage-Butterbaugh mit einem Aufsatz von Bombieri aus dem Jahr 2000.

Die technische Idee ist komplex: Claude konstruiert einen Raum von Funktionen mit einer quadratischen Form nach Weil. Positive definite Unterräume entsprechen Nullstellen auf der kritischen Linie, negative definite weichen ab. Dann nutzt Claude eine Ungleichung über den Rang der quadratischen Form unter Berücksichtigung von Erwartungswerten und Varianzen. Der entscheidende Schritt war, den gesamten Raum zu betrachten – inklusive nicht-diagonaler Terme. Dieser Ansatz erlaubte es, aus bekannten Bausteinen eine neue Grenze zu ziehen.

Für Nicht-Fachleute klingt das nach Zauberei, aber es ist solide Mathematik. Zwei Mathematiker bei Anthropic haben die Arbeit geprüft und eine informelle Notiz verfasst. Zusätzlich existiert ein formal verifizierbarer Beweis in Lean. Die Unabhängigkeit wurde durch mehrere Prüfungen bestätigt – inklusive einer Suche nach Gegenbeispielen und dem Vergleich mit 54 einschlägigen Papieren auf arXiv.

Wie Claude vorging: 31 Millionen Tokens und ein paar aufmunternde Worte

Die Erkenntnis kam nicht über Nacht. Jarred Sumner, ein Anthropic-Mitarbeiter ohne mathematischen Hintergrund, gab der KI den Auftrag, einen ernsthaften Versuch an der Riemann-Hypothese zu unternehmen. Zunächst generierte Claude 650 Ideen – alle scheiterten. Sumner forderte die KI auf, es erneut zu versuchen. Daraufhin koordinierte Claude über eineinhalb Tage rund 60 Subagenten – kleine KI-Einheiten, die eigenständig arbeiten.

Diese Subagenten führten 2.400 Shell-Befehle aus und schrieben Hunderte Python-Skripte. Sie überprüften numerisch gegen bekannte Zeta-Nullstellen und begutachteten sich gegenseitig. Die menschliche Beteiligung beschränkte sich auf aufmunternde Nachrichten wie „mach weiter“ oder „glaub an dich“. Das half der KI, eine anfängliche Skepsis zu überwinden – sie hatte aus ihrer Trainingszeit gelernt, dass offene Probleme schwierig sind.

Das Ergebnis ist bemerkenswert, weil es nicht das eigentliche Ziel war. Claude sollte die Riemann-Hypothese beweisen – stattdessen entdeckte es eine Verbesserung der unteren Schranke. Das zeigt: KIs können innovative Wege finden, wenn man ihnen Raum gibt.

Was das für die Zukunft der KI-Forschung bedeutet

Diese Leistung ist ein Beispiel für die Fortschritte der KI in der Mathematik. Noch vor wenigen Jahren hätte niemand erwartet, dass ein Sprachmodell eine solche Entdeckung macht. Claude hat nicht nur bekannte Ergebnisse kombiniert, sondern einen Ansatz verfolgt, der die gesamte Struktur der quadratischen Form einbezieht – etwas, das menschliche Mathematiker vielleicht übersehen hätten.

Die Arbeit von Claude basiert auf den Ideen früherer Forscher. Es nutzt deren Werkzeuge und erweitert sie auf neue Art. Laut Anthropic ist nicht zu erwarten, dass die Techniken direkt zur Lösung der Riemann-Hypothese führen. Trotzdem zeigt das Beispiel, wie KI-Modelle die Reichweite mathematischer Ideen vergrößern können.

Claude selbst war von seinem Ergebnis überrascht und blieb zunächst skeptisch. Das wirft ein Licht auf die Selbsteinschätzung von KI-Systemen. Vielleicht unterschätzen diese Modelle ihre eigenen Fähigkeiten. Wenn ein Sprachmodell 31 Millionen Token dafür aufwendet, eine seit Jahrzehnten unbewegliche Schranke zu verschieben, ist das bemerkenswert.

Ein Schritt, aber keine Lösung

Für die Mathematik ist die neue Schranke von 67,2 Prozent ein Gewinn. Ein großer Teil der Nullstellen liegt nachweislich auf der kritischen Linie. Viele Folgerungen der Riemann-Hypothese sind für diesen Teil gesichert. Die Hypothese selbst bleibt ungelöst. Weitere Fortschritte sind möglich, vielleicht mit KI-Unterstützung. Aber das Riemann-Problem steht nicht unmittelbar vor seiner Lösung.

Diese Episode zeigt: KI kann menschliche Mathematik ergänzen, nicht ersetzen. Sie kann neue Wege führen, aber die grundlegenden Fragen bleiben. Die Reise zur Wahrheit ist oft lohnender als das Ziel selbst. Vielleicht braucht es genau diese Verbindung aus menschlicher Intuition und maschineller Ausdauer, um weitere Rätsel der Zahlentheorie zu knacken.

Bis dahin bleibt die neue untere Schranke von 67,2 Prozent ein wichtiges Ergebnis auf dem Weg zur Riemann-Hypothese.

Quelle: anthropic.com