AI Won't Replace Data Scientists. It Will Replace Lazy Ones.

The question arrives in every mentoring conversation now, usually about ten minutes in, usually phrased apologetically. Is it still worth learning this?

The honest answer is yes, but not the version of it most people are learning.

AI has genuinely collapsed the value of one specific skill: producing correct code from a clear specification. That skill used to take two years to build and it was most of what a junior Data Scientist was paid for. It is now close to free. If your plan was to be the person on the team who knows the Pandas syntax, that plan is finished, and pretending otherwise does you no favours.

But that was never the job. It was the entry fee.

Why this matters right now

There is a real reorganisation happening in what teams need, and it is not "fewer Data Scientists". It is a shift in where the scarce skill sits.

When code was expensive, the bottleneck was implementation. Teams hired for it. Interviews tested for it. A person who could reliably turn a well-specified request into working analysis was valuable, and there were never enough of them.

Now implementation is cheap and the bottleneck has moved upstream, to specification, and downstream, to judgement. What should we be measuring? Is this result believable? Does the business actually work the way this model assumes? What do we do if the model is wrong?

Those questions were always the hard part. They were just hidden behind a wall of syntax that took most people two years to climb. The wall is gone, and what is behind it is now visible to everyone, including the people doing the hiring.

The professional mindset: AI is a very fast colleague with no context

Here is the mental model I find most useful, and it is not "tool" and not "replacement".

Treat AI as a colleague who is extraordinarily fast, has read almost everything, works instantly at any hour, and has never attended a single one of your meetings. They do not know what the CFO said last Tuesday. They do not know that the sales team stopped logging a field in March. They do not know that the last three retention initiatives failed for organisational reasons rather than analytical ones.

You would not hand that colleague a business problem and ship their first answer unread. You would give them a well-scoped task, review the output, and supply the context they cannot have.

That is the working relationship. It is not junior and it is not senior, it is fast and contextless, and it changes what you should spend your own time on.

What AI does well, honestly

Understating this is as unhelpful as overstating it. In current practice, AI is genuinely strong at:

Writing Python and SQL. Joins, window functions, reshaping, the Pandas operation you always have to look up. It is fast and usually right, and when it is wrong the error surfaces immediately when you run it.

Translating between tools. R to Python. Pandas to Polars. A stored procedure to a dbt model. Legacy Excel logic into something maintainable. This used to be a week of tedium.

Building the first version of a dashboard. Chart specs, layout, the query behind each tile. A competent starting point in minutes rather than a day.

Explaining methods. What a partial dependence plot shows, why your class weights matter, what assumption a t-test is making. It is a patient and available teacher, which is more than most of us had.

Documentation and communication drafts. Docstrings, README files, the first draft of a stakeholder summary. Genuinely tedious work that it removes almost entirely.

Reviewing your code for the obvious. Leakage between train and test, a merge that silently fans out, an index misaligned. It catches real mistakes.

Take all of it. Refusing these gains is not craftsmanship, it is just slower.

What AI cannot do, structurally

Notice that the items below are not things that get fixed by a better model. They are not capability gaps, they are position gaps: they require standing somewhere AI does not stand.

Understand what the business is actually trying to achieve. Stated goals and real goals diverge constantly, and the gap is political, historical and personal. "Reduce churn" might really mean "give the retention team a defensible reason for their budget". You learn that in a corridor, not from a schema.

Attend the meeting. Most of the important information in any organisation is transmitted verbally, informally, and once. The reason a metric is defined strangely, the reorganisation coming next quarter, the fact that the regional director does not trust the data warehouse. None of it is written down anywhere a model can read.

Decide which metric matters. Optimising the wrong metric with excellent technique is the most efficient way to do harm. Choosing between precision and recall in a fraud system is a decision about how many honest customers you are willing to inconvenience to catch one thief. That is an ethical and commercial judgement with a named owner.

Know your organisation's constraints. What the regulator will accept. What the engineering team can realistically deploy. Which stakeholder will block anything they did not help design. Which dataset is technically available and politically radioactive.

Take responsibility. This is the one that ends the argument. When a model denies someone a loan, when a forecast drives a hiring freeze, when a healthcare triage tool underserves a group, a person has to answer for it. Accountability cannot be delegated to something that cannot be held accountable. As long as that is true, the role exists.

A real-world example: the churn model that worked and failed

Consider a marketing team that asks for a churn model. The request is clear and an AI assistant can take you a long way with it: write the feature engineering, handle the imbalance, fit a gradient-boosted model, produce the evaluation. Give it a clean table and you can have a strong result the same afternoon. Genuinely strong, not toy.

Then it goes into production and does not reduce churn at all.

The reasons will look like these, and none of them are modelling problems.

The prediction arrived too late to act on. The model flags customers likely to churn in the next thirty days. The retention team's only lever is a renewal offer that has to be made at least sixty days out. The model is accurate and useless. Someone had to know the operational calendar.

The definition of churn did not match the business. The data said churn was a cancelled subscription. The business cared about customers who stop using the product while continuing to pay, because those are the ones who cancel in six months and who complain loudly first. That definition is a conversation, not a column.

The strongest feature was an artefact. The model leaned heavily on "contacted support in the last week", because support tickets get logged at cancellation. The feature was leaking the outcome. AI will not flag this, because in the data it looks like an excellent predictor. Only someone who knows how tickets get created will catch it.

Nobody owned the intervention. The scores landed in a table. No one had agreed who would act on them, with what budget, or how success would be measured. The project produced a model and no decision.

Every single failure sits upstream or downstream of the modelling. The modelling was the easy part, and it was the part AI did well.

Where the code fits

A concrete illustration of the division of labour. Here is work that AI should do for you, and you should let it:

import pandas as pd
 
# Aggregate product events to one row per customer-month, with the
# rolling behaviour features a churn model needs. Tedious, well-specified,
# and exactly the kind of thing to delegate.
monthly = (
    events
    .assign(month=lambda d: d["event_ts"].dt.to_period("M"))
    .groupby(["customer_id", "month"])
    .agg(
        sessions=("session_id", "nunique"),
        actions=("event_id", "count"),
        last_seen=("event_ts", "max"),
    )
    .reset_index()
)
 
monthly["sessions_3m_avg"] = (
    monthly.groupby("customer_id")["sessions"]
    .transform(lambda s: s.rolling(3, min_periods=1).mean())
)

That is fifteen minutes of your time saved and no judgement expended. Now here is the part that is yours, and note that it is not code:

# Decisions made before any of the above, none of which are in the data:
#
# 1. Churn means 60 days with zero sessions, NOT subscription cancelled.
#    Agreed with retention on 12 March. Cancellation lags disengagement
#    by roughly a quarter, so cancellation labels arrive too late to act on.
#
# 2. One row = one customer-month, labelled with churn in the FOLLOWING
#    month. Matches the monthly retention cycle the team actually runs.
#
# 3. Support-contact features are excluded. Tickets are frequently created
#    by the cancellation workflow itself, so they leak the outcome.
#
# 4. Optimising recall at a fixed budget of 500 outreach contacts a month,
#    because that is the team's actual capacity. Precision above that
#    threshold is not worth trading recall for.

Four comments. No syntax. That block is worth more than the model, it took three conversations and two weeks of watching how the team works, and there is no prompt that produces it.

Common mistakes

Refusing to use AI on principle. You are not proving rigour, you are spending your scarce hours on the cheap part of the job. Rigour is applied to the output, not withheld from the tool.

Accepting output you cannot explain. If you cannot defend every step to a sceptical stakeholder, you have not done the work, you have forwarded it. When it breaks, and it will, you will be the one in the room.

Learning prompts instead of fundamentals. Prompting is a thin skill on top of a thick one. Without knowing what a leaky feature or an unbalanced class or a mismatched grain looks like, you cannot evaluate what you are given, so you cannot use the tool safely.

Skipping the stakeholder conversation because the data is right there. The data will not tell you what anyone intends to do with the answer. That has to be asked.

Competing with AI on speed. You will lose. Compete on being the person who knows which question is worth answering.

Treating fluent output as verified output. Confidence of tone and correctness of content are unrelated. This is the single most expensive habit to acquire.

Best practices

1. Delegate the specified, own the unspecified. If it fits in a prompt, prompt it. If writing the prompt is the hard part, that is the work.
2. Verify everything you cannot derive yourself. Run the code. Check the numbers against a source you trust. Sanity-check magnitudes.
3. Spend the time you save upstream. Use it to talk to the people who own the process you are modelling. That is where the returns are now.
4. Learn fundamentals deliberately, not incidentally. Grain, leakage, sampling, causality, uncertainty. These are what let you audit a fast answer.
5. Write down the decisions, not just the code. The comment block above is the deliverable a future colleague will need most.
6. Name an owner for every model output. A prediction with no decision attached to it is not a project, it is a table.
7. Stay the person who says "should we". The room is now full of things that can answer "how". It is short of people who ask whether it is the right thing to build.

Key takeaways

• AI has made implementation cheap. Implementation was the entry fee to the job, never the job.
• The bottleneck has moved to specification and judgement, which is where it always really was.
• AI cannot attend your meetings, know your organisation, choose your metric, or be accountable. Those are position gaps, not capability gaps.
• The dangerous failure is a plausible answer to an unexamined question.
• Refusing AI and outsourcing your thinking to it are the same mistake in opposite directions.
• The competitive advantage is context plus judgement plus responsibility. Build all three deliberately.

Continue the series

This is Part 2 of the Data Thinking Series.

Previously: The First Question Every Data Scientist Asks: What Does One Row Represent? makes the case concretely, with the one question AI cannot answer for you no matter how good the schema looks.

Next: Before You Clean Your Data, Ask This One Question: Is It Actually Dirty? takes the same argument into data cleaning, where the reflex to fix arrives long before anyone has asked what the mess is telling them.

The philosophy holds throughout: learn the fundamentals, and use AI to accelerate them, not to replace them.

Your turn. Look at your last project and split it in two: what could have been prompted, and what could not. If the second list is short, that is not a verdict on you, it is a map of what to build next.