Der Engpass in Software war nie Intelligenz. Es war Kontext.

Eine Geschichte macht immer wieder die Runde: Rakuten gab einem KI-Coding-Agenten eine einzige Aufgabe in einem großen Open-Source-Projekt, ging weg und kam Stunden später zu funktionierendem Code zurück. Es ist eine gute Geschichte. Sie stimmt größtenteils. Und der Teil, den alle wiederholen, die Stunden und die Genauigkeitszahl, ist der am wenigsten interessante. Interessant ist, warum es überhaupt funktioniert hat, und was das über den Job des Engineerings heute sagt.

Das ist eine Engineering-Perspektive, kein Vendor-Pitch. Wir steuern Coding-Agenten jede Woche auf echter Kundenarbeit, also ist das weniger ein heißes Take als eine Beschreibung, wie sich die Arbeit tatsächlich verändert hat.

Was ist bei Rakuten wirklich passiert?

Hier die Fakten, sorgfältig formuliert, denn die virale Version bläst einen davon auf. Beim Launch von Claude Opus 4 im Mai 2025 sagte Anthropic, Rakuten habe das Modell mit einem anspruchsvollen Open-Source-Refactor validiert, der rund sieben Stunden eigenständig lief. Das Detail kam später, in Rakutens eigener Kundengeschichte: Ein Engineer richtete Claude Code auf vLLM, die Open-Source-Inference-Engine, und bat es, eine bestimmte Methode zur Extraktion von Aktivierungsvektoren zu implementieren. Das Ergebnis traf laut Bericht 99,9% numerische Genauigkeit gegenüber der Referenzimplementierung.

Zwei ehrliche Korrekturen, weil wir lieber richtig als dramatisch sind:

• Es lief nicht unbeaufsichtigt. Der Engineer beschrieb, über diese Stunden gelegentlich Anleitung gegeben zu haben. "Lief sieben Stunden eigenständig" ist echt und beeindruckend. "Voll autonom, null Menschen" ist nicht das, was passiert ist.
• 99,9% ist eine enge Kennzahl. Es ist die numerische Genauigkeit der Ausgabe einer Methode gegenüber einer Referenz, keine allgemeine Aussage, dass der Agent zu 99,9% bei allem richtig liegt. Nützlich, spezifisch und leicht als Schlagzeile misszuverstehen.

Und die Zahl, die das Internet am liebsten mag, dass vLLM "12,5 Millionen Zeilen Code" sei, ist die, bei der man am skeptischsten sein sollte. Sie steht in Rakutens eigenem Text, also zitieren Leute sie in gutem Glauben, aber sie ist um etwa das Zwanzigfache daneben. Der vLLM-Kern liegt in der Größenordnung von 84.000 Zeilen Python und unter 600.000 Zeilen über alle Sprachen. Auf 12,5 Millionen kommt man nur, wenn man Dinge zählt, über die niemand nachdenkt: die gesamte Git-Historie, jedes verwandte Repository, eingebundene und generierte Kernel. Der eigentliche Punkt übersteht die Korrektur sauber: Claude bewegte sich durch eine große, mehrsprachige Codebasis, die es nie gesehen hatte, in Python, CUDA und C++, und platzierte eine Änderung an der richtigen Stelle. Das ist das Beeindruckende. Die Zeilenzahl war es nie.

Warum war Kontext der eigentliche Engpass, nicht Intelligenz?

Zieht man die Demo auf ihren Kern zusammen, ist die Lektion fast langweilig. Ein erfahrener Engineer, der vLLM bereits kannte, hätte diese Methode auch schreiben können. Ein neuer Mitarbeiter auch, irgendwann, nach Wochen mit Fehlversuchen. Der Unterschied zwischen dem Senior und dem Neuen war nie rohe Intelligenz. Es war, wie viel von der Codebasis jeder gleichzeitig im Kopf halten und durchdenken konnte.

Das ist der Engpass in den meisten Softwarearbeiten. Nicht "kann ein kluger Mensch das herausfinden", sondern "kann überhaupt jemand genug von diesem System im Arbeitsgedächtnis halten, um die richtige Änderung an der richtigen Stelle zu machen, ohne drei andere zu brechen". Auf einer großen Codebasis ist das wirklich schwer, und es ist auf eine Weise schwer, die nichts damit zu tun hat, wie clever du bist.

Was bedeutet "KI bekommt keine Kontext-Müdigkeit" eigentlich?

Menschen sind schlecht darin, großen Kontext über lange Strecken zu halten, und nicht, weil wir dumm wären. Wir werden müde. Wir vergessen das, was wir vor vierzig Dateien gelesen haben. Wir machen eine Pause und verlieren den Faden. Wir machen spät in einer langen Sitzung kleine Fehler, die wir in der ersten Stunde nie gemacht hätten. Ein weitläufiges mentales Modell eines Systems zu halten, ist anstrengend, und Erschöpfung ist, woher die Bugs kommen.

Ein Coding-Agent wird auf diese Weise nicht müde. Er kann den relevanten Ausschnitt einer großen Codebasis vor sich behalten und in Stunde sieben genauso konsistent durchdenken wie in Minute zehn. Das ist der eigentliche Hebel in der Rakuten-Geschichte. Nicht, dass das Modell klüger ist als ein erfahrener Engineer, sondern dass es über eine lange, kontextschwere Aufgabe nicht so abbaut wie ein Mensch. Anhaltender Kontext, nicht überlegene Intelligenz.

Der Haken, und er ist real, ist: Der Agent denkt nur über den Kontext gut nach, den er tatsächlich bekommt. Richte ihn auf die falschen Dateien oder halte ihm die entscheidenden Rahmenbedingungen vor, und er baut selbstbewusst und ohne Müdigkeit das Falsche. Ihm den richtigen Kontext zu geben, ist jetzt die Fähigkeit. Über die Kostenseite dieser Disziplin haben wir in wie du LLM-Token-Kosten 2026 senkst geschrieben: Kontext managen, nicht nur Tokens ausgeben, ist der Großteil des Spiels.

Verschwinden damit die Engineers?

Nein, und wer das vorhersagt, verkauft meist etwas. Was passiert, ist, dass sich die Arbeit verlagert. Die Engineers, die gerade skalieren, sind meist nicht die, die jede Zeile von Hand schreiben. Es sind die, die gut darin geworden sind, Agenten zu steuern, Output kritisch zu prüfen und den Moment zu erkennen, in dem ein Agent gleich etwas Dummes tut.

Diese letzte Fähigkeit wird unterschätzt. Ein Agent produziert selbstbewussten, gut formatierten, plausiblen Code, der subtil falsch ist, und ein Junior-Reviewer winkt ihn durch, weil er richtig aussieht. Das zu erwischen, erfordert genau das Urteilsvermögen, das Jahre des Code-Schreibens von Hand aufbauen. Die Erfahrung wird nicht wertlos. Sie verändert sich von "ich tippe die Lösung" zu "ich erkenne die falsche Lösung, bevor sie live geht". Wenn du eine konkrete Version dieser Prüfung willst, ist unsere Vibe-Code-Produktionsreife-Checkliste genau die Liste, gegen die wir Agenten-Output prüfen.

Wie sieht gutes Engineering aus, wenn Agenten den Code schreiben?

Delegation wurde zur neuen Deep Work. Die tiefen, wertvollen Stunden waren früher die, die man kopfüber damit verbrachte, die schwere Funktion zu schreiben. Zunehmend sind es die, die man damit verbringt, eine Aufgabe präzise zuzuschneiden, den richtigen Kontext zusammenzustellen und das Zurückkommende mit scharfem Auge zu prüfen. Das ist ein wirklich anderer Muskel, und viele starke Engineers haben ihn noch nicht aufgebaut, weil der Engpass ihre ganze Laufbahn lang das Tippen der Lösung war, nicht das Spezifizieren.

Gutes Engineering in diesem Modus sieht so aus: eine enge, klar definierte Aufgabe; der richtige Kontext, dem Agenten vorab übergeben; Tests und Guardrails, die die falsche Antwort automatisch abfangen; und ein Mensch, der wie ein Senior prüft, nicht wie ein Abnickstempel. Der Agent ist schnell und unermüdlich. Der Engineer entscheidet, was "richtig" heißt, und verifiziert, dass es wirklich dort angekommen ist.

"Der Agent wird nicht müde, die ganze Codebasis im Kopf zu halten. Du schon. Das ist die ganze Verschiebung. Dein Job ging vom Schreiben jeder Zeile dazu über, zu entscheiden, was richtig heißt, und es abzufangen, wenn der Agent es falsch macht."

Wie solltest du deinen Workflow um Coding-Agenten herum umbauen?

Wenn du das Rakuten-Ergebnis auf deiner eigenen Arbeit willst, die Schritte, auf die es ankommt, in der Reihenfolge:

1. Die Aufgabe eng zuschneiden. "Implementiere diese bestimmte Methode, passend zu dieser Referenz" schlägt "verbessere die Inference-Schicht". Eine präzise Aufgabe machte sieben unbeaufsichtigte Stunden möglich. Eine vage produziert sieben Stunden selbstbewusster Fehlversuche.
2. Gib ihm den richtigen Kontext, nicht den ganzen. Richte den Agenten auf die Dateien, Schnittstellen und Rahmenbedingungen, die wirklich zählen. Mehr Kontext ist nicht besser; der richtige Kontext ist es. Hier liegt jetzt der Großteil der Fähigkeit.
3. Mit Tests und Guardrails absichern. Der Grund, warum Rakuten dem Output trauen konnte, war eine Referenz zum Abgleichen. Reproduziere das: eine Test-Suite, eine Referenz, ein Guardrail, das laut fehlschlägt, wenn die Antwort falsch ist.
4. Prüfe wie ein Senior, nicht wie ein Abnickstempel. Lies den Diff auf die subtilen, plausibel aussehenden Fehler, die kompilieren und einen flüchtigen Blick bestehen. Das ist die wirkungsvollste Stunde, die du investierst.
5. Halte Eigenverantwortung und Wissen im Haus. Ein Agent, der Code ausliefert, den niemand im Team versteht, ist eine Abhängigkeit, kein Gewinn. Stelle sicher, dass ein Mensch verantwortet und erklären kann, was ausgeliefert wurde.

Nichts davon ist exotisch. Es ist dieselbe Disziplin, die gutes Engineering immer brauchte, nur neu gewichtet: weniger Zeit, den Code zu produzieren, viel mehr Zeit, ihn zu spezifizieren und zu verifizieren.