When AI Does the Execution, What's Left for You?
One product data scientist's year with AI — the tools, the trade-offs, and what she still does herself.
I didn’t notice the shift while it was happening.
It only became clear when I looked back at how I worked a year ago compared to now.
The tools changed, but more than that, the nature of what I spend my time on changed, in a way that’s hard to reverse once you see it.
What My Work Used to Look Like
A year ago, a large part of my week was operational.
Cleaning data, writing SQL and Python, producing ad-hoc analyses, and building dashboards that stakeholders would inevitably come back to and ask me to update.
A lot of repetition, much of it necessary to make sure the final output actually fit their use case.
That layer has started to shift. For me, the change wasn’t from “using AI as a helper” to “using AI more”; it was from using AI as a tool to building agentic skills, MCP servers, and LLM applications as part of my job.
What I Actually Use, and for What
The fundamentals of my role haven’t changed, but the shape of it has. I’ve gone from a builder of dashboards to a curator of domain context and a builder of AI systems.
Codex and Claude Code
I use Codex and Claude Code for generating code, refactoring, and code review. Most of the time, it’s faster than writing it myself. Sometimes it’s not, I’ll come back to that.
Claude or ChatGPT
For first-pass analyses, I use both Claude and ChatGPT. I feed in a previous analysis and ask it to draft a new one for a similar problem. I still rewrite most of it, but starting from a draft is much easier than starting from a blank page.
Agents and Claude Skills
I use Agent and build Claude skills for the parts of my work that repeat. Here, I’m not the writer of the analysis; I’m the conductor, making sure the AI’s logic aligns with business goals.
The Bigger Change Wasn’t Speed. It was Scope.
A few weeks ago, a UX researcher reached out asking me to help understand a product behavior pattern. The analysis involved building a logistic regression to understand what drives users to return (for a product I don’t own).
A year ago, that kind of cross-functional ask would have required real setup: scoping the work, routing it to a data scientist to do the analysis, even for a proof of concept.
Now, stepping into an adjacent problem is much easier because execution isn’t the limiting factor anymore. Judgment is.
Our team is also building an LLM-powered internal tool right now, even though none of us are full-stack web developers. The gap between “what I know” and “what I can build” has narrowed, not because we suddenly became experts, but because the execution layer is no longer where the time goes.
And this isn’t unique to data roles. I see engineers building tools outside their main stack, designers prototyping with code, PMs running their own analyses.
The shape of what someone can do at work is changing across the entire workforce.
Where My Time Actually Goes Now
Less coding. More everything else.
More time talking to PMs and stakeholders to understand what they need to move faster.
More time on the deep analyses where the pattern looks fine on the surface and only gets interesting when you push on the assumption underneath.
More time deciding what’s even worth building in the first place.
AI is fast at implementation, but it’s not yet reliable at knowing what’s meaningful to pursue. It tends to over-engineer when the context isn’t constrained, so part of my job is now framing the problem tightly enough that the output stays grounded.
Strong references in, useful output out.
What I Won’t Outsource
Even with all this, there are parts of my work I still do myself.
I talk to PMs and stakeholders directly to understand what they actually need before any code gets written. I sanity-check data across sources manually; that’s the kind of work where being wrong is expensive, and AI shortcuts haven’t earned my trust yet.
I design the experiments and write the recommendation at the end of an analysis, because AI lacks the domain knowledge to decide which metrics are worth tracking and which trade-offs are worth accepting.
There are also moments where writing the code myself is just faster than waiting for AI to generate and review it. I’ve stopped forcing it.
The point isn’t to use AI for everything, it’s to use it where it actually helps.
For small code updates and edits, I let it handle the work.
For framing, judgment, and decisions, that part stays mine.
💭 Final Thoughts
When writing code becomes easy, deciding what to build becomes the real bottleneck.
A year ago, you could still get by as a primarily execution-focused data scientist, someone who writes the SQL and Python, builds the dashboard, and answers the request. I don’t think that’s enough anymore.
The value is shifting toward understanding the business, the KPIs, and the system behind the product. Toward being the person who uses AI as an execution layer, rather than being the execution layer.
I’ve stopped thinking about it as a replacement and started thinking about it as positioning.
That’s the part of the year that actually changed me.
If This Resonated With You
We’re so grateful to Kessie 🌟 for allowing us to share her story here on Code Like a Girl. If this resonated, don’t just read it. Follow her work. Writers like this deserve readers who show up.
This story was originally published on our Medium publication, where we found it. Kessie cross-published it on her Substack here.
Most of what gets written about women in tech stays at the surface. We don’t.
Code Like a Girl publishes three times a week with stories, tutorials, and hard-won lessons from women who are building, leading, and refusing to stay quiet.
If you’re not subscribed yet, start there. It’s free.
If you’re already here and ready to go deeper, Her Edge is a monthly paid column from our founder, Dinah. She spent twenty years in tech, hit that ceiling herself, and came out the other side as a VP who retired at 43.
Each month, she shares the specific frameworks that broke through it.
Summer Hours
We're taking two short breaks this summer: June 27 – July 7 and August 1 – 12.
 | A guest post by
|
AI is pushing every one of us to be strategists and marketers.
Great article, Kessie.
Understanding customer behavior from metrics is a major challenge for any company. Companies have means to collect so much data these days that just dealing with the data, extracting the signals, and visualizing them is a full-time job.
While AI can help build new tools, it can also help ask better questions and explore patterns faster. In my previous 9-5 job, I worked with a young, talented data scientist to explore a large dataset of time-series metrics extracted from a large-scale website serving 35 million customers.
Over a year, that dataset became a data pipeline, and signals were turned into a KPI dashboard and eventually the source of truth for the organization, thanks to the weekly conversations we had about the past week's performance.
It was hard work that took time - not because of writing code but because of building shared understanding and trust in the numbers and what they represent, and how they impacted customers.
Asking the right questions started with customer impact details. We made significant progress in this area, thanks to the new AI tools that became available before I retired.