The Bottleneck in Software Was Never Intelligence. It Was Context.

One vendor case study keeps getting passed around: Rakuten gave an AI coding agent a specific task inside a large open-source project and reported a working result after a long session. The event is real, but it is not a controlled productivity study and does not prove a general theory about coding agents. Its useful lesson is narrower: scoped tasks, relevant repository context, executable checks, and human review can let an agent sustain useful work on an unfamiliar system.

This is an engineering perspective, not a vendor pitch. The factual claims and sources were checked on 2 September 2026. Agent capability and productivity vary by model, tool, repository, task, reviewer, and evaluation method.

What actually happened at Rakuten?

At its Claude Opus 4 launch in May 2025, Anthropic said Rakuten had tested the model on an open-source refactor that ran for about seven hours. In Anthropic's Rakuten customer story, an engineer asked Claude Code to implement a specific activation-vector extraction method in vLLM. The story reports 99.9% numerical accuracy against a reference implementation. These details are vendor-published customer evidence, not an independent benchmark.

Two honest corrections, because we would rather be right than dramatic:

• It was not demonstrated as fully unattended. The story says the engineer provided occasional guidance. Treat "autonomous" as the publisher's description of the session, not proof of zero human intervention.
• 99.9% is a narrow metric. It is the numerical accuracy of one method's output against a reference, not a general statement that the agent is 99.9% correct at everything. Useful, specific, and easy to misread as a headline.

The same story calls vLLM a 12.5-million-line codebase but does not publish the counting method, revision, included repositories, or treatment of generated and vendored code. Do not use that figure as a measured repository size. The supported claim is simply that the task involved a large, multi-language open-source system and a specific reference implementation.

Why was context the real bottleneck, not intelligence?

The case supports a practical hypothesis, not a universal law: repository context and feedback can be bottlenecks even when a model can generate plausible code. Engineers also bring tacit domain knowledge, architecture history, product judgment, and accountability that are not captured by loading more files.

The useful question is not whether context or intelligence is the single bottleneck. It is whether the agent received the relevant code, constraints, tools, tests, and feedback for this task, and whether the reviewer can detect failure modes the checks miss.

What are the limits of long-running agent context?

Humans are bad at holding large context for long stretches, and not because we are dim. We tire. We forget the thing we read forty files ago. We take a break and lose the thread. We make small mistakes late in a long session that we would never make in the first hour. Holding a sprawling mental model of a system is exhausting, and exhaustion is where the bugs come from.

A coding agent does not experience human fatigue, but that does not mean stable reasoning across a seven-hour run or perfect use of a large context window. Models can lose relevant information, over-weight recent observations, compound earlier mistakes, or consume their context budget. Long-context research has shown that performance can depend strongly on where relevant information appears. Long-running agents therefore need context selection, summaries, checkpoints, tests, and recovery paths.

The catch, and it is a real one, is that the agent only reasons well over the context it is actually given. Point it at the wrong files, or starve it of the constraints that matter, and it will confidently build the wrong thing without fatigue. Feeding it the right context is now the skill. We wrote about the cost side of that discipline in how to cut LLM token costs in 2026: managing context, not just spending tokens, is most of the game.

For a concrete architecture that separates durable memory, shared state, bounded reasoning and intent routing, see our fact-checked Meterless context-layer review.

When cross-file relationships are the missing layer, our Graphify buyer review compares a codebase knowledge graph with repository search and RAG, then gives CTOs a measured two-week adoption test.

When parallel agents make repository setup and change integration the next constraint, use our Git worktrees vs Jujutsu decision guide to choose a cached Git baseline or a measured Jujutsu pilot.

For the tooling layer that writes that context down between sessions, see our Graft review on whether an agent repo map belongs in git or stays a rebuildable local cache.

Does this make engineers disappear?

This case cannot answer an employment question. It shows one technical workflow, not a labor-market outcome or universal productivity gain. Coding agents can shift work toward task design, context preparation, tool supervision, and review, while the effect varies across teams and tasks.

That last skill is underrated. An agent will produce confident, well-formatted, plausible code that is subtly wrong, and a junior reviewer will wave it through because it looks right. Catching that requires exactly the judgment that years of writing code by hand builds. The experience does not become worthless. It changes from "I type the solution" to "I recognize the wrong solution before it ships." If you want a concrete version of what that review looks like, our vibe-code production-readiness checklist is the list we actually run agent output against.

What does good engineering look like when agents write the code?

Delegation can become concentrated engineering work: scoping a task, assembling evidence, defining acceptance criteria, and reviewing the result. It does not eliminate implementation knowledge, because reviewers still need to understand the system and the consequences of the change.

Good engineering in this mode uses a bounded task, relevant context, least-privilege tools, reproducible checks, a reviewable diff, and a qualified human decision. Tests reduce risk but do not prove correctness beyond what they cover.

"An agent does not experience human fatigue, but it still has bounded context and failure modes. The engineering advantage comes from selecting evidence, defining checks, and reviewing the result, not from assuming it holds the whole codebase perfectly."

How should you restructure your workflow around coding agents?

If you want the Rakuten outcome on your own work, the moves that matter, in order:

1. Scope the task tightly. "Implement this specific method, matching this reference" is more testable than "improve the inference layer." A precise task reduces ambiguity; it does not guarantee an unattended success.
2. Give it the right context, not all of it. Point the agent at the files, interfaces, and constraints that actually matter. More context is not better; the correct context is. This is where most of the skill now lives.
3. Gate with tests and guardrails. Use a relevant test suite, reference, static checks, and security controls. Treat passing checks as evidence within their coverage, not proof that the change is correct.
4. Review like a senior, not a rubber stamp. Read the diff for the subtle, plausible-looking mistakes, the ones that compile and pass a shallow glance. This is the highest-leverage hour you will spend.
5. Keep ownership and knowledge in-house. An agent that ships code nobody on your team understands is a dependency, not a win. Make sure a human owns and can explain what shipped.

None of this is exotic. It is the same discipline good engineering always needed, reweighted: less time producing the code, much more time specifying and verifying it.

Visual work needs the same treatment. Our Claude Code design system guide shows how to turn approved examples, brand evidence and implementation rules into durable repository context instead of repeating them in every prompt.

Semaprax is one research response to this context problem, not proof that a new language solves it. The Semaprax benchmark freezes a small structured-context contract and publishes its limitations, including that it does not yet measure model tokens, task quality or repository-scale cost.