Reinforcement learning engineering sits at the bleeding edge of what AI systems can do. The RL Engineering team at Anthropic focuses on the efficiency of sampling in RL training and weight transfers across large compute clusters — work that is technically demanding, often poorly documented by prior art, and increasingly reliant on the kind of large-scale distributed infrastructure where debugging and iteration cycles can be slow.
The team has adopted Claude Code with a notably pragmatic orientation. They've been clear-eyed about both its strengths and its limitations, and their workflows reflect careful thinking about when to trust Claude's output and when to maintain close oversight. Their honest assessment: Claude Code works on the first attempt about one-third of the time. That number might sound discouraging, but in the context of a checkpoint-heavy workflow, a one-third success rate on complex tasks represents enormous time savings.
Feature Development With Supervised Autonomy
For small to medium features, the team's standard workflow involves letting Claude write the majority of the code while the engineer maintains oversight and provides guidance.
A concrete example: implementing authentication mechanisms for weight transfer components. This is real, production-relevant code — it needs to be correct, secure, and well-integrated with existing systems. The engineer starts the task, explains the requirements and context, and then supervises as Claude works through the implementation.
The supervision isn't constant. Claude works in stretches, the engineer reviews output and provides direction when Claude needs to make decisions, and the process moves faster than pure manual implementation would. The engineer's role shifts from writing code to directing and reviewing — which tends to surface issues earlier and produce better architecture.
This supervised autonomy model sits between full manual implementation and fully autonomous operation, and for this team, it's the right balance for code that needs to meet high correctness standards.
Test Generation and Code Review
After implementing a feature or making significant changes, the team routinely asks Claude to generate tests and review the code. This has become a standard part of the development lifecycle rather than an optional enhancement.
Claude's test generation for this team serves a similar function to what we've seen across other Anthropic teams: it catches edge cases that the implementing engineer didn't explicitly consider. For RL infrastructure code, where edge cases can manifest as subtle bugs in distributed systems that are difficult to reproduce, comprehensive test coverage is particularly valuable.
The code review workflow is equally useful. Claude can review a set of changes with fresh eyes, checking for consistency with the existing codebase patterns, potential performance issues, and correctness of the implementation logic. This doesn't replace human code review, but it means that human reviewers see higher-quality code and can focus their attention on higher-level design questions.
Debugging and Error Investigation
RL training infrastructure is complex and the debugging surface is large. When something goes wrong — a training run diverges, a distributed job fails, a weight transfer produces unexpected results — identifying the root cause requires navigating multiple systems simultaneously.
Claude Code is the team's first stop for debugging. The workflow: describe the error, share the relevant stack trace and logs, and ask Claude to help identify what's going wrong. Sometimes Claude identifies the issue immediately and proposes a fix along with relevant tests to verify it. Sometimes it needs more information or guidance to make progress.
The team's honest assessment is that Claude provides value on these debugging tasks even when it doesn't immediately solve the problem — it often identifies where to look, proposes hypotheses to test, or suggests diagnostic steps that accelerate the investigation.
Codebase Comprehension and Call Stack Analysis
RL codebases tend to be large, complex, and not extensively documented — because the work moves fast and the team is building new things rather than documenting existing ones. When an engineer needs to understand a component they haven't worked with before, Claude Code provides a quick orientation.
The specific workflow the team has found valuable: ask Claude for a summary of relevant components and their call stacks. This is faster than reading through the code manually, and the resulting summary is in plain language rather than code — which makes it easier to hold in working memory while making changes.
This is particularly valuable for debugging, where you often need to understand the execution path that led to a failure. Claude can trace the relevant call stack, identify the key decision points, and explain what each component is doing — giving the engineer a mental model for where to look.
Kubernetes Operations Guidance
Like other infrastructure-heavy teams at Anthropic, the RL Engineering team uses large Kubernetes clusters for training and weight transfer operations. Getting Kubernetes right requires specific command syntax, an understanding of resource configurations, and familiarity with how different components interact.
Rather than maintaining their own command reference or searching documentation, the team uses Claude Code for immediate answers to Kubernetes questions. This keeps them in flow and reduces the cognitive overhead of working with complex infrastructure tooling.
Team Impact
- Checkpoint-heavy workflow enables experimental approach — the ability to try things and roll back creates space for more ambitious experiments
- Documentation accelerated as a side effect — Claude adds helpful comments automatically when implementing or reviewing code
- Small-to-medium PRs completed with significantly less time investment, even accounting for the roughly two-thirds of attempts that need iteration
- One-third first-attempt success rate on complex tasks translates to substantial time savings at scale — saving hours of engineering time per week
Top Tips From the RL Engineering Team
Customize your CLAUDE.md file with specific patterns. The RL Engineering team has found specific instructions make a meaningful difference in Claude's behavior. Examples from their actual configuration: "run pytest, not run" (to avoid Claude using a less appropriate test runner), "don't cd unnecessarily — just use the right path" (to prevent navigation errors in complex directory structures), and tool-specific flags for their testing environment. These small instructions prevent recurring mistakes that would otherwise accumulate into significant friction.
Use a checkpoint-heavy workflow as your safety net. The ability to experiment ambitiously depends on being able to roll back cleanly. Commit regularly as Claude makes changes — not just at natural stopping points, but frequently during an autonomous session. If a session goes off track, you can revert to a known-good state and try again without losing significant work. This is what makes the "try and rollback" methodology practical rather than risky.
Try one-shot first, then collaborate. The team's approach: give Claude a clear prompt describing the full task and let it attempt a complete implementation. Evaluate the result. If it works (roughly one-third of the time), you've saved significant engineering time. If it doesn't, you now have a starting point, you've learned something about what Claude did and didn't understand about the task, and you can refine from there. The failed attempt is informative, not wasted — it guides the collaborative iteration that follows.