--- title: "KI-Coding-Agenten 2026: Der Engpass war Kontext" canonical: https://wavect.io/de/blog/ai-coding-agents-context-not-intelligence/ language: de description: "Rakuten ließ einen Coding-Agenten 7 Stunden mit 99,9% Genauigkeit laufen. Die Lektion: Kontext, nicht Intelligenz, war der Engpass. So steuerst du Agenten." image: "https://wavect.io/img/blog/headers/header_ai-coding-agents-context-not-intelligence.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 Min Lesezeit · 23. Juni 2026 [**Weiter**](/de/blog/internal-ai-adoption-2026/) # Der Engpass in Software war nie Intelligenz. Es war Kontext. TL;DR Rakuten richtete einen Coding-Agenten auf vLLM und ließ ihn eine bestimmte Methode implementieren. Er lief rund sieben Stunden mit gelegentlicher menschlicher Anleitung und traf 99,9% numerische Genauigkeit gegenüber der Referenz. Die virale Zahl "12,5 Millionen Zeilen Code" ist etwa zwanzigmal zu hoch; der eigentliche Punkt ist, dass der Agent eine große, unbekannte, mehrsprachige Codebasis durchquerte und die Änderung an der richtigen Stelle platzierte. Die Lektion: Der Engpass war nie Intelligenz, sondern Kontext. Menschen ermüden und machen Fehler, wenn sie ein großes System im Kopf halten, Agenten bekommen diese Kontext-Müdigkeit nicht. Das löscht keine Engineers aus, es verlagert die Arbeit. Wer skaliert, ist gut darin, Agenten zu steuern, ihnen den richtigen Kontext zu geben, Output mit Tests und Guardrails abzusichern und wie ein Senior zu prüfen, um die selbstbewusste falsche Antwort abzufangen. Delegation wurde zur neuen Deep Work. Eine Geschichte macht immer wieder die Runde: Rakuten gab [einem KI-Coding-Agenten](/de/glossary/llm/) 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 in echter Kundenarbeit, das ist also weniger eine steile These 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](https://www.anthropic.com/news/claude-4) 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](https://claude.com/customers/rakuten): Ein Engineer richtete Claude Code auf [vLLM](https://github.com/vllm-project/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](/de/blog/reduce-llm-token-costs-2026/) 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](/de/blog/meterless-ai-agent-context-layer-review/). Wenn dir vor allem Cross-File-Beziehungen fehlen, vergleicht unser [Graphify Buyer Review](/de/blog/graphify-review-codebase-knowledge-graph/) 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](/de/blog/git-worktrees-vs-jujutsu-ai-coding-agents/) zwischen optimierter Git Baseline und messbarem Jujutsu-Pilot. Für die Werkzeugebene, die diesen Kontext zwischen Sessions festhält, siehe unser [Graft Review](/de/blog/graft-review-agent-repo-map/) zur Frage, ob eine Repo-Map ins Git gehört oder ein neu baubarer lokaler Cache bleibt. ## 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](/de/blog/vibe-code-production-readiness-checklist/) 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. ![Kevin Riedl](/img/team/kevin.webp) "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. Semaprax ist eine Forschungsantwort auf dieses Kontextproblem, kein Beleg, dass eine neue Sprache es löst. Der [Semaprax Benchmark](/de/semaprax/benchmarks/) fixiert einen kleinen strukturierten Kontextvertrag und veröffentlicht seine Grenzen. Er misst noch keine Modelltokens, Aufgabenqualität oder Kosten im Repository-Maßstab. ## Fazit Die Rakuten-Geschichte ist kein Beleg dafür, dass KI klüger ist als deine Engineers. Sie ist ein Beleg dafür, dass der Engpass nie Intelligenz war. Es war Kontext, und die menschlichen Kosten, ein großes System im Kopf zu halten, ohne müde Fehler zu machen. Agenten bekommen keine Kontext-Müdigkeit, und das ist die eigentliche Verschiebung. Also verlagert sich der Job. Die Engineers, die skalieren, sind die, die gut darin wurden, Agenten zu steuern, ihnen den richtigen Kontext zu geben und die selbstbewusste falsche Antwort abzufangen, bevor sie live geht. Delegation wurde zur neuen Deep Work. Die Zahl, die man ignorieren sollte, ist 12,5 Millionen Zeilen. Die Fähigkeit, die man aufbauen sollte, ist genau zu wissen, wonach man fragt, und zu erkennen, wenn der Agent gleich etwas Dummes tut. ## Das könnte dich auch interessieren.. [**Programmiersprachen werden unwichtiger. Software Engineering wird wichtiger.** Das evidenzbasierte Follow-up: Syntax und Boilerplate werden billiger, während System Design, Runtime-Verständnis, Memory Safety, Verifikation und Wartbarkeit gewinnen.](/de/blog/programming-languages-matter-less-ai/) [**AI Enablement vs eine generische KI-Beratung** Die eine reicht dir ein Strategie-Deck. Die andere liefert ein funktionierendes Setup auf deiner Infrastruktur, das dein Team besitzt und betreiben kann.](/de/compare/ai-enablement-vs-generic-ai-consultancy/) Agent Engineering ## In diesem Cluster weiterlesen Coding Agents, MCP, Kontextsysteme, Evaluation und Kontrollen für verlässliche Automatisierung. [Mit dem Grundlagenartikel starten**Graph Engineering für KI-Agenten: Wann lohnt sich ein Knowledge Graph?**](/de/blog/graph-engineering-ai-agents/) - [OpenViking im Test 2026: Ist Dateisystem-Memory produktionsreif?](/de/blog/openviking-agent-memory-review/) - [LLM-as-a-Verifier erklärt: Architektur, Kosten und Produktionseinsatz](/de/blog/llm-as-a-verifier/) - [TrueForge im Test: Ist das Open-Source Agent Harness produktionsreif?](/de/blog/trueforge-agent-harness-review/) - [Agentenlesbare Websites: llms.txt, Markdown-Spiegel und was kaputtgeht](/de/blog/agent-readable-website-llms-txt-markdown-mirrors/) - [Lokalisierte URLs zerlegen hreflang: ein englischer Slug genügt](/de/blog/english-slugs-vs-localized-urls-hreflang/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 Min Lesezeit · 23. Juni 2026 [**Weiter**](/de/blog/internal-ai-adoption-2026/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/ai-coding-agents-context-not-intelligence/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/de/blog/ai-coding-agents-context-not-intelligence/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Rakuten richtete einen Coding-Agenten auf vLLM und ließ ihn eine bestimmte Methode implementieren. Er lief rund sieben Stunden mit gelegentlicher menschlicher Anleitung und traf 99,9% numerische Genauigkeit gegenüber der Referenz. Die virale Zahl \"12,5 Millionen Zeilen Code\" ist etwa zwanzigmal zu hoch; der eigentliche Punkt ist, dass der Agent eine große, unbekannte, mehrsprachige Codebasis durchquerte und die Änderung an der richtigen Stelle platzierte. Die Lektion: Der Engpass war nie Intelligenz, sondern Kontext. Menschen ermüden und machen Fehler, wenn sie ein großes System im Kopf halten, Agenten bekommen diese Kontext-Müdigkeit nicht. Das löscht keine Engineers aus, es verlagert die Arbeit. Wer skaliert, ist gut darin, Agenten zu steuern, ihnen den richtigen Kontext zu geben, Output mit Tests und Guardrails abzusichern und wie ein Senior zu prüfen, um die selbstbewusste falsche Antwort abzufangen. Delegation wurde zur neuen Deep Work.", "articleBody": " Blog-Übersicht/AI und Agents/Agent Engineering Der Engpass in Software war nie Intelligenz. Es war Kontext. TL;DR Rakuten richtete einen Coding-Agenten auf vLLM und ließ ihn eine bestimmte Methode implementieren. Er lief rund sieben Stunden mit gelegentlicher menschlicher Anleitung und traf 99,9% numerische Genauigkeit gegenüber der Referenz. Die virale Zahl \"12,5 Millionen Zeilen Code\" ist etwa zwanzigmal zu hoch; der eigentliche Punkt ist, dass der Agent eine große, unbekannte, mehrsprachige Codebasis durchquerte und die Änderung an der richtigen Stelle platzierte. Die Lektion: Der Engpass war nie Intelligenz, sondern Kontext. Menschen ermüden und machen Fehler, wenn sie ein großes System im Kopf halten, Agenten bekommen diese Kontext-Müdigkeit nicht. Das löscht keine Engineers aus, es verlagert die Arbeit. Wer skaliert, ist gut darin, Agenten zu steuern, ihnen den richtigen Kontext zu geben, Output mit Tests und Guardrails abzusichern und wie ein Senior zu prüfen, um die selbstbewusste falsche Antwort abzufangen. Delegation wurde zur neuen Deep Work. 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 in echter Kundenarbeit, das ist also weniger eine steile These 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", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-07", "datePublished": "2026-06-23", "description": "Rakuten richtete einen Coding-Agenten auf vLLM und ließ ihn eine bestimmte Methode implementieren. Er lief rund sieben Stunden mit gelegentlicher menschlicher Anleitung und traf 99,9% numerische Genauigkeit gegenüber der Referenz. Die virale Zahl \"12,5 Millionen Zeilen Code\" ist etwa zwanzigmal zu hoch; der eigentliche Punkt ist, dass der Agent eine große, unbekannte, mehrsprachige Codebasis durchquerte und die Änderung an der richtigen Stelle platzierte. Die Lektion: Der Engpass war nie Intelligenz, sondern Kontext. Menschen ermüden und machen Fehler, wenn sie ein großes System im Kopf halten, Agenten bekommen diese Kontext-Müdigkeit nicht. Das löscht keine Engineers aus, es verlagert die Arbeit. Wer skaliert, ist gut darin, Agenten zu steuern, ihnen den richtigen Kontext zu geben, Output mit Tests und Guardrails abzusichern und wie ein Senior zu prüfen, um die selbstbewusste falsche Antwort abzufangen. Delegation wurde zur neuen Deep Work.", "headline": "Der Engpass war nie Intelligenz. Es war Kontext.", "image": "https://wavect.io/img/blog/headers/header_ai-coding-agents-context-not-intelligence.svg", "inLanguage": "de", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/ai-coding-agents-context-not-intelligence/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/ai-coding-agents-context-not-intelligence/", "wordCount": 1989 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/agent-engineering/", "name": "Agent Engineering", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/ai-coding-agents-context-not-intelligence/", "name": "KI-Coding-Agenten 2026: Der Engpass war Kontext | ", "position": 5 } ] } ```