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

Eine Fallstudie eines Anbieters wird häufig zitiert: Rakuten gab einem KI-Coding-Agenten eine konkrete Aufgabe in einem großen Open-Source-Projekt und berichtete nach einer langen Sitzung ein funktionierendes Ergebnis. Das Ereignis ist real, aber keine kontrollierte Produktivitätsstudie und kein Beleg für eine allgemeine Theorie über Coding-Agenten. Die engere Lehre ist nützlich: klar abgegrenzte Aufgaben, relevanter Repository-Kontext, ausführbare Prüfungen und menschliches Review können einem Agenten längere nützliche Arbeit in einem unbekannten System ermöglichen.

Das ist eine Engineering-Perspektive, kein Anbieter-Pitch. Die Fakten und Quellen wurden am 2. September 2026 geprüft. Fähigkeiten und Produktivität variieren je nach Modell, Tool, Repository, Aufgabe, Reviewer und Evaluationsmethode.

Was ist bei Rakuten wirklich passiert?

Beim Launch von Claude Opus 4 im Mai 2025 erklärte Anthropic, Rakuten habe das Modell bei einem Open-Source-Refactor getestet, der rund sieben Stunden lief. In Anthropics Rakuten-Kundenbericht bat ein Engineer Claude Code, in vLLM eine bestimmte Methode zur Extraktion von Aktivierungsvektoren zu implementieren. Der Bericht nennt 99,9% numerische Genauigkeit gegenüber einer Referenzimplementierung. Das sind vom Anbieter veröffentlichte Kundenaussagen, kein unabhängiger Benchmark.

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

• Es wurde nicht als vollständig unbeaufsichtigt belegt. Laut Bericht gab der Engineer gelegentlich Anleitung. Behandle "autonom" als Beschreibung des Herausgebers, nicht als Beleg für null menschliche Eingriffe.
• 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.

Die gleiche Geschichte bezeichnet vLLM als Codebasis mit 12,5 Millionen Zeilen, veröffentlicht aber weder Zählmethode noch Revision, einbezogene Repositories oder den Umgang mit generiertem und vendortem Code. Verwende diese Zahl nicht als gemessene Repository-Größe. Belegt ist nur, dass die Aufgabe ein großes, mehrsprachiges Open-Source-System und eine konkrete Referenzimplementierung betraf.

Warum war Kontext der eigentliche Engpass, nicht Intelligenz?

Der Fall stützt eine praktische Hypothese, kein universelles Gesetz: Repository-Kontext und Feedback können Engpässe sein, selbst wenn ein Modell plausiblen Code erzeugen kann. Engineers bringen außerdem stilles Domänenwissen, Architekturgeschichte, Produkturteil und Verantwortung mit, die sich nicht durch das Laden weiterer Dateien erfassen lassen.

Die nützliche Frage lautet nicht, ob Kontext oder Intelligenz der einzige Engpass ist. Entscheidend ist, ob der Agent für diese Aufgabe relevanten Code, Grenzen, Werkzeuge, Tests und Feedback erhielt und ob der Reviewer Fehler erkennt, die die Prüfungen nicht abdecken.

Wo liegen die Grenzen von Kontext bei langen Agentenläufen?

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 erlebt keine menschliche Ermüdung. Das bedeutet aber weder stabiles Reasoning über sieben Stunden noch perfekte Nutzung eines großen Kontextfensters. Modelle können relevante Informationen verlieren, neuere Beobachtungen übergewichten, frühe Fehler fortschreiben oder ihr Kontextbudget verbrauchen. Long-Context-Forschung zeigt, dass Leistung stark davon abhängen kann, wo relevante Information steht. Lange Agentenläufe brauchen deshalb Kontextauswahl, Zusammenfassungen, Checkpoints, Tests und Wiederherstellungspfade.

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.

Eine konkrete Architektur, die dauerhaftes Memory, gemeinsamen Zustand, begrenztes Reasoning und Intent-Routing trennt, prüft unser faktenbasierter Meterless Context-Layer-Test.

Wenn dir vor allem Cross-File-Beziehungen fehlen, vergleicht unser Graphify Buyer Review eine Codebase Knowledge Graph mit Repository-Suche und RAG und gibt dir einen messbaren Zwei-Wochen-Test.

Wenn parallele Agenten als Nächstes Repository-Setup und Change Integration belasten, hilft unser Entscheidungs-Guide zu Git Worktrees vs. Jujutsu zwischen optimierter Git Baseline und messbarem Jujutsu-Pilot.

Für die Werkzeugebene, die diesen Kontext zwischen Sessions festhält, siehe unser Graft Review zur Frage, ob eine Repo-Map ins Git gehört oder ein neu baubarer lokaler Cache bleibt.

Verschwinden damit die Engineers?

Dieser Fall kann keine Beschäftigungsfrage beantworten. Er zeigt einen technischen Workflow, kein Arbeitsmarktergebnis und keinen universellen Produktivitätsgewinn. Coding-Agenten können Arbeit in Richtung Aufgabendesign, Kontextvorbereitung, Tool-Aufsicht und Review verschieben. Der Effekt variiert zwischen Teams und Aufgaben.

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 kann zu konzentrierter Engineering-Arbeit werden: Aufgabe zuschneiden, Belege zusammenstellen, Akzeptanzkriterien definieren und Ergebnis prüfen. Implementierungswissen bleibt nötig, weil Reviewer System und Folgen der Änderung verstehen müssen.

Gutes Engineering nutzt eine begrenzte Aufgabe, relevanten Kontext, Werkzeuge mit minimalen Rechten, reproduzierbare Prüfungen, einen reviewbaren Diff und eine qualifizierte menschliche Entscheidung. Tests senken Risiko, beweisen aber nur das, was sie abdecken.

"Ein Agent erlebt keine menschliche Ermüdung, hat aber weiterhin begrenzten Kontext und eigene Fehlerbilder. Der Engineering-Vorteil entsteht durch ausgewählte Belege, definierte Prüfungen und Review, nicht durch die Annahme, er halte die ganze Codebasis perfekt."

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" ist besser testbar als "verbessere die Inference-Schicht". Präzision senkt Mehrdeutigkeit, garantiert aber keinen unbeaufsichtigten Erfolg.
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. Nutze relevante Tests, Referenzen, statische Prüfungen und Sicherheitskontrollen. Behandle bestandene Prüfungen als Beleg innerhalb ihrer Abdeckung, nicht als Korrektheitsbeweis.
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.

Visuelle Arbeit braucht dieselbe Behandlung. Unser Leitfaden zum Claude-Code-Designsystem zeigt, wie freigegebene Beispiele, Markenevidenz und Umsetzungsregeln zu dauerhaftem Repository-Kontext werden, statt in jedem Prompt neu aufzutauchen.

Semaprax ist eine Forschungsantwort auf dieses Kontextproblem, kein Beleg, dass eine neue Sprache es löst. Der Semaprax Benchmark fixiert einen kleinen strukturierten Kontextvertrag und veröffentlicht seine Grenzen. Er misst noch keine Modelltokens, Aufgabenqualität oder Kosten im Repository-Maßstab.