Why Students Still Need to Learn Coding When AI Writes the Code
On coding literacy, new assessment formats, and data science education in 2026.
Why This Is a Valid Question
In my programming and data science courses, students now regularly ask why they should still learn to code. ChatGPT, GitHub Copilot, and other AI tools can generate, explain, and correct code within seconds, making the effort of learning syntax seem unnecessary.
The question is valid because practical work with code has changed. A language model can create a data preparation workflow, explain an error message, or add cross-validation to an analysis. It will often produce solutions that would take a beginner considerably longer to develop. Ignoring this progress in education would make little sense.
From my perspective, however, it does not follow that we can dispense with coding fundamentals. What changes is the reason why students need these fundamentals:
Students do not need to learn coding despite the fact that AI can write code. They need to learn coding because AI can write code.
Traditionally, a substantial part of programming education has focused on producing working code independently. This ability remains relevant, but it must be complemented by other skills. Students need to read, understand, adapt, test, and, when necessary, correct AI-generated code. Programming knowledge is therefore becoming an increasingly important prerequisite for exercising professional control over automatically generated solutions.
Working Code Is Not Necessarily Correct Code
AI-generated code often looks convincing. Variable names are understandable, comments appear to match the task, and the program runs without an error message. It is therefore tempting to assume that the analysis itself must also be correct. In data science applications, however, this is not necessarily the case.
Many important errors concern the logic of an analysis rather than its syntax. A join may multiply observations because the keys are not unique. Missing values may inadvertently be imputed using the full dataset before the train-test split, allowing information from the test data to enter the training process. A feature may also contain information about the target that would not yet be available at the time of prediction. The code will run in all three cases, but the resulting model evaluation will be overly optimistic.
Other problems arise when metrics are selected and interpreted. Accuracy alone is often insufficient for a highly imbalanced classification task. A strong correlation, moreover, does not establish a causal relationship. A language model can generate suitable analysis code for these situations, but it does not automatically know how the data were generated or in which organizational context the result will be used.
A small qualitative case study involving five students illustrates this ambiguity. An AI-supported analysis tool helped students engage with statistical questions. At the same time, some students relied on the generated output or lost track of their own analytical process (Rao et al. 2026). The small sample does not support general conclusions about effectiveness. It does, however, show that providing an AI tool does not in itself ensure subject-matter understanding.
There is another important aspect in practice: the language model is not responsible for the consequences of an analysis. Responsibility lies with the people and organizations that process the data, select the models, and use the results for decisions. Anyone using AI-generated code must therefore also be able to determine whether that code is appropriate for the task at hand.
Programming Education Must Change as Well
The continued importance of coding fundamentals does not mean that programming education should remain unchanged. Pure syntax exercises become less relevant when students can consult documentation, existing code examples, and AI assistants outside an examination. It is therefore of limited value to measure learning exclusively by whether a particular function can be reproduced from memory without assistance. Denny and colleagues reach a similar conclusion for computing education: code-generating models can solve many typical tasks from introductory programming courses, which requires us to reconsider learning objectives, teaching formats, and assessment (Denny et al. 2024).
Different approaches to generative AI are already being discussed in statistics and data science education. Ellis and Slade describe possible uses for explanations, examples, and feedback, while also emphasizing the need to critically review the output (Ellis and Slade 2023). Bien and Mukherjee used generative AI to produce analysis code in an introductory data science course for MBA students. This allowed the course to focus more strongly on questions about data and the interpretation of results (Bien and Mukherjee 2025). For audiences for whom independent software development is not a primary learning objective, this can be a sensible approach.
For degree programs in data science, statistics, or information systems, however, operating such a tool is not sufficient. Graduates will be expected to develop existing analyses further, review code written by others, identify problems in data, and justify methodological decisions. Programming education should therefore place greater emphasis on these activities.
Coding Literacy
The term coding literacy describes this changing objective quite well. Coding literacy is not limited to the ability to write code independently. It also includes the ability to read code and assess what it does. In particular, this involves being able to:
- explain code in one’s own words,
- understand the role of individual data sources and intermediate results,
- identify assumptions and possible side effects,
- adapt a solution to changed requirements,
- formulate tests and plausibility checks,
- investigate error messages systematically,
- validate results independently, and
- document the use of AI-generated code.
This also changes the typical question asked in a course. It is no longer only a matter of whether students know the syntax of a function. More important is whether they can explain what a section of code does to the data and whether that approach is appropriate for the substantive question.
Assessing a provided solution can be more demanding than implementing a familiar example. To identify an error in a modeling pipeline, students need to understand the program code, the statistical method, and the structure of the data. Coding literacy is therefore not a simplified form of programming education. It extends programming education to include diagnostic and evaluative skills.
Foundations as Control Knowledge
From my perspective, the required foundations should not be understood as a list of individual language constructs. The decisive question is not whether students can reproduce a particular function from memory. The decisive question is whether, in an analysis, they can identify which assumption is being made, which data are affected, and how an error would become visible.
This control knowledge begins with understanding the unit of analysis: What does one row in the dataset represent? Which observations belong to the target population? Which information would actually be available at the time of decision? Many errors in AI-generated code only become visible once these questions have been clarified before the technical implementation.
It is equally important to understand how data change over the course of an analysis. Aggregation changes the level at which a statement is made. Combining several data sources can change the number of cases or unintentionally give more weight to particular groups. The treatment of missing values can be harmless, or it can leak information from later stages of the analysis. Students do not only need to carry out such changes; they need to judge whether these changes fit the substantive question.
For modeling, the logic of evaluation remains central. Automatically generated cross-validation is only useful if it is clear what needs to be separated, which metric fits the question, and which simple comparison should serve as a baseline. Without this knowledge, an AI tool may generate a technically clean workflow, but it cannot guarantee a professionally defensible assessment.
Finally, students need to be able to break an analysis into testable intermediate steps. Anyone adopting a suggestion from an AI assistant should be able to state which parts of the solution were checked, which assumptions remain open, and how data provenance, methodological decisions, and interpretation are documented. In this sense, foundations are not an end in themselves. They are the prerequisite for using automated analyses responsibly.
More Automation Requires a Better Overview
Automation in data science is not limited to generating individual sections of code. AutoML systems already handle parts of data preparation, model selection, and optimization. AI agents can connect several stages of an analysis and invoke different tools independently. This makes it easier to produce a complete analysis for a given task.
The substantive decisions do not disappear. Someone still has to define the target, determine which data may be used, and select the metric by which a model will be evaluated. It is also necessary to check whether a simple baseline is available and whether a more complex model delivers a relevant improvement. These questions cannot be answered by technical execution alone.
As automation increases, understanding the entire analytical process therefore becomes more important. Students should not only know individual functions, but should also understand how data preparation, modeling, evaluation, and interpretation are connected. Only then can they determine where an error occurred in an automated analysis.
AI Is Becoming Part of the Data Science Environment
This development can now be observed directly in the tools used for data analysis. AI support is no longer limited to a general-purpose chat application running alongside the development environment. AI is increasingly being integrated into the environments in which data are loaded, transformed, visualized, modeled, and documented. This gives it more context and allows it to generate more relevant suggestions. At the same time, its use becomes harder to separate from the analysis itself.
These tools can also be understood as agentic, that is, action-capable, data science environments. Similar to specialized coding agents in software development, they do not merely answer a question. They can inspect context, propose changes, invoke tools, and coordinate several steps. In data science, however, the relevant context is broader. It is not only program files that matter, but also data, intermediate results, visualizations, model objects, and evaluation metrics.
Code and Notebook Environments
One form is code- and notebook-centered environments. In Positron, Posit Assistant can use not only open files and selected code, but also information from the interactive session, including loaded data, generated plots, and console history (Posit Software, PBC 2026). A question can therefore refer directly to the current analysis. This is particularly relevant for education because the assistant no longer answers only an isolated programming question; it can take the state of an active data analysis into account.
Jupyter AI takes a more open and configurable approach. The project connects AI agents to notebooks in JupyterLab. Depending on their configuration, these agents can read and write files, run commands, and interact with notebooks (Project Jupyter 2026). Conversations are stored as files in the relevant workspace. This supports transparent documentation, but it also raises questions about which models are connected, which data are transmitted to them, and which actions an agent is allowed to perform.
Support extends even further in integrated data platforms. Databricks Assistant can generate, explain, and debug code in notebooks and editors. An additional Data Science Agent is designed to coordinate multi-step workflows from a single task description (Databricks 2026). Assistance is thus moving from individual code suggestions toward the execution of larger parts of an analytical process.
Visual Workflows
A second form is visual low-code and no-code environments. Systems such as KNIME, Orange, and commercial analytics platforms represent data science processes as workflows. Generative AI fits this setting not because language models are particularly good at operating graphical interfaces. The more interesting case arises when the visual tool has its own formal representation of the workflow. In that case, an AI system can generate nodes, connections, comments, or configurations from a task description. KNIME, for example, describes a build mode for its AI Assistant in which a prompt can be used to add nodes and related comments to the workflow canvas (KNIME 2026).
This creates an intermediate layer between a chat response and program code. The prompt provides an entry point, while the visual process makes the proposed steps visible. Students can execute individual nodes, inspect intermediate results, and discuss the analytical sequence. Especially for learners with limited programming experience, this can lower the barrier to data science. Recent work on web-based visual analytics environments also emphasizes this lower entry barrier and the possibility of embedding interactive workflows in learning contexts (Bevec et al. 2026).
The risks are similar across both classes of tools, and agentic capabilities tend to increase them rather than reduce them. An automatically generated section of code can look plausible. An automatically generated workflow can be just as convincing because it appears ordered, commented, and complete. If a system also coordinates several steps on its own, an early error can propagate through the entire analysis without being noticed. A misplaced filter, an inappropriate aggregation, or a problematic evaluation can occur in a visual workflow just as it can in a script. In complex workflows, the black box is no longer the code, but the interaction of many nodes and automatically executed decisions.
For teaching, this leads to a shared conclusion. Students should learn more than how to formulate a prompt. They must also understand which context an assistant uses, where data are transmitted, which changes it has made, which steps were executed automatically, and how central results can be checked independently. Prompt-based workflows, AI-generated code, and agentically produced analysis steps should therefore be treated as testable hypotheses. The specific interfaces may change quickly; these control questions will remain relevant.
A Possible Teaching Model
From my perspective, a course can address these developments in three phases.
A Foundation Phase with Limited AI Use
In the first phase, students work through central analytical processes largely on their own. This phase does not have to be very long. It should, however, ensure that students develop their own understanding of how data are generated, changed, checked, and evaluated in an analysis. Code should not be perceived merely as a sequence of plausible-looking text fragments.
Limited AI use does not mean that no support tools may be used. Documentation, help pages, and existing examples are part of programming. Temporarily limiting generative AI is intended only to ensure that the basic structures are first understood independently.
AI-Supported Work
In the second phase, generative AI can be used deliberately. Students might ask it to create a function or explain an existing section of code. They must then test the proposed solution, adapt it to changed data, and justify the individual steps. This also provides a useful opportunity to demonstrate that a plausible AI response is not always correct.
For example, an assignment might provide working code in which imputation is performed before the train-test split. Students would be asked to identify, explain, and correct the problem. Another assignment might ask them to adapt a generated visualization to a changed question. The focus therefore moves beyond code generation toward reviewing and developing code further.
Projects with Documented AI Use
In a final project phase, the use of generative AI can generally be permitted. Assessment then focuses on understanding the problem, the quality of data preparation, model selection, evaluation, reproducibility, and communication of results. Students also document where they used AI, which suggestions they accepted or rejected, and how they checked the central results.
Writing the project report is itself part of the subject-matter work. DeLuca and colleagues compared texts produced by language models with texts written by students and published researchers. They found differences in how information was structured, how levels of certainty were expressed, and how statistical results were reported (DeLuca et al. 2025). A polished AI-generated text is therefore not automatically a good analytical report. Students should demonstrate that they can interpret results appropriately and communicate the uncertainty and limitations of an analysis.
Suitable Assessment Formats
If generative AI is part of the normal working environment, assessment should focus more strongly on whether students can understand and evaluate code. Suitable tasks include:
- explaining AI-generated code and identifying its assumptions,
- investigating and correcting code that runs but is flawed,
- adapting an existing solution to a changed question,
- identifying data leakage in a modeling pipeline,
- assessing whether the selected model metrics are appropriate,
- comparing a simple baseline with a more complex model,
- reviewing an automatically generated workflow or agent trace and justifying the central decisions,
- documenting and reflecting on the use of an AI tool,
- justifying decisions in a short oral code review, or
- producing a reproducible analytical report that documents data provenance, assumptions, uncertainty, and limitations.
Such tasks do not automatically prevent every unauthorized use of AI. They do, however, assess more directly the skills that students will need in practice. The decisive question is not only whether a working program is produced, but whether students can explain how it works and assess the quality of its results.
Conclusion
Generative AI does not make learning coding fundamentals obsolete. It does, however, change the emphasis of programming education. Manually producing standard code becomes less important, while code comprehension, error diagnosis, validation, and documentation become more important.
For data science education, this means placing less emphasis on memorizing individual elements of syntax. At the same time, students still need a solid technical and methodological foundation. Only with this foundation can they determine whether automatically generated code is appropriate for the task, the data, and the eventual application context.
AI can accelerate many stages of an analysis. Increasingly, this is not only about AI producing individual lines of code, but about AI preparing, executing, or coordinating parts of the analytical process. Responsibility for the professional correctness of that analysis, however, remains with the people who create and use it. This is exactly why students still need to learn coding even when an increasing share of both code and analysis steps is generated by AI.