Rakuten setzt OpenAI Codex als Coding-Agent an drei Engstellen ein, Incident-Response, CI/CD-Prüfungen und die Umsetzung unklarer Spezifikationen. Das Unternehmen berichtet über rund 50% weniger Mean-Time-to-Recovery (MTTR), schnelleres, konsistenteres Code-Review und Projekte, die statt eines Quartals in wenigen Wochen lieferbar werden.
Übersicht:
Warum ausgerechnet jetzt Agenten-Workflows greifen
Rakuten entwickelt und betreibt Produkte in einem breiten Portfolio, von E-Commerce über Fintech bis Mobilfunk, und skaliert das über eine weltweit große Belegschaft. In so einer Umgebung ist Geschwindigkeit nur dann wertvoll, wenn sie zuverlässig bleibt, weil jeder Release und jede Störung in viele Systeme ausstrahlen kann. Hintergrundinfos zu Rakuten finden sich auf der Konzernseite Rakuten Group, Inc..
Rakuten treibt deshalb Agenten-Workflows nicht als Experiment, sondern als Betriebsmittel. Codex wird als verlässlicher Baustein in den Engineering-Alltag integriert, dort wo sich Durchlaufzeiten stapeln, Diagnose im Betrieb, Prüfungen vor dem Release, Umsetzung größerer Vorhaben. Was OpenAI unter Codex als Coding-Agent versteht, beschreibt die Produktseite Codex.
Die interne Leitidee lässt sich als Dreiklang lesen, schneller bauen, sicherer ausliefern, autonomer umsetzen. Der entscheidende Punkt ist die Koppelung, mehr Tempo entsteht nicht durch mehr Code, sondern durch weniger Leerlauf zwischen Erkennen, Entscheiden, Prüfen und Ausrollen.
Wie aus Alarmen schneller Fixes werden
Rakuten misst Geschwindigkeit auch im Betrieb, nicht nur im Feature-Backlog. Wenn APIs auffällig werden, zählt die Zeit vom Alert bis zur belastbaren Abhilfe, genau dafür steht MTTR, Mean-Time-to-Recovery. Rakuten schätzt den Effekt von Codex in diesem Bereich auf rund 50% weniger MTTR, praktisch bedeutet das, Störungen werden etwa doppelt so schnell behoben.
Was Codex im SRE-Alltag konkret abnimmt
In vielen Teams ist die Diagnosearbeit ein Patchwork aus Telemetrie, Log-Suchen, Hypothesen und Quick-Fixes. Rakuten nutzt dafür KQL, eine Abfragesprache für Log- und Telemetriedaten im Azure-Umfeld. Microsoft beschreibt KQL als Sprache zum Erkunden und Analysieren großer Datenmengen, unter anderem in Monitoring- und Security-Kontexten. Kusto Query Language (KQL).
Codex läuft dabei nicht statt der Observability-Tools, sondern neben ihnen. Der Gewinn entsteht, wenn der Agent schneller Vorschläge für sinnvolle Abfragen, plausible Root-Causes und konkrete Fix-Ideen liefert, und Engineers die Zeit in Validierung und Rollout investieren, statt in das Zusammensuchen der Einzelteile.
Mini-Modell für den Nutzen im Betrieb
Für Incident-Response lässt sich der Business-Impact als Multiplikator denken:
- Tempo: schneller zur Hypothese, schneller zum Patch.
- Vertrauen: Fixes müssen testbar und nachvollziehbar sein, sonst entsteht nur „schneller Schaden“.
- Wiederholbarkeit: wenn Diagnosepfade als Agenten-Workflow standardisiert werden, wird aus Einzelfall-Know-how ein Team-Asset.
Wie Tempo steigt, ohne Sicherheitsnetze zu lösen
Je schneller Teams deployen, desto eher wird das Review zur Engstelle, oder es wird aus Zeitdruck oberflächlich. Rakuten umgeht dieses Dilemma, indem Codex direkt in der CI/CD-Pipeline mitläuft und dort Code-Review sowie Vulnerability-Checks automatisiert, bevor Änderungen Richtung Produktion gehen.
Guardrails statt Heldentum
Wichtig ist der Mechanismus hinter dem Versprechen „sicher und schnell“. Rakuten speist interne Coding-Standards in den Workflow ein, damit die Prüfungen nicht generisch bleiben, sondern zu den eigenen Regeln passen. So wird die Pipeline zu einem konstanten Gatekeeper, nicht zu einer wechselnden Meinungsrunde.
Praxisbeispiel für eine klare Prüflogik
Ein pragmatischer Ansatz für Teams, die Ähnliches aufbauen wollen, ist eine zweistufige Regel:
- Blocker: Findings, die den Merge verhindern, zum Beispiel sicherheitsrelevante Muster, fehlende Tests, offensichtliche Secret-Leaks.
- Verbesserungen: Vorschläge, die die Code-Qualität erhöhen, aber nicht zwingend release-kritisch sind, zum Beispiel Lesbarkeit, Namensgebung, kleinere Refactorings.
Codex kann beides liefern, entscheidend ist die harte Trennung, damit Geschwindigkeit nicht durch endlose „Nice-to-have“-Schleifen verloren geht.
Wie aus vagen Anforderungen lauffähige Software entsteht
Rakutens dritter Fokus zielt auf Autonomie, intern als „AI-nization“ beschrieben. Gemeint ist, dass Codex nicht nur Snippets liefert, sondern größere Vorhaben von einer Spezifikation bis zu nutzbaren Artefakten vorantreibt, selbst wenn Anforderungen unvollständig sind.
Praxisbeispiel aus dem Full-Stack
Als Referenz nennt Rakuten ein Projekt, bei dem ein bestehender webbasierten KI-Agenten-Service als mobile App umgesetzt wurde. Codex erstellte dazu eine Full-Stack-Implementierung mit Python/FastAPI im Backend und Swift/SwiftUI für iOS, inklusive Backend-APIs, ohne dass jede Einzelschritt-Anweisung manuell vorgegeben wurde. FastAPI ist ein gängiges Framework für Web-APIs in Python, die offizielle Dokumentation findet sich unter FastAPI.
Für die iOS-Oberfläche verweist Apple auf SwiftUI als Framework zum Aufbau von Apps über Apple-Plattformen hinweg, Überblick unter SwiftUI.
Rakuten beziffert den Zeiteffekt für dieses Vorhaben nicht als kleine Optimierung, sondern als Wechsel der Zeitskala, statt eines Quartals wurden Wochen genannt. Der Kernhebel ist nicht „Code tippen“, sondern die Fähigkeit, aus einer Spezifikation ein konsistentes Paket zu erzeugen, das anschließend getestet, gehärtet und integriert werden kann.
Was sich an der Entwicklerarbeit verschiebt
Mit mehr Agentenarbeit verlagert sich der Schwerpunkt von „alles selbst schreiben“ zu drei Tätigkeiten, Spezifikationen präzisieren, Ergebnisse gegen messbare Kriterien prüfen, und die Release-Qualität über Tests und Standards absichern. Rakuten unterstützt diese Umstellung laut Fallbeschreibung durch Workshops, auch über Engineering hinaus, damit Spezifikations- und Validierungsarbeit nicht an einzelnen Personen hängen bleibt.
Wann sich Codex lohnt, und wann nicht
Der Codex-Einsatz zahlt sich besonders dort aus, wo ein Team wiederkehrende Engpässe hat und Output objektiv prüfen kann. Ein Coding-Agent ist dann weniger „Magie“, sondern ein Beschleuniger für gut definierte Arbeitspakete mit klaren Abnahmekriterien.
Klare Entscheidungsregel
- Einsetzen, wenn Aufgaben einen definierten Rahmen haben, zum Beispiel Incident-Diagnose mit vorhandener Telemetrie, Code-Review nach internen Standards, oder Feature-Umsetzung mit Tests, Linter, Build-Pipeline.
- Zurückhaltend sein, wenn Anforderungen politisch oder fachlich ungeklärt sind, oder wenn es keine verlässliche Test- und Review-Infrastruktur gibt, dann steigt das Risiko, dass „schnell“ nur „schnell falsch“ bedeutet.
Ein praktischer Startpunkt für Teams
Wer den Rakuten-Ansatz nachbauen will, startet nicht mit einem großen Plattform-Umbau, sondern mit einem einzigen Workflow, der heute Zeit frisst, zum Beispiel eine wiederkehrende Incident-Klasse oder ein Review-Gate in der CI/CD-Pipeline. Sobald MTTR, Review-Durchlaufzeit oder Release-Frequenz messbar besser werden, lässt sich der Agenten-Workflow schrittweise ausweiten.
Für weiterführende, offizielle Einordnung von Codex bietet OpenAI neben der Produktseite auch eine Sammlung im Help Center unter Codex im OpenAI Help Center.