in 2022, things were wildly different.
Kids nowadays don’t know what it’s like.
I used to spend hours:
- Writing Python and SQL code from scratch, line by line
- Memorizing which libraries to import and what functions they contained (from sklearn.metrics import r2_score)
- Debugging code errors
- Writing documentation for my code
- Building dashboards to analyze large datasets
Even in just the last year, as AI tools have become increasingly more advanced, my job as a data scientist has changed. I’m less of a coding machine and more of a strategist. Someone who understands the data in my organization really well and knows how to best present it and derive insights from it.
Claude is changing things even faster
Claude is one of those tools that I believe will transform the industry and this career faster than anyone can imagine. I won’t lie, it’s kind of scary. At the same time, there are ways in which data scientists can take ownership of this tool, master it, and continue to stay ahead of the game.
Here are 3 CRUCIAL skills every data scientist should be working on mastering right now:
1. Claude Dashboards
I used to spend an entire day building a Tableau dashboard for a client just to explore a few questions about a large dataset that might never be looked at again in a few months.
Now, Claude can generate a fully working, interactive dashboard in a few minutes, complete with:
- KPI metric cards
- Line charts
- Bar charts
- Drill-down buttons
- Tabs
- … and More
Let’s showcase a simple example using the AEP hourly energy dataset (CC0 license).
Claude Prompt:
I have a time series dataset of hourly energy consumption (AEP_MW) with a datetime column. Build me an interactive HTML dashboard that includes:
1. Four KPI cards showing average load, peak load, minimum load,
and summer vs winter comparison
2. A line chart showing average load by hour of day split by weekday vs weekend
3. A bar chart of average monthly load with higher months highlighted in a warmer color
4. A bar chart of average load by day of week with weekends in a different color. Use a clean, minimal style.
The result looks like this:
A few insights immediately stand out from the dashboard that wouldn’t be possible to obtain from a raw CSV:
- Weekday consumption peaks sharply around 5-6 PM, while weekends peak earlier (around 2 PM) and at a lower level overall
- July and August consumption is significantly higher than spring months, confirming strong summer seasonality from air conditioning load
- Saturday and Sunday loads are consistently about 10% lower than weekdays
These types of dashboards are perfect for doing EDA as well as for producing one-time reports for stakeholders who just want to know what’s going on at a single point in time. You can also generate a dashboard on a schedule so you can get a new report every week.
2. Claude Cowork for Prioritizing Jira Tickets & Tasks
Here’s what a typical Monday morning used to look like for me: open Jira, click through 20 open tickets, try to remember the context on each one, figure out what’s blocking what, and write a rough priority list for the week.
Claude Cowork is different from Claude Chat in that it actually connects to your desktop and can read/write files. It can connect to Jira (Or another Scrum/Agile platform), and summarize your priorities for the week. Here’s an example:
Pull all my open tickets from the current sprint. For each one, give me: the ticket ID, a one-sentence summary of what needs to happen, the current status, and any blockers. Rank them by priority and tell me what I should tackle first today.
Here are a few other prompts you can use with Cowork:
Writing tickets to Jira
Here are my notes from today’s model review meeting: [paste notes – or link to the notes if your Cowork is connected to Google Drive]. Create Jira tickets for each action item in the DS project.
For each one, write a clear title, a 2-sentence description of what
needs to happen and why, set the priority based on urgency,
and assign them to the current sprint.
Preparing for a stakeholder meeting
Read the last 3 weeks of comments on tickets tagged ‘model-deployment’ and write me a 5-bullet status summary I can share with the engineering team lead. Keep it non-technical.
Drafting documentation from scratch
Open the file preprocessing_pipeline.py in my project folder and write a README section explaining what the pipeline does, what inputs it expects, and what it outputs.
End-of-sprint reporting
Based on the closed tickets from this sprint, write a 3-paragraph sprint summary for my manager that covers what we shipped, what we learned, and what’s carrying over to next sprint.
This is a huge time saver and will also keep you more organized.
3. Debugging with Claude Code
Claude Code is a command-line tool that runs in your terminal with full access to your codebase. It can:
- Read files across your project
- Run commands
- Execute tests
- Make changes across multiple files
For data scientists, the most immediately useful application is debugging pipelines.
Here’s a real scenario I ran into at work recently with dbt. The names of the models and files have been changed so I do not share any confidential company information.
I ran dbt run --select fct_energy_forecast and got this:Database Error in model fct_energy_forecast column "meter_reading_mw" does not exist LINE 14: AVG(meter_reading_mw) AS avg_load_mw,
The problem with dbt models is that a column error in a downstream mart model doesn’t tell you where the column actually broke. It could have been renamed in the raw source, in the staging model, in an intermediate aggregation layer, or in the mart itself. To find the root cause manually, you’d have to open each file in the dependency chain one by one, trace the column name through every transformation, and figure out where the old name was never updated. On a project with 24 models and 6 sources, that could be over an hour of reading, re-running and re-building models.
I handed it to Claude Code instead:
My dbt model fct_energy_forecast is failing with ‘column meter_reading_mw does not exist’.
Find where this column is defined upstream, trace all dependent
models and source files, figure out what happened, and fix it.
Claude read every file in the dependency chain and came back in about 40 seconds with a diagnosis.
It then applied the fix across all three lines, re-ran the model, and confirmed it passed.
Conclusion
As tools evolve, our roles will too. Claude is changing the type of work that data scientists are going to end up doing. Instead of spending 8 hours a day debugging various dbt and Python errors, those errors will be resolved in 2 minutes, allowing us more time to dive deeper into our data and ask more important questions. As data scientists in 2026, it’s important that we continuously grow our skillset and remain up to date.
It’s also important to note that while Claude has a lot of capabilities, it is still AI and can (and does) make mistakes. Data scientists who have mastery of Claude will still be needed to validate data, improve prompts and processes, and correct Claude when it is wrong.