Tomorrow I start teaching a six-week data science bootcamp with iXperience, a data science programme endorsed by the Gordon Institute of Business Science. It is the same course I have taught before, but this time I am running it differently. This article is partly an explanation of why.

When I first started teaching data science in 2020, I spent a lot of time helping students become comfortable with Python. That made sense at the time. If students could not write a filter, group a dataset, join two tables, or make a basic chart, they could not really do the work. A lot of teaching was about building technical fluency, practising syntax until it became familiar enough to use under pressure. I still think those fundamentals matter, but I no longer think they are enough.

Over the past few years, the environment around data science has changed. Students can now generate working code in seconds. They can ask an AI tool to write the pandas logic, debug an error, explain a function, or restructure a notebook. In many cases, the first version of the code is no longer the hard part. The hard part is knowing whether that code answers the right question, and that has made me rethink what I am really trying to teach.

The bar has moved

I used to think a good beginner data science course had to focus heavily on whether students could write code from scratch. Now I think the more important question is whether they can produce analysis that holds up. Can they frame the problem properly, understand the grain of the data, spot when a join has duplicated rows, tell the difference between correlation and evidence for action, and explain what is known, what is uncertain, and what still needs to be checked? These are not smaller skills than coding. They are bigger ones.

AI has made the mechanics faster, but it has not removed the need for judgment. If anything, it has made judgment more important, because students can now produce polished-looking outputs before they fully understand the logic underneath them. That is both exciting and dangerous.

The code can run and the analysis can still be wrong

One of the clearest examples is a simple business question like: do discounts increase purchasing? It sounds straightforward. You have an orders table and a discounts table, and an AI tool can generate a join, calculate average spend for discounted and non-discounted customers, and produce a chart almost instantly. But the analysis can go wrong in quiet ways. The “discounted” label might be applied to a customer based on their entire history, so purchases made before a discount was ever issued get counted as discounted purchases. The analysis is using information from the future to define groups in the past. The join might be done only on customer ID, when the logic should also consider time, product, or campaign, duplicating rows and inflating the result. The comparison group might be unfair because customers who receive discounts are already different from those who do not.

The notebook still runs. The chart still looks clean. The conclusion may still be wrong. This is the part I want students to slow down for. Not because I want them to distrust every tool, but because I want them to understand that working code is not the same as defensible analysis.

AI is useful, but it does not take responsibility

I do not think the answer is to ban AI from learning. That would feel artificial. In real work, people use the tools available to them: they search, copy, adapt, ask colleagues, reuse old code, and now use AI. Pretending otherwise does not prepare students for the world they are entering.

But using AI well requires a different kind of discipline. Students need to learn how to specify what they want clearly, read the code that comes back, test it against small examples, check row counts, validate keys, inspect missing values, and ask whether the result makes sense. The learning is no longer only in writing the first draft of the code. The learning is in the review. It is in asking whether the logic matches the question, what assumptions the AI made, what could silently go wrong, what would need to be checked before trusting this, and whether the conclusion could be defended to someone who understands the business. That is a much more realistic version of data science.

Teaching failure modes more explicitly

One of the biggest shifts in my own teaching is that I want to spend more time on the mistakes that actually happen in real work. Bad joins, leakage, wrong granularity, misleading metrics, sampling bias, overconfident narratives. These are not advanced edge cases. They are everyday risks. A student can know Python syntax and still make all of these mistakes. A model can have a good score and still be useless for the decision. A chart can be technically correct and still imply something the data does not support.

So I want students to build habits around verification. Checking row counts before and after merges, validating join keys, creating small “known truth” examples, using holdout data properly, comparing against simple baselines, and writing conclusions that separate evidence from interpretation. Those habits are not glamorous, but they are what make analysis trustworthy.

This is not lowering the standard

I understand the concern that AI might make learning easier in the wrong way. If students can generate code quickly, are they still learning? I think the answer depends entirely on what we assess. If we only assess whether code exists, then yes, AI weakens the exercise. But if we assess the reasoning behind the code, the standard becomes higher. Students now need to show that they understand the problem, the data, the method, the assumptions, the checks, and the conclusion. They need to show that they can use AI without outsourcing their thinking to it.

That is closer to what real data scientists are expected to do. In a real organisation, no one cares very much whether you remembered the exact syntax for a groupby. They care whether your analysis can support a decision, whether the result is reliable, and whether you have noticed the caveats before the business acts on the output. That is the bar I want to teach towards.

Where I have landed

The most useful thing I can teach now is not simply how to type code. It is how to think with data. How to move from a messy question to a structured analysis, how to use tools without being led by them, how to notice when an answer is too easy, how to check whether the data really supports the conclusion, and how to communicate uncertainty without losing clarity.

AI changes the workflow, but it does not change the responsibility. If anything, it makes that responsibility more visible. The mechanics are faster now. The judgment still belongs to us.

That is the version of the course I am taking into tomorrow morning. Same six weeks, same group of students arriving in Cape Town, but a different emphasis on what we spend our time doing together. Less time on whether the code runs. More time on whether the analysis holds.