A Day in the Life of a Data Scientist in 2026

, My Day Looked Completely Different

Believe it or not, two years ago, I was still writing and debugging code daily. Line by line. Practically slamming my head against the desk after 2 hours of debugging to no avail. I know, it sounds kind of crazy, right?

A normal day for me: 

• Writing (and debugging) every SQL query and Python script from scratch
• Building slide decks bullet by bullet
• Writing documentation nobody would read until something broke (and even then, they hardly would)

I wrote about my day in the life as a data scientist back in 2024. And almost none of that is what my actual Tuesday looks like now.

I won’t pretend that’s purely a good thing. Some days it feels less like my job got easier and more like it quietly turned into a different job. One I had to learn on the fly, while I was still doing the old one.

(And yes, I know there are plenty of data scientists still doing a lot of the things I did two years ago, but this is my experience as well as the experience of many data scientists I know nowadays). 

Prompt Engineering Is a Major Part of the Job

Image generated by author using Claude

Yes, we had ChatGPT in 2024. We had prompt engineering. But I was not doing it because ChatGPT often frustrated me. It was more work to explain the context behind what I was doing before feeding ChatGPT my code, and even then it would still not seem to be able to find the bug. 

Advancements in AI, especially those with Claude, have changed a lot of that attitude. Things like projects and skills have made it much easier to discuss your project with an AI that already knows the context and history behind it. 

So a meaningful chunk of my day now goes into writing and refining prompts. Early on, my prompts were lazy. Something like:

Summarize the forecast accuracy for this model.

Which gets you a vague paragraph that often doesn’t contain the insights you really want. Now I write prompts closer to:

Summarize this model’s forecast accuracy over the last 14 days. Report the exact MAPE and RMSE for each day, flag any day where MAPE exceeded 5%, and state whether the trend is improving or degrading week-over-week. Do not round error metrics, report them to two decimal places.

The difference in output quality is enormous, and honestly, that’s now a skill I have to actively strengthen.

A few things that are now part of my regular workflow:

• Double checking LLM model outputs

• Testing prompt variants against the same task and comparing outputs side by side

• Writing constraints directly into the prompt (units, decimal precision, what not to guess at) instead of correcting the output after the fact

Finding Cost-Effective LLM Solutions (& Cutting Token Usage)

Image generated by author using Claude

LLMs are expensive. Much more so than XGBoost models. This means that a lot more consideration needs to go into utilizing LLMs to analyze large datasets. 

The same data science principles still apply, though:

• When a simpler heuristic or model can perform the task, always go with that first. 
• Always clean your data before feeding it into a model. Garbage in=garbage out 
• Perform feature selection and select only meaningful features before training an ML model so you don’t shove hundreds of random features and cause overfitting or too much noise.

 

These pillars map over very well to LLMs. Not every task needs the biggest, most expensive model available. Classifying a support ticket or extracting a date from a document doesn’t need the same horsepower as summarizing a 40-page contract. Routing the easy stuff to a smaller, cheaper model and reserving the expensive one for tasks that need it turned into a real cost lever.

Here are some examples of how I work on limiting costs:

• Data cleaning to cut down input sizes (for example, removing links, images, and other characters not relevant to the model from an email chain) 
• Caching repeated calls instead of re-running the same prompt against the same input
• Using traditional ML when appropriate instead of an LLM for everything
• Tracking token spend per task 
• Researching best practices for reduced token usage

Stakeholder Communication and Presentations 

Photo by Campaign Creators on Unsplash

Here’s where a lot of saved time goes: meetings, slides, and translating what a model did into something a non-technical stakeholder can act on.

I used to spend hours building a deck from scratch. Now I can generate a rough draft of a stakeholder-ready dashboard or slide outline in minutes, which sounds like it should free up my afternoon. In practice, it just means I spend that freed-up time in more meetings, walking people through what the model found and why it matters, because the turnaround is fast enough that stakeholders expect check-ins more often.

The actual skill that matters here hasn’t changed: taking something technically true and making it something a product manager or executive can make a decision from. AI can draft the slide. It can’t decide what the point of the slide is (that’s still me.)

Conclusion

Even with all of this, most of my job is still the same underneath. I still have meetings and need to collaborate with my team members. I still have to decide what’s worth modeling in the first place. I still have to catch when an AI-generated summary confidently states something that isn’t true. I still have to know the domain well enough to notice when a number looks slightly wrong instead of obviously wrong. And I still use traditional ML when necessary.

If anything, that judgment matters more now, not less because it’s the one part of the day that never got automated.

My day in 2026 isn’t shorter than it was in 2024. It’s just shaped differently. Less time doing the mechanical parts, more time on the parts that require me to think deeper about business problems.

Thanks for reading

• I built a 30 day social media content calendar generator using AI: Get it here.
• Connect with me on LinkedIn
• Buy me a coffee to support my work!