Skip to main content

How Rakuten uses Claude Code: enterprise case study

· 40 min read
Vadim Nicolai
Vadim Nicolai
Senior Software Engineer

The number everyone quotes from Rakuten's Claude Code rollout is 99.9%. It is also the number that gets read wrong most often.

Here is what actually happened, according to Anthropic's published customer material. An ML engineer named Kenta Naruse asked Claude Code to implement an activation-vector extraction method inside vLLM, the open-source LLM serving library. The agent ran for seven hours. Naruse, in Anthropic's telling, "didn't write any code during those seven hours." The result was reported at 99.9% numerical accuracy against the reference method (Anthropic 2026a).

Read that as a productivity claim and you will build the wrong thing inside your own company. Read it as a test result and the case study becomes genuinely useful.

Because 99.9% is not evidence that the model is good. It is evidence that the task had an oracle. Somebody, before the agent started, already knew how to compute the right answer independently — a reference implementation existed, and the agent's output could be diffed against it. That single structural fact explains more about why Rakuten's rollout produced results than any statement about model capability you will find in the marketing.

Everything below is vendor-published or self-reported. Rakuten and Anthropic produced essentially all of it; none of it has been independently audited; no baseline methodology accompanies the headline percentages. The independent critique that does exist — Kevin Riedl's June 2026 analysis of AI coding agents — takes aim at exactly one number and is right to (Riedl 2026). I will flag each claim's provenance as I go, because the difference between "Rakuten reported" and "Rakuten measured under a stated methodology" is the entire difference between a case study and an advertisement.

The Seven-Hour Run Is a Test Result Wearing a Productivity Costume​

Loading diagram…

Strip the framing and the vLLM incident has four components: a long-running autonomous agent, a bounded refactor, an independently computable reference, and a numerical comparison. Seven hours of unattended execution is the part that gets headlines. The reference comparison is the part that made the seven hours safe to allow (Anthropic 2026a).

This distinction matters because a 99.9% figure against a reference implementation is a differential test with a 1-in-1,000 tolerance, and a differential test says almost nothing about the properties enterprises actually pay for. It does not tell you the defect rate across the codebase. It does not tell you whether the merged code is maintainable, reviewable, or cheap to change in eighteen months. It does not tell you how many human hours of review the seven agent-hours generated on the other side.

Noriko Yamashita's 2013 comparative case study on code smells makes the general version of this argument a decade before anyone pointed it at an LLM: a metric is a proxy whose validity has to be demonstrated for the specific codebase under study, not assumed from the fact that it is computable (Yamashita 2013). Smell counts, complexity scores, and accuracy-against-reference-rate are all in the same category. They are instruments. Instruments drift, and instruments lie when you point them at the wrong object.

The strongest available counter-argument — that agentic coding has already crossed from web CRUD into genuine performance engineering — comes from You (2026), which documents Claude Code optimizing MuMax3, a GPU micromagnetic simulator, via CUDA-graph-based refactoring. That is kernel-level restructuring where correctness is numerical rather than stylistic, which is precisely the shape of task where an oracle is cheap to build and where the 7-hour, 99.9% pattern is plausible rather than miraculous. The paper's full-text speedup figures are not in the material I can verify, so I am not quoting them; the qualitative point stands without them, and the exact multiplier should be pulled from the paper before anyone repeats it. [NEEDS VERIFICATION]

Here is the uncomfortable implication. Naruse spent seven hours not writing code. Somebody else spent some unknown number of hours deciding that activation-vector extraction was the right thing to delegate, specifying it precisely enough that a reference implementation was the obvious acceptance criterion, and then reviewing whatever came back. The 99.9% is real. The zero-effort version of the story is not.

Nobody Published the Baseline, and That Makes 24-to-5 a Claim About Direction, Not Magnitude​

The flashiest figure in Anthropic's customer story is time-to-market for new features: 24 working days down to 5, a 79% reduction (Anthropic 2026a). Arithmetically that is a 4.8x improvement in cycle time. Operationally it is a number without a denominator.

What was the 24-day figure measured on? Which features? Which quarter? Was the pre-period measured prospectively, or reconstructed from memory after the tool was deployed? Was the post-period measured on comparable work, or on the subset of work that the tool happens to accelerate? None of that is published. Riedl (2026) makes the same complaint about the codebase-size figure — the customer story describes vLLM as "about 12.5 million lines," but never publishes the counting method: which revision, whether vendored dependencies were included, whether generated code was excluded (Riedl 2026). Count lines of a Python repository with and without its vendored tree and you can move the number by an order of magnitude without lying about a single character.

I am not going to repeat 12.5 million as fact. The honest description is what the source itself falls back on: a large, multi-language open-source codebase. Twelve-point-five million is a claim under dispute, and the dispute is legitimate.

The baseline problem is older and broader than this one vendor story. Arcuri (2020) frames enterprise digital transformation through BCG's Digital Acceleration Index and the "Bionic Company" model, and notes that roughly 80% of companies planned to increase digital investment in the post-COVID period — a figure drawn almost entirely from self-assessment instruments rather than audited outcomes (Arcuri 2020). When four out of five enterprises are grading their own transformation homework, a customer story reporting a 79% cycle-time reduction and no methodology joins a very large and very credulous population.

And the dashboard may not even be the binding problem. Nevo (2021) examines the gap between detection accuracy and human judgment — the finding being that even when an AI system's detection is accurate, human decision-makers do not reliably update their behavior in response. A 79% improvement that engineers and product managers do not believe in, or do not route work through, produces no organizational change at all. Which is the point at which measurement stops being a reporting problem and becomes a change-management one.

The Unit of Delegation Moved From a Chunk to a Goal, and That Is the Only Genuinely Reusable Finding​

Buried in the Q&A is the sentence that explains everything else. Before the current generation of models, Rakuten's teams had to cut work into well-defined chunks before handing it over. A multi-hour run was a gamble on the first decision. As Yusuke Kaji, Rakuten's General Manager of AI for Business, puts it: "If they choose the right path in the first step, everything is fine" (Anthropic 2026b).

That is a description of a variance problem, not a capability problem. Chunked delegation bounds the blast radius of a bad early decision to something a reviewer can absorb in minutes. Move to whole-goal delegation and the blast radius becomes the goal — seven hours, hundreds of files, one trajectory.

So what changed? Not, primarily, that models got smarter. What changed is that Rakuten's teams learned to state an end state and let the agent choose the steps, and — crucially — that they had something to check the end state against. The July 2026 Anthropic interview describes teams that now hand off whole tasks where they used to hand off well-specified fragments (Anthropic 2026c). Kaji's incentive here is obvious and worth naming: he is the internal sponsor of the program, and a narrative in which the constraint has moved from model capability to human judgment is a narrative in which his program's success is a matter of organizational learning rather than vendor roadmap.

But the claim survives the skepticism, because it is testable against Rakuten's own described practice. Non-engineers contribute through the terminal, with coding guidelines as the guardrail. A production-exception agent built by Applied AI lead Tanapat Ratana posts root-cause analysis to Slack and is packaged so non-engineers can stand it up for their own products. Agents live in Slack, Microsoft Teams, and an internal Kanban-style task system, with artifacts built in sandboxes. That is not a description of people using a better autocomplete. It is a description of an organization rewriting its work-decomposition boundary so that the unit of handoff is an outcome rather than a diff.

The failure mode of copying this is severe and silent. Teams that lift the goal-delegation pattern without lifting the acceptance criterion get the seven-hour runs and none of the 99.9%. They get a long unattended trajectory with no oracle at the end, reviewed by a human whose only check is "does this look plausible," which is exactly the review posture that lets a confident wrong answer through.

The Artifact You Have to Copy Is the Harness, and Almost None of It Is Made of Model​

Liu et al. (2026) state the structural point plainly: an agent is executed not by a single model call but by an execution harness managing observation, context, control, action, state, and verification, and frontier and open models are structurally specialized enough that they should be routed by task within that harness (Liu et al. 2026). Read against Rakuten's 24-parallel-session monorepo project — a task Naruse estimates would have taken over a month by hand — the harness is not a supporting character. It is the whole engineering.

The cleanest evidence that harness effects dwarf model effects comes from outside the enterprise-coding literature entirely. In ReTool, the same base model (Qwen2.5-32B-Instruct) reaches 67.0% on AIME2024 and 49.3% on AIME2025 when a code interpreter is in the loop during reinforcement learning, versus 40.0% and 36.7% for the text-only RL baseline — and it gets there in 400 training steps instead of over 1,000. It also beats s1-32B by 10.3% on AIME2024 (ReTool 2025). A 27-point swing on the same base model, purely from whether the loop could execute code and check the result. Substitute "unit tests" for "code interpreter" and you have the enterprise version of the same result.

Lin et al. (2026) give the enterprise reader the frame that the practitioner literature mostly lacks, mapping LLM systems onto computer architecture: LLM as CPU, KV cache as processor cache, context window as main memory, and listing cache reuse, context capacity, agent scheduling, and permission control as classical systems problems (Lin et al. 2026). Four systems problems. Three of them are capacity-and-scheduling problems that every enterprise that has ever run a build farm already understands. The fourth is the one that gets skipped.

Pham et al. (2026) close the loop with a case study of human-AI collaborative software development using Claude Code multi-agent orchestration for production-grade full-stack systems, and identify the gap as methodological rather than capability-based: the practical methodology for effective human-AI collaboration remains underexplored (Pham et al. 2026). Note what that means. The paper's own authors, describing their own method, say the method is the open question. Rakuten's 24 concurrent sessions and 7-hour runs are an existence proof that the harness can be made to work at that scale. They are not an effect size, and no paper in this corpus provides a controlled comparison against a human-only team.

Permissions Stop Being a UX Preference the Moment the Same Company Runs a Bank​

Rakuten is not a single product. It is more than 70 businesses spanning e-commerce, travel, fintech, digital content, and communications (Anthropic 2026a). That portfolio composition is why the permission question is the hard one, and it is the question the vendor material answers least.

Lin et al. (2026) treat permission control as a systems primitive on par with scheduling and cache management (Lin et al. 2026). In a company that operates a bank and a securities brokerage alongside a marketplace, an agent's permission scope is a regulated control, not a developer-experience dial. Karaiskos (2019) examines platform operator liability in Japan for C2C and B2C intermediation — the legal frame that determines what a marketplace operator owes when a transaction goes wrong (Karaiskos 2019). An agent that can read production data, write to a repository, and post to a shared Slack channel sits inside that frame whether or not anyone designed it to.

Nikiporets-Takigawa (2025) analyzes Japan's national cybersecurity strategy and the traps in its approach (Nikiporets-Takigawa 2025). The relevant trap for agentic coding is scope creep by convenience: you start with an agent that opens pull requests, you end with an agent that opens pull requests, reads incident data, and can be reconfigured by a non-engineer through a packaged template. Rakuten's own described design does exactly that last part — Ratana's production-exception agent is packaged so non-engineers can set it up for their own products (Anthropic 2026a).

That is a good product decision and a hard governance decision simultaneously. Every packaged agent template is a permission grant that a non-engineer can instantiate. At 70-plus business units, the number of instantiations is not bounded by the number of engineers who understand the permission model. Nothing in the published material describes how that bound is enforced — not role scoping, not approval workflow, not audit cadence. The sandboxed-artifact detail suggests execution isolation is handled. Execution isolation is the easy half.

Generation Got Cheap and Review Did Not, So Review Became the Factory Floor​

Ram et al. (2017) document rOpenSci's decision that making scientific software reproducible "could only be a community effort," built on open code review as a social process rather than an automated gate (Ram et al. 2017). The transferable structural finding is that review capacity, reviewer supply, and review norms are the rate limiter — and that they are deliberately constructed, not emergent.

Apply that to a 4.8x reduction in cycle time. If generation throughput rises by roughly a factor of five and review throughput does not move, the queue relocates. It does not disappear. It accumulates in front of the reviewer, and the reviewer's per-item attention drops until the review becomes a rubber stamp with extra steps.

Rakuten does run AI code review on pull requests (Anthropic 2026a), and that is the right instinct — but note what it does and does not solve. Automated review scales with code volume; it also produces findings at a rate proportional to code volume, which means it converts a human review bottleneck into a human triage bottleneck. Tang et al. (2024) describe exactly this architecture in CodeAgent, autonomous communicative agents for code review, where multiple specialized agents coordinate to produce review commentary (Tang et al. 2024). The system generates more, better-structured review signal. It does not generate the person who decides which of those signals blocks a merge.

You (2026) is the exception that proves the rule, and it is worth being precise about why. In the MuMax3 case, verification is numerical — the kernel either produces the correct field evolution or it does not (You 2026). No reviewer judgment required; the oracle arbitrates. Most enterprise work is not shaped like that. Most enterprise work is shaped like "should this endpoint paginate at the repository layer or the service layer," which has no oracle, only a convention, and the convention lives in the head of the person who has been there eleven years.

That is the constraint Rakuten's July 2026 material actually names: the bottleneck moved from who can write code to who understands the business problem. Human judgment, not agent capacity. At 24 parallel sessions per engineer, you are not short on code. You are short on people who can tell whether the code is right for this business.

The Reversal: Faster Generation Raises the Debt Intake, Not the Cost of Carrying It​

I expected the opposite, and I want to be explicit about that because the expectation is the common one. The intuition runs: agents handle the toil, humans handle the thinking, the codebase gets cleaner because the boring cleanup finally happens.

Silva et al. (2026) is the paper that breaks that intuition. Their multiple-case study proposes hybrid prioritization of self-admitted technical debt alongside static code analysis, on the explicit finding that neither human-flagged debt nor tool-flagged debt alone is sufficient (Silva et al. 2026). Read the implication carefully: debt triage already required a hybrid human-plus-tool process before agentic tools existed. The process was already the constraint. It was already the thing that could not keep up.

Now scale the input. A team that goes from 24 working days to 5 for feature delivery — a 4.8x increase in delivery cadence — is producing artifacts at roughly 4.8x the rate. Every one of those artifacts carries a debt decision: accept this shortcut, defer this refactor, tolerate this duplication. The triage queue does not need to get worse per item to become the binding constraint. It only needs the item count to rise.

And the instruments you would use to measure whether the resulting code is better are the instruments Yamashita (2013) warns about — smell counts and complexity proxies whose validity for this codebase has not been established (Yamashita 2013). This is the disagreement worth stating plainly, because the corpus contains both sides. The practitioner and vendor side says agentic coding reduces toil and therefore maintenance burden. The methodological side says volume rises, debt signals are noisy, and the metrics used to claim improvement are of unproven validity.

The skeptical side is stronger, and not because it has better outcome data — it has none. It is stronger because it rests on methodological findings that do not depend on any particular tool, while the optimistic side rests on outcome claims from parties who benefit from the claims being believed. There is no longitudinal study in this corpus in either direction. That absence is the single largest hole in every article written about this deployment, including this one.

The stakes are concrete. A team that reads 24-to-5 as a productivity dividend and staffs accordingly will find, somewhere around month nine, that its review and triage capacity is running at roughly a fifth of what the intake rate requires. The failure does not announce itself. It shows up as a slow drift in how much of the codebase anyone actually understands.

The 97% and the 30% Are the Numbers With the Smallest Denominator​

In a pilot of agents with memory, Rakuten reports 97% fewer initial critical errors, with cost and latency down more than 30% and no loss of output quality (Anthropic 2026b). Three numbers, one sentence, no stated scope.

Every word in that sentence is doing work. "Pilot" means a bounded population of tasks chosen by the people running the pilot. "Initial" means measured at some early stage before downstream correction — which is the stage where errors are cheapest and least consequential. "Critical" means a severity classification assigned by someone whose definition is not published. "With memory" means the intervention being evaluated is not the model but the persistent context layer around it, which is the harness again, and which is the thing I would actually want a controlled comparison for.

A 97% reduction in anything is a spectacular number. It is also the kind of number that emerges naturally when the baseline is a first-run draft with no context at all, compared against a run that starts with accumulated project memory. Of course the memory-equipped run produces fewer initial critical errors. The interesting question is what happens to the final error rate after human review, which is the number nobody publishes because it is much less dramatic.

Compare the metric Rakuten's July 2026 material describes tracking: task completion ratio alongside cost per task, with the largest model routed only to work where capability changes the outcome (Anthropic 2026c). That pairing is the most operationally sophisticated thing in any of these documents, and it is the one I would copy verbatim. Completion ratio without cost per task tells you the agent succeeded and bankrupted you. Cost per task without completion ratio tells you it was cheap and did nothing. Together they form a frontier, and routing the expensive model only to tasks where it moves the frontier is straightforwardly correct engineering.

The other tracked metrics — speed and ROI, innovation velocity, test coverage, and an internal "AI-nization ratio" — are softer. Test coverage is a real, computable number, but as Yamashita (2013) would remind you, it is a proxy, and coverage can rise while confidence falls if the tests are agent-authored against agent-authored code (Yamashita 2013). An "AI-nization ratio" measures adoption intensity, not value. It is the kind of metric that improves when people use the tool and tells you nothing about whether using the tool was the right call.

Every Benchmark You Would Use to Predict This Was Built on Code Rakuten Doesn't Own​

Ye et al. (2017) is the cleanest available demonstration of a failure mode that transfers exactly. Name-based nationality classifiers trained on small, unrepresentative sets of labeled names, typically extracted from Wikipedia, achieve limited performance (Ye et al. 2017). The classifier is not broken. The population it was trained and evaluated on is not the population it gets deployed against.

Substitute "public GitHub repositories" for "Wikipedia" and the argument transfers without modification. Agentic-coding benchmarks are built and evaluated on a population of code that is not Rakuten's proprietary, multi-decade, multi-language estate. SWE-bench — the benchmark that anchors most claims in this space — draws its task instances from a small set of popular open-source Python repositories, and its own analysis of successful patches uses Radon to compute cyclomatic complexity and Halstead complexity on the modified functions in the Oracle retrieval setting for repositories like psf/requests (Jimenez et al. 2024). Oracle retrieval means the model is handed the exact files that need changing. Rakuten's engineers are not handed the exact files. That gap between the benchmark condition and the production condition is not a rounding error; it is the entire difficulty of the task.

The same domain-shift caution applies to the rigorous-evaluation line of work. Liu et al. (2023) argue that code generated by models like ChatGPT must be evaluated rigorously rather than against thin test suites, because passing a handful of hand-written tests is not evidence of correctness (Liu et al. 2023). Li et al. (2023) built TACO, a topics-in-algorithmic-code-generation dataset, precisely because coverage of problem types in existing benchmarks is uneven (Li et al. 2023). Both are telling you the same thing: the measurement instrument was undersized relative to the claim.

Which is why the 99.9% number is worth defending in exactly one context and no others. Against a reference implementation on a specific numerical task, with the reference available before the run started, the measurement is sound because the oracle is sound. Extrapolate that to "Rakuten engineers are 99.9% accurate" and you have made precisely the error Ye et al. (2017) document — evaluating on a population that has nothing to do with the deployment population.

Rakuten Has Run This Play Before, and the Precedent Says Mandates Get Mediated​

Sato (2018) is a longitudinal organizational ethnography of Englishnization in Japanese firms and corporate in-house English training — the same genre of top-down mandate Rakuten is famous for, studied roughly 15 years before the Claude rollout (Sato 2018). The findings that matter here are not about language. They are that such programs are studied as discourse and curriculum problems, with resistance and middle-management mediation as central variables.

Fifteen years later, the AI rollout inherits that template whether or not anyone designed it to. A mandate arrives from the top. Middle managers decide what it means in practice for their teams. Some fraction of engineers quietly do not change their workflow because the tool does not touch the thing they actually spend their day on.

Boudreau and Holmström (2011) supply the mechanism for that last failure. Their loose-coupling analysis of IT implementation failure at MacGregor Crane describes relatively autonomous individuals who are "only loosely connected in terms of" practices, so the technology never binds to real work (Boudreau & Holmström 2011). Seat count is not usage. License rollout is not practice change. The failure mode is silent non-use by exactly the engineers whose workflows the tool does not touch — and it is invisible on every dashboard Rakuten describes tracking, including the AI-nization ratio, which measures the people who did adopt.

Against that, Cheung et al. (2024) describe Lifewood's 2022 transformation integrating GPT and Gemini across the organization, which commenced with a robust training program before tooling spread (Cheung et al. 2024). Training-first, tooling-second. Rakuten's material does mention new hires using Claude Code to learn the codebase and its architectural decisions, which is a training use case rather than a training program — and that distinction is the one I would want clarified before treating this rollout as replicable.

Whether Rakuten's actual mechanism was mandate, enablement, or both is not documented in any source I can verify. That is the single biggest unverified assumption in every secondary article on this topic, this one included.

Parallelism Multiplies Throughput Only Where the Merge Is Cheap​

Kaji describes the new working posture as having five tasks running at once, delegating four to Claude Code while focusing on the remaining one (Anthropic 2026b). Naruse's ambient agent splits a monorepo update across 24 parallel Claude Code sessions — work estimated at over a month by hand (Anthropic 2026c).

Twenty-four sessions running for one wall-clock hour is 24 agent-hours. That arithmetic is the entire appeal and the entire risk. Fan-out is free; fan-in is not.

Svejvig and Pries-Heje (2013) note that outsourcing "does however increase the complexity of coordination substantially" (Svejvig & Pries-Heje 2013). The same sentence applies to parallel agents with the word "outsourcing" swapped for "delegation." Twenty-four parallel sessions touching one monorepo produce a merge problem whose cost scales faster than the work saved, unless the changes are genuinely disjoint — which is exactly why monorepo-wide mechanical updates (dependency bumps, API signature migrations, lint fixes) are the ideal first target and feature work is not.

That is the decision rule I would apply. Parallelize work whose merged result is mechanically verifiable and whose individual diffs are independent. Do not parallelize work whose diffs interact, because the interaction surface between 24 agent-authored changes is where review capacity goes to die. Rakuten's most-cited parallel example happens to be the good case. That is not an accident, and it is not a general result.

The Cost Denominator Is Missing From Every Number Rakuten Has Published​

Moravec et al. (2025) examine generative AI's energy consumption as an enterprise-level constraint in the era of climate change (Moravec et al. 2025). No paper in this corpus connects agentic-coding token usage to enterprise cost or emissions at scale. That is an open question, not a settled fact, and I want to be careful not to overstate it.

But notice what is absent from the Rakuten material. Seven hours of unattended agent execution has a token bill. Twenty-four parallel sessions have a token bill 24 times larger per unit of wall-clock time. The Q&A reports cost down more than 30% in the memory pilot without publishing an absolute figure (Anthropic 2026b). Thirty percent of what?

The July 2026 material's cost-per-task metric is the right instrument here, and it is the only place in the published record where anyone asks the question in the correct form. Task completion ratio next to cost per task, with routing that sends the largest model only where capability changes the outcome (Anthropic 2026c). That is a cost-aware architecture. It is also a description of a routing policy whose thresholds are not published, which means you cannot tell whether the routing is aggressive or nominal.

Every enterprise evaluating this should ask a question no case study answers: what is the fully loaded cost per merged pull request, including tokens, review hours, and the share of human attention consumed by triage? Without that denominator, a 10x-faster issue closure rate is a numerator looking for a reason.

The Published Record Describes Agents Closing Issues 10x Faster Across Every Domain, Which Is Not a Measurable Claim​

The July 2026 blog states that Claude Managed Agents were deployed to product, sales, marketing, and finance within one week of availability, and that agents "close issues roughly 10x faster across every domain" (Anthropic 2026c).

Ten-x across every domain, in one week. Consider what has to be true for that sentence to be measurable. The baseline for "faster" must be established per domain, which means sales issue-closure time and finance issue-closure time must both have been measured before deployment. The definition of "issue" must be stable across four functions with genuinely different work. And the measurement must be attributable to the agent rather than to the deployment itself — because standing up a new intake system frequently speeds up closure by forcing triage that was previously implicit.

One week is not enough time to establish any of that. It is enough time to observe that the system is being used and that things feel faster, which is a legitimate early signal and not a 10x claim.

Deployment across four functions in seven days is, however, a real and impressive operational fact, and it is the one I would flag for anyone planning a rollout. It implies the packaging was done before the deployment window opened — templates, sandboxes, permissions, and intake surfaces all ready — rather than per-team. That is a maturity signal, and it lines up with Arcuri (2020)'s argument that maturity frameworks, not tools, are what differentiate transformation outcomes (Arcuri 2020). The organizations that deploy in a week are the ones that already know what they are deploying into.

The Literature Is Zero-for-Fifty on This Topic, and Three of the Hits Were Coupon Spam​

I want to record something about the research base itself, because it is a publishable observation and because it should change how you read coverage of this story.

Across the 50 retrieved records for a literature review on this topic, not one peer-reviewed paper studies Rakuten's Claude Code deployment. Zero. Every case study in circulation is vendor-published or trade press. Of those 50 records, three are Crossref entries authored by "Rakuten Discount Code" with titles in the promo-code genre. Two more are 1978–1982 papers about the word "code" — one on curriculum, one on graphic symbol systems. Keyword collision, not evidence.

Scholarly indexes are polluted by SEO records on high-value brand keywords. The practical consequence is that a naive literature review about a company like Rakuten is systematically unreliable, and a writer who does not check authorship will cite a coupon. The most useful framing paper in the corpus — Lin et al. (2026)'s operating-systems analogy for LLM systems — is about computer architecture, not software engineering (Lin et al. 2026). The strongest skeptical evidence about AI-code quality is a 2013 paper about code smells, published more than a decade before the tools it critiques (Yamashita 2013). The evidence base for this topic is assembled sideways or not at all.

That is worth 30 seconds of your attention the next time you read a confident synthesis of "what the research says" about enterprise AI coding. The research, in this case, largely does not say anything, because it has not been done.

Two things make this case more informative than a typical customer reference, and neither is the model.

The first is strategic. Willenborg (2016) analyzes Rakuten's innovative business-to-business-to-consumer strategy for entering new markets; Reed and Brunson (2021) ask how long rapid growth can be sustained (Willenborg 2016; Reed & Brunson 2021). The strategic pressure is time-to-market across many verticals simultaneously. That is precisely the workload agentic coding is sold against, and it is why a 24-to-5 day cycle-time claim is at least directionally plausible for this company in a way it would not be for a single-product firm.

The second is organizational. Sato (2018)'s ethnography of Englishnization studied exactly this company's most famous mandate, and the lesson — mandates are mediated and often blunted by middle management, and require curriculum rather than directives to stick — is directly predictive of an AI rollout and almost universally omitted from coverage (Sato 2018).

The third is regulatory, and it is the one that makes the case hard rather than easy. Karaiskos (2019) on platform operator liability for C2C/B2C intermediation in Japan and Nikiporets-Takigawa (2025) on Japan's national cybersecurity strategy are not background color (Karaiskos 2019; Nikiporets-Takigawa 2025). They define the permission and audit regime that a code-generating agent operates inside at a company with a bank, a brokerage, and a travel platform.

A single-product SaaS company can treat agent permissions as a developer-experience problem. Rakuten cannot. That is why its rollout tells you more — and why the parts of it that would be hardest to copy are the parts that were never published.

A Decision Framework for Reading Any Vendor Case Study​

The framework I would actually use is four questions, asked in order, applied to any case study of this genre including this one.

Is there an oracle? You (2026) and the vLLM incident both describe tasks with an independently computable correct answer. If the case study's headline result comes from a task shaped like that, the result is real and it is not transferable to tasks without one. If the case study does not tell you which shape the task was, assume oracle.

Is the baseline published? Twenty-four to five days without a methodology is a direction, not a magnitude (Anthropic 2026a). Independent work on self-assessed enterprise transformation says roughly 80% of companies grade their own homework (Arcuri 2020). Ask what would have been measured if the tool had not been deployed.

Is the constraint named, and is it human? Rakuten's July 2026 material is unusually honest here: the bottleneck moved to whoever understands the business problem. That claim is testable in your own organization in a week. Count the people who can adjudicate whether an agent's output is right for the business, not the people who can write the prompt.

Is there a debt intake plan? Silva et al. (2026) show hybrid human-plus-tool prioritization was already required before code volume rose (Silva et al. 2026). If your triage process was at capacity at the old delivery rate, it is structurally broken at 4.8x that rate, and no amount of agent capability fixes a queue.

The operational playbook that falls out of these four questions is short. Build the acceptance check before you build the delegation — unit tests, reference implementations, differential harnesses, whatever makes the end state verifiable without a human reading every line. Track completion ratio next to cost per task, not completion ratio alone. Route the expensive model only where capability changes the outcome. Parallelize only work whose merged result is mechanically checkable. Instrument triage throughput from day one, because that is the number that will determine whether the program survives its second year.

And read every published figure as a single-source claim with an unstated scope, because that is what it is.

Frequently Asked Questions​

Does Rakuten actually use Claude Code? Yes, per Anthropic's published customer material, which describes deployment across engineering as well as product, sales, marketing, and finance functions (Anthropic 2026a; Anthropic 2026c). Rakuten has used Claude since March 2025 according to the same sources, and Kaji has tested Claude models since September 2024. None of this is independently audited.

What results has Rakuten reported? A 24-to-5 working-day reduction in feature time-to-market, a seven-hour autonomous refactor in vLLM reported at 99.9% numerical accuracy, biweekly rather than quarterly major releases on one product manager's products, and 97% fewer initial critical errors in a memory-agent pilot with cost and latency down more than 30% (Anthropic 2026a; Anthropic 2026b). All vendor-reported, all with unstated methodology.

Is Claude Code suitable for enterprise engineering teams? The Rakuten material is an existence proof at large scale, not an effect size. The harness questions — permissions, audit, review capacity, debt triage — are organizational, and Lin et al. (2026) treat permission control as a first-class systems problem rather than a configuration detail (Lin et al. 2026). Suitability depends on whether you have the oracle and the reviewer, not on the model.

Can other enterprises copy Rakuten's approach? The reusable parts are the delegation unit (goal, not chunk), the metric pair (completion ratio against cost per task), and the verification-first posture. The parts that do not transfer are the regulatory context, the organizational precedent for mediated mandates, and whatever internal enablement mechanism Rakuten used — which is not documented anywhere I can find.

What the Case Actually Demonstrates​

Rakuten's rollout demonstrates something narrower and more useful than the coverage suggests. It demonstrates that a large, multi-language enterprise estate can absorb autonomous agents running for seven hours and 24 parallel sessions, provided the work is decomposed by outcome and the outcome is checkable. That is a real result. It required years of organizational preparation that the case study mostly does not describe.

The 99.9% is the whole argument in miniature. It exists because somebody built the reference implementation first — before the agent ran, before the seven hours started, before anyone knew whether it would work. The verification came first. Everything downstream of that ordering is just throughput.

Copy the ordering, not the seat count. The teams that get the seven-hour runs without building the thing that checks them will produce more code than they can understand, faster than they can review it, and they will find out roughly nine months later. Rakuten's numbers do not tell you that will happen. The methodological literature does, and it has been saying so since 2013, about a company that had never heard of Claude Code and would not for another twelve years.

References​

  1. Anthropic. (2026a). Rakuten accelerates development with Claude Code. https://claude.com/customers/rakuten
  2. Anthropic. (2026b). Rakuten Q&A with Yusuke Kaji. https://claude.com/customers/rakuten-qa
  3. Anthropic. (2026c, July 20). Working at the frontier: How Rakuten builds agents overnight with Claude. https://claude.com/blog/working-at-the-frontier-rakuten
  4. Riedl, K. (2026, June 23; updated 2026, September 16). AI coding agents: context, not intelligence. https://wavect.io/blog/ai-coding-agents-context-not-intelligence/
  5. Anthropic. Claude Code. https://www.anthropic.com/claude-code
  6. Anthropic. Claude Code documentation. https://docs.claude.com/en/docs/claude-code/overview
  7. Anthropic. (2025). Claude 4. https://www.anthropic.com/news/claude-4
  8. vLLM Project. https://github.com/vllm-project/vllm
  9. Pham et al. (2026). A case study of human-AI collaborative software development using Claude Code multi-agent orchestration. https://scholar.google.com/scholar?q=Pham+2026+Claude+Code+multi-agent+orchestration+case+study
  10. You. (2026). AI-assisted performance engineering of MuMax3 with Claude Code. https://scholar.google.com/scholar?q=You+2026+Claude+Code+MuMax3+CUDA+graph+performance+engineering
  11. Liu et al. (2026). Execution harnesses: observation, context, control, action, state, verification. https://scholar.google.com/scholar?q=Liu+2026+execution+harness+agent+observation+context+verification
  12. Lin et al. (2026). LLM systems as operating systems: cache reuse, context capacity, agent scheduling, permission control. https://scholar.google.com/scholar?q=Lin+2026+LLM+operating+system+KV+cache+context+window+permission+control
  13. Willenborg. (2016). Rakuten's innovative business-to-business-to-consumer strategy. https://scholar.google.com/scholar?q=Willenborg+2016+Rakuten+innovative+B2B2C+strategy
  14. Reed, & Brunson. (2021). Rakuten: how long can rapid growth be sustained? https://scholar.google.com/scholar?q=Reed+Brunson+2021+Rakuten+rapid+growth+sustained
  15. Rakuten Kobo. (2020). https://scholar.google.com/scholar?q=Rakuten+Kobo+2020
  16. Sato. (2018). Englishnization in Japanese firms: a longitudinal organizational ethnography. https://scholar.google.com/scholar?q=Sato+2018+Englishnization+Japanese+firms+corporate+English+training+ethnography
  17. Cheung et al. (2024). Lifewood: enterprise GenAI transformation with GPT and Gemini. https://scholar.google.com/scholar?q=Cheung+2024+Lifewood+GPT+Gemini+enterprise+transformation+training
  18. Arcuri. (2020). BCG Digital Acceleration Index and the Bionic Company. https://scholar.google.com/scholar?q=Arcuri+2020+Bionic+Company+digital+acceleration+index
  19. Boudreau, & Holmström. (2011). Loose coupling and IT implementation failure at MacGregor Crane. https://scholar.google.com/scholar?q=Boudreau+Holmstrom+2011+loose+coupling+IT+implementation+MacGregor+Crane
  20. Yamashita. (2013). How good are code smells for evaluating software maintainability? https://scholar.google.com/scholar?q=%22How+Good+Are+Code+Smells+for+Evaluating+Software+Maintainability%22
  21. Silva et al. (2026). Hybrid prioritization of self-admitted technical debt and static code analysis. https://scholar.google.com/scholar?q=Silva+2026+hybrid+prioritization+self-admitted+technical+debt+static+code+analysis
  22. Ram et al. (2017). rOpenSci: open code review as community effort. https://scholar.google.com/scholar?q=Ram+2017+rOpenSci+community+code+review+reproducible+research
  23. Ye et al. (2017). Nationality classification using name embeddings. https://scholar.google.com/scholar?q=Ye+2017+nationality+classification+name+embeddings+Wikipedia
  24. Moravec et al. (2025). Generative AI energy consumption as an enterprise constraint. https://scholar.google.com/scholar?q=Moravec+2025+generative+AI+energy+consumption+enterprise
  25. Nikiporets-Takigawa. (2025). Japan's national cybersecurity strategy and its approach's traps. https://scholar.google.com/scholar?q=Nikiporets-Takigawa+2025+Japan+cybersecurity+strategy
  26. Karaiskos. (2019). Platform operator liability in Japan for C2C and B2C intermediation. https://scholar.google.com/scholar?q=Karaiskos+2019+platform+operator+liability+Japan+C2C+B2C
  27. Nevo. (2021). AI detection accuracy and human judgment. https://scholar.google.com/scholar?q=Nevo+2021+AI+accuracy+human+judgment+detection
  28. Svejvig, & Pries-Heje. (2013). Outsourcing and coordination complexity. https://scholar.google.com/scholar?q=Svejvig+Pries-Heje+2013+outsourcing+coordination+complexity
  29. Dionela et al. (2026). AI-assisted product review in e-commerce. https://scholar.google.com/scholar?q=Dionela+2026+AI+product+review+e-commerce
  30. Temmers. (2026). AI in e-commerce merchant and consumer workflows. https://scholar.google.com/scholar?q=Temmers+2026+AI+e-commerce
  31. Jimenez et al. (2024). SWE-bench: Can language models resolve real-world GitHub issues? https://arxiv.org/abs/2310.06770
  32. Tang et al. (2024). CodeAgent: Autonomous communicative agents for code review. https://arxiv.org/html/2402.02172
  33. ReTool. (2025). Reinforcement learning for strategic tool use in LLMs. https://arxiv.org/abs/2504.11536
  34. Liu et al. (2023). Is your code generated by ChatGPT really correct? Rigorous evaluation of LLMs for code generation. https://openreview.net/forum?id=1qvx610Cu7
  35. Li et al. (2023). TACO: Topics in algorithmic code generation dataset. https://doi.org/10.48550/arXiv.2312.14852
  36. Yang et al. (2023). InterCode: Standardizing and benchmarking interactive coding with execution feedback. https://arxiv.org/abs/2402.01030
  37. Chen et al. (2021). Evaluating large language models trained on code. https://arxiv.org/abs/2107.03374
  38. Xia, & Zhang. (2023). Conversational automated program repair. https://arxiv.org/abs/2308.12562
  39. McCabe. (1976). A complexity measure. https://scholar.google.com/scholar?q=McCabe+1976+A+Complexity+Measure
  40. Rakuten Group. About Rakuten. https://global.rakuten.com/corp/about/

Disclosure: all Rakuten-specific figures in this article are vendor-published and self-reported by Rakuten Group or Anthropic. None has been independently audited. The 12.5-million-line codebase figure is treated here as disputed rather than established, per Riedl (2026). The 99.9% figure describes numerical accuracy on one bounded task, not a defect rate across a codebase. The 97% and 30% figures come from a pilot whose scope is not published.