Notes on Data and Learning — N.22
Learning R in the Age of AI
Opening Observation
This week I found myself thinking about a question that would have sounded strange only a few years ago.
What exactly should students learn when an AI system can already write most of the code?
As someone who teaches R, hosts tutorial about R regularly, I increasingly find myself working in an environment where learners have immediate access to tools capable of generating functions, debugging scripts, explaining packages, and producing complete workflows.
The technical barrier to writing code has never been lower.
Yet learning programming does not appear to have become easier. In some ways, it may have become more complicated.
The New Student Problem
Historically, learning R meant learning syntax. Students spent considerable time memorizing function names, arguments, package conventions, and debugging patterns. Progress was often slow because much of the effort was devoted to overcoming technical friction.
Today that friction can disappear in seconds. A student can ask AI to write a ggplot, reshape a dataset, create a Shiny application, or explain a statistical model. The answer appears immediately.
The question therefore changes.
If code generation becomes inexpensive, what remains valuable to learn?
The Calculator Parallel
This reminded me of an earlier technological shift.
The arrival of calculators or the arrival of the search engines, both changed what students were expected to remember. When calculators became widely available, many feared that mathematics education would disappear. Why memorize arithmetic if a machine could perform calculations instantly?
The first electronic handheld calculators appeared in the late 1960s. Early models were expensive and mainly used by engineers, scientists, accountants, and businesses. The turning point came during the 1970s when companies such as Texas Instruments, Casio, and Hewlett-Packard dramatically reduced prices and calculators began entering schools.
Everybody Counts documented the shift from procedural arithmetic toward mathematical reasoning and problem solving (1989).
The emphasis gradually shifted from performing calculations toward understanding concepts, reasoning, and problem solving. Students still needed numerical fluency, but education increasingly focused on interpretation rather than manual computation.
Programming may be entering a similar phase. The ability to write code remains important, but the ability to understand what code is doing may become even more important.
Memory Still Matters
One of the more interesting questions concerns memorization. If AI can generate code, does it still make sense to memorize functions, syntax, or programming patterns?

I suspect the answer is yes, but perhaps not for the reasons we traditionally assumed. Experienced programmers often know when generated code looks wrong because they have internalized enough patterns to recognize inconsistencies. They do not necessarily remember every argument of every function, but they understand the structure of the language well enough to evaluate outputs critically.
Without that internal model, students risk becoming dependent on code they cannot assess. The objective is therefore not memorizing everything, but developing enough familiarity to exercise judgment.
Why Some Teachers Remain Reluctant
An interesting question is why many educators still hesitate to integrate AI explicitly into programming education.
Part of the reason may be practical. Assessment systems were designed around the assumption that students produced work independently.
Part of it may be cultural. Many instructors learned programming through repetition, debugging, and gradual accumulation of expertise. The idea that a student can generate complex code immediately feels incompatible with that experience.
But another possibility is that we have not yet fully agreed on what programming education is supposed to optimize.
What I Would Tell Students
If I were advising a student learning R today, I would not tell them to avoid AI.
I would tell them to use it aggressively, but strategically. Ask it to explain functions, to compare approaches, review code, generate examples.
Ask it why something failed.
But do not stop at the answer. Learning still happens through interaction. AI simply changes the speed at which interaction becomes possible.
IDEs and the Future of Development
This also raises a question I have been asking myself recently.
If tools like Codex or Claude continue improving, do we still need traditional development environments?
Project structure, files, version control, dependencies, documentation, testing, reproducibility, and debugging have traditionally been managed through development environments designed to make software projects visible and navigable. What is beginning to change is not the need for these activities, but where they are coordinated. AI systems are gradually moving beyond code generation and starting to function as operational environments in their own right. They explain code, navigate repositories, modify files, review pull requests, generate tests, manage documentation, and increasingly understand the broader context of a project. The interesting question may therefore not be whether IDEs remain important, but whether AI is slowly becoming a new kind of IDE—one organized around conversation, context, and coordination rather than menus, windows, and files.
A Working Position
What this week reinforced for me is that learning programming and learning to use AI are increasingly becoming the same educational problem.
The objective is no longer simply learning how to write code. It is learning how to reason about systems that can write code.
Just as calculators did not eliminate the need for mathematics, AI is unlikely to eliminate the need for programming. What it may change is where expertise resides. Future expertise may depend less on remembering every function and more on understanding how functions, systems, data, and decisions connect together.
Perhaps that has always been the deeper purpose of learning programming. The syntax was never the destination. It was the vehicle through which we learned how to think.


