Data scientists and ML engineers face a particular challenge when it comes to visualization: they have deep expertise in the models and data they're analyzing, but limited time and inclination to become full-stack developers just to build good dashboards. The result, historically, has been either poorly designed ad-hoc visualizations in Jupyter notebooks or a dependency on frontend engineers who need to be onboarded on highly specialized ML context before they can build anything useful.
Anthropically's Data Science and ML Engineering teams have found a different path. Using Claude Code, they're building production-quality visualization applications themselves — without becoming full-stack developers. The results have been striking enough to change how they think about the relationship between research and tooling.
Building JavaScript/TypeScript Dashboard Applications
One of the most striking examples from this team: a data scientist who describes themselves as knowing "very little JavaScript and TypeScript" built an entire React application for visualizing reinforcement learning model performance.
The application runs to 5,000 lines of TypeScript. The data scientist has acknowledged not fully understanding the code. And yet: it works, it's maintainable (with Claude's help), and it provides visualization capabilities that would have previously required either learning a new technology stack or waiting weeks for engineering resources.
The key insight from the team is that visualization applications are "relatively low context" — they don't require understanding the entire monorepo or deep integration with core systems. They take data as input and produce visual output. This bounded scope makes them ideal candidates for autonomous Claude Code development, even for engineers with limited frontend experience.
The Slot Machine Approach to Refactoring
For repetitive refactoring tasks — updating component interfaces, restructuring data pipelines, normalizing inconsistent patterns across a codebase — the team has developed a workflow they describe as treating Claude Code like a "slot machine."
The process: commit the current state to create a clean checkpoint, then let Claude work autonomously for 30 minutes or more. Review the results. If the output looks good, accept it. If Claude went off track, revert to the checkpoint and try again — possibly with a more refined prompt, possibly just as-is.
The team has found that starting over tends to have a higher success rate than trying to fix Claude's mistakes mid-stream. When an autonomous session goes wrong, the resulting code often has interleaved problems that are hard to untangle. A fresh start, by contrast, gives Claude a clean mental model and often produces much better results on the second or third attempt.
This workflow produces 2–4x time savings on routine refactoring compared to doing it manually — and critically, it doesn't require the engineer to stay engaged during the 30-minute autonomous window.
Creating Persistent Analytics Tools
One of the more consequential shifts this team has made is moving away from throwaway Jupyter notebooks toward persistent React dashboards.
Jupyter notebooks have their place — they're excellent for exploration. But they're poor vehicles for recurring analysis. Every time you need to revisit a model evaluation, you either re-run the notebook (hoping the environment still works) or rebuild the analysis from scratch. The knowledge encoded in the notebook doesn't accumulate in a reusable way.
Claude Code has made it practical to build permanent dashboards that grow more valuable over time. When a new model needs to be evaluated, the team loads the relevant data and the dashboard updates — no rebuilding, no environment issues. Analysis that used to be one-time work is now infrastructure.
Zero-Dependency Task Delegation
For tasks in completely unfamiliar codebases — areas where the data scientist has no context about the architecture, the conventions, or the relevant files — the team has found that Claude Code can often handle the entire implementation autonomously.
The workflow is hands-off by design: describe the task, provide the entry point, and let Claude gather context from the monorepo and execute. The engineer doesn't need to stay engaged or provide guidance — Claude figures out what it needs by reading the code.
This works particularly well for well-scoped tasks with clear acceptance criteria: add a new data format, implement an export function, update a configuration schema. Claude can read the existing code, infer the patterns and conventions, and produce an implementation that fits.
Team Impact
- 2–4x time savings on routine refactoring compared to manual implementation
- Built complex TypeScript applications (5,000+ lines) with minimal JavaScript/TypeScript experience
- Shifted from throwaway Jupyter notebooks to persistent, reusable React dashboards that compound in value over time
- Better model performance understanding through sophisticated visualizations that would previously have required dedicated frontend engineering
- Zero-dependency task delegation enables engineers to contribute to unfamiliar codebases without onboarding overhead
Top Tips From the Data Science & Visualization Team
Treat it like a slot machine. Save your state with a git commit before letting Claude work autonomously. Let it run for 30 minutes or more. Then evaluate: either accept the output or revert and try again. Don't try to wrestle with corrections mid-stream — starting fresh from a clean checkpoint often produces better results than attempting to fix a session that's gone sideways. The key is having a clean rollback point so fresh starts are low cost.
Interrupt Claude and ask for simplicity. When Claude is heading toward an overly complex solution — adding abstractions that aren't needed, building infrastructure for edge cases that don't exist in your context — stop it and ask directly: "Why are you doing this? Is there a simpler approach?" Claude responds well to this kind of redirection and often produces much cleaner solutions when explicitly prompted to simplify. It's a useful check on the tendency toward over-engineering.