Як Rakuten скоротила delivery з 24 до 5 днів із Claude Code

Rakuten працює з десятками бізнесів, великими багатомовними codebase і тисячами інженерів, тому вузьке автодоповнення коду не вирішує головної проблеми: команди мають швидше доводити зміни до перевіреного результату, не втрачаючи контроль над тестами, безпекою та production-ризиком. У customer story Anthropic компанія описує Claude Code як інструмент, якому делегують цілісні bounded engineering tasks — від розуміння репозиторію до тестів, bug fixing і документації.

Ключовий приклад — складна зміна у vLLM: інженер дав Claude Code задачу реалізувати метод extraction у великому multi-language open-source codebase. Anthropic/Rakuten повідомляють про сім годин безперервної автономної роботи з лише періодичним guidance і 99,9% numerical accuracy відносно reference method. Це сильний case signal, але не універсальний benchmark: задача, acceptance oracle, repo та команда були конкретними.

Відтворюваний production pattern починається не з команди «зроби фічу», а з task contract: base SHA, allowed paths, expected behavior, forbidden changes, test commands, time/compute budget і критерій завершення. Agent отримує окрему branch/worktree, читає релевантний контекст, формує короткий plan, робить bounded edits і запускає deterministic checks. Результатом вважається не фраза «готово», а diff плюс evidence.

Rakuten описує використання Claude Code для unit tests, API mocks, components, bug fixes, documentation, code review і паралельних sessions. Це дозволяє розкладати engineering queue на кілька незалежних потоків. Практичний контроль тут простий: паралелізуйте tasks, а не authority. Кожна session має власний scope, budget і postcondition; merge/release залишаються за стандартними CI та human-review gates.

• Trigger → issue, refactor або test gap.
• Input → repo snapshot, requirements, conventions, tests.
• Agent execution → inspect, edit, test, summarize.
• Verification → deterministic tests + diff review.
• Side effect → PR/merge/deploy лише через окремий authority gate.
• Recovery → після timeout спочатку reconcile Git state, а не повторювати write.

У кейсі доречний рівень A4 для bounded coding execution: Claude Code може автономно виконувати довгу технічну задачу, але organizational authority залишається у людей і delivery system. Публічний матеріал не дає підстав стверджувати, що модель самостійно approve-ить критичні PR або деплоїть production без контролю.

Найкращий human-in-the-loop — ризик-орієнтований. Зміна тестів чи локального utility може пройти стандартний review; auth, billing, security policy, data migration або public API потребують domain owner, додаткових regression checks і staged rollout. Review packet має показувати intent, files touched, commands run, unresolved risks і exact evidence, а не довгий self-report агента.

Anthropic/Rakuten повідомляють про 79% скорочення average time to market для нових features — з 24 робочих днів до 5 — а також 99,9% numerical accuracy у згаданій складній modification task. Це customer/provider-reported outcomes. Вони показують, що agentic coding може суттєво змінити delivery economics у зрілій engineering environment, але не доводять однаковий multiplier для будь-якого репозиторію.

Для власного rollout не копіюйте headline metric. Вимірюйте accepted task success, lead time to verified change, escaped defects, reviewer minutes, CI rework, rollback rate, cost per accepted PR і частку tasks, де агент вклався в scope без ручного переписування. Якщо агент пише в п'ять разів більше diff, а review queue росте в десять разів, throughput не виріс — bottleneck просто переїхав.

Синтаксична помилка — найменш цікава, її швидко ловить compiler. Гірші класи: тест закріпив неправильну поведінку; agent змінив зайвий scope; dependency update приніс supply-chain risk; migration частково застосувалась; flaky test створив false green; timeout стався після push і retry відкрив duplicate PR. Саме ці сценарії треба закласти в regression suite.

Контроли: protected paths, least-privilege credentials, network policy, secret scanning, dependency policy, required CI, code-owner review, idempotency key для зовнішніх actions, signed/auditable artifacts де доречно, canary і rollback. Production incident або escaped defect перетворюється на мінімізований permanent eval case. Інакше агент навчає команду лише одному — швидше повторювати ті самі помилки.

Rakuten описує паралельні Claude Code sessions і напрямок до багатьох agent tasks. Це логічний наступний крок: engineering work часто можна декомпозувати. Але concurrency треба обмежувати reviewer capacity, CI throughput, repo locks, downstream API limits і risk budget. Десять агентів, що одночасно торкаються одного migration boundary, — не масштабування, а distributed merge conflict.

Cost model повинен включати model usage, sandbox compute, CI minutes, storage, observability, reviewer time і rework. Корисна одиниця — cost per verified accepted outcome. Model routing теж доречний: прості mechanical changes можуть іти дешевшим route, складні cross-repo tasks — сильнішим. Перемикання моделі проходить той самий eval set, інакше економія з'явиться тільки до першого rollback.

Поточна Claude customer surface уже показує наступний етап Rakuten: компанія рухається від Claude Code до Claude Managed Agents для ширших функцій. Це не треба змішувати з історичним coding-case metric. Для AI-Magister це окремий сигнал еволюції architecture: після локального task execution організації починають інвестувати в persistent compute, memory, storage, governance і інтеграцію з corporate systems.

Практичний 80/20 висновок: спочатку доведіть один вузький engineering workflow із сильним deterministic oracle, а shared agent layer додавайте лише коли повторюються однакові needs — identity, state, memory, permissions, trace, evals і recovery. Будувати платформу до того, як є два-три стабільні jobs, — класичний спосіб отримати дорогий control plane без контрольованого outcome.

Виберіть 20–50 історичних задач із відомим результатом і сформуйте eval set: expected behavior, tests, forbidden paths, time budget. Запустіть read-only analysis, потім test-generation і bounded refactors у sandbox. Після стабільного task success дозвольте PR generation, але залиште merge/deploy окремими authority gates.

На кожному етапі фіксуйте model/version, prompt/task contract, repo SHA, tools, commands, diff, test results, human edits і final production outcome. Scale gate має бути математичним: success вище порога, escaped-defect budget не перевищено, p95 duration і spend прийнятні, review queue не деградує. Тоді autonomy зростає як наслідок evidence, а не як налаштування темпераменту агента.

• Зібрати історичний eval set.
• Зафіксувати baseline lead time, defects і review effort.
• Запустити sandbox із least privilege.
• Дозволити PR тільки після stable deterministic checks.
• Ввести risk tiers для protected paths.
• Додати recovery/idempotency для retries.
• Масштабувати concurrency після перевірки review/CI capacity.